Hacker News Reader

> it just seems that people get scared of the documentation and run away before they really give it a try

Anedoctally, as the author of another JS framework (http://mithril.js.org), I see a lot of people migrating away from Angular due to complexity, bloat and performance issues. I, myself, spent a good two years wrestling w/ Angular problems full time before jumping ship. Our apps were quite complex and we were fully invested in trying to make Angular work, and definitely not just making a half-assed effort to like it. So it's definitely not just newbies.

I like Mitiril, but the way you manage your view layer doesn't work for me. I've tried several "build a Dom in code" approaches before, and they haven't proven to be very maintainable in the long run, especially for larger and more complex solutions. Additionally, the cost of migrating an app is much much higher.

So while this post is mostly FUD, your points are valid, I feel all frameworks come with a tradeoff.

I love Mithril's (and other's) "build a DOM in code" approach. Traditional templating systems are always limited domain-specific languages that add lots of complexity for things that should be simple, template "partials" and iteration come to mind instantly.

Making the virtual DOM tree a first-class value that can be treated as a persistent data structure is a huge win. Templates are functions that return a virtual DOM node. Rendering a list is a map from Thing -> virtual DOM node. Redundant rendering is avoided with memoization. "Partials" are just functions. The system handles escaping and prevents XSS vulnerabilities by distinguishing plain strings from DOM nodes, which string-based templating systems do not do. All of the complexity and difficulty of working with templating systems goes away when we can just use the usual functional combinators we all know and love to compose views.

On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional. Angular just doesn't compose well with other things like Mithril and other primarily functional libraries do. I should really write a blog post on this.

> On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional.

How are you using an FRP library with Mithril? I thought with vdom libraries you never touch the real DOM.

Mithril allows you to declare callbacks for the various DOM events on the virtual DOM nodes. This is where you glue in the FRP library. A callback will set the current value for one of the roots of the signal graph.

synthetic events' handlers can publish events to a bus, and you can create observables on the events on the bus.

VDom lets you express UI as a function of the state

Observables let you express state as a function of user interactions

Would you care to elaborate on the maintainability aspect? I've worked with various "build DOM in code" approaches too, ranging from anywhere between Ext.js to HTML string interpolation/concatenation in jQuery and I think a lot of approaches do suck (some more so than others).

One major problem with older "build-DOM-in-code" approaches was ability to integrate to third party libraries, but I feel that this problem has been solved by newer frameworks (e.g. via lifecycle methods/mixins in React, `config` in Mithril, etc).

Personally, I find that mapping the DOM structure onto Javascript a la Mithril, React, et al works out better than mapping scopes and closures and logic onto HTML (a la Angular), simply because it's easier to refactor code that is, well, code, rather than something that tries to emulate having programming-language-like properties in HTML by shipping its own quirky implementation of scopes, expression parsers, compiler, etc.

I disagree on cost of migration. It's not exactly trivial to migrate from Angular to any framework that I know of, for example, especially once you start using things like form validation flags or filters. The only migrations that sound somewhat straightforward to me are Meteor/Ember (since both use Handlebars flavors) and - perhaps ironically - React/Mithril (assuming JSX/MSX), but for mostly anything, you're pretty much stuck with manually porting framework-specific syntax. With that being said, it's not necessarily impossible. I know of success stories of people porting non-trivial codebases from Ember to Mithril and even from jQuery spaghetti to Mithril (via its template converter too). At the end of the day, I think it comes down to tooling. With React's renderToString or mithril-node-render, it's quite feasible to automate a large portion of the work of porting templates away from these newer frameworks, should you need to do so down the road.

I haven't been able to write this without sounding critical of mithiril, and I don't want to do that. I suspect it all comes down to use case, and the line of work I'm in, it's not a wise choice.

I've been working pretty much exclusively with Angular for the past 18 months on some high volume financial processing systems. Shipped 3 codebases that would probably be considered 'large'. It's been one of the best development experiences I've ever had.

The learning curve is steep, but when you get into the groove, when it finally clicks, then you can really take off with it.

I love the tooling (node, Yeoman, Grunt, jshint, karma, protractor etc.). While not perfect, it's definitely helped me write better, more readable code.

The one article that helped me get to my 'gotcha' stage was this one by Todd Motto: http://toddmotto.com/rethinking-angular-js-controllers/

We have been dealing with a large angular front end and our big problem is really more along the lines of using watchers to take the place of what should be handled by a domain model. I don't think this is a problem with Angular but an issue with JSON. I have yet to find something that can take serialized JSON and hydrate a domain object in javascript.

I think Angular is so widely used because so many people do like it. It has quirks and shortcomings (per the article), but those are only relevant because it is generally liked and used by so many.

I agree on the documentation being unusual. I found the Angular Style Guide to be a huge help: https://github.com/johnpapa/angular-styleguide

Totally agree. That style guide has changed the way I write Angular apps completely, and it feels so much cleaner.

> "I like that I don't need to render things server-side because then the server is just running a REST-ful API."

Thank you! I never understood the big push towards server-side rendering. I did server side rendering for 10+ years in JSP land. I love having a clean separation between client and server, freeing me to experiment with different languages and frameworks on the server side. Likewise, if I want to experiment with a React component consuming my REST API I can. Not to mention my AWS expenses are kept minimal as most of the processing is offloaded to the client side.

