Build systems for web applications are great: they give dependency management, code minification, and the ability to use tech like SASS or CoffeeScript that require pre-processing.
However, I find actually using build systems to be ugly and annoying… you need to make sure developers have the build tools installed, that the versions they have installed are compatible with your configurations, and that any dependencies of the build tools(SASS compiler, jsmin, etc) are met. Getting a new developer onboarded now requires a suite of tools to be installed on their local system.
We can fight this by using virtualization: a system like Vagrant can allow the setup of developer systems to be codified. There’s a clear series of steps to create a developer environment with all dependencies, or a machine image that’s already set up and can simply be installed and run.
My goal is to make the build system non-intrusive. I would like developers to not even necessarily have to be aware of the build system in order to hack on a project. This might be unrealistic.
With Vagrant, you might accomplish this by having a “watch” service of your build system automatically run and re-build the files whenever they change. That’s good, but what about a local-system developer who doesn’t want to run Vagrant? They have to remember to run a separate process whenever they sit down to develop.
One approach I’ve not seen is to make the application build system aware. It seems to violate a separation of concerns, however with modern web development it seems we are already tightly coupled to our build systems: without running the build script, will you be able to run your web app and see anything meaningful? Will your static assets be in place?
Is there a compelling reason not to have your application look at its build status and rebuild itself when necessary, when in development mode? When running the development server, the application could be build-system aware and build its assets if needed.
This doesn’t get away from the dependency requirements on the developer system. I don’t have a concrete idea of what I’m looking for yet, but I feel like build systems for web apps aren’t quite “worked out” yet. I hope to can have a good brainstorm here.
0
That’s exactly what happens for small projects. LESS or Sass are converted to CSS on the fly by the web application itself, and JavaScript is minified by the web app as well.
This approach for example became the default one with ASP.NET MVC: CSS (or any preprocessor, if you have the required library for it) and JavaScript code is combined into a single CSS and a single JavaScript files and then served; if you change one of the CSS files, you don’t have to recompile: just refresh the page, and the bundle is regenerated automatically.
It’s great for small projects. Change the LESS file. Switch to the browser. Press F5. Get the result. Immediately.
It’s not so great for large projects.
-
First, you don’t get the immediacy you can have with a small project, simply because there are too many files to transform, and it just takes time. It’s not like you have to wait for a few minutes, but even five seconds become quickly annoying if you have to make hundreds of small changes in your stylesheets.
If the task is to make lots of small changes to CSS while getting a nearly-immediate visual feedback, there are better ways to do it than the change-build-refresh workflow. A basic one is to modify CSS directly in browser; any decent browser enables to do that.
-
Then, you’re less concerned about how your new style is appearing in a browser, and more about passing the tests. With thousands of tests to pass, you simply can’t do it locally. You have to dedicate this hard work to a build server, and by server, I mean more a farm of powerful machines capable of running in less than five minutes what would waste days if ran locally.
Imagine you have to change how a piece of information appears on a web app. What’s your primary concern?
-
Change the code.
True. If you need visual feedback, do it in browser, and then reflect the change in the source code.
-
Ensure the new code matches coding conventions.
This is what a pre-commit hook does, so you actually have to either commit your code and wait for the version control server to respond, or do the check locally, which means installing the checkers.
-
Ensure you haven’t introduced regressions.
This is the most important part. You changed the styles, and it works on the particular page you were looking at at the moment of change. But what about thousands of other pages? What if your change broke another page you weren’t even aware of?
Here comes the build server. It will do the
pdiffand show you the visuals of the changes. Hey, watch that! It seems that your change affected a page which is now totally broken. You couldn’t know that when working locally.
For JavaScript, it goes further: one have to unit-test, to run functional tests, to generate the new version of the documentation. All those steps make a build server crucial.
-
-
Also, large projects simply can’t afford doing LESS and CoffeeScript transforms during run time, for two reasons.
The first one is performance. You can’t let an end user wait for five seconds while you rebuild your JavaScript files.
The second one is that it adds complexity, and the sort of complexity which can easily be mitigated by moving it to the build. More complexity means more chance to have bugs and more tests to run.
-
Finally, having two systems (the build which runs tests and the post-build first-run which builds CSS and JavaScript) just looks awkward. Keeping everything in the same place and doing all the hard work on a build server after each commit makes things much easier.
Conclusion
Your idea is great for small-scale projects. It’s already popular in Microsoft community, and I expect that other communities use the same approach as well. It enables the developer to get the nearly-immediate response without having to recompile the app or to install additional components on the machine.
For large-scale projects, on the other hand, the workflow is centered around a build, which is both the heartbeat of the project and the mean to check that the changes are correct and if they are, move them into production. Watching the effect of the changes locally makes no sense, because the most important part—regression testing, takes days on an ordinary desktop machine, and because even transforming CSS and JavaScript takes too long compared to the nearly-immediate response you would expect.