I was asked to do a talk about Single Page Applications and Angular 2 in a couple of weeks. At first I was a little sceptical, because Angular 2 is far from a finished product yet. After agreeing that the main points could be around SPA architecture, TypeScript and how you can build these kinds of applications without using a framework I said yes. So lately I have been working on the talk and the first part has been quite easy to do. Yesterday I got started on demoes, and dived into Angular 2 for real.
Some are more alpha than others
I have in many ways become sceptical about using frameworks lately, especially the short lived kind that we see way to many of as webdevelopers where everything is changeing very rapidly. I am however trying to stay fair, and give new things a chance. That being said I would still be dishonest if I didn't say that yesterday was painful. As alpha versions go, this one has a huge amount of changes to even the most basic parts, so it was hard to come across anything beyond hello world samples that were not already broken. Choosing to call it Angular 2, when it has close to nothing in common with the first generation Angular also makes it a pain to google for samples in the first place.
Its milk, its chocolate, its freakin heavy!
Moving beyond that it feels like an alpha of alphas, I also couldn't shake a few nagging thoughts. In my oppinion Single Page Applications, are really just a few patterns and a bit of commonly used functionality. So how can a framework, argue to be "build for mobile", when just the bare minimum parts are close to a 1 megabyte download? Another thing is that I like tools that let you start very light weight and then build on that based on your needs. It's not horrifying in that sence, but light weight is not any where near the feeling I get for even a hello world angular 2 app. Just take a look at the quickstart lots of yack shaving before you get anywhere.
I declare declarative bankrupsy
After I got going and I had spent some hours playing with the new flavour Angular I got around to thinking about the value of "declarative" code. In my experience declarative is good when it allows you to focus on the big picture, and not worry so much about the how as just specifying the what. This comes to fruition with languages and tools where the domain is well defined, so the pieces that you declare are easily understood. HTML 5 semantic markup is a good example of this, because tags are well and widely understood and the communicate meaning. The same is the case with functional programmine where concepts are well understood, and the implementation details really aren't important in everyday programming. It is however not the case with tags you create as you go along with webframeworks like Angular. When you read a tag eg. <Product> it tells you next to nothing about look, behaviour, semantics or anything really - and it is in no way widely used or understood. This means that to get any real meaning you need to go through templates, metadata and code - which are all expressed in a way that is not aimed at being readable as much as to support the fact that it should revolve around a tag. So although it may be shiny in a quite nerdy kind of way, it is not making the product better or the domain more well understood or readable.
My growing love for TypeScript
For a while I have been writing quite a bit of TypeScript, and I was really happy to see it adopted by the Angular team. The best part about Angular 2, is the clarity that comes from working with ES6 and TypeScript syntax over traditional JavaScript. It is easy to pick up for most developers, and it gives you the flexibility you need to express your domain well. On top of that the static typing and tooling around it catches me doing bad things every day. I learned that in a big way when I got to rewrite some old JavaScript, and I was all the subtle issues that were in the codebase.
Patterns, libraries and languages all the way
I still love me some TypeScript, and I will keep an eye on Angular 2 as it progresses. I do however think that your best bet if you are building a rich JavaScript application is to stick to the wisdom of learning the patterns rather than a framework. Understanding the domain, applying the patterns and using the best language to express the logic is a tried and tested approach. It may not be a silver bullet, but it is still the best we have got.
Subscribe