By: Phillip Sharpless
Website Deployment Back in the Day
Deploying a website was once upon a time a rather straightforward process. You simply copied or uploaded all your site’s various core files (HTML, JavaScript, etc.) and any assets they might utilize (CSS, images, fonts, etc.) to the web server hosting your site, and that was that. In fact, many websites to this day are likely still deployed in this manner. For simple websites, this deployment model still works fine. But with this simplicity comes some tradeoffs and potentially serious headaches for more complex sites.
As web development matured, it became more likely that your site was more of a web application, containing numerous JavaScript files and also likely referencing various outside libraries or frameworks. A modern web app can quickly become a maze of implied dependencies amongst the various components. You are required to import all your individual JavaScript files into your pages in a very specific order to ensure everything is in place before it is referenced. This is not only tedious to maintain, but also prone to error. It also can result in a bloat of objects to the global namespace, leading to potential name collisions.
Several solutions have arisen over the years to tackle these issues. Rather than JavaScript files being thought of as just raw source code to be dumped somewhere into your project, instead the idea was to organize functionality into constructs known as “modules”. These modules would be self-contained, reusable, and more explicitly express dependencies amongst each other. Several unofficial specifications arose for declaring and utilizing module functionality within JavaScript, such as AMD (Asynchronous Module Definition) supported by RequireJS or the CommonJS standard, supported by NodeJS.
More recently though, module support has been officially brought into the ECMAScript standard as of ES2015 (ES6) (see ES6 Module Reference). Given that the ES6 module syntax is an official part of the language specification and natively supported by modern browsers, it is now widely considered the preferred way of handling module functionality.
A Great Tool for Managing JavaScript Modules: Webpack
Many utilities exist for managing JavaScript modules and one such that has gained a great deal of attention over the past few years is webpack. Webpack is an extremely robust and highly configurable module bundler. The signature feature of webpack is its ability to build a dependency graph of the various components of your application and then bundle those assets together for deployment.
Another great feature is that webpack can handle dependencies of many types of different files beyond that of just JavaScript. It can also bundle the required CSS and static assets like images and fonts. This feature has two benefits: it can prevent the deployment of unused assets, and more importantly, it ensures that all required assets are present. This eliminates the possibility of deploying a website but somehow missing a file or two, leading to hard to find runtime errors lurking in the project. Another useful feature of webpack is its ability to auto-generate unique names for your built output, which provides you a simple way to do cache busting, ensuring a new version of the web app is fully picked up by all users. Webpack can also serve as a powerful transpiler. When configured to, webpack can transpile higher level assets (ES6 code, TypeScript, LESS, etc.) into the appropriate vanilla version suitable for all browsers.
There are a few minor inconveniences the webpack bundling philosophy introduces, but they pale in comparison to the overall benefits. The only noticeable nuisance is that debugging your bundled source code is no longer as straight forward a process. As your various files are put through potentially several different processes: combination, transpilation, minification, etc. the final output is not one that lends itself to readability or debugging. Fortunately a solution exists for this issue: source map files. You have the ability to generate a source file map during the webpack build process that will allow browsers and IDE’s to translate the transformed code back to its original state. Another consideration is that this bundling model does not lend itself towards partial deployments or small hotfixes. Given the dicey nature of partial deployments to begin with, this restriction could be viewed as a blessing in disguise.
Module bundlers such as webpack provide tremendous potential for facilitating modern, flexible web application development. Building your next web application with these sort of tools in mind is likely to improve its overall quality and provide for much greater maintainability down the line.
Now, a question for you: Have you used Webpack before? And if so, what has your experience been like?
Questions?
Thanks for reading! We hope you found this blog post to be useful. Do let us know if you have any questions or topic ideas related to BI, analytics, the cloud, machine learning, SQL Server, (Star Wars), or anything else of the like that you’d like us to write about. Simply leave us a comment below, and we’ll see what we can do!
Keep your data analytics sharp by subscribing to our mailing list!
Get fresh Key2 content around Business Intelligence, Data Warehousing, Analytics, and more delivered right to your inbox!
Key2 Consulting is a data warehousing and business intelligence company located in Atlanta, Georgia. We create and deliver custom data warehouse solutions, business intelligence solutions, and custom applications.