Tags: transpiling

htmx ~ Why htmx Does Not Have a Build Step

The best reason to write a library in plain JavaScript is that it lasts forever. This is arguably JavaScript’s single most underrated feature. While I’m sure there are some corner cases, JavaScript from 1999 that ran in Netscape Navigator will run unaltered, alongside modern code, in Google Chrome downloaded yesterday. That is true for very few programming environments.

And yet:

Of course, most people’s experience with JavaScript is that it ages like milk. Reopen a node repository after 3 months and you’ll find that your project is mired in a flurry of security warnings, backwards-incompatible library “upgrades,” and a frontend framework whose cultural peak was the exact moment you started the project and is now widely considered tech debt.

How I Build JavaScript Apps In 2021

Sensible:

• I avoid build processes.
• I avoid transpiling.
• I avoid the new and shiny.
• I test EvErYtHiNg.
• I optimize for performance and quality.
• I use my own work.
• I use open source to my advantage.

Deploying ES2015+ Code in Production Today — Philip Walton

The reality is transpiling and including polyfills is quickly becoming the new norm. What’s unfortunate is this means billions of users are getting trillions of bytes sent over the wire unnecessarily to browsers that would have been perfectly capable of running the untranspiled code natively.

Phil has a solution: serve up your modern JavaScript using script type="module" and put your transpiled fallback in script nomodule.

Most developers think of <script type="module"> as way to load ES modules (and of course this is true), but <script type="module"> also has a more immediate and practical use-case—loading regular JavaScript files with ES2015+ features and knowing the browser can handle it!

Frameworks without the framework: why didn’t we think of this sooner? • Svelte

Interesting ideas around front-end frameworks:

The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that’s not really true. At best, frameworks move the complexity around, away from code that you had to write and into code you didn’t.

Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your concepts. Frameworks are primarily a tool for structuring your thoughts, not your code.

The proposed alternative here is to transpile from the idiom of the framework into vanilla JavaScript as part of the build process, which should result in better performance and interoperability.