I’m from a background in ASP.NET. Like me, anyone from a .NET background is familiar with what some may now call a failed experiment from Microsoft: WebForms. It was a cold January day in 2002 when Microsoft introduced WebForms to the .NET community. This was a time where Vb6, Distributed COM, C++ were still a common choice toolset amongst developers. Now, when you can stop cringing for long enough to read on, WebForms was a great idea at the time. If you’re not familiar with it, the Visual Studio IDE had a drag-drop interface where you could drop UI widgets like Data-Grids on the form, click a few options to connect it to a SQLServer database, hit F5, and Boom! Fully functional CRUD web-app. This was a technology designed to bring Visual Basic developers writing windows forms applications to the Web, by making the learning curve as simple as possible (ie making the experience exactly the same as developing Windows forms applications).
Then down the line you want a designer to make some change , you go and inspect that page source only to be greeted with something like this:
You don’t have to understand that code to see that it’s a dog’s breakfast. It’s going to cause issues like performance (huge page bloat), and difficulties in bringing people like designers on the team to make changes. The motivation was good, but with the benefit of hindsight, the implementation was wrong.
So, now whenever I hear of a development environment enhancement that will save developers time getting started, and shield them from the need to learn the nitty gritty aspects of a technology, I approach said technology with a healthy dose of scepticism. I had this mindset approaching the Aurelia-CLI. But I’ve also learned over time not to diss it before I’ve tried it. So I decided to spend some time with the CLI to see what it’s like to use in practice.
The first thing that I noticed about the Aurelia-CLI is that it aims to solve a different problem than the WebForms example from above. It doesn’t try to write your application for you, but instead solves the a problem that many new developers have when getting started with any of the newer SPA Frameworks: The Front end Build Pipeline.
When I was initially learning Aurelia I was overwhelmed by the sheer concept count required just to get hello world up and running, but that concept count wasn’t in actually building the applications, it was in setting up the dependencies, and the Shell of the application.
You can install the Aurelia CLI with this command:
npm install aurelia-cli -g
Once you’ve got it installed you can spin up a new application by running this command and then stepping through the prompts:
What this really does for you:
- Installs all of your NPM dependencies.
- Provides a set of pre-baked Gulp tasks that the Aurelia CLI can run for you in order to things like build and run the app.
- Sets up an initial set of application bundles that make sense, so that you can continue by amending this list rather than trying to learn the structure from scratch.
- Puts in place an initial directory structure for you.
- Creates your index.html, app.js model, and app.html view so that when you run the project you’re starting from a known working state that you can then experiment with.
Sets up the RequireJS module loader.
The common thread between all of the items I’ve listed is that they are done rarely.
These tasks are only completed at the start of a project, which has two implications:
- If you were doing this manually you’d be doing it so rarely that you’d most likely forget and need to look at the documentation again next time anyway.
- You may have somebody in your team that can specialize in these aspects so that the entire team doesn’t need to get bogged down in them.
What the Aurelia-CLI really does is take you down the happy path for getting started with an Aurelia application, by giving you a project structure and build-pipeline designed by people who actually know what on earth they’re doing with this stuff.
Yes, I agree this stuff is not rocket science, and it’s definitely helpful to know how all of it works under the hood. I would even recommend setting a few projects up from scratch as a learning exercise so when you inevitably need to modify the build pipeline or bundle configuration you are not completely lost. But these tools and techniques are also not core to your application. In the same way that we are happy to let the garbage collector deal with memory management for us, perhaps we can lean on the CLI for the same reasons. They let us get on with the important work of building our actual applications rather than Yak Shaving.
I’ve found the experience working with the CLI to be surprisingly pleasant. The project structure and build pipeline are clean, and probably better than what I would have come up with on my own anyway. This is not Web-Forms, the problem that it is solving is one that is useful to solve, and it’s been implemented in the right way.
If you’re interested in getting started with the Aurelia CLI there is a great guide available in the Aurelia docs Hub.