Hacker News Reader

Just thought I'd add a bit of meta context: PPK (the author of the article) is perhaps the first person in the js community to catalogue detailed per-feature cross-browser compatibility tables. You could say he's one of the old timers.

PPK has a very strong background in cross browser testing and high level technology evaluation for non-techie audiences, but (from my impression of reading this article, at least), it doesn't seem like he has much experience w/ Angular per se and sounds like he is writing his opinions more based on blogosphere echo than personal time spent with the framework (clue: lack of Angular-specific terminology criticism)

Some of the criticism is valid, I think: hiring "Angular" devs is hard, partly because of the over-engineered-Java-like feel. I've seen a few times overconfident frontenders think they could pick up Angular through Google-Fu just as they picked up jQuery, and then hitting a brick wall face first, with a looming deadline to add insult to the injury. The reality is that a lot of people (especially frontend people) don't have the CS foundation to understand why and when the design patterns prevalent in Angular/Java are useful (or even what patterns exist to begin with).

@jasonwocky The snippets you highlighted do seem a bit like a "get-off-my-lawn" reaction from the author. SPA architectures certainly have their places, and it does feel like the author hasn't had experience w/ building heavily dynamic UI apps.

>> Find me a framework that hasn't evoked serious criticism from some corner of the Internet.

I think the point is that Angular criticism is much more prominent (and sometimes vitriolic) than other frameworks.

Enterprise Java dev here. Angular has made no great in roads here. Not sure where its popular.

> The reality is that a lot of people (especially frontend people) don't have the CS foundation to understand why and when the design patterns prevalent in Angular/Java are useful (or even what patterns exist to begin with).

That's hardly fair. Design patterns are not that difficult conceptually and in my (admittedly limited) experience Angular doesn't really introduce anything new. It's not hard to pick up because devs are lacking foundational skills. It's hard to pick up because it's overcomplex and difficult to adopt in pieces. Despite claims that it's easy to "add as much or as little of AngularJS to an existing page as you like", there seem to be no examples of piecemeal adoption in the docs. I'm sure someone with Angular experience could plug in a bit of Angular to an existing app, but someone just starting apparently has to choose to 1) go all in, 2) spend a lot of time learning Angular, or 3) use something else. If many competent devs are "hitting a brick wall face first", that seems to be indicative of problems with the framework.

Also, this is somewhat tangential, but I'm not sure software design patterns are part of computer science anyway. They belong to software engineering, which is really not the same thing.

> in my (admittedly limited) experience Angular doesn't really introduce anything new

If one's coding experience is limited to jQuery et al, it does introduce a lot and very fast: you can't really get very far in Angular before stumbling upon IoC and services/factories, for starters. Just look at the comments for any article that talks about Angular service/factory/provider/etc to see that even the most basics of patterns are not exactly universal knowledge.

A lot of the complexity you talk about originates from other patterns. More advanced tools like parsers/formatters, interceptors, decorators are there specifically to be alternatives to procedural spaghetti code and it's hard for a lot of people to even guess that these tools exist, let alone figure out why they should (or not) use them.

To be fair, it's true that a lot of complexity is very much Angular's fault and not a lack of preparedness from developers (the directives API and the digest system come to mind).

But my point was that it's hard to find Angular devs. Around where I live, a typical non-angular frontend job pays between 60-70k (generous extrapolation from salaries of people I know) and might involve a job interview that talks about responsive design. An Angular job easily pays 90k-110k (from job interviews I've been to) and might have a job interview that talks about algorithms. Even though both are considered "frontend" jobs, the former is more likely to be filled by a self-taught person that reads html5rocks or whatever, while the latter is more likely to be filled by someone w/ a CS degree and backend experience (which, here, usually means either Java or .NET). I think we can agree that the skill sets for the two jobs don't overlap much, and the dissonance in qualifications is not merely because of the level of complexity in a tool.

> Also, this is somewhat tangential, but I'm not sure software design patterns are part of computer science

If we're going to be nitpicky and pedantic, I said knowing when and why to use them is part of a CS foundation. s/CS/software engineering/, as long you get the main idea.

My impression of Angular is that it makes simple things complex and that it's poorly designed and engineered. I think that it tries to do too much, and tries to be too clever, and doesn't try at all to be usable (beyond maybe trivial examples, which could still be simpler, honestly). It speaks very poorly of Angular that many (most?) people familiar with all the tools it builds on (CSS, HTML, JS) find it difficult and unpleasant to work with.

It may be the case that only people with deeper engineering experience can wrangle it because they have the necessary background. It could also be that people who are used to working with friendlier tools just aren't willing to put up with Angular's crap.

