Posts tagged “javascript”, page 2

Jeremy Keith:

I really like this design pattern. Cover 80% of the use cases with a declarative solution in HTML, but also provide an imperative alternative in JavaScript that gives more power. HTML5 has plenty of examples of this pattern. But I feel like the history of web standards has a few missed opportunities too.

In recent years there’s been a push to expose low-level browser features to developers. They’re inevitably exposed as JavaScript APIs. In most cases, that makes total sense. I can’t really imagine a declarative way of accessing the fetch or cache APIs, for example. But I think we should be careful that it doesn’t become the only way of exposing new browser features. I think that, wherever possible, the design pattern of exposing new features declaratively and imperatively offers the best of the both worlds—ease of use for the simple use cases, and power for the more complex use cases.

Heydon Pickering:

Most of you will be familiar with JavaScript’s fat arrow functions, also known as “chonky darts”.

In ES2019, fat arrow functions are not the only kinds of arrow functions available to you. Let’s take a look at some of the others and what they have to offer.

Brad Frost:

JavaScript is eating the world and the rest of the frontend stack with it. Those server-side languages people used to write in? Node. HTML? JSX. Styling? We do that in JS now too. HTML, CSS, and JavaScript are three sturdy, capable languages that each have their own histories, nuances, and best practices. I do worry that as we author more and more in JS we risk losing those hard-won HTML/CSS best practices. Of course, it’s totally possible to preserve those HTML/CSS best practices even as we write everything in JS, which is why I want to make sure libraries like React are accessible to frontend people like me who don’t come from a JavaScript/programming background.

At the top of Jeremy’s list, other people’s Javascript:

At number one with a bullet, it’s all the crap that someone else tells us to put on our websites. Analytics. Ads. Trackers. Beacons. “It’s just one little script”, they say. And then that one little script calls in another, and another, and another.

It’s so disheartening when you’ve devoted your time and energy into your web font loading strategy, and optimising your images, and unbundling your JavaScript …only to have someone else’s JavaScript just shit all over your nice performance budget.