Developing Web Components

Chapter 17. Packaging and Publishing

Jarrod Overson

Build processes in JavaScript are a subject of common debate. On the one hand, there is a beautifully romantic simplicity in being able to author code that gets delivered directly to an end user and runs without modification. There are people who optimize for that simplicity, using it as a creative constraint to encourage simple and clever programming. On the other hand, authored code and delivered code exist in different environments and are read by different machines. On the client side, the user’s machines parses the code and runs it to deliver the end user experience. On the development side, the machine is you, and you parse code in a very different way than an executable interpreter. Good development practice may actually result in very poorly optimized code when it comes to delivery and parsing.

When acknowledging those differences, an intermediary process that translates the code from one environment to the deployable artifact for the other seems like an obvious necessity and something that one should optimize for from the start.

The important aspects to consider when determining the extent of a build process are the same as for anything else: what is the cost and value of one choice versus another? It’s impossible for anyone to tell you what you should do in your particular situation, so it’s important to test it yourself.

Oftentimes one of the biggest red flags in browser code is the number of requests being made, and ...