This rapid pace of major releases is a little scary. We're stuck running Angular 1.x because there's no reasonable upgrade path for us. We're a .NET shop and really like Angular, but after the 2.x cluster fuck, we're now thinking about going with something else entirely.
Angular 2 will not help your team deliver valuable web experiences to customers any more quickly or reliably than Angular 1. Probably almost certainly the opposite.
I'd argue most teams, if they're willing to go all-in on an SPA framework (which for most apps is a waste of time and money imo) would be better off with React + TSX.
Edit: Vue is probably closer to the "Angular way" with databinding, but component to component communication really needs something additional like Vuex. So, really, just use React/Redux and you'll get a bigger community with more real-world apps being built with the tooling.
Vue has one of the best component models I've seen. Angular's is some odd mix of SystemJS, HTML, RxJS, and TS...and it's dependent on it's custom CLI for optimization. It's probably the most complicated component model of the modern JS frameworks. And there's no JSX support on Angular.
I'd consider Ember to also be a top choice (if not the top choice) for teams who want to just go all-in on a framework and reap the productivity benefits. From all the frameworks I've tried, it's the one that's allowed me to focus the most amount of my time on actual product code, not plumbing.
Same here! Although it seems that Ember is getting little love from the HN crowd, we are very happy that we chose it for our company two years ago. I would encourage everyone who is looking be extremely productive and don't worry about plumbing too much to take a deeper look into it.
This is false. Angular 2 is a remarkable improvement over Angular 1. I started off with Angular 2 and Angular 1 code makes me want to barf. Typescript is a major improvement over vanilla javascript.
I agree with you. I came from a native app (macOS/iOS) background and joined the team maintaining an AngularJS app, and also worked on an Angular 4 app.
I felt like Angular 2 was the Angular team repudiating all the mistakes they made with the original AngularJS.
They don't even seem comparable. I too want to barf each morning when I work on the ancient JavaScript AngularJS app, and then moving in the afternoon to the more modern Angular 4 project, written in TypeScript, feels like stepping out of my time machine back into the modern era, with a spring in my step and a cool breeze wafting through my beard.
I would have no objections to joining a modern Angular project, whereas I would absolutely, positively never join an AngularJS project again (unless the fate of the human race depended on it, or something like that).
Love Angular and it's definitely a modern framework. Ironically it feels like I'm going back in time to old school RAD development with Delphi. I've been following Anders Hjelsberg all my career.
Vue has one big advantage over React for an Angular shop: the views are often trivial to port, while JSX is further syntactically from Angular templates.
I would say that Vue's core libraries are very well put together. Vuex, Vue-router, vue-resource, vue-axios, etc are all simple and easy to use. Personally, I wouldn't say either community has better supporting libs than the other.
Well, being able to reuse other people's software (number of npm packages available for the library/framework) is an important variable when choosing a tool.
You can go Polymer 2.x or Vue 2.x both feel similar to angular 1.5 `component()` approach. React might be a nice option too but it is probably requires more different way of thinking than the former options.
I disagree, our experience with Angular 4 is very good, we are iterating at very high velocity, at a very large scale (Enterprise Tools, Telemetry, Dashboards, Admin tools), and we wouldn't do it any other way. Testing tools are awesome, so the end product is solid if you use them, and with Lazy Loaded Modules + AOT Compilation the applications are very performant.
With vue you don't need vuex for most things actually. Medium sized projects can just have a global vue component they use as a central store and just set and get data on it. Simple. Transparent. Works like a charm for a lot of cases. Actually most people i know are not big enough for anything else.
I've just (as in, 5 minutes ago) deployed an application that we upgraded from angular 1.x (originally 1.2, up through 1.5) to angular 4 using ng-upgrade. I've also got another application that I've migrated over to react from angular 1.3.
I'm a fan of react. I appreciate the component-based approach, and it really addresses a lot of my complaints about angular.js. If I was starting an application from scratch, I'm almost certainly going to use react or maybe preact for it.
However, having been through this process, if angular had been as far along as it is now when I began the migration process on app 2 (angular.js -> react) I would have almost certainly opted to go with angular instead. Its not perfect, I still have my complaints with it (promises? observables? make up your effing mind already gang) but the migration path wasn't nearly as bad as I thought it was going to be. NgUpgrade is pretty good and gives you a path forward, and I think you'll find once you're in it that mostly, your angular 1.x stuff will be a fairly straightforward migration to angular whereas you're going to be doing more of a rewrite with react. I've arguably lost a year of time where I wasn't able to deploy significant new features while I got the full UI ported to react to make a clean release. That's valuable time I wish I could get back. (Its more complicated than that, but things usually are…)
TL;DR—Upgrade to Angular, its good enough that you get 80% of the improvements you'd feel moving to react or something else and you can preserve momentum.
Are you able to share any notable trimphs or tragedies that arose when using ng-upgrade to go from AngularJS 1.x → Angular 4?
On a scale of absolute clusterfuck to divine epiphany, how did you find that process in general? Did you leave the app running in a hybrid state with both frameworks bootstrapped, and if so for how long and how much did it suck?
(I always ask people about when the topic comes up here, but I am hungry for tales recent real-world experience! We will be doing this soon, I think...)
I did have a bit of a chest-thumping moment when I got routers from both versions playing nicely within the same app. Other than that though, it's been fairly devoid of spectacle (just the way I like it.) Most of my complications have arisen from the fact that this was my first project to get my hands dirty with typescript (which, on the whole, I found to be a really nice improvement) and there was an afternoon of headscratching while I was trying to figure out whether to be using observables or promises or both (for good or ill, I'm using both in various places right now.)
My migration path was to take a small new feature and implement it in Angular, but mounted with an angular.js template. That let me prove out the practicality of it on a big-picture basis. The next bit was to implement a larger area of the application and then get both routers working alongside each other. Then some refactoring, moving some of the bits I'd just finished into their own modules (before this, I was putting everything into the application module, which was getting crowded fast.)
So now I have new routes in the submodules and I'm just mounting new features that way. We're converting other modules as time permits but I suspect we'll have both coexisting alongside each other for quite a while yet. As long as maintenance on the older parts of the app is pretty limited, I don't really think its too bad. This isn't an app that's a labor of love or anything—the old stuff is working ok, and when something comes up that demands a lot of work in there, we'll convert it at that point.
I agree. I exlusively write React Frontends since 2014, and very minor things have changed.
It feels a lot more stable than before, where every project had homegrown framework stuff on top of backbone.js or jquery, or then using ember.js. There was just an awful lot of difficult discussion on how to design event-bus abstractions, global state management and general architecture
To me it feels like the frontend ecosystem has stabilized a lot, since the react paradigm is very robust and versatile. For most difficult problems, the solution is somewhat clear. Sometimes more, sometimes less elegant, but at least the timeconsuming disussions have become less frequent within a team
Most of my pain with the React ecosystem happened when people kept rebuilding react-router every 6 months. I managed one upgrade, but after that we gave up and stuck with the old version because it worked well for our purposes.
Certainly, the React ecosystem is full of stuff that changes gratuitously --- but my feeling is the rate of change on that stuff is usually inversely proportional to its utility. For instance: I'm not entirely sure why anyone uses an add-on router library.
Asking because I'm just getting into React, and not really clear on best practice yet. You seem to know a thing and have an opinion; will you share them?
Yes. There's a continuum of routing needs in React apps. If you're not strictly an SPA, you don't need it at all; the browser already does it for you. For a lot of straightforward SPAs, the most basic "display this component based on current tab" works. Past that, a "real router" is just a small piece of code that looks at window.location to decide which component to render, and a Link that knows how to use the history API.
I don't understand why people bloody their foreheads on react-router. The thing it is doing is simple enough to re-do by hand in any application.
You see the same thing with flux implementations: flux libraries change rapidly, because there's not that much to the underlying concept and it's easy to mess with them. But most apps probably don't need flux at all.
You can do this, but routes-per-page with parameters and working back/forward buttons with no serious deps is literally something like 15 lines of code. I think more people should just hack their own router together before introducing a dep for it.
It might be an interesting academic problem to chew on but there's edge cases there with history, route parsing, nested routes etc that are beyond beginner level I would argue. There's something to be said for using a massively popular lib like React Router that the rest of the community is battle testing for you.
* History: on modern browsers this is ~5 lines of code? Pushing URLs with pushState, triggering PopState events, and binding a popstate handler to trigger render changes.
* Route parsing: just use pathToRegexp. Yes, it's a dep, but it's an easy, well-understood one that does one simple thing you can get your head around. Or: don't use route paths with parameters at all (it's overkill for a lot of applications) and just use a trivial switch statement.
* Nested routes: why bother? The routes we're talking about are totally artificial. Having a formal, declarative route system in the first place is already a lot of "engineering". Just define your routes so they don't do that.
My argument is that the hand-hacked system that does this will be approximately as capable, future-proof, reliable and performant as the first production system anyone builds with react-router will be, the learning curve is shorter, the code you're building won't have APIs shift out from under it, and the final system will be trivial to port to react-router once that library stabilizes, if you ever wanted to bother doing that.
React and react-router are not the same thing at all. They're developed by different teams at different organisations. It's not fair to compare the two.
But we're comparing against Angular, which has a router and the rest of the kitchen sink. If your React app is anything more than a toy, it will almost certainly require most of that sink and you'll suffer the version churn of a thousand ambiguously maintained components.
This is just not true, and is I think a pretty harmful cargo-cult idea. People think "industrial strength React" means react-router and redux, even though neither of those deps are required for serious production applications.
As I said upthread, there's a spectrum of routing needs for applications. There are ways to use React (for real) where the server handles routing, because you're not running the whole app as a single page (but still want easy, clean dynamic behavior from React). There are serious applications that are single-page, but don't use a formal router because their application doesn't decompose into "routes". And there are applications --- not enough of them, if you ask me --- that just write their own routers, because 98% of what you need for a router can be accomplished in ~20 lines of code.
It's a similar story with Flux and Redux. Dan Abramov has been trying to convince people for years to start with just props and state and resist the urge to introduce a Redux dep before it's actually needed. He's not saying that to ease the learning curve. He's saying it because a lot of those apps will never need or benefit from Redux. For a lot of applications, Redux isn't worth the trouble. Moreover, just like with routers, the Flux pattern started with an idea about how to structure code, and morphed into a library dep. But Flux isn't about libraries! It's about code structure. It is not only possible but probably easier to structure your data in a Flux pattern without introducing Redux. The original Flux "library" was just EventEmitter.
It is in fact not fair to compare the API turnover for Angular to vanilla React plus two optional ecosystem components that aren't actually part of React. But more importantly, it's time to stop giving developers the impression they aren't building a "real application" if they don't have an extremely complicated router library and a whole bunch of thunks and reducers.
Sure, you may not specifically need react-router or redux, but you do need to route and you do need to manage state. So you either build your own router / state management engine or you take one off the shelf.
Yes, I do think it's fair to say: If you don't need routing, you have a toy app or at the very least are annoying the crap out of users who try to bookmark things. React-router is not "extremely complicated". On the other hand, your homegrown router may very well be a few years of revision while you learn all the lessons the react-router team learned before building v4.
Redux is a different matter; I loathe it and do not use it. Component state is great! Until it isn't. Angular has a great story around this with injected components. React... well, you bring in a library like Redux or MobX or you do something else on your own. Personally I do "something else". But Angular has a clear story here, and you aren't saving yourself any code by using React.
There's more; fetch libraries and scss resources come to mind, as well as the whole build system itself. Not to mention the actual UI component libraries.
In my short year in the React ecosystem I've gone through quite a lot of version churn, just with all the libraries that surround React. It's real and I don't see this as a "benefit" over Angular.
> But more importantly, it's time to stop giving developers the impression they aren't building a "real application" if they don't have an extremely complicated router library and a whole bunch of thunks and reducers.
A thousand times, this. I am working on Redux-enabled app that answers "no" to all 5 of the questions to consider when trying to decide "do I have to put all of my state in Redux?" [0]
IMO it's now all so much more complicated than it needs to be. Admittedly this is my first exposure to Redux, but rather than "you might not need Redux" I'm leaning towards "you almost definitely don't need Redux"
OTOH I'd be amazed if no-one's built an SPA in production with React and nothing else from the React ecosystem. What would be so hard about that? You can totally use it as just a view layer, if that's what you want to do. Granted, you probably use other non-React libraries, but that's not what we're talking about.
You can also have a "view layer", some control flow behavior in simple higher-order components, and then stores and actions that are simple plain-ol'-Javascript without needing a framework dep. The idea that a React app without Redux and react-router must simply be a brainless view layer is reductive and misleading.
Right, I'm sure there's some Rails and Django folks out there just using React as the view layer. Plus as someone mentioned above, Next.js is one of the simplest ways to do full stack React.
Angular, React, etc. are nothing but a bunch of pre-written lines of code that does data binding. Quality lines of codes with a lot of candies, but in the end it's only a bunch of JS lines.
There are no obligations whatsoever to keep your project cutting edge and even less of reason to migrate to a more popular framework. It's not as if browser support for Angular 1 would stop.
It is, but you have to balance it out. Updating an entire app to a new major version (without backward compatibility) simply to use let's say a new API wrapper or syntactic sugar is a waste of time. If the app works fine, there's no need to migrate.
The 2+ updates are really more like point releases which might add some features and/or break some things here and there, but are in no way comparable to the huge 1.x -> 2 "just rewrite it all" jump.
Naming matters though, since the Angular ebook I was reading saw fit to end update support at 2.x and not support 4+, even though there's not much difference from what I can see.
This isn't v5 of "Angular" though, this is more v4 of Angular 2. Angular 2 became just "Angular" a while back, and Angular 1 became "AngularJS", I suppose to distinguish them as two separate products. There really isn't much going on between major releases as their confusing dichotomy would have you believe.
From a purely technical standpoint, the upgrade path from AngularJS to Angular seems better thought out than some things I've had to handle before - you can run the 2 in one Angular app as you upgrade pieces and there is a whole library aimed at easing some of the annoyances of upgrading. https://angular.io/guide/upgrade
Vue + Vuex is where we went after Angular 1.x. We're also a C# shop and felt burned by the Angular 2+ changes. We worked with React and really liked it, but it was hard to bring on new devs quickly.
Vue is a lot like Angular with data binding, only about a million times easier to get going than React. Vue + Vuex (feels like a really well thought out Mobx) + Vue-Router and you'll be knocking out slick looking web apps in no time.
Also the vue-cli is like a gift from a more intelligent Javascript writing species.
This. Vue feels a lot like Angular 1, but gets more stuff right. Angular 2 feels like an over engineered React clone using more complex tech to solve the same problems. I also really dislike JSX so I am biased.
I am in the same boat as you. I was in love with Angular 1 and when Angular 2 was announced I was very much disappointed. There was not one redeeming things about A2 IMO, just a huge clusterfuck which is still growing with every version.
Also never liked React. The whole JSX and everything is just isn't for my taste. I'm speaking as a solopreneur who likes launching a new site every month. Anyway, so a friend suggested Vue and this framework brought me actual joy. It is everything I was hoping to see in Angular 2 and better.
Seriously, if you like A1 but not a fan of A2 or React then Vue is definitely up your alley.
I love Vue. I prefer it to React and Angular. But once you get to customizing your use-case (like adding Typescript, State management, or Design frameworks) you start relying on increasingly smaller projects with less and less "maturity". For example I make heavy use of the vue-typed library[1] but it has 47 stars and two contributors.
That's true, but I dislike "essential" third-party projects anyway. Part of the reason I like Vue so much is because of the "official" Vue + vuex + vue-router combo (for React you have to use third-party libraries for state management and routing).
I don't get why people say this. Vue and Angular 1.x are only similar when you're comparing the templating engines. But how much of the work migrating to React or Vue actually involves porting the view? I think that's not a very substantial amount compared to the application logic.
I've worked with all three, and I would say that Vue and React are for more similar than Angular and Vue.
I hear you. What's causing them to iterate so fast? I still remember the days of Java and .Net where they did yearly releases and phased transitions with good documentation of what's deprecated and what's new.
> phased transitions with good documentation of what's deprecated and what's new.
Am I missing something? Do they not have that? This is just a blog post. They have a changelog and utilize the @deprecated jsdoc tag for IDE notification.
I work in a large health care organization and they decided a two years ago to jump on the Angular bandwagon. Well, after some serious growing pains they were able to get it to work. One of the major issues was the "executives" just paid a hefty fee to bring in AEM (Adobe Experience Manager) and anything the teams wanted to do had to be able to integrate with AEM. I won't bore with the details, but it was painful.
After a long journey to get those issues solved, the Angular team came out and said they were going in a totally different direction for Angular 2. One of my responsibilities was to write up a migration path to 1.5, and then how to eventually make a full migration to 2.
Yeah, after I told upper management about the rapid release cycle, they just about choked. No way an org this big can move that fast. At this point, any future projects won't have it and we're in legacy support already for three other projects who did use it.
In short, Angular in all forms is dead here, which is sad.
We were in the exact same position and ended up converting to react to escape another potential clusterfuck with angular. This was despite the fact that I enjoyed angular very much but as you said it is certainly scary from business perspective.
Last year in August I left Angular because of the v2 nightmare. So, that's over a year ago. I think they've learned from it. Came back for v4 and never had an issue with it being immature.
