For those who do not know, AngularJS is in short, a trendy JavaScript framework for writing "single page applications". Last autumn the angular team unveiled their plans for Angular 2, and a lot of people freaked out, because surprise, surprise the major point release will introduce breaking changes. The fun does not actually stop at breaking changes, the Angular team has also "invented a new language" called AtScript, and is using it to write the next Angular.
Over the last few days I have stumbled across a number opinion pieces that are excessively negative. This amuses me greatly.
This is not to say that all the grievances are invalid. My amusement is born of the fact that the "loudest" grievances fall under two broad categories:
- Grievences rooted in using the wrong tool
- Fundamental technological misunderstandings
Wrong Tool For The Job
Angular is not for everything, most tools are not. There are a *lot of different web use cases where Angular is overkill, or just poorly suited to the task.
Angular is the right tool for me because:
- I manage complex single page applications
- Some of my applications have to work offline
- Maintaining unit tests is convenient
- There is an e2e testing framework
- Many team members only know a small slice of the codebase
Fundamental Technological Misunderstandings
Here is a list of silly arguments floating around:
- The "Angular Way"
- Angular is developed for Java people * / Angular is Java style
- Browser templating is "wrong" (ROFFFFFL)
- Angular is for enterprise IT people
- Angular is slow
The Angular Way
Repeat after me, "JavaScript is not the DOM". When most people speak of the so called "Angular Way" they are referring to DOM manipulation. With respect to DOM manipulation, Angular is highly opinionated. This does not mean that Angular is "not JavaScript", it just means that Angular is not DOM manipulation.
Most people are used to manipulating the DOM either directly, which is much improved in modern browsers, or through a library like jQuery. I also think that it is a great thing for people to know how to manipulate the DOM directly,
One of the purposes of Angular is to abstract away DOM manipulation. If you are of the opinion that Angular is not JavaScript because the DOM is abstracted away, choose a different tool.
I would argue that Angular programming is more "pure" JavaScript than browser programming because Angular is largely a dependency injection framework.
Really this whole grievance is akin to picking up a drill and complaining that it is not a screwdriver. Hey sometimes a screwdriver is what you need, but programming is trade offs, and the tradeoff with using the Angular drill is that when you need to finely screw something down it is an overly bulky tool.
Java People
I despise Java. I like Angular. Logical fallacies be damned.
My real argument is that Angular is not Java-like because it does not promote the same style of OOP as Java. There are a lot of opinionated Angular best practices, but those largely relate to agnostic practices not specific to Java.
The Angular style guide that Goolge has made available even points out that the team are in favour of first class functions, and closures. Java just got these features in Java 8.
I will concede that some of the lexicon is Java-esque, but we have to relate abstractions to each other somehow.
Browser Templating is Wrong
Why?
Even in 2009 I had written an Angular like declarative HTML style framework that acceptably rendered templates client side, even on first gen iPads. Well under fifty milliseconds for a bootstrap pass, and updates well under five.
Why should I spend my money processing on my server when it is a handful of milliseconds on the client side.
Why should my application be so tightly coupled to the server? For my use cases server templating is horrible.
However that is the problem. For my use case server templates are wrong. I can imagine use cases where server templates make way more sense. Here we are back again at right tool for the right job...
Angular is For The Enterprise
Angular is for whomever the use case fits, that might often be the enterprise, but it might just as easily not be. This is just a vaccuous argument. I am not the enterprise, but I make extensive use of Angular.
Angular is Slow
Like most tools Angular can be made slow. So can jQuery. So can C++, it is also easy to write slow/stupid assembler.
In practice for what it is intended, Angular is quite snappy. In many cases after init, Angular itself does very little.
What Angular Is
- Dependency Injection Framework
- Double binding client side templating framework
- Basic wrapper modules for things like XHR, forEach, etc
- Unit Testing Framework
- e2e Testing Framework
Unfortunately the first three of these items are (seemingly) tightly coupled, meaning you cannot just have the dependency injection, or just the templates.
Karma is decent at managing general purpose DOM oriented JavaScript unit tests.
Protractor seems married to Angular, but the underlying toolchain is general purpose.
AtScript
AtScript is freaking a lot of people out, and not just the JavaScript programmers, I have seen uhappy Dart programmers too.
I think the freak outs come from people hearing "new language"
AtScript is in its infancy, so who is to say what it is or is not? Right now my use case for AtScript extends outside of Angular to all JavaScript. This is primarily driven by the annotation features, and traceur.js
I do not think of AtScript as a new language at all. I think of AtScript as a way of writing es5/6 code that my development environment can make better use of. One explicit better use is that annotations provide me with a mechanism to dramatically imporve maintenance, while adhering to DRY.
"Introspection" is immensely valuable to me. I like to know exactly what my software does, or does not do. High quality runtime feedback can literally save me weeks of work sometimes. Like anything else, "introspection" is not a magic bullet, just another tool in your collection.
AtScript & TypeScript
AtScript has been presented as a superset of TypeScript. This also might be freaking people out, and I having read the TypeScript docs I can understand why!
Having played with the languages I do not see AtScrtip as a "strict" superset of TypeScript, in that TypeScript seems militant about types, and AtScript does not. In fact at this point, out of the box, traceur does not even have types enables. Even with AtScript enabled, there does not seem to be static type checking, and dynamic checking through RTTS has to be configured.
The Middle-End
Some people suggest that the lines between front-end/back-end have blurred
http://blog.salsitasoft.com/the-shifting-definition-of-front-end-developer/
I can largely agree with this, although I think the skill waterfall diagram is messed up. Java/C++ are not on the same line at all, but I digress...
I would argue that for a growing class of web applications there is now a "middle end". The middle-end more or less encapsulates non-view code that lives in the user agent. I stress user-agent, as WebViews are more, and more common environments these days.
- Front End - view logic, presentation logic
- Middle End - data managment, and business logic
- Back End - Serving logic, scaling logic, and more
In a front-middle-backend architecture the front end job description stops at the front end API, whether it is jQuery, angular, ember, etc.
The middle end extends to the XHR, right up to, and including the client managing its end of "the wire".
The back end extends from the wire all the way down through the stack to the bare metal, plus all the dataqbases, etc... (joking)
Really though the backend is more or less glue logic, whether it is written in Ruby, JavaScript, PHP... "backends" without templating more or less figure out the right static data to serve, safely query databases, and enforce strict business logic.
I do not mean to trivalize the backend. I mean to point out that below the so called "backend" is where the real backend begins, the web servers, vms, userland, and kernel on which everything else sits.
See mel the real programmer for more info.
Summary
- Use the right tool for the right job.
- Write flexible code that can be adapted to frameworks.
- JavaScript != DOM
- front end/back end labels are nebulous, maybe harful
- Traceur has lots of agnostic potential