There is an awful lot of change on the web. Sometimes the languages we use to build for the web change. Some of it comes from browsers themselves changing. An awful lot of it comes from ourselves. We change UIs and not always for the better. We build new tools. We see greener grass and we lust after it and chase it.

Marco Rogers calls some of it a treadmill and has a hot take:

A lot of frontend teams are very convinced that rewriting their frontend will lead to the promised land. And I am the bearer of bad tidings.

If you are building a product that you hope has longevity, your frontend framework is the least interesting technical decision for you to make. And all of the time you spend arguing about it is wasted energy.

Personally I wouldn’t cast as harsh of judgement that rewriting a front end is automatically wasted energy. Revisiting code, whatever the circumstances, can have helpful effects, like the person doing it actually understanding it. But I take the point. The success of a product likely has fairly little to do with the front-end framework at play and change for change sake isn’t exactly an efficient way to achieve success.

The web doesn’t just have fits and spurts of change, it’s ever-changing. It’s just the nature of the teams and processes put around specs and browsers and the whole ecosystem really. The cool part about the web platform evolving is that you don’t have to care immediately. The web, gosh bless it, tends to be forgivingly backwards compatible. So staying on top of change largely means taking advantage of things that are easier to do now or a capability that didn’t exist before.

One take on understanding evolving web features is Baseline, which is Google’s take on essentially a badge that shows you how practical it is to use a feature at a glance. Rachel Andrew’s talk Browser Support and The Rapidly Changing Web gets into this, but sadly I haven’t found a video of it yet. I have some critiques of Baseline (namely that it doesn’t help you know if a feature is usable through progressive enhancement or not) but largely it’s a win.

Sometimes changes in a language cause massive sweeping movement. An example of this is the advent of ESM (ECMAScript Modules), that is, import and export in JavaScript. Seems small — is not small. Particularly because JavaScript also means Node ‘n’ friends, which needed an import mechanism, thus support require() (CJS format) for umpteen years, which is a bit of a different beast. So if you want to support ESM, that’s the future, but it means shipping Node modules in the dual CJS/EMS format, which is annoying work at best. Anthony Fu weighs in here with Move on to ESM-only, a controversial take, but much less so now that Node ships with the ability to require() an ESM file (vice versa would be even more magical).

In some situations, sticking with the old actually does come with some cost. For instance, shipping “old” JavaScript (i.e. ES5) is slower, larger, and requires more compilation work. Philip Walton digs into the data there and has a solid conclusion:

Given the data presented in this article, it definitely does not make sense for JavaScript library authors to be transpiling their code to ES5 anymore.

Best case scenario there is to compile code that looks at your chosen browser support targets, so it can evolve as the world does.

Source link

Views: 0