Thoughts on browser support of ES6 modules
By now, especially due to modern build and bundling tools, all experienced web developers are familiar with ES6 modules (if you are not then you should totally get yourself informed!).
And in March this year, we were informed of some very exciting news! ES6 module support has come (or, is coming) to browsers! Safari became the pioneer with version 10.1 and landed module support, by adding full ES2016 support (see here and here). Then followed Chrome, Firefox and Edge browsers, announcing the support behind specific flags.
Since then, many blog posts have been written about how one can try them or the technical benefits of their use. There is no special value, thus, for one to go in technical detail about them and rewrite things that others have already covered adequately.
However, as soon as I learned the news, a feeling of excitement struck me. And I would like to express my thoughts, in a philosophical manner, showing that apart from the technical benefits of this feature, there is something even bigger to be cheerful for!
Sweet, let’s cut to the chase
Chances are that you are not going to use native ES6 modules in production. You need minification and you need bundling.
Distributing your web app’s js assets in plain source format and in hundreds of files is not a good idea. File sizes get a lot bigger, not only because the files are not minified, but also because gzip compression in many small files is nowhere as powerful as compression of a few large files.
Furthermore, with bundling we can have dead code elimination via tree shaking (which leads again to less code downloaded). Also, without bundling, the number of requests raises dramatically, which in turn leads to even greater problems and bottlenecks.
So, what’s the fuss all about?
First and foremost, the past years have shown that the open source community is a very energetic organism, managing to progressively tackle difficult problems and find way outs and clever uses even for the most unhelpful situations. So I surely anticipate that this new feature added to browsers will evolve to something great that I can’t even foretell, when forged by the collective cognitive dynamic of thousands of human minds!
Secondly, it is truly encouraging to see browsers striving to offer complete support of the EcmaScript standard. Especially when we reflect on the past and remember the time when browsers offered little (none basically) tools to help the developer debug and grow an application.
It somehow places the developer at the position of a first class citizen, catering for all his/her needs, assisting them in their effort to write maintainable, robust code without obstructions. It induces awe to see and realize how much sophisticated and advanced pieces of software browsers currently are.
But there is far more than that. The specifications often instruct that we delegate complex or difficult algorithms to the browser. Thus we need not worry about such implementation details, and let the teams of wise people developing the browsers pick what is best for us. A good example of this is the `srcset` attribute in responsive images, and how browsers pick on their own the right image asset to show.
An excerpt from A List Apart — Responsive Images in Practice:
How do they choose? Here’s my favorite thing about
srcset: we don’t know! We can’tknow. The picking logic has been left intentionally unspecified.
The first proposed solutions to the responsive image problem attempted to give authors more control. We would be in charge, constructing exhaustive sets of media queries — contingency plans listing every combination of screen size and resolution, with a source custom-tailored for each.
srcsetsaves us from ourselves. Fine-grained control is still available when we need it (more on that later), but most of the time we’re better off handing over the keys and letting the browser decide. Browsers have a wealth of knowledge about a person’s screen, viewport, connection, and preferences.
Still, though, browsers do even more. They also offer development/debugging features that assist the developer, and although not part of any standard, have now become indispensable to any web engineer’s work routine. Think of various stuff like Code Coverage analytics, Network Simulation and Blocking features, Rendering and Paint debugging features, or Workspaces for syncing changes made in DevTools to your project’s files directly! Aren’t they awesome?
OK, you might say, but these features are very high-level ones, more like a luxury at the hands of the engineers. And you are right — but then let’s talk about Inspecting elements in the DOM tree, Code completion in JS console, Descriptive and informative messages in JS errors! Can’t really think of life without them, huh? Don’t stop here, though, think also of the “basic” Network Tab that all browsers’ DevTools offer us nowadays, or the Profiling capabilities we are provided with!
There was a time when everyone could build a browser because all he had to do is render a page successfully. There was a time, when those tools offered today were beyond any web developer’s dream. Surely, client-side code was basic (if any) back then, but still, even a slight error caused by a typo would take too long to debug.
So, a big thank you goes to all the people building/maintaining our favorite browsers. They really do assist us a lot and what they build is some really sophisticated piece of software, requiring high expertise. They are no more just “web browsers”. Kudos!