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
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,
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.
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
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.
Protractor seems married to Angular, but the underlying toolchain is general purpose.
I think the freak outs come from people hearing "new language"
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.
Some people suggest that the lines between front-end/back-end have blurred
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)
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.
- Use the right tool for the right job.
- Write flexible code that can be adapted to frameworks.
- front end/back end labels are nebulous, maybe harful
- Traceur has lots of agnostic potential