15 ms·
Angular 2/4 Is Too Little Too Late
- forgottenacc57 9y ago>>time-travel debugging, hot module reloading, and simple and easy undo/redo capabilities 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.
- onion2k 9y agoI don't know enough about React to say whether or not I like Redux, but I've written enough Angular code to know that Angular's lack of a good state manager is a problem. A lot of Angular apps end up storing an object in $rootScope that's treated like a global state, and that leads to weird side effects and bugs if you're not careful. Something like Vuex would be be a great addition to Angular.
- Sujan 9y ago> ... $rootScope ... Didn't you write AngularJS code then? As the article riffs about at length, Angular (Angular 2+) and AngularJS (Angular 1) are fundamentally different.
- forgottenacc57 9y agoMaybe I'm doing it wrong but when I (rarely) need state between components I just plop it into a global variable, of which there only ends up being s handful, and it's never been a problem. When I tried to use Redux first it burned my brain trying to grasp its architecture and how to write the various bits of code it needed, all replaceable with this.app.globals.foo=42
- shadow_banned 9y agoYour really a fan of the this.app.globald.foo = 42 eh?
- bdcravens 9y agoLike @ngrx/store? https://github.com/ngrx/store https://github.com/ngrx/store
- hamersmith 9y agoIn Angular 1 I have always used Services for storing state and sharing it between components. In the latest versions of Angular we have started using angular-redux.
- lhnz 9y agoRedux DevTools is immensely useful. Being able to see all of your state for your application and clearly know exactly which action caused some invalid state is great. It also enables QA to export the actions which caused some invalid state rather than needing to laboriously and perhaps inaccurately describe a series of steps. 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.
- forgottenacc57 9y agoI think it says it all the Redux comes with its own set of tools to see WTF is going on inside it. 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.
- simon83 9y ago> rip out all the Redux and Redux tooling and write this.app.globals.myvar='selected' It's obvious you have no idea what you are talking about.
- forgottenacc57 9y agoIt's lazy to make an ad hominem attack. I write big feature rich react apps without Redux and never hit any situation where I sit around going "damn I need time travel and hot loading and and extra thousand lines of Redux code to remember state."
- simon83 9y ago
- deleted 9y ago[deleted]
- jbreckmckye 9y agoI have always felt that the Redux projects I've seen are extremely bureaucratic. I don't know if they are outliers, if they are just 'Redux done wrong', but typically I find that every piece of behaviour is split out across multiple layers, generally in different files, to the point it is very difficult to reason what a particular button or event will actually _do_. 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.
- mmargerum 9y agoUndo / redo is a nice to have? If you are building spa web front ends the right way these are essential. Using modals with OK/Cancel buttons to confirm actions is not ok in a web app. It should work more like you are editing a document in a structured way hence undo becomes a requirement. Trying to undo in a web app where state is stored inside components becomes a nightmare. Redux makes this a heck of a lot easier.
- deleted 9y ago[deleted]
- jamra 9y agoThis reads as react fanboyism to me. I used React/Redux on a project and was unable to bring people up in my aging team. Now we are fully Angular 2+. It is much better for my newly grown team of 15. The action creator approach of Redux isn't very readable or maintainable. The module system in Angular is better for us. 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.
- andrewjrhill 9y agoCouldn't have said it better myself.
- simon83 9y agoI guess when you say "aging" team then I imagine your team members mostly spent their time in the OOP world, and Angular is definitely a better fit in this case. 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,...
- jamra 9y agoI actually really liked Redux, but given the size of my team, I would choose Angular every time now. It's just more complete.
- unoti 9y agoYou might like NGRX, then. It's basically Redux for Angular 2. http://onehungrymind.com/build-better-angular-2-application-redux-ngrx/ http://onehungrymind.com/build-better-angular-2-application-...
- bdcravens 9y ago>> Benchmarks for React consistently show its superior performance over Angular 2/4: https://auth0.com/blog/more-benchmarks-virtual-dom-vs-angular-12-vs-mithril-js-vs-the-rest/ https://auth0.com/blog/more-benchmarks-virtual-dom-vs-angula.... 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.
- Wintamute 9y agoI agree with this. It's a mistake to characterise this solely as Angular vs. React though. It's really about these things, - 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.
- jamra 9y agoAngular is mostly a declarative UI. I don't usually put logic in my templates. I do, however, like how react leans towards using language features instead of abstractions. 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).
- erokar 9y agoI agree with the article's main point. In the market share fight between React and Angular, React has won — and for good reason, I think. 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.
- stupidcar 9y agoIt's bizarre that you would complain about Angular replacing vanilla JS/DOM/Browser APIS and then say React is better. React literally replaces HTML and the DOM with its own XML dialect and virtual DOM. 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 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.
- Nekorosu 9y agoThough I do think Angular 2/4 is inferior to React/Redux combo this article is very biased and not good for a constructive discussion and comparison of those frameworks.
- laichzeit0 9y agoI moved to Vue from Angular 1 instead of React when I started a new project last year. I regret nothing.
- jamra 9y agoI keep hearing good things about Vue. Do you know how it compares to Angular 2? More framework than library? State management built in?
- caseymarquis 9y agoMost interesting pieces of vue are separate plugins. Ie vue-router for routing. I believe there's a state manager, but I haven't reached a level of complexity where I've needed to use it (I've got maybe 40 .vue components in an app which acts as a hub for IIoT units) Vue is just the V in angular's MVC, so there's definitely less to it. Using it with es6, webpack, .vue files, and vue-router has been a great experience. 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.
- iamacucumber 9y agoThe Vue guide has a comparison just for you. (might or might not be too biased, I don't know ng2) [0] 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-known-as-Angular-2 https://vuejs.org/v2/guide/comparison.html#Angular-Formerly-... [1] https://vuejs.org/v2/guide/state-management.html#Simple-State-Management-from-Scratch https://vuejs.org/v2/guide/state-management.html#Simple-Stat... [2] https://vuejs.org/v2/guide/components.html#Dynamic-Components https://vuejs.org/v2/guide/components.html#Dynamic-Component...
- romanovcode 9y agoI am using Angular4 and am pretty happy about it. Especially I am happy of the fact that Angular is opinionated framework thus it is easier to work in teams on one project because there is usually just one way (angular way) of doing things instead of 100 different ways in React. 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.
- GiorgioG 9y agoIt's hard to take this post seriously when this guy has barely 5 years in the industry. If you're building a large enterprise app with lots of engineers not familiar with either framework, Angular 2/4 wins hands down.
- jmkni 9y agoHow many years experience does somebody need before you will take them seriously?
- chrisco255 9y agoAngular 4 is a few months old. It's not mature and the ecosystem is immature. Even the official Angular Material2 project is still in beta. You contrast this with React's ecosystem of UI components that have been built up over years...it's no contest. You can build better looking, better performing UIs with much less effort and they work great, even in IE11 and Edge.
- pjmlp 9y agoI doubt we will ever do React. All the SPA projects at our company are Angular based and I don't see any plans to change it.
- anton-107 9y agoAngular 2+ user here: - Components have nice API and are pleasant to use - Dependency injection containers out of the box are good for those who value inversion of control in their codebases - Change detection is good and fast. Gone are the times of leaky abstraction of the digest loop - Tooling has caught up: Angular CLI for rapid start, server-side rendering works just fine. You are using npm, webpack, typescript (brings es2016 features to you), modern testing frameworks and what not - Redux works nicely with Angular2+ as well, it's not exclusive to React - You can wrap pretty much any 3rd party browser widget into Angular component within maybe one hour of work 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
- shusson 9y agoYou about summed up my experience too. > 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
- tuan 9y ago> Gone are the times of leaky abstraction of the digest loop But now you have zone and it's leaky. See this stackoverflow question for example: https://stackoverflow.com/questions/43097291/firebase-datasnapshot-observable-not-updating-immediately-after-login-via-redire https://stackoverflow.com/questions/43097291/firebase-datasn... Edit: wrong link
- jinder 9y agoThe prevailing opinion on HN seems to be that React is great, and monolithic frameworks are bad bad bad - especially Angular. 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.
- Stoids 9y agoTo add to that, most new React/Redux projects are settling on the same technology decisions as the Angular team. TypeScript/Flow, RxJS for async/effect handling (or Sagas). React vs Angular is pretty negligible at this point. They are both component focused frameworks and that's the important paradigm and shared quality amongst all these frameworks. 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.
- luord 9y ago> Two way data-binding was a feature in 2013 and Facebook said it was a bug. It turns out they were right. Ember, Angular, Vue, and others would later adopt the one-way model. 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.
- ElatedOwl 9y ago>And VueJS employs two-way binding Two way binding is an anti-pattern in Vue. https://vuejs.org/v2/guide/components.html#One-Way-Data-Flow 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.
- luord 9y agoThat's about parent and child components, not about the state of a particular component. VueJS keeps two way data-binding between the template and the component; react does not and needs to handle events from jsx (or whatever one is using as template) explicitly. 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.
- ElatedOwl 9y agoThanks for the clarification but I'm still a little confused. >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.
- luord 9y ago> 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.
- rpeden 9y agoRe-post of what I wrote about this yesterday on Reddit: 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. :)
- Analemma_ 9y agoIt's even dumber than contemporary identity politics, because at least there you (usually) can't choose your identity and so there's a defensible case for firing back at people who try to make your life miserable because of it. But language/platform/framework fanboyism is just pure sunk cost fallacy: you spent a lot of time learning X, but if X was the "wrong" choice, then was all that time wasted? To avoid that outcome, people invest tons of emotional energy defending X.
- rpeden 9y agoI think part of the problem is that much of the job market is language/platform/framework oriented. So there's some value in defending the tools you know and use, because your value on the labor market depends on the market valuing your experience. 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.
- water42 9y agoHow to get upvotes on hackernews: write yet another clickbait medium article on how bad angular is. 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.
- jashmenn 9y agoHere's a litmus test for if you should use Angular or React: how do you feel about the fact that React has ~4 major routing libraries? 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.)
- albedoa 9y ago> 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. 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.
- emodendroket 9y ago
- xmatos 9y agoreact is crap and js devs are lemmings
- javiercr 9y agoFrom the article: > 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?
- chrisco255 9y agoNo. And it's a fair point. I might be reaching a bit. But I do think Facebook sees real productivity gains from using React Native in production and those gains benefit their velocity as a whole.
- rickcnagy 9y agoHaving just seen a whole bunch of React shops when interviewing for a front end position, a _lot_ struggle with React but also really enjoy it. Definitely don't see a significant difference in the end from Angular, they're really similar frameworks. 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!
- bla2 9y agoAt the peak of JavaScript fatigue in 2013 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.
- chrisco255 9y agoFront end technology has advanced rapidly in the last 5 years. You can't compare the back end as much. Although there's innovation there too from new languages and functional paradigms.
- ratbeard 9y agoI'd agree that angular 2 was a letdown. Seems like most people are like me and like typescript, the cli, and a better router, but those could have been incrementally added instead of starting from scratch. 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.
- Draiken 9y agoI stopped reading at > 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?
- SamUK96 9y agoUnless you're coding in https://en.m.wikipedia.org/wiki/Brainfuck https://en.m.wikipedia.org/wiki/Brainfuck
- aeturnum 9y agoI'm a mostly-backend dev that's been pressed into service on the frontend recently and I've worked on React and on Angular. 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.
- ernsheong 9y agoI'm hoping Polymer 2 will gain more traction. Anyone out there hoping for the same thing?
- empthought 9y agoI am. React is nice for consumer product development, but I think Web Components and Polymer will be much more effective for line-of-business and back office applications.
- ergo14 9y agoIt is gaining traction - almost 8k users on slack channel stedily growing - new components are getting released on webcomponents.org every day.
- ernsheong 9y agoI somehow find the dependency management system of Polymer 2 (loading script tags in a component), is going back to the old school ways/days. There is no dependency isolation, modules are loaded to the Global... v.s. ES6 imports via webpack, for example. Granted, module imports are not browser ready yet. Guess we'll just have to live with it for now. Happy for someone to point out a better way for Polymer 2 dependency management that feels... less dirty.
- addicted 9y agoOccasionally I have thoughts like these. And I often write them down. But rarely (never) publish because I am always hit by the idea that no matter how bad a certain framework/project is (especially open source), unless it's actively malicious, there are real people who are actually putting time and effort building and maintaining these projects. 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
- Achshar 9y agoI'll just be the sad puppy sitting in the corner writing everything in vanilla es2016/17. I never had any problems and everything works. The amount of code I write is no more than the angular code I write at work. Never used react but it looks like a jumbled mess. Vanilla JS is pretty sweet and has everything I could ever need.
- theodorejb 9y agoI strongly disagree with the claim that "React Is Much Simpler." React on its own may be simpler, but by the time you add libraries for routing, HTTP, dependency injection, date/currency formatting, animations, and all the other stuff that Angular provides out of the box, the complexity starts to look pretty similar. 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.
- TheCoelacanth 9y agoThere are already browser standards for HTTP and date/currency formatting. At most you need a polyfill if you want to support really old browsers. CSS transitions also take care of most use cases for animations. A library for dependency injection is just over-complicating things. You don't really need it. The only thing in that list that I have ever felt a need to use a library for is routing.
- colonelpopcorn 9y agoThis article ignores the power of Microsoft backing Angular in ASP.NET as a first class citizen with typescript. Most companies don't care about what stack they use, and if their Microsoft partnership agreement offers free Angular + TypeScript training? Most companies will go with Angular if they don't have specific performance needs.
- mnm1 9y agoReact won and those of us stuck on Angular 1 are mostly fucked. From that perspective, you'd have to be absolutely fucking insane to even consider Angular 2 after how badly the Angular team fucked up Angular 1 and all its users, leaving them in the dust. It's not about tech. Tech is irrelevant. I cannot trust this team to stand behind their software. Maybe that's because they build really shitty software. Fool me once and all that ... but IMO, you'd have to be a fool to use Angular 2+ after this fiasco.
- exclusiv 9y agoIs your problem more with the lack of proper migration to Angular 2 or with the differences between 1 and 2?
- ableton 9y agoI purposely chose to build on angular 1 instead of angular 2 when I started a project about a year ago. I'm actually glad I did, because every question you have has an answer already on the internet. I think it's actually good to stay behind the times in a lot of ways, let everybody else work out the bugs, then jump on board once it's all working well. Of course if I started now I would go with Vue, which I think is what angular 2 should have been - faster and simpler.
- bob1029 9y agoMy experience with Angular is that it was sort of the gateway drug of SPA architecture. 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).
- gregors 9y agoChocolate vs Vanilla argument here while(true){ if(dislikeAllCurrentFrameworks?()){ inventNewFramework() } }
- skylark 9y agoI can't help but feel like all of these posts are a bit overly dramatized. 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.)
- emodendroket 9y agoWhat I'd like to see is really mostly for them to just keep maintaining Angular 1.x. I don't care about "microlibraries;" I want a sane set of components that work well together, even if they're not all necessarily the absolute best in class.
- Manager 9y agoArticle is basically why use React over Angular. 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.
- brawny 9y agoThis is why I like Aurelia, its much lighter in terms of speed and amount of code, while still being a fully flared framework like Angular. Sure theres React/Redux Vue/Vuex but why do that setup when you can literally go au new hit enter about 4 times and your app is ready to code and build.
- sopooneo 9y agoThis article includes a statement I've seen several time before: "flux is more of a design pattern then a library or framework". This statement drives me to unspeakable levels of fury. What does that mean? It's like saying "Alvins ball is more a boulder in Yosemite than a mid century school of literary criticism". They're two totally different things! 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.