I think Alan Kay was right: computing, at this point, is pop culture. Articles like this are are kind of like identity politics for programmers.

I don't say that that to disparage the author, because stuff like this is nothing new. Programmers have divided themselves into warring tribes for almost as long have there have been programmers. You used to see C programmers saying that Pascal is for idiots, and Pascal programmers saying that C is for neckbeards. Or similar arguments between C++ and Visual Basic camps or C vs asembler. And there are dozens (probably hundreds or more, actually) of other examples.

So it's not a new phenomenon, and I don't expect it to go away. The way I look at it, it's usually more productive to mostly ignore the pop-culturists and just pick tools that allow you to get things done quickly and happily. I've used Angular 2/4, React, and Vue. I like them all, and I'd be happy to work on a project using any of them. Aurelia looks equally enjoyable.

At this point, I don't think it's especially likely that a project will fail because you chose Angular over React, or vice versa. Pick what works best for you and your team, and don't worry about what the chattering bloggers say you should be using. :)

I've used AngularJS, Angular2/4, and a bit of Backbone and Ember. I agree about React, Vue, and Aurelia and despite what hiring managers may think, I don't see competent engineers having much of an issue switching from one to the others.

Hiring has become too framework specific - if someone has built an application using a component oriented framework, I don't think they'd have much trouble moving between them.

I'd even cast a wider net when looking for good candidates while hiring - if I came across a great developer who knew JavaScript well and had also worked on WPF apps in the past...I'd probably be inclined to make them an offer, even if they hadn't worked with React or Angular yet. Maybe it's like Moneyball applied to the developer labor market. There are lots of people who would do a great job, but are undervalued because most hiring is fairly buzzword-oriented at most companies.

Frameworks and tools come and go. I think that the real value comes in understanding the underlying concepts and being able to apply them in new situations using new tools.

I went from been a "dyed in the wool" desktop/enterprise developer to a backend web developer in less than a year and a full stack in two, once you accept the patterns are different, programming is mostly just programming.

Here we are in 2017 and if you squint web app development looks a lot more similar to that stuff than it did back in 2009, I picked a fairly good time to move over I think, I missed a lot of the early bullshit around browser incompatibilities (I just caught the tailend of the shitfest that was older IE versions) and the tooling has improved hugely over that time.

TypeScript with node and some of the front end tooling is actually pretty pleasant day to day.

I might not agree with it all, and I do think our community is frequently overly-dogmatic. But, I also don't think it's fair or productive to dismiss out of hand any critique of any tech as simple pop-culturalism or tribalism.

I just found this article to be on dogmatic side of the spectrum. It doesn't seem that the author has enough experience with Angular to back up the negative assertions made about it.

I know it's only anecdotal, but I've seen teams that are simultaneously using both Angular and React happily and productively. When I've talked to people working on those teams, they don't really feel that one is drastically better or more fun to use, and they've found that speed of development and codebase maintainability ar comparable between the two.

Yeah, it really is just a matter of opinion and thinking styles. I'm not sure why we're so bent on this idea that we should all do everything the same way. Part of it is self-preservation, I suppose. "I've got 20 years in Java and you're telling me it sucks (and, by extension I suck too)? You and I now have a problem."

But, we keep doing this with any new tech, and never seem to get that it'll all change and matters a lot less than we think. What people raved about 5 or even 3 years ago is now passe'. Call it evolution, and that's probably a good thing. But seems we could have learned to skip the part where we beat each other over the head while awaiting The Next Big Thing.

Funny thing is that no matter which framework you like, the worst thing you can do is not choose any framework. People can't even wrap their heads around the fact that you haven't declared a side.

That is, once a person has invested in that learning curve and spent significant time working in a tech, tunnel vision tends to set in. It becomes the only tool, which that person fiercely defends. They've now got too much invested to just let it go.

It's actually not unreasonable from a raw self-preservation/self-interest perspective, but I do think it contributes to a lot of the emotion-filled tribalism we see. In other words, the intensity comes as much from interest in maintaining self-relevance and personal financial security as from the viability of the actual tech.

It seems like this is a bad approach to hiring, and I push back against it whenever I'm in the hiring decision loop any way. In the past, when the company I was at was looking for someone who would be working mainly with .NET, I wouldn't hesitate to being a strong advocate for a great candidate who has really only worked with Java. In my experience, such a candidate would take a week or two to really get up to speed and sort out the differences between the two ecosystems.

I'd have been just as strong an advocate for good candidates whose main experience was Python, or Ruby, or Node, or Haskell, or anything. I don't think I ever saw any of those, though. The company was using a recruitment agency to bring in candidates, and so we mostly ended up seeing people who fit a pretty specific archetype. And I don't think that led to us seeing the best candidates who might have been interested in us. Not that we didn't find some great people; we most certainly did. But we also found an awesome one via a post on an HN "Who's hiring" thread.

The whole premise of identity politics is that you are the sole arbiter of your identity. It's an extension of the post-modern idea that since there is no possible way to favor a given interpretation of the state of the world over another, the only humane course of action is to let the people most immediately concerned by the interpretation set the standard. As such, the individual is given full dominion over his identity.

So no, it's equivalent in this respect.

