I am a huge fan of modern web development, though I would describe it as “magical” — and magic has its upsides and downsides:
- When you understand how to use the magical tools of web development (babel! bundlers! watchers! etc!), your development workflow is speedy, powerful, and delightful
- If you don’t understand the magical tools of web development, it’s terribly confusing
- … and trying to learn how the magic works is all-too-often miserable, unless you have someone to help guide you through the tangle of jargon, hot takes, and outdated information on the web
Recently I have been needing to explain “modern web development workflows” to folks who only have a cursory of vanilla web development workflows and......
It is a LOT to explain!
Even a hasty explanation ends up being pretty long.
So in the effort of writing more of my explanations down, here is the beginning of a long yet hasty explanation of the evolution of web development:
Part 1: How we got from static websites to babel
Simplest website: Static website
Let's start from “classic” frontend web development, which I’m going to assume you-the-reader already understand.
The development workflow looks like this:
- Save the file in your text editor.
- Open and reload file in the browser.
With a service like Netlify, you can just drag-and-drop the folder containing your files to publish the page to the web.
Here's an example of the published page: https://sleepy-lichterman-6811cc.netlify.com/
That's so simple! Why did we make things complicated?!
So if you understand how the “classic” web development workflow works, you might ask: Gee, that’s really simple and convenient. Why did we ever deviate from that?! Why are modern web development flows so complicated?
The short answer: ...Ok maybe I have two short answers.
Two short answers:
- You don't have to make it more complicated. The classic web development workflow is great! And is perfectly sufficient for plenty of needs! You should never add superfluous tooling, or tools whose purpose you don't understand.
- But for certain projects you’ll benefit from a more sophisticated workflow. Every tool that you add to your workflow is meant to solve a problem.
In order to understand the tooling for modern web development, we have to understand the problems of web development.
In this long-but-hasty journey, we’ll address each problem individually, starting with an old web dev problem that has existed for decades:.
To name a few of these limitations:
- No modules
- No constants
- No Promises / async
- No Array.includes() (!!)
- Clunky syntax / missing for a lot of common primitives (no for-of, template literals, arrow function syntax, template unpacking…)
- (Web APIs) Countless DOM operations were needlessly complex (like adding/removing class names, hiding elements, selecting elements, removing elements…)
- Web APIs: document and every method on document; window and every method on window; Event, XMLHttpRequest, fetch, etc.
An old solution: jQuery & friends
jQuery includes APIs that help dramatically with common web tasks, like DOM manipulations, async processing, cross-browser discrepancies and resource-fetching.
A lot of time has passed since 2006, though!
… sort of!
A new-old problem: Cross-browser support
However, there’s a delay between:
- When the browsers have all implemented and shipped support for that feature
- When users have all upgraded to the latest version of their browser, usually via auto-updating/restarting your browser (and this sometimes doesn’t happen!).
This specific dilemma is commonly solved by Babel.
Aside: Babel doesn’t include Web APIs
So you’ll need a separate solution for polyfilling Web APIs! But we’ll get to that in a later post.
* * *
Back to workflows: Static website + babel
OK, so we’ve now motivated why one might want to use babel. What does a web development workflow with babel look like?
The following is the simplest babel workflow, which people don’t usually use. (That’s because a bundler like Parcel or webpack is more convenient, but we’ll get there another next time!)
- Install* babel
(*You can follow the CLI instructions here, though it assumes you understand how npm works. And they recommends that you install babel locally as an npm dev dependency for each project, vs globally on your machine.)
- Develop your site like a normal static web page.
Instead, you want to:
(*hopefully! Sometimes there are differences in Debug vs Release builds, but those are bugs!)
Pause to point out: Development vs Release code!
Notice that we now have a separation between “development” code and “release” code:
- Development code: The code that you write while developing your web app.
- Release code: The code that you want to run when users visit your web app.
We purposely want to keep these things separate, because:
- The development code is good for developers, but bad for users
- The release code is good for users, but bad for developers
In frontend web development, not everyone will uses or needs to use babel.
However! The general pattern of:
- Writing development code that does not get shown to users
- and is instead compiled into different release code, that should be shown to users
…is not just common, but is often expected in modern frontend web development.
(Note that having a separate “Debug” vs “Release” build is a general pattern in software engineering, not something new with web development. But it’s especially pertinent to frontend web development, both because of how commonplace it is, and because of how big the difference can be between Debug/Release for frontend web development in particular.)
A short list of frontend technologies that expect this separation between debug and release:
- npm modules
- Any CSS preprocessor
- React/Vue/Angular/any web framework
This is going to be a recurring pattern, so make note of it now!