FYI, I actually agree with you that Angular is overly complex and has a lot of serious problems. I even wrote about my gripes with it back when Angular was still somewhat "cool" (here: http://lhorie.blogspot.ca/2013/09/things-that-suck-in-angula... and here: http://lhorie.blogspot.ca/2013/10/things-that-suck-in-angula... ), and last year, I wrote a micro-framework of my own to get away from the frustrations I was getting w/ Angular ( I talk about it here: http://lhorie.github.io/mithril-blog/lessons-learned-from-an... ).

A lot of the stuff I wrote there is still relevant.

I didn't realize Mithril was yours. Seems nice, though I haven't used it myself.

The stuff you wrote is valid. I'm just not sure that dev ability is the major factor making it harder to hire Angular devs. Maybe I'm wrong. I'm thankfully not hiring Angular devs.

> The reality is that a lot of people (especially frontend people) don't have the CS foundation to understand why and when the design patterns prevalent in Angular/Java are useful (or even what patterns exist to begin with).

We're calling design patterns prevalent in Angular/Java "Computer Science"?

I'm not even sure they're worthy of the original terminology design patterns, and there's a pretty strong argument they're not foundational computer science at all (you can really see this by working in several different language paradigms and seeing how some problems patterns solve in some languages fall out without the pattern in others). They're aspects of industrial practice and a subset of software engineering. This isn't to say they're not useful (and some more broadly than others), but their usefulness arises in the context of the tools applied and concerns/constraints present rather than CS fundamentals.

And one doesn't have to be a jQuery hack to think that the concerns involved in dynamic single-page apps don't necessarily imply the utility of all Angular's abstractions (as I'm sure many devs who've embraced other front-end frameworks would agree).

Usually, when you detect a pattern in your design, you want to abstract it away. Design patterns are basically just data structures that nobody has really bothered to properly implement with full generality.

>> Find me a framework that hasn't evoked serious criticism from some corner of the Internet.

> I think the point is that Angular criticism is much more prominent (and sometimes vitriolic) than other frameworks.

That always happens to frameworks that get widespread usage. If your framework doesn't have vocal groups of haters, it is not successful.

I suspect this happens when frameworks start to be mandatory by decree in organizations.

> @jasonwocky The snippets you highlighted do seem a bit like a "get-off-my-lawn" reaction from the author. SPA architectures certainly have their places, and it does feel like the author hasn't had experience w/ building heavily dynamic UI apps.

> The snippets you highlighted do seem a bit like a "get-off-my-lawn" reaction from the author.

New and shiny ways are not always the best. I'm still not seeing people writing kernels and device drivers in JavaScript.

> SPA architectures certainly have their places

And what areas those might be and why?

You can build heavily dynamic apps without trying to do everything in the browser.

Problem with the web nowadays is that a lot of decisions are being made for political reasons rather UX considerations. SPA architectures are appealing to front-end developers who just can't be bothered to learn how to do routing and templating on the backend or they just want to have those things in their territory.

For me UX matters more than shiny architecture. I did the experiment in Chrome where I had HTML and applied some stylings to it via the raw DOM API as soon as possible. There was a noticeable delay before the stylings got applied and this was the highly optimized DOM code with no Angular, no jQuery, no nothing. The moral of the story is: browsers are still faster at displaying HTML and CSS.

Aside from the performance failures, Angular has huge problems when it comes to writing maintainable Angular code like the scope hell, but you can find many others here: http://ihateangular.com/

I've been writing Angular on Rails for the last year. We took a bag of jQuery code which manipulated DOM for a complex single-page app. We threw that all away and replaced it with 90% less Angular code. It felt (not to trot out a stale trope) like magic and we never looked back.

It was clear to us from day one that performance would be an area of concern, as well as the overall complexity of the framework. But those can be addressed. I don't agree that using another framework would magically prevent developers from thinking about performance issues. And many modules of angular we just don't use, and it doesn't impose those on us.

On a regular basis we re-evaluate alternatives: React, knockout, backbone, and so on. I expect those might involve tradeoffs that end up being positive or neutral for us, even it just forces a re-thinking of the app architecture. But this article doesn't make any recommendation or even mention the initial problem of rich, single-page apps that create user interactivity without page reloads. And the painting of the framework as Java and Enterprise do not match our experience or use case. I'm the first in line for recommendations on how we can improve what we do, but my impression is his bias is throw away frameworks and bring back our mass of raw javascript.

Ending up with a code base which is 10% of the size of the original is a massive improvement, can you share some examples of what the code was doing before? Even cutting down by 50% would be impressive.

Not to discount the value added in this case, but remember that the report is possibly biased in the same way that many "We rewrote it and now its 10x as awesome as it was before!" reports are. Rewrites almost always tend to result in higher quality code, regardless of what the rewrite is to or from.

I did something similar with a couple of my projects. Our apps had a soup of Jquery, Backbone, Backbone Marionette and a bunch of other libraries, and while we didn't get 90% less code (more like 70-75%), I feel it was a worthwhile migration. The overall structure of our code base is simpler.

Angular does have its annoyances and compromises, and in some areas, it's kind of a pig (i.e., ng-repeat).

Our projects aren't massive in scope (they're targeted towards small enterprise implementations), however, so I don't think Angular's limitations will really hit us hard except in certain use cases.

