r/javascript

i had a fight with a dear friend today about JavaScript and the reason was in the difference in how we perceived typescript. both my friend and I love typescript and prefers to use it instead of using javascript directly. but the difference in opinion is this: I love javascript and my friend dislikes javascript!

i see typescript as a plugin/library that allows us to write better JavaScript while my friend doesn't like JavaScript and finds typescript intresting. he sees typescript as a separate language that is an alternative which fixes the issues of JavaScript. our fight began when he said javascript will die because of web assembly and typescript and the JavaScript lover in me got mad. what do you make of our fight ? is the way you perceiving typescript is different than us?

I'd like to try to increase my productivity by adding in AI into my workflow. Since I occasionally code in places with very shitty internet (and also because I don't want to have to trust an AI SaaS), I'd prefer a purely offline solution. To my understanding, there's a couple of OS AI which seem to run decently fast on apple's M# hardware.

Can any of you recommend one of those? How are they integrated - or how are you integrating them - into your tools and JS/CSS/HTML writing workflow?

Thanks in advance for any advice!

I've recently started playing with mjs and the new import stuff. Is this a no-brainer to switch all my stuff to this? I was perfectly happy with require, and know all its quirks, so not eager to make the switch. But increasingly I'm relying on mjs packages, so thinking about just going full throttle on it and mastering mjs/import stuff. thoughts?

I’m curious to learn what technologies, frameworks, libraries, and tools other devs use to manage their repo(s), create complex applications, test them, and build and ship them for both web and mobile.

e.g. TypeScript, React, Next.js, Payload CMS, React Native, Expo, Reanimated, Zustand, NX, Turbo, Tailwind, Shadcn, Cypress, etc.

The common pattern for loading non-blocking scripts (e.g. any analytics or third party widgets) seems to be:

var script = document.createElement('script');
script.async = true;
script.src = 'https://example.com/script.js';
document.getElementsByTagName('head')[0].appendChild(script);

Or similar. There are other exmaples using insertBefore, but you get the gist.

Even as far back as 2014, that these script loaders could just be replaced with:

<script async src="https://example.com/script.js"></script>

In fact, he mentions that this new approach is not only shorter, but reduces load time, because it isn't blocked by the CSSOM.

But even today, Google Tag Manager, Facebook Pixel, and any other snippet I'm asked to embed uses the first approach. Throwing it out to the group: any ideas why?

Is it just that these services are designed to work across all devices, even as far back as IE 8 (that would explain the var), so they're covering their bases. Or do you think that developers are just copying each other? Or is there another reason? Do these scripts need the CSSOM to be ready before they can execute, for example?

The reason for asking: I was asked to add yet another tracking tool to a website, and seeing the same boilerplate code show up again and again just got me thinking about the Ilya Grigorik article.

Updates:

I probably should have used the term "script injection" instead of "script loading"

It turns out using an inline <script async src="..." /> tag.

Also, even though in my Google Tag Manger console, the snippet I'm given uses the script injection method, uses the inline script tag too.

So maybe there's a degree of cargo cultism going on, and it's more than safe to use inline scripts going forward.

Although, obviously, if you want to load a script conditionally, e.g. based on cookies, you have to use the script injection method.

Avoid map data to an intermediate/template data structure when writing, and then map it back when reading.

If there are unavoidable gaps between reading and writing, keep the data structure consistent throughout its lifespan. And ONLY convert it to another data structure when it has to cross the system boundary (e.g., a function, a RESTful API, etc.).

This avoids two costs:

1. We don't need to maintain or understand the redundant data structure until we pass it across the system boundary (maybe an API).

2. It's hard to track the data structure in JavaScript without a type system.

Post a link to a GitHub repo or another code chunk that you would like to have reviewed, and brace yourself for the comments!

Whether you're a junior wanting your code sharpened or a senior interested in giving some feedback and have some time to spare to review someone's code, here's where it's happening.