Alternatives to Angular

Back when Angular, Ember, and React were first gaining popularity and Single-Page Applications(SPAs) were less common, I chose to learn Angular as my SPA framework.

JavaScript functionality is usually something that gets put off to Phase 2 of my projects. As new projects come up before I get a chance to actually get into Phase 2, I end up spending a lot more time on the server side than the client side. That means I didn’t get actually a whole lot of time to devote to Angular. By the time I got comfortable with it, rumors of the dramatic changes coming in Angular 2 had already started circulating. At some point, I decided to jump in and give it a try. I felt like the concepts were smart and interesting, but I never quite got comfortable with the environment as a whole.

I had heard that Ember was switching to an environment that encouraged a completely separate project for the frontend up, so I thought Angular doing the same thing made of lot sense. In my smaller projects, I felt like this was a bit of overkill. I spent a lot of time trying to perfect the git and deployment workflows, but never quite ended up with something that was particularly convenient.

When Angular announced that it was going to be written in TypeScript, I started learning that as an alternative to CoffeeScript, which was more popular in the Ruby community. CoffeeScript already  provided a lot of features that ES6 and TypeScript implemented, but it made sense to my that static typing would be good for maintaining larger projects and it was closer to the ES6 syntax that will someday be available natively in browsers. However, getting a TypeScript environment set up was never a smooth process. Many JavaScript libraries had TypeScript definitions available, but it took me a long time to figure out how to deal with ones that didn’t. The preferred method of loading TypeScript definitions has changed several times and the beta versions of Angular often had bugs to work around to get compilation working.

For these reasons and others, I decided Angular was more trouble than I wanted to deal with for the majority of my small projects. Since the final release of Angular 2, there have been some improvements that I may decide to check out at some point. The CLI is out of beta, they have a consistent router, and TypeScript v2 should be a bit more stable. For now, though, I’m taking a look at alternatives for my own projects.

Vue.JS looks like it has really good performance and a clean coding style. It integrates seamlessly with Pug for templating, which I find really convenient. However, React is still quite a bit more popular, so I’m going to invest most of my free time in that. I’m also very interested in mobile development with React Native, which I have tried out a little bit and found pretty clear documentation on. I haven’t quite dug into Flux implementations, but I do like the concept of unidirectional data flow. That was something that I had started implementing in my Angular projects, when 1.5 came out with the components as an alternative to directives.

Both Vue.JS and React can be added to a project without setting up a completely separate environment. But there are tools available to set up such environments if necessary. That flexibility makes them much more appealing to me than Ember or Angular at this point.

Leave a Reply

Your email address will not be published. Required fields are marked *