I think besides ng-repeat, angular is pretty much like any other two-way template binding framework. I don't know why it's really considered so radically different and special.

It's when you get controllers such as ng-repeat that Angular's digest cycle makes some difference. But ultimately you could write a component like ng-repeat yourself. As for where you place the directives -- the tag name or attributes, inside the class -- who cares? Only the {{}} in the text nodes matters strongly.

As for alternatives, check out http://platform.qbix.com . It is compatible with angular, ember, jquery etc. But it is much more straightforward, like react. You only have two concepts - pages and tools (components). And you can not only re-use a whole lot of tools from a marketplace but they all can work with a standard opensource platform of user accounts, realtime streams of data, which can distribute the social layer the same way bitcoin distributes money and contracts.

Agreed, even ng-repeat has equivalents in each framework. Migrating from direct DOM manipulation is a no-brainer, but I wouldn't count it as an advantage of Angular over the other choices.

+1 !

Currently wrapping up my first commercial AngularJS project - I was outsourced by a client.

Prior to this contract I had no experience with it, now I've been using it nearly every day for the past month and a half, have run through the tutorials and implemented it on a side project of mine.

All that said, I will be stripping Angular out of my side project. It is something I am glad I learned for clients that demand it, but I wouldn't recommend it.

IMO Backbone with underscore templates are much cleaner and seem to perform much faster for my needs (no benchmarks performed on my end, but as a user my site certainly felt snappier prior to implementing Angular).

Might want to check out React eventually, it vibes pretty well with existing Backbone apps

Thanks for the tip

"Says who? What's the rationale for where a language belongs?"

From the article:

"Unfortunately they aren’t trained to recognise Angular’s performance problems." ... "The problem is that there is no way for Angular to discover these instructions except by parsing the entire DOM, including all text nodes and attribute values — a very expensive process if there ever was one, especially on mobile."

The author is arguing that it is bad for performance.

if Angular is truly dropping the template into the DOM and then parsing the DOM, Angular is doing something terribly wrong. Underscore (for example) parses templates that look very similar to this by parsing the template as a string (not as DOM nodes). If it's crucial to parse the content as nodes, the top element (or a wrapper) can be constructed outside of the DOM itself and parsed as nodes outside the DOM tree. I haven't looked into how Angular does this parsing but I would be very surprised if this complaint is accurate.

Yeah, that's pretty much what it does[0].

Most templates will typically live in separate files and be loaded and compiled when needed, of course - so not so much of a performance hit up front. But Angular still needs to know where to dump the stuff, so it needs to parse the DOM to find a node with the ng-app directive.

Also, I'm not aware of anything like handlebars's offline pre-compilation for Angular, although such a thing may well exist. There's a lot of stuff in there...

[0] https://docs.angularjs.org/guide/bootstrap

Hold on there, cowboy. The innate superiority of strings over DOM based templating is not universally accepted. Because it's not unequivocally proven.

In fact, a few years ago there was an obvious tide toward experimenting with alternatives to string based templating noticeable in several some high profile efforts in the client side templating space.

See http://modernweb.com/2014/03/24/string-templating-considered... for a recent overview that is pretty decent. Boris Moore did a lot of publishing about it, as I recall.

I agree, I wish the author brought reasoning to those points. I do think that it is a little odd of us to push more & more processing to the user's device, rather than doing it ourselves and purely delivering content. However, it does seem to have a net positive on server reliability, and the perceived performance & responsiveness of the apps.

It makes business sense: server cpu cycles you have to pay for, client ones you don't. (If the client is fast enough not to notice -- if not, of course, you could lose customers).

I've been pushing this strategy for years. It makes more and more sense to have the clients- which include phones- do the processing. They have an excess of power. And more importantly, once the app is downloaded network lag is not as big a factor (it still is, of course, for any ajax-based stuff- but we minimize this).

"If the client is fast enough not to notice -- if not, of course, you could lose customers"

This.

I honestly think most front end devs don't test with anything except a fast PC (or Mac). They sure don't test with last year's phones. Web pages are getting more and more sluggish (generally speaking) all the time.

