The Aurelia Experiment (Part 1)

Liveblogging web development on Aurelia

Introduction

About a year ago, I started to explore a new font-end web development framework called Aurelia. Having worked with Angular 1 for a while, I was immediately impressed by the simplicity and elegance of the sample applications built on Aurelia. When I started using the framework and following its development, Aurelia was still in alpha phase. After using it in several projects and seeing the framework progress to beta in November 2015, then release candidate in June and 1.0 release in July (see the pattern with the blog titles?), I now feel quite comfortable choosing Aurelia for new projects.

Writing about my experiences with Aurelia has been my intent for quite a while now, but I wasn’t sure if my struggles in the past would be relevant to other Aurelia developers that could now enjoy the much more polished release version of the framework. I have also been looking for a new project to start, where I could boost my Aurelia skills and try out some of the other new technologies that have caught my interest. After some (not much) thinking, I decided to combine these goals and write about Aurelia development. Not based on my past experiences, but while actually building my project. I will start from the very beginning, until however long I can stick with both the writing and the coding.

So this is my live (in a very broad sense of the word) blog about developing a new web application using Aurelia. In the first part I will make and explain my initial technology decisions. The following parts will concentrate more on the actual development, from setting up and writing the code to testing and deploying the application.

Technology Decisions

Front-End

The front-end JavaScript framework is of course Aurelia. There are couple of front-end frameworks that have shown potential within the past year. I’m not going to go into details about the differences between them as you can easily find articles comparing Aurelia to Angular 2 and React, or just sit back and let Rob Eisenberg show you. However I do need to justify my choice, so here is why I think Aurelia is a good choice.

The code in an application built on Aurelia is clean, with minimal references to the framework. For example, you can write a component that uses dependency injection, two-way databinding and value converters with only one imported decorator and an extra .bind in your attribute names. This will make the code easier to read and understand, and simpler and quicker to write. It will also help with maintaining the application by reducing the amount of code that is dependent on the framework.

Aurelia aims to be standards compliant (including emerging specifications such as the web components family), and the importance of standards is clear when following the development of the framework core modules. There are multiple advantages for building your application this way, even with incomplete support of such standards in current browsers:

• You will quickly notice that a big part of learning Aurelia is learning standards like EcmaScript 2015 and Shadow DOM. This will be beneficial regardless of the framework you end up working with.
• Browsers will eventually support the new standards. Your application will be ready for these future browsers, fully utilizing the potential of their native features.
• The code that relies on standards rather than framework-specific structures is more maintainable and can be ported to other frameworks or platforms with less effort.

Other front-end technology choices are mainly based on my personal experience. I will use Bootstrap as the UI framework with SASS for pre-processing css. This doesn’t really affect the development process, so I imagine it’s not a problem to change these to any other tool that does the same job.

Back-End

The server side of things will most likely be built on ASP.Net Core. C# is possibly my favourite language to code, and I like most of the things the ASP.Net team has done with their new open source incarnation of the framework. But I will not rule out some small services where I could try server-side JavaScript on Node.js. However, the focus of the writing will be on Client-side and Aurelia.

Tooling

With the rapid development of JavaScript and the EcmaScript standard, the demand for tooling in web development has increased significantly. By transpiling the code, we can use the most recent language features without sacrificing browser support. This is quite easy with Babel, but I have tasted statically typed JavaScript and I can’t go back, so my choice is Typescript. The recent release of TypeScript 2.0 has a number of cool new features that make type checking more reliable and intellisense more powerful, although we will still have to wait for async/await (unless you target only Chrome).

For my client-side package management needs, in earlier projects I have mostly used JSPM and quickly tried Webpack. This time I will be relying on Aurelia CLI. It promises to handle bundling, module loading, running unit tests and it even spins up a lightweight server to ease up development. Until now my only experience with the CLI is a quick test run, and the package is still in alpha phase, so I’m prepared for some difficulties on the way.

That wraps up the technology choices for the project, at least for now. I have intentionally left out many of the smaller details and choices that could easily change later. The ones above are those that I’ll be most likely to stick with, so if you are interested in any of them, you might want to follow up the updates. They will definitely be more practical with examples, code snippets and pretty pictures.

What Next?

Once the key technologies are more or less decided, I can start with building a template application to prototype the technology stack. In Part 2, I will get something to transfer from client to server to database and back. Hopefully I can also build up the tooling pipeline to get code committed to a repository, bundled up and deployed to somewhere cloudy.