Comment by doublerebel | Hacker News Reader

Comment by doublerebel | Hacker News Reader

This only refers to frontend JavaScript and reflects the opinion of a dev who hasn't been using JS all that long. Angular was never that great a framework, it's popularity was by and large because it came out of Google. It's far too tightly coupled to the DOM and was therefore destined to have problems as HTML and browsers evolve.

Npm is stable, Backbone is stable, Node is stable, Gulp is great, and devs like myself who have seen trendy frameworks come and go (Batman.js and jQuery templating come to mind) are still using the same great composable tools that were better designed from the start.

Backbone (and my favorite, Spine) are built on more loosely coupled components and can be used on applications which have no DOM, such as Canvas games or native mobile apps. Browser fragmentation has been an issue since the dawn of JS -- and these days the JS ecosystem extends far beyond the browser.

Take a look at the mature tools for front or backend that major companies rely on and be glad that the open-source nature of JS produces so many options and rapid evolution.

Factors in Angular's success:

* backed by Google * MEAN * plenty of media/blog coverage * seductive examples (that don't reflect best practices)

My personal gripe is with the last point. A lot of the appeal is in the two-way binding -- which is often the first thing to go out of the window once scaling becomes a problem.

Also, I have no idea why the author thinks Browserify and Angular go well together. They don't. At all. Browserify is great on its own, but there's not really any "blessed" way of using a module system with Angular (and like jQuery Angular 1.x is tightly coupled with the global scope).

Regarding seductive examples. I recently found out, that most of the examples even example apps are lacking best practices, and in many cases even basic security measures. Good example make a e-commerce app using x and x technologies, and then disclaimer that this app is just to show how fantastic framework x is. Many frameworks js, php name it have disastrous examples, which are oversimplified for the sake of understandability, and then all hell breaks loose when someone finds out that, for example, by default csrf policy, or authorisation is not implemented correctly or not implemented at all.

Yes. This was actually an even bigger problem when I started with AngularJS because the real documentation was woefully incomplete, so there was no obvious way to learn about best practices at all (except that everyone apparently agreed that the examples weren't following them).

I haven't seen two-way binding go out the window with scaling.

It's still the number one selling point and greatly reduces development time in both small and large applications.

The only thing I've seen is that in bigger projects, if there are locations where huge amounts of binding might take place (such as drawing, tables, etc...) you don't use two-way-binding in that particular place.

And in any case many of the popular frameworks (Ember, backbone etc... ) also use two-way binding, they just don't support two-way binding on simple js objects. And for that many of the bigger frameworks (

> The only thing I've seen is that in bigger projects, if there are locations where huge amounts of binding might take place (such as drawing, tables, etc...) you don't use two-way-binding in that particular place.

Sounds like two-way data binding went out the window then...

My brief encounter with angular - you write something, throw it into a black box, magic happens, and you receive output.

When it works - works fine. When it does not work you are completely helpless.

When it doesn't work, that usually means you have to learn implementation details like the digest cycle, which flies completely in the face of having these abstractions in the first place.

Which is exactly why I always hated ASP.Net's page/control lifecycle.. it was nice for windows-ui developers, but really poor when you had to do something custom. Same for MS's Ajax Toolkit. MS is finally learning these lessons. So should everyone else.

If you have simple modular tools that do something well, and you can string them together in a productive way, it's easier to replace certain pieces.

Which summarizes the reasons for my hesitance toward anything that looks like a "framework." And here, we're talking about an old problem . . .

If you like backbone, definitely check out http://ampersandjs.com. They've taken backbone and split it into separate modules with some nice upgrades.

website appears to be dead.

Well, broken anyway.

> It's far too tightly coupled to the DOM and was therefore destined to have problems as HTML and browsers evolve.

Maybe in the sense that the APIs will have to change as browsers evolve. But isn't there also some benefit from staying tightly coupled with the DOM? I know that React claims the fact that they are loosely coupled with the DOM is a benefit, but I'm not sure I really understand how this is inherently an advantage.

Reply on news.ycombinator.com