(N.B.: the post-modernist could reply to my comment with something equivalent to 'that's just like your opinion, man', thereby illustrating why this reasoning gets us nowhere useful)

Some people use that term to mean politics according to demographic factors they cannot directly control, such as their race. So, if it was what was intended, then I don't think your (actually quite excellent) critique of post-modernism is relevant to what they were talking about.

Unless of course, you're arguing that it's the underlying philosphy even if the participants in it don't know it or think that way consciously.

A lot of these articles give me this vibe. So what if a competing technology is "bad". What does the author get out of saying "X technology is the best and Y is fail"? Are these guys now thought leaders?

Also I tend to see these more often in front-end land. Not sure why. Possibly because the cost of switching technologies is so low that you need to convince people constantly that X is the best so they stick around.

If you are highly skilled, you're far less likely to be married to any one bit of technology, even if you have prior preferences. You're also likely to have been through a few fad cycles before, so you probably learned to tune out the holy wars and focus on being productive. And if some stack X is really a giant turd, you should be able to figure that out quickly and avoid it, so you don't have a reason to write about how much it sucks.

On the other hand, if you know next to nothing, you're going to be more likely to read "Don't ever use X!" stories because you don't know what to use and are looking for advice. And you may be more dependent on whatever things you do use, because you don't yet know many other things, and you may be more likely to believe that it's better for your career to establish yourself as an expert in whatever you know.

I think the "front-end land" sees more of these now because front-end land is a new and bizzare place that only came into being a few years ago; people generally don't understand it as well as they do other things.

I think it has something to do with signaling expertise, often for purposes of self-branding.

There is a bunch of tech that I bash all the time, but if that is what makes the customer happy, then that is what I would use.

These posts seem like people self assuring they have made the right decision to use whatever technology stack.

So many times I've read a post on HN or Reddit that I thought was spot-on, and then looked up and saw that you wrote it. Nice to see that the agreement goes in the other direction - or did on this occasion, at least. :)

I don't interpret this article like this. I understand the observation that people have different opinions, but with JS frameworks, there's so many developers who sunk their teeth into a framework to be productive just to lose their edge 6 months later.

It's substantive for a developer, a team of developers, a whole community to invest their time into a framework that gets thrown out every 2 years.

It's painful to constantly pursue a moving target with JavaScript changing. Meanwhile, web frameworks like Django and Rails remained stable for over a decade.

> At this point, I don't think it's especially likely that a project will fail because you chose Angular over React, or vice versa.

That sentiment feels rather just-worldish in light that becoming productive at a framework (not just doing small tweaks) is a chore in itself. I recognize that people have their own opinions and philosophies of the framework they pick, but the article also factors in the timeline of these frameworks.

When I read through that article, I felt sharp remembrance of being on the roller coaster of continually rebuilding my skills from scratch with the new framework where the action is at.

> Pick what works best for you and your team, and don't worry about what the chattering bloggers say you should be using. :)

While I do recognize there is also a cargo-cult fanaticism that comes with JS frameworks, the amount of upstream contributions and extensions these frameworks receive back is considerable. The effects are also felt on QA websites like StackOverflow and so on.

I don't see the same behavior for every framework in software development. Like for instance, SDL2/allegro/SFML, I don't feel attachment and the API's are somewhat less of a moving target.

Potentially, because it's safe to say you can just pin NPM packages and your old Backbone code will build. But will people hire you for that Angular 2.0 position if you're not top tier in that framework? They could pass you up for someone who's already ready for to take up the job. There's economic ramification for workers on what framework they pick.

It's really more interesting from a perspective of institutional blindness/incompetence/arrogance than any real technical discussion.

To their credit, though, I find the Angular development experience to be quite good now. I like that there's interest in the Angular community around generating code that can be aggressively optimized by the Closure compiler.I like to ship as little code as possible to browser as possible, as lots of people are using older computers, tablets, and phones where parsing an unnecessarily large code bundle causes a noticeable delay.

Thus far, I've had a lot more success at reducing bundle size when using Angular than when using React. But I still end up using React often, because I enjoy it and I like the size of its ecosystem.

Mabe just a part of human nature to defend brand buy-in.

Yup, this is because people invest their identities in the brands they consume/use.

I imagine that probably makes me seem like a glutton for punishment who loves development environments that require the power of a 90s supercomputer just to display a flashing cursor. :)

I do enjoy Emacs for Clojure development work, though.

You can use webpack with Angular. RxJs is a great addition that will eventually be removed when Observables become implemented in JS. The declarative style of templates are different than JSX, but are not hard to deal with in practice. Native script allows for mobile dev, although I don't personally use it.

Before I switched to Angular, I preferred React. Now that I use this framework approach, I am much happier and have more faith that my code base will be consistent. I read somewhere that google used Angular for adsense so I think it is good enough for production use for us.

React and Redux promotes a more functional style (even though React components are classes...), and a lot of OOP people I personally met were not so comfortable with it.

Personally I love the functional concepts that it taught me, and I would never want to use a framework like Angular again. I'd rather make the leap and look into a real functional language for the frontend, like Elm, ClojureScript, PureScript,...

1. It's not. React has had classes and states from the very begining. In fact, purely functional only views came in React 0.14.

2. That said, it really does make coding, debugging, and reasoning about views so much easier. When I have a bug in my React/Redux app, I can look at the Redux state, and figure out the cause of the bug right then and there. I'm not looking for some variable that accidentally got changed five steps ago.

My bug is either in:

(a) How I went from application state n-1 to n, or

(b) How my current application state is rendered in my views

Both of these are very fixable.

...of course, I do also have stateful React views in my app, and code with side-effects, because being "pure" all the time isn't always practical. If the bug is in those places, I'm in for a much longer debug.

That's a snarky reply, but there is a kernel of truth. OO was practically invented for GUIs (Smalltalk). Throwing it out entirely on principle just makes large programs harder to understand, IMHO.

Funnily enough, React + Redux is "Global god state + functions", with a bit of dispatch sprinkled in. Not too far away really.

I definitely see the benefits of having a functional approach to defining UIs. My code is _somewhat_ clear, clearer than what it would have been with say, WinForms or something of the like. Going purely functional everywhere is just devs cargo culting.

Once I got in touch with React, I got interested in FP. Then I read the "Mostly Adequate Guide to Functional Programming" [1] and it was kind of an revelation for me.

I still do OOP, and I'm far, far away from being an FP expert, but I think if I'd take the effort to learn a real FP language then I probably wouldn't want to go back to OOP, and that's something I fear :) I've read a few blog posts from people who stated that learning FP kind of made them "unemployable", because they suddenly saw all the problems and annoyances that OOP brings with it (unfortunately I can't find the link anymore).

This quote regarding OOP by Joe Armstrong, the creator of Erlang, is quite fitting: "You wanted a banana, but what you got was a gorilla holding the banana, and the entire jungle."

[1]: https://drboolean.gitbooks.io/mostly-adequate-guide/

My only regret after becoming comfortable with functional programming in JS (and eventually, even more robust techniques in Haskell, OCaml, and Scala) is not pushing harder for a functional approach in work projects that could have really benefited from the functional paradigm.

When you say that, what exactly do you mean by it?

I would write all of this in my own words, but it would become really long and I don't have the time at the moment. I tried to find the original article I read, but I'm unable to, but here is a similar article I just found: https://medium.com/@cscalfani/goodbye-object-oriented-progra...