It's one thing to always want to work with new technology, but devs really need to spend some time in their customers' shoes.

> "Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers (we’re talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server."

Agreed. I'd go even further: presentation logic, including templating, is the job of the browser. The server is the database. And I include "mobile" front-ends in this, which do all not equate to "low-powered" these days.

This is basically a +1 reply but I feel strongly about this point and wish to add my own rant.

This persistent idea that one should compile templates on the server is so mindbogglingly inefficient - compared to delegating to clients whose computing power is idling 99% of the time. Not to mention separation of UI from the core functionality and other benefits.

JS in browsers is incredibly fast nowadays. I can't remember the last time I ran into performance issues. Angular my not be the most efficient but it's a stepping stone in the direction of client-side apps + RESTful APIs which I think will be the rule rather than exception in the future.

Lots of features are in the pipeline which will make client-side apps even faster and more elegant (shadow DOM, Object.observer).

> This persistent idea that one should compile templates on the server is so mindbogglingly inefficient - compared to delegating to clients whose computing power is idling 99% of the time.

s/idling/conserving battery life/

much of the original article's criticism was aimed at angular apps on mobile devices.

Hi. So you're responsible for the increased battery usage on my mobile device. Please stop. Also, can you please test your code on a device that came out _last_ year? You know, so that you can make sure it's not sluggish and frustrating to use.

I would have thought a page reload from the server would use much more battery than a simple digest/apply in Angular.

Is there an Angular engineer who can speak to this?

37signals (now Basecamp) should have a post or two about how they made a new version of the product fast. One of the points was bringing templates back to the server, iirc.

[1] https://signalvnoise.com/posts/3112-how-basecamp-next-got-to...

It is usually the loading of many resources (js etc) that takes time. If you just send some html (and css) to the browser it can show it quickly. But companies like Facebook and Airbnb are starting to send html first and then use javascript for everything. This makes the first pageview very fast while still keeping the flexibility and other good parts of a SPA system.

The author is fine with other browser side rendering tools. The issue is the need to needlessly render templates client side by parsing out the DOM each time. There is no need for this, and doing it is pointless. Better to have the template render in a state where you don't need to do the dance that Angular does. This consumes a lot of CPU, and a lot of battery life. This impacts performance and user experience.

Angular must be so inefficient for mobiles if well-respected mobile-first UI frameworks like Ionic chose to use it as a base. /sarcasm

Why are we black-and-white fallacy-ing this?

It is indeed stupid and wasteful to deliver 40 KB of framework and 8 KB of templates and 14 KB of data and 20 KB of business logic and 15 KB of CSS to the client and then make the client do all the rest of the work to "make page happen"--especially on an open platform with so few reliable guarantees about the client's capabilities and resources.

But to say templating is only the job of the server is equally myopic. Web applications--high functionality, low content (as opposed to web sites--low functionality, high content) have struggled with the limitations of the static, stateless document paradigm for years and is the real use-case for client side templating as an answer to one of the many resulting challenges.

When a page is highly dynamic in response to interaction, it is equally stupid and wasteful to perform full page refreshes. Request, server compile, download, flow, paint. Bad. Slow, discontinuous.

Someone else mentioned UX being ignored in the quest for client side templates: no, wrong. Client side templates are at least 50% about UX. We have a DOM already there, let's use it. But that is also exactly the problem with the all-client mode: it delivers something several extra steps removed from being a useful (to the user) DOM when it could do otherwise and when doing otherwise would result in a better and more universally performant user experience.

Right now, truly smart isomorphic templates are what we need. (But, then again, by the time we get them, we probably won't need them--because the goalposts will have shifted and/or we'll have a better answer.)

This post resembles exactly my impressions. I don't see why such a weak reasoned article based on assumptions and feelings is getting upvoted.

Ditto - I also dislike Angular, am aware of the author's background and initially upvoted - but further reading shows this is a generic disagreement with browser-side rendering with 'Angular' thrown in for linkbait. Flagged.

That's not what flags are for. The article's on topic, you just don't agree with it, don't flag it.

Maybe a misuse of flags, but I agree that the title has the same inflammatory, ambiguous quality of a linkbait article.

Guys, do we really need to be so politically correct? Do we need to state that it’s his (author’s) personal thought on the topic?

You haven't actually read the post you're replying to. I do actually agree with the articles conclusion, but It has a misleading headline and my understanding is that this is exactly what flags are for.

Dang should we not flag this stuff?

"generic disagreement with browser-side rendering" re-read the article. Author has no issue with Ember or Backbone.

Please do so yourself. He repeatedly states that templating 'does not belong' in the browser with no justification whatsoever.

I wonder if it isn't badly phrased, there's a difference between rendering templates in strings and in the DOM after all.