In October last year the creator of the Ruby on Rails framework David Heinemeier Hansson posted "You can't get faster than No Build". It seems to have been quite a controversial take judging by the reactions online, no doubt in part due to this being on the back of a previous blog he posted about dropping Typescript from Turbo 8.
This way of looking at front end builds really resonates with me, I've always been slightly baffled by the way that Javascript seems to get more and more complex to use as time goes on. I use Javascript a lot and really like working with the language and the browser apis it's perfect for, however for the last 5 years or so I've felt increasingly disconnected from it, this is both down to it trying to move towards the server with server side rendering and the seemingly endless changes to the tooling. I'd pretty much just resigned myself to the idea that as a developer in my 40s maybe this stuff is just too hip for someone like me, so it's been interesting to see this debate appear as maybe there's still hope for me and Javascript in an "npm run" free / #nobuild future.
What is #nobuild
The core idea of no build is quite simple, there's no build step in producing your front end Javascript and CSS for the browser. So apps that currently have complex processes for bundling and transpiling Javascript and CSS can do away with that and replace it with import maps that lean on modern browser capabilities. Thanks to these advances in browsers import maps essentially allow you to reference your js files with an alias that can be imported into other js files directly in the browser, much like you'd do in any node project.
So something like this
<script type="importmap"> { "imports": { "square": "./module/shapes/square.js", "circle": "https://example.com/shapes/circle.js" } } </script>
Allows you to then do this:
import { name as squareName, draw } from "square"; import { name as circleName } from "circle";
I'm guessing that for most applications that heavily rely on React or Vue this kind of approach will never replace the build. But for small apps that don't require a lot of complex Javascript and are currently bogged down with brittle builds this might just be the right time to move to this simpler way to work with Javascript. You'll be able to work on your .js files and then just send them to the server where they'll be served up directly to the browser, you could even view source and see the same JS, imagine that!
I've not looked into this in great detail (as you can probably tell) but I like the sound of simplifying what's become a sea of complexity. It's not that build systems or progress are bad things, it's just that some of us actually have to manage and maintain older projects and those are quite often a nightmare to build even just 3 years after they were initially built. Julia Evans describes the issue very well here and you'll no doubt have encountered this pain if you've ever tried to pull a node build based JS project down from github and work with it a few years after it was last built. Not to dump on Javascript here but if I grab a PHP/Python/C project from github I can have it running very quickly locally and get to work on it, I just can't do that with a complex front end build... why will it not install? why does 'npm run dev' now throw 1000 errors? why has it now not copied the fonts over? why is this library no longer working in the build when it loads in the browser? etc etc etc.
I look forward to seeing #nobuild develop and be adopted in other frameworks. This won't replace builds, but it might hopefully carve out a lighter process that simplifies this all for those of us with applications that use Javascript but don't want to be buried under the technical debt of the build.
Photo by Ferenc Almasi on Unsplash