> "I like using nearly straight up HTML as my template." Agreed again. Am I the only one who works with people who know HTML, CSS, and a little bit of Javascript who can contribute to the front end design? I feel like if I threw a "DOM in code" type of approach at them they would feel lost.

IMO there is no problem with Angular, except when people use it as a square peg with a round hole. It's ideal for your use case - lots of data entry, forms, etc. etc. But then someone tries to write a blog platform with it, or something.

I think part of the problem is that everyone wants there to be The Next Thing that will solve all problems, when that doesn't exist.

This is the problem with angular. Why are people using it as a square peg with a round hole? Is it because people are stupid or is it because angular is stupid?

Looks to me angular is a round peg disguised as a square one.

I like those things (data bindings, values in models) too but Angular isn't the only solution. I don't like Angular's heavy handedness, and I really really don't like mixing JS and HTML (which rules out Ember or React).

I personally find Knockout to be almost the sweet spot. Very lightweight, plays well with others, doesn't "take over" or try to impose a top-down ordering on the page.

I know the rest of the developer world has moved on but I'm hoping I can hold on to using Knockout long enough until another MVVM system which separates view and model but binds them together comes along.

I agree with this, I've been using Angular for a while now and like it. Every time I read these criticisms of Angular, I always think...compared to what?

For example, I don't find fixing occasional performance issues when using two way binding a big deal. Two way binding makes my UI code much more concise and free from bugs concerning keeping models and the DOM in sync. I've worked with Backbone before for instance and found that dealing with listeners and syncing manually was a huge source of bugs.

Compared to Ember.

Most of the time all you need is a computed property. It simplifies the code base and allows the framework to make optimizations where it needs to. If you really need a two way binding you can always do it with a computed alias.

Are there any cons to the way Ember does things?

ember's computed properties are irrelevant if you're targeting any kind of modern browser. Object.defineProperty is the standardized way to do this and perfectly possible within Angular-land (and more performant than literring your code with $watches)

How are Ember's computed properties analogous to defineproperty? The latter doesn't give me dependencies for my properties, so may as well just be functions. Ember's properties will only need to be recalculated when their dependent properties change.

I really like Angular and have been able to pick it up faster than other frameworks. Mainly because its a complete framework as opposed to having to mix it with other frameworks like Backbone or React has to do with Express or Ampersand My only gripe is having so much code in the HTML that it makes it nearly unreadable. Maybe this is just the people I've worked with who do this. I think most of this could/should be put in separate controllers?

I like that I don't need to render things server-side because then the server is just running a REST-ful API. That way I can write different clients for the API and don't have to change the server (mobile app, desktop UI, etc.)

How is that specific to Angular?

It's not, but TFA mentions lack of server-side rendering as an Angular drawback.

I'm also a major fan of two way binding, but I agree with the problem the article raises re dirty checking. I much prefer Knockout because for the price of writing observable(value) rather than field = value I don't have to worry about dirty checking or the knock on effects of updating a value. Combine it with Typescript and you quickly get over the learning curve of calling to set a value rather than assigning.

On the server side rendering front I'd be curious to know if you do LOB apps. In my in house dev world where people are almost always within 100m of the server and used to Oracle Forms the experience you are describing is easy, fast and blows user's minds.

> Sometimes I feel like I'm the only one who actually likes Angular.

Why? You're obviously not the only one, considering Angular's immense (and deserved) popularity. The simple fact is that popularity does not immunize it to having some problems. Angular is great, but it's hardly perfect. The issues with scope (gone in 2.0), the complexity of directives (also gone in 2.0, I think) are well known and being addressed.

I have no issue liking angularjs. It's everywhere in the industry so let's not think that everybody hates it. It has problems , but I've yet to see a framework that allows developers to write complex front-end apps faster. There is none in my opinion. Anything that involves settings up events in some ways (and React usage involves writing event handlers) is a no deal for me.

I enjoyed Angular 1.x. But I feel burned really badly by 2.0. I learned 1.3 shortly before 2.0 was announced and it was a really frustrating experience to have just felt like I learned this tool and then have everything thrown out the window. So, I'm not excited about learning 2.0 and haven't yet. I believe the claims that it's faster/better, but the way they threw everything out the window with 2.0 makes me concerned that I'll get burned again.

You can upgrade bits and pieces as you learn it: http://angularjs.blogspot.de/2015/08/angular-1-and-angular-2... It will end up being no different than any other tech learning curve without breaking your application.

>Sometimes I feel like I'm the only one who actually likes Angular. Two way data bindings are very convenient for writing UI. I don't want to write an event listener for every onclick, onchange, and onkeypress. I want the values in my models and the values in the DOM to be in sync.

React solves all of those in a cleaner way.

>I like using nearly straight up HTML as my template.

And yet you don't. You use Angular-ized HTML as your template.

I work with React daily and love it but will freely admit that using it for simple data-binding for input heavy forms is a gigantic ass-pain.

If you're using Flux, you end up with an immense amount of boilerplate action and store code around every input field. The other option is to violate the model, make all your inputs uncontrolled and have boilerplate onChange listeners for each one.

Choose the right tool for the job. Angular's no-questions-asked data-binding is perfect for this scenario.

It is incredibly easy to write a function that creates an input field and keeps track of the state wherever you want, so I don't think that is a valid criticism at all.

I've got a React app which is basically just one giant form. My inputs are not uncontrolled, I use boilerplate onChange listeners, and I'm not violating the "model".