I'd understand if the inflammatory writing style and the memes are not yours, but I skimmed through it and I think it does explain some of the problems well. I'm sure there are better written articles on this subject, but I have to leave now unfortunately.

We have a strictly defined state object that is used throughout our entire application. Because we made a contract with redux, every transaction is readable and transparent.

Writing tests for our UI layer has never been easier with React. While we do have local state inside some react components, when we use redux to pass state to our react components, they become extremely easy to test, because they turn into pure functions.

When using something like jQuery, you wouldn't just look at each frame of your state to determine how the UI would look, you would also have to look at the transitional states between A and B. Transitional states are much more difficult to understand because of the contextual implications.

Our UI layer is completely separate from our business logic and we get it automatically. Without any code modification we were able to target our large application into a CLI app just by adding a new UI layer.

There's certainly Redux movement, because it solves few important problems almost for free. But React isn't bound to Redux in any way.

I'm a swift / go guy mainly but I've been looking at this space for a while and the only sane approach to me looks like ClojureScript with reagent / reframe or something along those lines.

But in a nontrivial number of cases it isn't, and then I use methods.

http://onehungrymind.com/build-better-angular-2-application-...

Since 0.14, React components can be functions, too: https://hackernoon.com/react-stateless-functional-components...

That is a bit of an understatement. Using the angular CLI the default is setting up a project with webpack with a single command. Webpack is wrapped in the "ng ..." commands for building and running. With "ng eject" the webpack config file is exposed and webpack is in the driver seat. It is not just "can" but it is really easy these days.

There may be reasons not to like Angular but articles focusing on AngularJS 1.x are not shining the light on relevant weaknesses.

Angular may be too late if one buys into the view that the growth in the JavaScript ecosystem has peaked or is peaking soon. My personal view is that the growth has been stunted by severe UX problems before ES6/Typescript and we are just at the beginning of an explosive growth phase with no end in sight.

Observable objects are tough to read in the debugger.

The main gotcha I found [1] was dereferencing property of an observable didn't trigger rendering. Didn't feel very intuitive to me.

Also, occasionally, I would insert a row into an observable array and nothing would happen, and I could never figure out why.

Using redux now, it's more explicit and full of boilerplate and ceremony, but I understand all the code, and there is far less magic.

[1] https://mobx.js.org/refguide/observer-component.html

For real!? This seems like either a critical bug or huge design mistake on the part of the MobX author.

I also cannot understand why you cannot make a Set an observable. It's such a fundamental part of programming!

In fact, Angular CLI uses Webpack by default.

Can you elaborate on this? I've been working on an Angular 2+ application that I think could benefit from a redux like state container a la ngrx/store. I'm curious if some of the issues you outline might also be applicable here.

Ionic, the mobile framework based on Angular mentioned in the article, actually does by default in it's `@ionic/app-scripts` that are used to build these applications.

https://webdev.dartlang.org/angular according to: http://news.dartlang.org/2017/06/a-stronger-dart-for-everyon...

Why isn't your comment Angular fanboyism?

Full disclosure: I prefer neither.

Full disclosure: I am not a web dev at all so my opinion is more valid.

Intellectually dishonest. The article linked to was from January 2016, around the time the first beta of Angular 2 was released. That code has all sort of debugging code in it, and the architecture changed quite a bit between then and the release in September 2016. (To say nothing of the fact that those benchmarks don't cover Angular 4, despite the preface in the article) With AOT in Angular 4, a site running in production is quite fast compared to JIT.

I've written a book on both Angular 2+ and a book on React. I've talked w/ hundreds of developers on both sides and I can tell you that people with different constraints (and backgrounds) will have a different response.

The author of this article cites "more ReactJS libraries on npm" to imply that React is the better choice. Some people love a la carte infrastructure and the power that comes from choosing each element in your stack.

Some people love to have those decisions made for them, because they just want to build their app.

It's often cited that React is "simpler" than Angular, and if you look at just the core that's true. But by the time you pick a data architecture, styling choice, router, etc. you're back at the same level of complexity.

Actually in React, you've spent a lot of time researching which components you want (and if they'll even fit together). The pro here is that you get just the stack you want! The competitive evolution of these libraries means that you _can_ have 4 routers and pick the best. But also, if you'd just picked Angular, you just use their router and move on.

Here's another litmus test: Do you want 'string' templates or JSX? (Now, I know it's technically possible to do either in both frameworks, but it's almost never done in practice.)

Almost everything that seems "more complex" in Angular is a result of string-based templates. DI, AOT, the *ngIf and `let` syntax, is all because you're doing templates in strings instead of code. How do you feel about that? Would you rather write templates in JavaScript/JSX? Then use React. Do you have designers doing HTML on your team? Then use Angular.

