Link tags: transpiling
3
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.