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.
Not only is it very pleasant to work in, but the end product for the user is high quality.
Vue is great, but it's lack of proper component support makes it a bit annoying to work with.
I have just migrated an app that was on Angular 2 RC4 to Angular 5 with little to no migrational woes.
The transition from Angular1 - Angular2 sucks, but ng2 and beyond is trivial.
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.
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...)
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.
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.
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.
I've worked with all three, and I would say that Vue and React are for more similar than Angular and Vue.
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.
If you're after that >> https://emberjs.com
It's written in TypeScript and, like Ng2, also heavily based on observables
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.
From ng1 perspective, the migration path to ng2/4 is more economic than a Vue or React rewrite. We examined that in depth. This is why we upgraded to ng2 instead of rewriting the application in Vue or React. And as i can see it, ng5 fixes major issues from ng2 and we're happy that the Angular team keeps on pushing here.
Github stars is a more precise metric. There, react has 80K, Vue is close with 72K (and gaining ground), and both are far ahead of angular on 30K (as of early November 2017).
https://github.com/vuejs/vue https://github.com/facebook/react https://github.com/angular/angular
Good grief, this is insanity. I'm still dealing with major issues in ng1.
Predictably, the discussion evolves around Angular vs react/vue/ember or whatever (personally, I like react).
My current customer project introduced me to a new generation of web front-end developers specializing in a particular framework (react/redux in our case) but know very little about CSS and the myriad of plumbing and polyfilling going on in browsers. In the end, they delivered an app that would only run on Chrome. Sadly, the whole thing makes me realize just how utterly inadequate the web platform after all these years still is for the kind of MVw apps folks want to use it for.
I think there's a place for a new "opinionated" web framework once again which more closely matches the needs of business apps, and which has an option to stand-alone app deployment outside web browsers. Mind you, this isn't a sentimental reflection on Java applets and their failure or some such, but based on years of actual project experience, including in front-end developer roles.
For example, the other day I learned that in 2017 there's no way to query the current zoom level of a web app (until very recently with the brand new Viewport API; but it's not supported using media queries; I mean, seriously?). Furthermore, I'm using a very simple SVG background image for a text area element, and the latest Chrome release introduced laughable aliasing bugs, which I could only workaround by using `opacity: 0.99`. There are still just so many tricks and hacks necessary for even the most basic of UI tasks that a realistic web app project feels like jumping from one ridiculous issue to another, frantically searching through StackOverflow, CSS-tricks, etc.
With the somewhat naive reception of react, Angular, and co (which don't actually do anything GUI-related, nor help with browser compatibility problems), I'm wondering whether I'm the only one feeling like putting square pegs into round holes using the web for anything other than content-driven sites.
It should allow side-stepping the complex morass of piecemeal evolved html features and implementation border case incompatibilities.
e.g. Today you can use Unity game engine to target WASM as a runtime and it should render, and function, very much identically across all browsers, and with a bit of creativity can be used to include forms and business functionality.
This does come at the cost of downloading the app runtime and UI libraries with the app, but frankly the download size is not such an issue anymore and in the future for many markets. e.g. 5G mobile broadband is targeting Gbit speeds!
I was thinking more about ditching the browser entirely for apps. Because what WASM and WebGL do is just a very tiny subset of what's been possible for ages with plain old native languages and D3D/OGL. And why do we need a new bytecode format when basically all phones run on the ARM ISA? I guess I don't get why games should run in a web browser with all it's security and privacy issues.
But yeah, almost anything is better than HTML/CSS/JS for complex UIs.
The adoption of simple REST style resources over SOAP, corba etc shows how useful the original "handle system + simple verbs" design really is.
It is small if I want to, but it has lots of features if I need them.
I don't have to worry about 3rd party libraries, because the official router, forms modules, http client, material components, flex layout etc. are all high-quality.
The CLI not only helps with new projects, but also makes testing, linting, building, serving, generating new components/services/etc. easy.
Implementing lazy loading with the router was easy, so that only the modules that I need for a certain route get loaded and my home site isn't 500kb+ for no good reason.
It has a predictable release schedule.
Did they finally fix it to be actually possible to make it small? I remember them quoting some ridiculous number, and none of my colleagues, nor I, could get it below a megabyte using the suggested methods, nor below a few hundred k for a hello world.
I tried Angular 2 and it was a mess. It feels as though the ideology is fighting you every step of the way, but with no foreseeable benefit beyond the benefits of Angular 1. Angular 1 had some issues of course (mostly with scope) but it gave us a way of working around them (via, $rootScope, etc), but Angular 2 seems to have taken away (again, think $rootScope).
Around the time Ancular 3 came out (yes, a renaming of Angular 2), I moved over to vuejs and haven't looked back yet.
Yeah, to be honest, if you aren't suffering performance issues as a result of it, Angular 1 is very productive. Problems present themselves in applications with large views, or using esoteric low-performing features. Angular >2 should never have been called Angular. Even if they call it "Angular" instead of "AngularJS", everyone called AngularJS Angular to begin with. It's so utterly different that it doesn't even fit in the same places.
Add to that the frequent execution and performance issues with watches and we deeply regret having to deal with it now.
Add to that having to learn the painful guts around digest-related executions. Watches fire on init so you have to ignore those first calls. Tests are nasty because timeouts have to be flushed manually, and $q promises won't resolve until you call $apply, etc. It quickly became "WTF is going wrong internally".
Angular 2 is a lot better, but at this stage I think so many former AngularJS/v1 developers went the react/vue route and don't see any reason to return.
Angular doubles down on the component-based model it tried to emphasize in Angular 1. It also is very performant. The main router is much better than Angular 1’s.
I haven’t used Angular in the past 5-6 months though - in my current role, we decided on React, and have been satisfied with it for the most part, although some things have been more painful than if we were to use Angular (testing being the big one), but also some things are simpler too. There’s tradeoffs with whatever library one goes with, but as a whole, Angular is still a very strong choice IMO.
EDIT: whoops, mistyped. We don't use karma anymore in our React testing stack. It's mocha now.
Now, it all depends what you prefer / what's good for you. For me it was a huge productivity boost to switch to Angular because they just tell me how to do things. I don't spend much time on thinking how to architecture or about which library to choose (e.g. MobX vs. Redux), I just do it. With WebStorm it's two clicks to get a component / service / etc. scaffolded. That is pretty much the fasted it can get. Once you know Angular, you can develop really fast despite it's complexity.
But that's really a personal choice. If you need structure and tend to get lost in decision making, give Angular a try.
For the same reasons I'd choose for larger teams.
(1) Ionic makes it relatively easy to bundle angular apps into hybrid-native packaging. I personally know it's not much different from users pinning an app to a start screen (other than the offline functionality you get in iOS, since iOS doesn't support service workers yet), but my users like apps for whatever reason. Of course, Ionic is moving away from angular-only, so this won't be a constraint in the future.
(1a) I have worked with react-native and nativescript as well, and can say that it's way easier to build cross-platform stuff with Ionic. If you're building bog-standard businessish CRUD apps, Ionic is super-straightforward. If you're doing cutting edge interfaces and games, well, that's not what this is for.
(2) I honestly prefer Ionic's parameter-binding syntax to mixed JSX syntax. I've written enough JSP, PHP, handlebars and other mixed-template languages, tyvm. I like having a template with data-bound properties and a controller in its own file.
(2.5) Another preference: while I like unidirectional data flow and have written my own rxjs-based middleware for fetching data out of a local cache and from and API (and sending data back), I'm not a fan of how redux and redux-like architectures work. Giant switch blocks feel like they're just re-inventing object method dispatch from another angle.
At the end of the day, the performance differential is negligible (I probably write faster code in angular, because I'm more conversant with it). I get more frustrated with Ionic than Angular most days (I am also looking forward to a future version where using Ionic doesn't tie you into a specific locked version of angular, typescript, and build tooling that's hard to modify).
Sure, there's weaknesses, but from my perspective, people like to yell about angular because they made so many breaking changes with the v2 transition - it's basically just a different framework from the same people now. But the latest stuff is fast and has great AOT package size reduction. If you just come to it as a "well, maybe I'll use angular for this new project" perspective instead of "dang, I don't want to port my 1.x stuff over", you're fine.
And I think Angular is winning anyway by a large margin: https://trends.google.com/trends/explore?date=all&q=Angular%...
Compare that to .tsx templates (Typescript's version of JSX). All html as well embedded expressions are checked at compile time, and typos are caught at compile time.
In .tsx templates you can.
Templates frequently need loops and conditionals. In the case of .tsx this logic is in TyprScipt so you can debug it just like any other TypeScript. In the case of Angular such logic is written in an undebuggable custom syntax.
AOT compilation converts an Angular template to TypeScript that is then type-checked. So on v4+, an `ng build --aot` performs type-checking.
But since that's not great developer ergonomics, v5 has included enough performance improvements on AOT that it's reasonable to enable in development (see "TypeScript Transforms"). And then that means that development includes the type-checking compilation step!
While I agree that this is very annoying it will not compile using command below so your story about developer who introduces new bug does not check out.
ng build --prod --aot # Errori just updated a medium sized angular 4 app to angular 5 with no problems. typescript has been our saving grace especially when you're collaborating code with your team. we've really come to enjoy angular. if you're migrating from angularjs it can be difficult but if your developing a new app with form validation, routing, redux then i would recommend angular.
I think a lot of the hate is down to the naming (AngularJS vs Angular), but at some point you need to just accept that it is what it is and get over it!
What's even weirder is that most people I know using Angular are still using version 1.
A few minor things here and there, and a few deprecations, but by and large most everything that worked in 2.0 should still work in 5.0.
I can personally stand it because I remember working on 2 million line C++ projects in the 90's. The millennials on my team, on the other hand, are going insane. I've recommend they disable live-reloading completely.
Projects like ui-grid are dying and ui-bootstrap is dead and they're moving to Angular support only. We're suddenly using tech that's being abandoned a lot sooner than we foresaw.
I have my issues with Angular v2+, though overall it's way better than v1, but I truly hope the same doesn't happen to those making an investment in this new platform.
https://medium.com/@isaacplmann/getting-your-angular-2-libra... http://dbarnes.me/writing-an-aot-compliant-angular-library/ https://angular.io/guide/aot-compiler https://angular.io/guide/metadata
There is actually another problem when you want to develop reusable UI component library project is that you have to inline style files and template file into ts component.
We have a webpack-based process, and using the angular2-template-loader will take care of this for you. Unfortunately, webpack and aot don't mix well.
We watched the Google I/O presentation from 2016 where the team pitched a lot of exciting stuff coming to angular like SSR/Universal rendering, and decided to buy in and use ng2, but using universal with the CLI was near impossible to get done given how undocumented it was. There was a CLI fork that was quite promising, and with a bit of work we managed to get client side AOT optimization and SSR.
Bundle sizes after all this were unacceptably high. The documentation and talks had discussed things like tree shaking and other such optimization processes, but there was a tussle between webpack and rollup where the CLI used one and not the other, and rollup did tree shaking better, so we had to either drop tree shaking or the CLI. It was not a fun experience.
Eventually angular 4 dropped and there was a timeline on getting the CLI up to speed with universal, the guys at Google I/O 2017 did a talk on universal rendering, but they used some cryptic command line tools that were also fairly undocumented at the time. The angular 2 app sat in production using the old CLI fork that had been abandoned and we weren't able to migrate because universal documentation for angular 4 was also relatively unclear.
Finally for future projects we opted to go with Vue, which has been relatively nicer. We used localization, token based authentication via cookies to enable authenticated universal rendering for logged in users, PWA features (offline). The project was analogous to Yelp, with product and service suggestions displayed to the user depending on their browsing habits and other aspects of their profile. Roughly 300k monthly uniques. Universal was essential for SEO and performance since 90% of traffic was search.
Other than struggles with universal and SEO, there were some issues with getting customizations to the webpack build process since the CLI fork we used didn't allow for many changes like adding minification, etc. We also wanted stuff at the express end of things like HTML minification, but there was no clear-cut way to do caching across things like authenticated vs unauthenticated. Maybe we couldn't think of the best way to go about this. Other frameworks seemed to have a painless way of doing this stuff, so we spent a lot of time wondering if we had made the right choice. Most of the plain client side stuff was very satisfying to use. RxJS is great as well, and it was nice to see it become popular across the JS ecosytem. I am not sure if I would go with angular for future work because the bundle size seems to be overwhelmingly high - perhaps due to a knowledge gap at our end. What would be fantastic some sort of sample kitchen sink demo application that employs all the best practices for everything - auth, localization, seo, universal, build process customization, etc.
At the time of our evaluation, we looked at a number of quickstart and bootstrap/boilerplate/starter kit projects, but each one seemed to lack one thing that we really wanted, with no clear path to integrating it in.
Turns out the CLI didn't play nice with Universal. I spent a week trying to convert the bare bones Angular 2 tutorial 'tour of heroes' into an Angular Universal architecture. I couldn't figure it out. Lots of version mismatches and either out of date or 404'd documentation.
I just gave up. If I couldn't convert a simple project to do server side rendering there was no way I'd be able to convert a more complicated project.
thanks... please fix: https://github.com/angular/angular-cli/issues/6742 before..
So the major version changes whenever they make a backwards-incompatible change.
However, I clicked in their upgrade calculator (linked from the post) and at a glance it appears the incompatible changes are fairly minor.
So much semver adoption seems to be based entirely on wishful thinking.
Step 1: hey, perfect drop-in compatibility would be so cool
Step 2: we can do it, with semver!
Step 3: we use semver! Yay us!
Step 4: oh, turns out adopting semver did not make perfect drop in compatibility any easier
Step 5: don't ever touch that zero between major and bugfix