(Also the other opens by citing webpack, npm, and third-party libraries as a React-specific benefit, but that makes no sense because angular-cli uses Webpack, it's on npm, etc.)

Everything you're talking about is great in a vacuum, but stable APIs and backwards compatibility is more important to organizations in the real world.

I can't trust Angular as a framework anymore, as past actions are indicators of future behavior.

Yet the end result was still the same. Another lesson in branding for Angular.

I think it's worth mentioning that the API for the largest one of these (react-router) has had breaking changes with every single release, and takes a totally new approach to routing each time. So the question is more, 'How do you feel about changing your approach to routing every time you write a new app?'

Or maybe I'm just too old and bitter for React haha

You can npm install react-router@^3.0.0 and keep using what you know.

My biggest problem with Angular is the sheer surface area of the API and the dependencies between the different modules. Angular as a framework has 10+ different components, all of which are deeply integrated. All of this is wrapped up in Zone.js which produces some of the least helpful stack traces in history.

A React app may be a composition of 4-5 key libraries (state management, routing, authentication and potentially a form helper) but each individual library has a much smaller API surface area and the decoupling makes it easier to debug.

I recently rebooted a project that was built in Angular in React after over a week of trying and failing to debug a wide range of subtle issues in our implementation of universal rendering which absolutely broke AoT compilation. I won't deny that there's a high possibility that our code was the problem - it's just that there were no useful stack traces showing where to look and digging through the different libraries was a mission and a half.

There's a lot to be said for composing a few independent libs with small APIs, rather than having a gigantic framework whose documentation is only skin deep.

I don't disagree with the facts-on-the-ground of your post, but I think you're drawing a mighty false equivalency and this line highlights it. The pro here, for a React-based stack is that you are forced to understand the tools involved well enough to make meaningful decisions (if you're a competent developer). By the time I was done evaluating routing libraries, I was confident in my ability to write my own, effectively--and so I didn't have to because I was able to adopt the library of my choice's mental model immediately. If you "just want to build your app", your app is gonna blow up (not might, will, given a long enough timeframe) and you're not going to be equipped to fix it.

Passive consumption is unwise for programmers. We've seen it bite people forever (be it the "all things come from Microsoft" era of .NET that they're just shaking now or the "Spring does it for us" era of Java or most of Rails pre-3.0).

The stump-dumb-simple routing layer of your JavaScript handwavey crap is one that You Really Just Gotta Know; it's literally central to everything you do in a SPA. And yet the overwhelming majority of AngularJS folks I have ever met--and, to their discredit, way too many keypuncher ReactJS folks, but a significantly smaller proportion--have no idea what to do if their web framework spits the bit. And my contention is that having to make choices means the likelihood of a baseline understanding of what chose choices mean is way higher.

There are plenty of capable developers who work on and choose to use AngularJS. I've worked with great ones. But, like the other environments I mentioned before, it sure seems like they brought that capability to AngularJS rather than had that capability fostered by AngularJS in a pedagogical manner. And that's troubling to me, because these folks are going to be writing software that you and I depend on, too. I'm not hanging people for not being able to work meaningfully with the JavaScript runtime or understand how the browser works internally (though these are handy to know, most of my knowledge of JavaScript comes indirectly from embedding first SpiderMonkey and then V8 in a game engine once) or how their OS handles process segmentation to sandbox off their web runtime environment (not a super complicated topic but, sure, out of scope) or how their OS handles memory (this one, ditto) or or or--I'm saying you gotta understand the thing your hands are on all the time and that tools that attempt to swaddle you in a nice comforting "you don't need to worry about that" are gonna put you in a real rough place when that doesn't hold.

There were no abstraction breaks. C++ compiled, the thing works, the same goes for ng2 with TS. Ng1 is just plain ugly, but works fine.

I like React/JSX, FRP, I hate the size of the bundles Angular spits out, the byzantine boilerplate required to put something on screen and to make components interact, but it works, and it comes as a full package, and it keeps getting better.

The design principles of Ng are sound. Ng1 was overcomplicated. Ng2 is okay-ish.

I think ng lacks the "documentation" that the React ecosystem must provide due to its separatedness/modularity.

But my main point is, that basically good developers will compare those routing plugins/libs, and those same devs can solve problems when ng2 spits at them. And newbie frontend devs jump on the React is small and simple hype train and take the first tutorial and then get lost in that jungle. (And I'm not saying this can't happen with ng1/2, but neither codebase is about teaching programmers, so that's a very fringe aspect of this topic.)

If you "just want to build your app", your app is gonna blow up (not might, will, given a long enough timeframe)

I feel pretty safe building stuff using technology (Java EE) that I only know the surface. (i.e. API) of.

I think that we should choose solid, well though out libraries that we wouldn't have to fix by yourselves.

and you're not going to be equipped to fix it.

This seems to be more of a problem in JS land where tecnologies seems to get born, hit peak popularity and die within a few months.

In such a case I guess it makes a lot of sense to choose stuff that I could rewrite myself.

I don't think it's relevant for evaluating tools.

It is only relevant when hiring as you would like to find developers that is competent enough to grasp low level stuff at least at a rudimentary level.

In this case some side interest in routing frameworks might be indicativ regardless if they prefer to work with angular.

Come on, that is not an honest reading. The author uses those numbers to demonstrate the health and maturity of the respective ecosystems. The power of choice is a bonus for those who choose to leverage it.

I guess when your open source library passes a million downloads per month, you are not worrying too much about marketing anymore. So i'm not quite sure why it's so important for the author to declare one and only one winner in the race. Both React and Angular users are benefiting from the competition

But now you have zone and it's leaky. See this stackoverflow question for example: https://stackoverflow.com/questions/43097291/firebase-datasn...

Edit: wrong link

> So i'm not quite sure why it's so important for the author to declare one and only one winner in the race

Attention seeking I guess

Angular 4 is an improvement over Angular 1.x, but Angular's main problem is still needless complexity, both in syntax and concepts added by the framework, and a totalitarian approach, in the sense that Angular seems to want to replace vanilla JavaScript/DOM/Browser API's with it's own slightly different and unnecessary versions. What you learn developing in Angular is therefore specific to Angular and not transferable to other domains. Personally I find that depressing and demotivating.

Angular 4's HTML templating syntax is terrible. I get the feeling the deliberately set out to make it as complex and inconsistent as possible — it's hard to phantom how else they ended up with such a mess.

Angular seems to have been inspired by the worst of Java EE from days of yore, it's riddled with needless complexity and ceremony. No one should have to work with that with the nice alternatives we have today.

This means that, until recently, you couldn't use CSS Grid in React components, because every single CSS property that you want to pass through JSX needs to be explicitly whitelisted[1]. No other front-end framework has gone as far as React in trying to replace the vanilla web platform with its own technology and idioms.

[1] https://github.com/facebook/react/pull/9185

Angular's new template and component syntax have a learning curve. But they retain a far closer mapping to what's actually alive in the browser's DOM. A component instance actually wraps a native element, instead of being a function that emits a tree of objects that eventually get turned into DOM elements by some opaque virtual DOM process. When you grok what the syntax means, it's actually a rather elegant way of expressing binding to the HTML element properties and attributes and between component instances.

There are arguments for and against both approaches, but I don't see anyone on the React side of things even trying to understand them. Instead, they dismiss Angular's approach based on five minutes spent scanning syntax examples, and adopt a cult-like mindset that React is the silver-bullet for software development, and that alternative approaches are wrong and evil, and that anyone who uses them or likes them is stupid and/pr incompetent. It's a very arrogant and unpleasant attitude.

This is one thing I don't like about React. If my intention is to create an HTML template, I would like to use HTML to do that, not through another layer of indirection (JSX).

>> No other front-end framework has gone as far as React in trying to replace the vanilla web platform with its own technology and idioms.

I think Angular does something similar with zonejs while trying to patch every javascript async function. I just don't like this approach at all. Because of this, while using Angular, I have to keep in the back of my head that the setTimeout function that I'm calling is not the native setTimeout function. Most of the time I don't have to worry about it, but it still bothers me.

I think HN members often forget that there is a whole world of software development outside of the big tech giants and startups. Often the tooling and frameworks used there is very different.

The biggest win for Angular 1 was push for code reusability throught enforced modularity. This matters a lot for both "big co." and "outsourcing sweatshop" type collectives.

To defeat React, Angular guys will need to defeat Angular 1.x first

All the data I've seen indicate that both Angulars, combined, account for twice as many production code bases as React. I wonder where you got the idea that "React has won"?

"Won" usually means, "the thing that people most want to read or talk about at the moment".

And yes, this represents a steep drop-off in the number of jQuery-centric applications in the past couple of years.

Edit: I thought I had bookmarked the Web site where I saw these numbers, but I couldn't find it before running out the door this morning. Suffice it to say, the JS landscape is changing rapidly, and assumptions that were safe even 12 months ago are not valid today. jQuery is fading quite rapidly, and though it won't disappear any time soon, and, increasingly, it is no longer seen as a good choice for large apps with tons of business logic.

What I'm saying is not that jQuery is the end-all-be-all. It isn't, and trying to build a highly dynamic web application with tons of client-side logic around jQuery is indeed a recipe for spaghetti.

What I AM saying is that most web applications (especially in the enterprise business world), simply AREN'T all that dynamic. They are primarily driven by full page loads rather than AJAX, and server-side logic rather than client-side code.

On HN, the terms "web application" and "SPA" are practically synonymous. But outside of a few social media titans, and the startup community, that's hardly true.

Life has gotten toughter since then

These things are prime selling points of Redux and it's interesting that they are simply unimportant bells and whistles not worth the massive increase in complexity and cognitive load that Redux brings to ReactJS applications. Use Redux and you have to write a lot more code, really for no good purpose when in most cases you can just store a (HERESY!) global variable and get straight on with the job without twisting your mind around actions and all the other Redux guff.

Redux is an anti pattern.

This article also breathlessly praises webpack, which is a massively complex and configuration heavy JavaScript tool and one of the prime culprits responsible for the JavaScript build tool ecosystem being so damn complex. Webpack needs to go the way if it's predecessors and he replaced with something simple.

I notice also that in these projects, every pull request takes many files. Whereas in an Angular 1 project there would be an update to a template and a controller, now each PR comprise updates to a reducer, a container, a component, a saga, a 'lifecycle component', an action creator, and a props schema.

As for Webpack, I don't understand the popularity. I find configuring it awkward, not least because it relies on third-party plugins of highly variable quality. Most plugins are very poorly documented, and those that aren't invariably seem to have big fat DEPRECATED notices. It seems that any plugin that makes enough assumptions to be useful is inevitably chucked in favour of something that is totally configurable but by default equally useless. YMMV.

At least with Gulp, I could step through a build process and write a little bridging code when two plugins stepped on each others toes. Webpack doesn't give me any such chances.

It's not managing the combined state of a massive 1000-system enterprise mess, it's just pushing some shit out through a browser.

Redux itself can cause people to write quite a bit of boilerplate, however it massively improves testability, and if you use the correct abstractions and debugging techniques around it definitely decreases cognitive load. The problem is that it's possible for people to misunderstand how it should be used and shoot themselves in the foot.

I agree that Webpack is complex, however it is much more manageable than a series of folders containing obtuse Grunt/Gulp tasks, ad-hoc scripts and wrapper plugins.

None of it is necessary. Your code base will thank you as will the gods of software simplicity when you rip out all the Redux and Redux tooling and write this.app.globals.myvar='selected'

Honestly, think about all the time you spend writing not React code but Redux code - it's crazy and totally wasted time and effort.

  this.app.globals.myvar='selected'

Your 'solution' is a bad practice, and Redux is a huge improvement over it.

Generally, it's easy. My state variable represents a single concept in my problem domain, so there's usually only a single source of truth that would ever update it.

> What if two or more bits of logic try to set this variable at the same time

Generally, this will only happen if the variable is actually a derived property, rather than a primary one. I handle this by making my primary properties observables, and my derived properties read-only computeds. Taking this approach, I don't think I've ever had the quandary you describe, and I've built everything from very thick SPAs to very thin and nimble content sites.

> How will you control that `myvar` can only be set to particular values dependent on other state?

It seems to me a matter of simple discipline.

> How will a QA engineer demonstrate to you that it was this state change which broke your application?

She might write a failing test case, or use the debugging tools I've added to the console. She certainly wouldn't mess about with something as proprietary as Redux devtools, because at that point I'll be unable to move to better JS technologies without getting cross-team buy in. At most companies, that basically means it just won't happen.

You have effectively advocated for both NIH syndrome and a social solution to a technical problem (effectively "it is possible to write error-prone and difficult to debug code so we should ask everybody in the team to be more disciplined" vs. "lets make it impossible to express error-prone logic, and lets make it easy to observe our state"). I think Yaron Minsky's "Make illegal states unrepresentable" is appropriate here.

I suppose the reason I don't 'get' Redux is probably that I don't 'get' the problem it claims to solve. Redux developers seem to say their issue with prior frameworks was that it was difficult to understand where state changes came from. But that's just not an issue I've had in the apps I've built.

Maybe the apps I call 'thick client' really aren't? Then again, I've done a fair few gigs in this game, on lots of kinds of projects, so I'd expect by now to have the perspective to say which was which.

That experience also makes me a little stubborn. I've had a few exchanges like this, where people have reacted with incredulity. They remind me a little of the arguments I had convincing people to abandon 'semantic' CSS, or grouping templates and view logic into components. I think history was on my side, at least in those cases, so I no longer feel abashed to walk against the crowd.

Prior to React/Redux we used two-way data binding with first kendo then Knockout.js in a non trivial SPA. It was a nightmare to figure out where certain change events came from. It became a big ball of (un)observable spaghetti. Now you will tell me that our problem was that we let it come this far, and I totally agree with you, but the whole app was started years ago by inexperienced web developers (they were C/C++ devs), then it grew historically into an unmaintainable monster. This was long before I joined the company, and my team is now like the 4th generation working on and refactoring that code.

Redux makes it laughably easy to figure out where state changes come from. Not only that, but time travel debugging is a thing. For the parts that are mostly React/Redux, we made a little debug UI for QA so that they can serialize the last n states, send it to a database and automatically link it to issues. It's still more or less a proof of concept and not as useful as it could be, because not everything is stored in Redux yet, but it did show us that once we are where we want to be it will be an incredibly useful tool to reproduce bugs. Besides that writing unit tests for React/Redux is also easy, compared to other libs/frameworks.

May I ask with what kind of technologies you've been working with so far? Because reading your comments gives me the impression you live in a perfect world, with highly experienced and disciplined team mates, with no problems what so ever. If so congrats, you've won the lottery I guess.

But I don't have real experience with it. I just extrapolate from general overusage of strong (but inappropriate for smaller projects) tools in JS world and subsequent annoying whining about "JS fatigue".

React is pain to debug unless internal React error catching logic fires

With vanilla js, things are as simple as putting breakpoints in code and running it in Chrome's standard debugger

In software development simple = understandable and reliable.

Eventually you are going to get bugs, and you are going to have a hard time tracking them down for the reasons I've described.

It might be okay if you work on small projects without many team members, but in larger projects it's extremely annoying to have these kinds of issues.

I read:"Sometimes you are going to get event bus." Indeed sometimes simple event bus (pub-sub etc.) could be sufficient for replace Redux. EventEmitter is already a dispatcher. And then you can easily listen to each event in your app, like in Redux.

I think the key to the scalable apps is good architecture (and correct design patterns), not framework.

And Redux is good as education tool. It encourages people to use one global event bus("dispatch" function), it educates about principles of functional programming. It shows people advantages of event sourcing and CQRS. I think the most value of Redux is that people got educated.

But I don't think Redux (at least Redux alone, without Redux-saga or other solutions) is good tool for use in production code. It's too low level. Too many moving parts. No clear way "what should go where". And JS sucks when comes to immutable code (either Object.assign / ... mess or necessity of using third part library like Immutable.js)

Additionally people don't know how to use it properly. Redux codebases are usually much worse than Redux really demands (e.g. people use ugly switch/case despite the fact in Redux docs there are instructions how to get rid of them: http://redux.js.org/docs/recipes/ReducingBoilerplate.html#ge...

When I hear about these apps with a heavy reliance on client side state I wonder what the heck they are doing... if you've got so much complex data/logic does it really belong in client state? I'd see it as a problem and try to architect it out, or store it somewhere.

It's obvious you have no idea what you are talking about.

Try looking at egghead.io tutorials; Dan Abramov has a series showing the implementation of redux and it really is quite tiny. It solves one problem and solves it well: ensuring that components get notified when state changes.

> extra thousand lines of Redux code to remember state

Sorry for yet another ad hominem attack, but this just shows that you are doing something wrong. Yes, Redux requires some amount boilerplate code, but if you need thousands of additional lines of code for state management, then you are lacking code abstraction skills.

I think you're underplaying this. The Redux apps I've seen thread data through a great many layers - action creators, actions, reducers, sagas, schemas - and I think it's fair to say that compared to other projects, Redux apps have very long 'chains of operation' (I want to avoid value-laden terms like 'structure' or 'bureaucracy').

Is it worth it? I'm not sure. The Redux apps I've seen have used this 'highly formalized' approach to handle quite simple interfaces. Maybe I'd have different feelings if I was writing something bigger?

It's not that I hate Redux, or think it out and out 'sucks'; but I've worked on a lot of projects and first Redux ones I've worked on seem unusually difficult to reason about, and a few of my colleagues share my feelings. We feel like it is hard to reason exactly what an event or command exactly 'does', and that the diffusion of behaviour across files plays a part in that.

It is true that if you do Redux "by the book", as taught in the official documentation, then it is indeed quite verbose and confusing in the beginning. But once it makes "click" and you start to understand what the point of all these moving parts is, then it's possible to come up with thin abstractions on top of it to reduce the boilerplate. It would have been great if there was a common "standard" way how to do this, but on the other hand, having the flexibility and power to do things how you want, to make it fit your team and project, is quite nice.

For example, we never liked those huge switch statements in reducers. We just use plain objects, where the key corresponds to the action name, and the value is the reducer function. Not really a big deal, but it just shows that you have the freedom to lay out your Redux app however you see fit.

We also saw no real value in strictly splitting up actions, action creators and reducers among multiple files. We simply put actions, action creators and reducers that belong together in a single file.

And then there is the possibility to use middle wares, which can greatly help in debugging and tracing down actions.

So far everyone in my team is very happy with Redux (and React of course).

I think that's a much more pragmatic approach for smaller applications.

I just became less dogmatic about it. We all have been taught how important it is to separate HTML/CSS/JS, but then came React along and put HTML into JS, many people were outraged, including me. I thought I'd never use that crap that violates basic principles of software design, but here I am and I'm loving it. In the context of UI it makes sense to me. Same with Redux.

Could you please give me an example in which cases you think it could become problematic to have actions, action creators and reducers in a single file? In an application that is not small?

I think applications can be architected that don't need it.

You can build an application without functional state management. Of course you can. But, frankly, you can't demonstrate conclusively that you know it's correct or where incorrectness stems from. Which strikes me as something of a problem, and one that does violence to the verb "architect".

If you use @ngrx/store, they can be used with Angular2+ as well.

https://github.com/ngrx/store-devtools

Didn't you write AngularJS code then?

As the article riffs about at length, Angular (Angular 2+) and AngularJS (Angular 1) are fundamentally different.

https://github.com/ngrx/store

On a recent project I started for a client, we did a full evaluation of React + Redux vs Angular 2/4 and NGRX.

Angular's first-class support for TypeScript, and RxJS is incredible when leveraged properly. Integrate this with NGRX for Redux style state management, and you get a compelling solution that is miles ahead of the React/Redux combo if you can get over the template syntax (instead of JSX) and the opinionated flavour of Angular.

It's difficult to offer an alternative opinion in the HN echo chamber, but we're having excellent results using Angular CLI + Angular 4 + RxJS + NGRX. It's worth the steeper learning curve, IMHO.

Anyone who understands the architecture of one should be able to learn the other relatively quickly. I haven't personally used Angular 2/4, but it looks like a really solid and opinionated solution. Some people don't want to spend 3 days researching thunks vs sagas vs observables, so I'm glad something like Angular exists.

Also, author is praising features like rx, time travel, webpack but does he know that all these are baked in angular as well? ngRx is very solid maintained project that actually works with all time-travel debuggers. And webpack is built-in in every angular project.

- Declarative UI as a pure function of state

- One way data flow

- Frameworks that use plain language features and functions, rather than template-like DSLs

No need for framework holy wars, but objective speaking these sorts of approaches are objectively the right future for UI development imo.

Angular does one way data flow. It also allows for two way binding. The choice is the developer's.

So your argument boils down to using language feature over the template DSL. I think it's more important to consider state management, code reuse, and inter component communication (perhaps also a part of state management if using something like Redux).

In my experience, I like the React way of defining components and functionality a lot better. The errors that Angular spits out from the HTML-templates are difficult to parse. There's also an unfortunate combination of a fractured community and incomplete first party documentation that makes Angular hard to ramp up on.

That said, Angular has a huge advantage that has made developing in it a lot faster for me. It's got everything right there. Angular doesn't have unique functionality, but it starts you off with a standard set of design patterns that stand you in good stead. React is just a frontend and when you're new to the space you don't know what else you need. Frequently, the productivity gain of not having to think about how to solve a problem is greater than solving the problem the "right" way.

Realistically, most teams solve this problem by having a senior team member who can pick technologies and design patterns. I haven't had that luxury on this last project, so I appreciate the Angular ecosystem. Javascript is great, but it's still very wild-west like.

I don't think the OP has ever used Angular CLI or followed Angular development. If he had then he would have not written this article since a majority of his claims about Angular are wrong.

I regret nothing.

Vue deals only with the view layer. So I would't directly compare it to Angular. But the authors do give you Vuex, for Redux-style state management, and Vue-Router which does exactly that.

Alternatively:

- use a second Vue instance as an event bus. Bonus points as the Vue devtools list all the events fired. Makes it easy to debug.

- due to it's reactive nature, Vue let's you implement a single source of truth quite easily. [1]

- Using dynamic components, you might not even need a router [2]

Personally, I've tried to use the single source of truth pattern but quickly resorted to Vuex. It just resonates with me.

[0] https://vuejs.org/v2/guide/comparison.html#Angular-Formerly-...

[1] https://vuejs.org/v2/guide/state-management.html#Simple-Stat...

[2] https://vuejs.org/v2/guide/components.html#Dynamic-Component...

That said, the other half of my job involves .net/c/assembly/tcp, so I always worry I'm a step behind on web dev because I'm not devoted to it full time.

If you're building a large enterprise app with lots of engineers not familiar with either framework, Angular 2/4 wins hands down.

As much as people complain about Angular, I think it's completely fine for the majority of use cases at large scale. So is React. So is Vue. Even Angular 1 is fine. In practice I've never run into most of the issues people preach about. Two way data binding isn't the devil. One way data flow isn't a panacea.

My developer happiness has always been contingent on the quality of my coworkers, and not on the framework itself (all of which, I feel, are great in their own ways.)

There is absolutely no reason to dismiss all their efforts.

I can provide a critique and state my preferences for a certain framework over another without demeaning the project I don't find preferable.

The O/S

> mature ecosystem of tooling and libraries

That tells me the author is either blind or so lost in his world that he thinks this is actually true.

This fanboyism around languages and frameworks is apparently ever-growing. Haven't we learned by now that everything is about trade-offs and there is no One True Way?

Furthermore, because you have to rely on third-party libraries for all the features that React doesn't provide, you have to worry about separately keeping them all up-to-date. What if there's a critical bug fix in the latest version of your HTTP library, but it's only compatible with the latest version of React, which isn't compatible with the router version you're using? In my experience it takes a lot more time to keep dependencies up-to-date and working together with React than with Angular.

The only thing in that list that I have ever felt a need to use a library for is routing.

All the SPA projects at our company are Angular based and I don't see any plans to change it.

Back in 2010-11 I first tried out Angular to experiment with the SPA concept. This was hard to reason with back in those days, as most client DOM was still server-generated (at least for initial requests). It was really a big paradigm shift for a lot of developers, myself included. I found that Angular's foundations (directives, services, controllers, etc.) helped to constrain my thinking in ways that made the SPA concept more clear. The angular ecosystem in those days was really a haven of SPA-oriented thinking that couldn't really be found elsewhere on the web.

Fast forward to now, SPA architecture is essentially the norm. Almost every web-enabled device now has a full javascript runtime. Additionally, it has actually become an anti-pattern in some cases to force server-generated DOM on the client, as each clients' JS runtime is usually better suited for interacting with its specific DOM quirks and handling device features.

Now that SPA has become a more mainstream way of thinking, developers have begun to seek out ways of implementing this architecture with fewer constraints (and arguably bloat) than Angular could bring to the table. Frameworks like RiotJS are starting to explode in popularity because developers still want some fundamental SPA-style framework, but also want to maintain the ability to interact with the DOM in a more direct and vanilla way. When working with Angular, I found myself constantly trying to find (or god forbid write) the angular-compatible directive wrapper for whatever 3rd party javascript component I wanted to add to my project. Being able to simply include something like moment.js directly in my project and use it exactly as their documentation indicates has been a massive productivity gain for me and my team.

I took a few cracks at Angular 2, but there was something that always felt off about the component system and how more complex pages were composed. Their attempts to bring typescript into the fold only served to confound things even further for me. I know this is a hugely-subjective thing, but it was basically the end of the road for my Angular experience. It took me 5-6 weeks to get my team truly productive on Angular 1.x. I was able to bring them up to speed on RiotJS in a single afternoon (the router being the hardest bit).

Someone who understands the statement, could you help me? Does it mean that there is a design pattern so light that some particular library which implants it would be trivial to recreate?

Any answer, I beg you, please clearly distinguish between the very different concepts of design patterns and named code projects which implement them.

I think the ones that really have invested in making React work in their org but move a _bit_ faster, but Angular making strong decisions and providing really good patterns out of the gate is extremely valuable.

Both are great frameworks, so adopt works best for your company, your team, and your product!

> We can be almost certain that React & React Native are a competitive advantage. We can see evidence in how Facebook simultaneously launched Snapchat-like “Stories” across four applications (WhatsApp, Messenger, Facebook, and Instagram) in its product suite.

> It’s not hard to infer that React was a key reason why Facebook was able to do this so rapidly.

Is there any actual evidence that React / React Native was used to build the Stories feature for any of these apps?

I don't think JavaScript fatigue peaked in 2013. FTA:

it is quite easy to maintain a large, flexible, well-engineered SPA with React, Vue, or other lightweight JS libraries, even at enterprise companies with large teams.

Vue's initial release was just over three years ago. Other technologies used by enterprise companies has usually proven itself for a decade or two. Articles like this don't help with JavaScript fatigue.

It still boggles my mind thinking about the massive amount of effort google's large team spent on ng2, library authors spend porting ng-bootstrap, plus every app that will be rewritten, plus the interim confusion of having 2 versions of libraries, documentation pages, etc. For improvements in some areas, more complexity in others. And I think to the point of the article, it feels far behind react in a lot of advanced development features as it is still trying to get a solid footing. Just saving a file and waiting a few seconds for a full page reload is much worse than the gulp then webpack browserupdate system I setup for ng1 apps, and the cli is not _that_ much better than a custom gulp task I setup to generate new components and services in ng1.

My theory is the primary motivation for ng2 came from the angular team not wanting to maintain a js and dart version of the library, so they wanted to move it to a single codebase that could compile from nativescript/typescript to both, and it was an easy sell to all the people who identify in the angular tribe.

Some specific things I don't like in ng2:

- Too many ways to do forms. Template driven vs reactive, with some things like mdAutocomplete I could only get working w/ reactive. You can do [ngModel] + name attribute, [ngModel]="name", [(ngModel)], formControl, formControlName. Little things like adding `Validators.required` isn't picked up by the view, so you have to specify required there too to get the little (*) asterisk in the view for mdInput

- Testing got much harder to do, with mocking every dependency. Just when ng1 made frontend unit testing pretty painless to do, it feels like a step back.

- The DI system in general feels like waaay too much complexity for the much smaller benefits it brings now that `import`s are available. I was reading the docs to try to figure out an equivalent to a factory function and I realized even if I could figure it out, another developer or myself in 6 months would not understand it. Mocking imports for testing would be good enough, I think.

- Unless you plan to be an "ng2 developer", dipping into the 100+ ;) rxJS observable methods is a good way to confuse your teammates or future self. Have fun remembering what mergeMapTo vs switchMap vs forkJoin do. Observables are cool, but imo another case of too much complexity and too many ways to do things for the benefits. I haven't seen good guidelines of at which point in your app do you transition from observables (returned from http request) to plain objects - should you pass observables down through components for things that can change, or rely on the component seeing its input property changed? Should I implement a snapshot property on my objects that can change, similar to how they do routes? It is silly to me an http request response is modeled as an unending sequence of events, instead of a promise. The only benefits I see like being able to specify `retry(3)` could be implemented as an option in your api service that wraps http, and would probably be more consistent that way.

- A lot of small things are gone, like a capitalize pipe, ngFor iterating over objects. A little slower when getting started on an app when you have to add them yourself. They got rid of things like http interceptors and route resolves, and are adding them back in now after people complain. Even stuff like adding a query param to a url required a bad java-like api and multiple lines of code. They improved that since, but why start w/ a step back from ng1?

- Speak of route resolves, they have gone from a simple 1 liner in the route definition to being a 10 line standalone service, which you have to import and add to your providers array.

- Hasn't been an issue for a while, but having your global ng-cli which housed the webpack and typescript config(?) go out of sync w/ your local version, and your angular/core version, was a really confusing and painful upgrade.

- I like typescript, but it does have strange errors where it seems to have an older version of a file cached and you need to restart the server to fix it. Seems to happen more when importing a class that isn't @Injectable()?

- It is slower. My livereloading browsersync ng1 apps were faster and more fun to work on.

- It is a huge pain to rename things or reorganize your files. VSCode was rename symbol which is nice, but to stay consistent when renaming a component you need to rename: each of the 4 files+directory, all the imports, the `selector` and all tag references to it across the app, the `.my-component` css classes. I do a lot less refactoring of component names or directory structure in ng2 than a glob import style ng1 app, where you don't need to manually requiring everything.

Hmm, maybe should write a blog post about this.

Wasn't performance meant to be the whole raison d'etre of the rewrite?

Happy for someone to point out a better way for Polymer 2 dependency management that feels... less dirty.

No, they weren't. It's just a different way to manage state. And VueJS employs two-way binding so I'm not sure what was the intent here.

> Redux brought predictable, functional, maintainable state management to JavaScript.

Stopped reading here. Too sensationalist.

Two way binding is an anti-pattern in Vue. https://vuejs.org/v2/guide/components.html#One-Way-Data-Flow

You actually get console warnings if you try to affect state in that manner.

And making child controllers directly alter the state of their parents is generally thought as an anti-pattern in angular 1 too, as far as I understand.

>VueJS keeps two way data-binding between the template and the component

In what sense? If you need to update your data on the JS side from the DOM you have to use events. There's v-model, but this is just syntax sugar for binding an event on input to update the value prop.

Which is why calling two-way data binding in js a "bug" is so weird (for lack of a better word). In angular, two-way data binding is, ultimately, also syntactic sugar over DOM events.

For that matter, everything every frontend framework provides is syntactic sugar over vanilla javascript.

<input v-model="someProp">

is equivalent to

<input v-bind:value="someProp" v-on:input="someProp = $event.target.value">

Which, as far as I understand, is exactly how React handles it and is deemed one way binding. ¯\_(ツ)_/¯

    while(true){
      if(dislikeAllCurrentFrameworks?()){
        inventNewFramework()
      }
    }

One thing though - Facebook succeeded because of the sheer amount of money plowed into the team. Our team is succeeding with Angular at the moment and feel pretty strong that it solves our front end rather splendidly.

Disclaimer - I do like React, it has its place.