This is the first in a series of blog posts which I am using to document and demonstrate the development of a real-world Aurelia web application. In this post I will describe the benefits of Aurelia and then I will talk what the app is and does and what technology stack I will use to develop it.
Because it’s fantastic. It’s easy to learn and easy to be productive with. Here are some of the things that I really like about it in no particular order:
- It has everything you need built-in. This means that you don’t have to have any dependencies on third-party libraries. HTTP client (AJAX), routing and navigation, data validation, dependency injection, i18n support and much more all already there for you.
- It’s the framework that gets out of your way. There’s very little code that you have to write that the framework needs to be able to do its job. This means that you can focus on your application logic and your code is much cleaner and easier to maintain.
- 2-way data binding. This means that your UI and your application state are always kept in sync and you don’t have to write any special code or use any third-party libraries to update your application state with user input.
There are a few other benefits about it that aren’t necessarily important to me but are worth mentioning here:
- It will feel very familiar to developers who have worked on XAML applications and especially those who have used any of the MVVM app frameworks like Caliburn.Micro or MVVM Light.
It is an official commercial product with available enterprise support. Many corporate development shops disallow the use of open source code because it isn’t commercially backed and supported.
- It is highly extensible. Don’t like a particular convention? Override it! Don’t like its template syntax? Override it! You get the idea.
- It is highly modular. Just because it has everything you need built in, doesn’t mean you have to use everything. Want to use its dependency injection system in your Node app? No problem. You can use just the DI module if you want. Don’t need to use routing or data validation in your web app? Easy. Just exclude them from your application and the code will never get sent down to the browser. This way you can make your web apps super lean.
A note on 2-way data binding. There seems to be a trend away from 2-way data binding in some modern frameworks and app-development patterns. There are good arguments for and against it. The architects of Aurelia decided that 2-way data binding is the way to go and have implemented it smartly and efficiently. It works very well and you never need to think about it. That being said, if you really like the idea of one-way data flow or immutable objects it is very easy to implement those types of patterns in your Aurelia app and still be able to take advantage of all the other great things it has to offer.
I love m&m’s candy. They’re delicious. Plain and peanut usually but the others are great too. I also love numbers and stats and counting things. Do you see where I am heading with this? For years, I have kept a spreadsheet where I log a bag of the delicious candy. Each log entry is the count of each color of candy. The spreadsheet calculates a bunch of stats and totals.
So the app I am going to create in this series of blog posts is going to replace that spreadsheet. Here are the basic requirements of version 1.0:
- Be able to enter the counts of each of the colors in a bag of m&m’s.
- Be able to chose which type of m&m’s the bag is: plain, peanut, crunchy, etc.
- Calculate/display basic stats based on those counts:
- Total in a bag (all and by color)
- Total of every bag entered (all and by color)
- Distribution of colors by percentage for a bag
- Distribution of colors by percentage for all bags
- Show the color distributions in a chart of some kind like a pie or stacked-bar
- Be able to log in. Each bag of candy should be tied to a user so that the above stats can be calculated by user and globally.
- I only care about the bags with the traditional colors: red, green, blue, brown, orange, yellow.
- Data storage will include basic audit data: who and when.
Obviously there’s much more that I can add but this covers all the functionality I get out of my spreadsheet.
The web client will obviously be built on Aurelia since this whole series is about building web apps with Aurelia. The rest of the tech doesn’t really matter but here’s what I am going to use: Client code will be written in TypeScript. The server-side will be an ASP.Net Core application with C#. SQL Server for data storage. The whole thing will be hosted on Azure and I am going to use Visual Studio 2017 for development. I don’t really want to deal with auth and user profiles or anything like that so I am going to use Auth0 for that.
Up Next: Setting up the development environment.