Contents tagged “JavaScript”

There are 22 contents with this tag:

screenshot of The (extremely) loud minority

Andy Bell avatar Andy Bell wrote

The (extremely) loud minority

Always remember that although a subset of the JavaScript community can be very loud, they represent a paltry portion of the web as a whole. This means that when they say something like “CSS sucks”—what they mean is “CSS sucks for a small subset of less than 1 percent of the web”

screenshot of The Cost of Javascript Frameworks

Tim Kadlec avatar Tim Kadlec wrote

The Cost of Javascript Frameworks

In an ideal world, I believe a framework should go beyond developer experience value and provide concrete value for the people using our sites. Performance is just one part of that—accessibility and security both come to mind as well—but it’s an essential part.

screenshot of Second-guessing the modern web

Tom MacWright avatar Tom MacWright wrote

Second-guessing the modern web

[…] 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.

screenshot of Hydration

Jeremy Keith avatar Jeremy Keith wrote


The layered approach of progressive enhancement echoes the separation of concerns in the front-end stack: HTML, CSS, and JavaScript—each layer expressing more power. But while these concepts are related, they’re not interchangable. Separating out the layers of your tech stack isn’t necessarily progressive enhancement. If you have some HTML that relies on JavaScript to be useful, then there’s no benefit in separating that HTML into a separate payload. The HTML that you initially send down the wire needs to be functional (at least at a basic level) before the JavaScript arrives.

screenshot of The importance of elegance

Johan Halse avatar Johan Halse wrote

The importance of elegance

If code is explicit and testable but hard to read and follow, then we’ve lost our most important property along the way. Code is first and foremost designed to be read by humans, not computers. Turning source code into CPU instructions is the compiler’s job, not mine […]

screenshot of When should you be using Web Workers?

Surma avatar Surma wrote

When should you be using Web Workers?

Surma explains very well how “low-end phones will mostly likely be used by the massive number of people coming online in the next couple of years“, and why we need to take that into account when we design our frontend Web architectures.

screenshot of Front-end Developer Handbook 2019

Cody Lindley avatar Cody Lindley wrote

Front-end Developer Handbook 2019

If you want to grok the great diversity of topics and technologies involved in Front-end Web development, here is probably the most comprehensive source you can find nowadays.

screenshot of What if?

Harry Roberts avatar Harry Roberts wrote

What if?

If you’re going to build an image loader that hides the whole page until all images are ready, you must also ask yourself what if the images don’t arrive?

screenshot of Metrics from 1M Sites

Steve Souders avatar Steve Souders wrote

Metrics from 1M Sites

What catches my eye are the gaps between TTFB and the paint metrics, and between the paint metrics and First CPU Idle. These gaps are caused by JavaScript dominating the browser main thread. This happens after TTFB when all the blocking scripts are executed – these have to finish before any rendering can happen.

JavaScript universel et architecture isomorphe

On parle depuis quelque temps de « JavaScript isomorphe » pour décrire des architectures Web dans lesquelles on abandonne les principes historiques des Single Page Applications composées de coquilles HTML vides et moult JavaScript pour les remplir. Le JavaScript isomorphe a plutôt comme principe de produire des pages HTML pleinement fonctionnelles dès la sortie du serveur, mais chargeant elles aussi moult JavaScript pour prendre le relai —si possible— afin d'améliorer l'expérience utilisateur. Je propose que l'on parle d'« architecture isomorphe », une implémentation possible étant en « JavaScript universel ».

See all tags.