How to build web pages so they work in HTML first: starting with HTML, extra styles and features, using JavaScript.

Do not build your service as a single-page application (SPA). This is where the loading of pages within your service is handled by JavaScript, rather than the browser.
Single page applications rarely bring benefits and can make the service inaccessible.

A beautiful letter to progressive enhancement.

The only thing React is better at than other front-end frameworks is being popular. So how long will that self-perpetuating cycle continue?

New web services are being built to a self-defeatingly low UX and performance standard, and existing experiences are now pervasively re-developed on unspeakably slow, JS-taxed stacks. At a business level, this is a disaster, raising the question: why are new teams buying into stacks that have failed so often before?

Make use of the requestIdleCallback callback to improve the responsiveness of input while ensuring JS actions during the typing.

Dropdown, navigation button, tooltip, collapsible panel, lightbox, tabs, switch like above…
UI components made in minutes without worried about JavaScript. Only set a few HTML attributes, and code the rest with your CSS skills.

Alpine.js offers you the reactive and declarative nature of big frameworks like Vue or React at a much lower cost.

Stimulus is a JavaScript framework with modest ambitions. It doesn't seek to take over your entire front-end—in fact, it's not concerned with rendering HTML at all. Instead, it's designed to augment your HTML with just enough behavior to make it shine. Stimulus pairs beautifully with Turbolinks to provide a complete solution for fast, compelling applications with a minimal amount of effort.

I recommend the part on how to curb the JS tax (14:48).

A wonderful pen by Vincent Valentin

track and measure the performance of sites that use popular JavaScript frameworks and libraries.

And for what? Again - there is a swath of use cases which would be hard without React and which aren’t complicated enough to push beyond React’s limits. But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are optimizations to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.

The issue with most slow JAMstack sites is that they load a loooot of JavaScript. Remember that any added JavaScript has to be sent to the browser, which will also need more computation for it. It quickly impacts performance.

Good frameworks should provide a better starting point on the essentials (security, accessibility, performance) or have built-in constraints that make it harder to ship something that violates those.

That doesn’t appear to be happening with performance (nor with accessibility, apparently).

It’s become a trend for developers to reach for frameworks on every single project. Some people are of the mindset that separating HTML and JavaScript is obsolete, but this isn’t true. For a simple static website that doesn’t need much user interaction, it’s not worth the trouble. The more enthusiastic React fans might disagree with me here, but if all your JavaScript is doing is creating a non-interactive webpage, you shouldn’t be using JavaScript. JavaScript doesn’t load as fast as regular HTML, so if you’re not getting a significant developer experience or code reliability improvement, it’s doing more harm than good.

This leads to a situation for users that’s almost worse than before. Instead of staring at a blank screen, now they get HTML lickety-split—excellent! But if they try to interact with what’s on screen, they’ll find that nothing is working yet. Even worse, once the JavaScript is delivered, and is being parsed, they probably can’t even scroll—their device is too busy interpreting all that JavaScript. Your users suffer.

Supports de cours JavaScript au format Gitbook, pour étudiants EEMI de 1ère année

Wikipedia reduceds the JS initial payload to fit within a budget of 28 KB. In total, the year-long effort is saving 4.3 Terabytes a day of bandwidth on our users' page views.

Yes, we need to better prioritize our asset delivery, but most importantly, we need to stop delivering so much JavaScript. We need to audit our script inventory, and scrutinize our 3rd party integrations regularly, as many of these packages are abandoned or meant to be short-lived.

Just is a build task definition library. Tasks can be composed, executed in series and in parallel. Logging, command-line arguments, conditionnals, a very simple API…