This is a very controversial article for front end developers.

This is a very controversial article for front end developers. If you are an advocate of single page applications (SPAs) it should make you challenge your assumptions.

Even though this piece advocates for a particular backend framework, the front-end JavaScript toolkits that are talked about will work with any backend.

Client-server architectures are like a pendulum swinging back and forth with more emphasis given to one than the other according to the fashion cycle. Web architectures are no different and right now we are approaching peak SPA. Expect arguments like the ones in this article to get louder in coming years.

These days you should be shipping two sets of bundles with your webapp.

These days you should be shipping two sets of bundles with your webapp. One which targets IE11 and the other that targets JavaScript.

http://main.mjs

http://fallback.js

Browsers that understand type=”module” ignore scripts with a nomodule attribute. This means you can serve a module-based payload to module-supporting browsers while providing a fallback to other browsers. The ability to make this distinction is amazing, if only for performance! Think about it: only modern browsers support modules. If a browser understands your module code, it also supports features that were around before modules, such as arrow functions or async-await. You don’t have to transpile those features in your module bundle anymore! You can serve smaller and largely untranspiled module-based payloads to modern browsers. Only legacy browsers get the nomodule payload.