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.
I somehow do not get all that bashing. Angular did extremely great things with Angular 1 (back then). As time passed, the community learned that there are better/other concepts. React came out - nice. NG2/4 therefore had to include major changes to pave the way for the future and more modern concepts. And it is important that they do that because some people have built huge teams and applications based on Angular. So, thanks!
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.
People jump on a victim train too easy. If they can't complain on life, they complain on JS or Angular. If you think something is better, ok thanks, we will consider it. But what is the alternative? React? Good god, never. Vue? Can't comment, but doesn't seem to be doing good:
https://trends.google.com/trends/explore?date=all&q=Angular%...
Google trends can be quite hard to read - that search term will include Angular 1, which is far larger than Angular 5.
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).
Consider upgrading. Ng2/4 fixes a lot of major issues in ng1. It takes you a week or so but you'll have a solid foundation for the future. And it's as i said more economic than doing a full rewrite to react/vuejs (of course VueJS is sexy as hell)
Congrats to the new release! I've got a lot of respect for putting so much energy into open source projects.
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.
Perhaps WASM will provide the better match for business applications, sidestepping HTML entirely.
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 know people put high hopes into it, but WASM by itself does exactly nothing to improve the basic rendering model of browsers (CSS and it's various layout models). It just replaces JavaScript (which I have no problem with at all), making browsers even more complex. WebGL, OTOH, can be used from JavaScript without problems, including typed arrays and SIMD.
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.
Since you stressed the point that WASM does nothing to improve the rendering model, it's worth noting I never wrote that it did.. but about replacing the UI with custom libraries (rendering to canvas), hence why I used Unity as an example, then mention the need to download UI libraries.
This is the only approach supported by WASM in the near future, although a browser DOM bridge is roadmapped for a couple of years on. ie ditching the (DOM of the) browser entirely for apps (in WASM) - apps that can run on ANY platform with a modern browser.
>> And why do we need a new bytecode format when basically all phones run on the ARM ISA?
There are in fact some good reasons
* It's an open standard, which it seems many vendors will get behind and it will become ubiquitously available, and as such stands a chance of competing with Html/JS for the crown of the 'everywhere platform'.
* Being sandboxed by the browser instead of running on bare metal has huge value for security.
* Being sandboxed as an abstraction layer allows ISA portability. You mention most phones run on ARM, but more than a handful of people want to use PCs running Intel too! Also not all phones run ARM, and there are future ISAs that don't exist or aren't mainstream yet (such as open source ones) and the abstraction of a runtime makes it easy. WASM has been design to be good as a portable target (ie easy to implement on a new ISA as opposed to writing full emulation).
The first one is the most important one, about being an open standard with enough industry implementation to achieve critical mass for users and become a sustainable 'any/everywhere' platform .. the technical issues could be addressed other ways, but that only matters if people can access your runtime (which is what killed Flash and Silverlight).
There are downsides too, such as performance, however the market has shown it doesn't really care about performance by choosing the bloated Javascript mess have today.
tl;dr; Runtimes are good for the majority of consumer and business software, and WASM is the first one all the big players are supporting instead of the competition sabotaging
>> I guess I don't get why games should run in a web browser with all it's security and privacy issues.
The question implies that native code has a better security and privacy profile than a hardened browser sandbox.. actually that right there is the issue. You actually get a far better security and privacy 'platform' on the browser, despite/because of the much larger attack volume.
With native you can do and access anything the OS allows, and find vulnerabilities in the entire OS APIs. Even on e.g. iOS the native code can do all sorts of things and call private hidden apis etc, Apple just tries to use static analysis to attempt to find these issues before you download it..
I mean, I feel ya. The web was built for rendering PhD research papers, not the complex, rich, responsive apps we have today. Square peg, round hole for sure...but we been hacking away at the hole for sometime to get that peg in there...and today it is feasible to build these things. But you're right that if the web had conceived of being used for rich apps from the beginning we would have been spared a lot of trouble.
I think, at a minimum, they would have needed support for something like HTML5 canvas. Then Flash would have never happened. HTML should probably should have been XML with a component centric model from the beginning. Modules from the start with JS. Scoped CSS...lots of things would have improved the web's position earlier...but you know, hindsight and all that.
From my colleagues, both front-end developers and full-stack developers, I've heard nothing but criticism of Angular >2.0.0. I would like to hear the other side. If you use fresh Angular, why?
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.
Not really. Testing components is still really a pain: there's lots of boilerplate and the tests are extremely slow. In a medium-size project, they're far too slow to treat as unit tests: I break out all the TestBed stuff into a separate karma integration test config.
Angular is in desperate need of something like Enzyme.
Well if you use the Angular CLI it will generate the boilerplate test code for you, I don’t find them slow to run personally (my dev machine is pretty well specced though)
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.
To be fair the situation has changed drastically over the past 12 months.
After 2.0, AOT got enabled by default, drastically reducing size, then 4.0 drastically reduced size, then the build-optimizer (default with 5.0) drastically reduced size.
I hate CLIs that do too much. Just give me a sane starter generator and I`ll take it from there. And please don`t hide webpack from me like angular cli does.
And this part "generating new components/services/etc. easy" I always find strange. Creating a component or whatever takes like 1-2 shortcuts in a normal IDE. And you can also use templates to expand various reusable/common parts. Why would I ever want to learn some cli command that would create ordinary file for me which I can create as usual with the tool I already use.
Heavy CLI tools just add another layer of unnecessary complexity to the project. Why don't just learn webpack which you can use on any project, and you will have much more power at your fingertips.
When I used Angular 1, the two way binding was a breathe of fresh air. It was akin to when jQuery first hit the scene and you all of a sudden had selectors. There was a learning curve regarding the "Angular way" (think: $scope, controller, directive), but altogether I was happy with the result and the ideology.
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.
> When I used Angular 1, the two way binding was a breath of fresh air.
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.
Two-way binding is amazing for smaller sites, but it becomes a nightmare for an enterprise-level app. Digests, and having to wait for the next event cycle is an incredible headache, especially when you have to write tests and modify values outside of angular control.
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.
Interesting considering Angular 3 was never in existence, they switched to Semver specifically avoiding vs 3 because of the move to an rxjs based router.
Angular 2+ is much better than 1 - it fixes pretty much all of the warts with 1. On the flip side, there are some tradeoffs, some that is not quite Angular’s fault, although they’re tradeoffs chosen by the Angular team in designing the framework.
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.
My gripe with testing in React has a lot to do with testing in JS in general - it avoids the elephant in the room of how to mock dependencies (whether it be functions, classes, etc.), and control various scenarios so you appropriately unit test business logic. One can impose a solution by convention with React, whether it be creating/using a DI mechanism, creating functions that one can pass in dependencies to that returns the desired function, or other numerous ways. Or one can choose to avoid creating a solution and decide not to directly test those scenarios, but then that just leads to more expensive, fragile, and complicated scenarios where one loses the advantage of the fast & tight feedback cycle a unit test gives you.
Angular’s solution of a robust DI mechanism is a little on the heavy side, and the test execution perf is worse than Angular 1’s in general, but it is almost certainly the most powerful test helper situation available for testing frontend JS chrrently.
Note that testing serverside JS doesn’t suffer as much, since there are libraries for making use of the require cache for mocking such as testdouble.
Enzyme and Jest (for React) are pretty awesome. I haven't seen UI testing that good elsewhere...not to mention Storybooks which are great for documentation and manual review. Snapshots, auto mocking, etc...you can't beat React's tooling.
I came from React. Angular is a much more complex and strict tool, but with that comes more power (build-in functionality): It's a framework not just a view layer. So it takes more time to learn, but with React you need to first choose, then learn Router, http, ... as well.
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.
Typescript. When working in a shop with a large contingent of .NET developers, having a language that somewhat resembles what they are used to is a great asset.
I found especially that working with a project that requires a lot of extra bits to be installed (like the react ecosystem) makes working with JavaScript libraries from typescript especially painful, since you need to get typescript definitions for all of them, and they may not always mesh well together.
I believe the latest version of Visual Studio Code can automatically install the type dependencies from the IDE (e.g. a quick fix if the type definitions are missing).
In recent Typescript it defaults not found modules to type `any` and only complains if `--noImplicitAny` is used.
Even with `--noImplicitAny`, it's gotten pretty easy. Leave a scratch .d.ts file somewhere in your project and when you install a new library you can start with:
That gives you an explicit `any` for those libraries. Then you can go back and add types later.
The number of npm packages with types directly included is growing at an impressive rate (even Facebook often bundles them for React libraries), so there's not even the need to seek out types in so many cases these days.
I use angular 4.x for two and a half reasons in a small shop (e.g., just me, making internal web apps for my org)
(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.
All that said, I was working on 1.x code for quite some time, and only started playing with angular 2+ after 4.0.0 had been released. If I had started a new project during the transition, I probably would have ended up using react. Mostly timing is all.
They are probably just angry at themselves for jumping into React too early. Good I had wits not to do it. Angular is simply awesome, especially with CLI. I am doing a big project and I never touched nasty webpack files. All that I wanted additionally was available via npm install. Typescript is awesome. Tons of frameworks, PrimeNG being the greatest .
Lack of compile-time checks for the template (and embedded expressions) is a major limitation of Angular. This may be OK for small projects. For large projects with many developers this is a huge problem. Here's what happens: a developer modifies code he's not familiar with. He introduces a bug due to a typo. He builds the code without errors, and runs the application, and everything seems to be OK. The bug is not found even at run time because the developer did not click on something during his manual testing. You can try to reduce such problems with automated tests, but test automation can't reach every corner. As much as possible such issues should be caught at compile time, and Angular can't. This is a major flaw.
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.
This isn't true and hasn't been true for a while. Angular's ahead-of-time compiler converts the template strings into TypeScript which are then type checked, all at compile time.
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.
This is part of what v5 is fixing by enabling AOT by default in development (and production).
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!
That's an improvement, but what about syntax coloring, intellisense suggestions and instant squiggly-lines when you make a typo? These are all important for productivity. You get all this when you use .tsx templates (which by the way, are not limited to React, see https://github.com/wisercoder/uibuilder )
As others have mentioned, this is all possible with Angular >=4, both in WebStorm and VSCode. The main issue is with performance and debugging. Using Angular's AoT compilation is still extremely slow and your squiggly lines take several seconds to show up after you modify a template in your editor. And no stepping through templates either when trying to debug why something isn't rendering properly.
But, imho, the biggest problem with Angular, by far, are it's NgModules. You can't just import a component normally and use it in your template. You need to also add it to an NgModule to make it available in the templates of the components inside that NgModule. And if for some reason you stop using a component, you need to remember to clean up the module as well since nothing will warn you about unused declarations or imports in NgModules.
And then there is also the fact that you can't directly import a function/constant and use it directly in the template because, like Components, the template engine needs to be told about it. So you need to add properties to your component class which are just providing access to things you imported above. So. Much. Pain.
Some people really like templating languages but imho just using TSX (which is just mapping to function calls) and normal ES modules is the best solution by far.
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.
we're a c# shop too. 7 developers. we started with angular 1. we too got caught in the angular 2 mess but we stayed with it. we know react but after you add routing, redux, forms, etc to react, you've got something close to angular.
i 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!
Yeah. I have only ever used Angular 2+ . It seems that Google messed up on the transition from Angular to Angular2, and the community hates them for it. This is the situation that Python has been trying to avoid for years now.
While most still are on Angular 1, releasing 5 reminds me of Magento where most shops are still on version 1 with no desire to upgrade to 2. There are even forks that focus on improving version 1 ignoring the version 2 of the upstream project.
Thank you for new release. For me there is still nothing better than Angular - I hate html validation, but I hate JSX even more. I hate verbosity of declarations (app.module, app.component, imports...), but I hate lack of official router in React even more. I don’t like RxJS and I hate that you are forcing me to use it, that you ignore even simple feature request about GET-caching, but there is still no good replacement for Angular. I didn’t mention hell with tests just to don’t be too sad on this happy moment of new release with a lot of breaking changes. Thank you.
The more time I've spent with Angular 2+ and later the more it feels like a DSL to me than a Typescript framework, much more so than the, admittedly very limited, time I've spent with React and jQuery before that. That's not really a knock on it, I find it to be extremely productive for me which is why I haven't gotten away from it. I just don't think it does much to enhance my skillset in front-end development overall.
Have recently moved system from TS + Angular 1 to Angular 1.5 and then to Angular 2 (took us solid 1 year and you can still see some traces of older code), by time we finished move to 2, Angular 4 was released! And now this! This is WTF moment of my life.
All I want for Angular are better error message and better browser-refresh times. Right now on 4 I get a meaningless page of gobbledeguck for most error (b/c of transpilation) and 12 seconds to reload the page.
It isn't. A fresh 'ng serve --open' takes ~20 seconds to get to a ready page, and each reload is taking 10+ average. Every minor change.
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.
Several years ago we chose AngularJS/v1 for an enterprise-level app. Once Angular/v2 was announced it was still more of an experiment, but things have changed far faster than we anticipated.
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.
Has anyone had success using the AOT tools to build a package of reusable angular components? I was able to use AOT pretty easily for a stand-alone app, but keep running into issues when trying to create a shareable component, and there is not a lot of documentation around this.
I have, but by using ngc in my gulp build task (had to use gulp for the reason below), unfortunately couldn't make it incremental at that time, so it takes several seconds to re-build when the source is changed.
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.
> 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 have invested time into Angular 2 and leveraged a fair amount of its features and ecosystem, but implementation specifics on some have been a great challenge.
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.
I was in the same boat - Watched Angular 2 presentations live (was it ng-conf or something?), was excited about Angular Universal and the Angular CLI that was announced.
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.
Coming from the jQuery and Datatables and Knockout era, I just can't accept the weight and performance of Angular beyond the 1.0 release. I fell in love with Vue.JS (it works like jquery and knockout very similarly)
Woah! static injector and typescript transforms! does this mean i can use angulars dependency injection framework for any typescript project without including any 'real angular' so i can start writing node services like i would with spring!? (or perhaps closer to dagger2?)
But did semver really set out to eradicate all distinction between minor incompatibilities and complete architectural reboots?
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
Adopting and enforcing usage of semver across teams helps tame some code cowboys that think they can change their library and everyone else should just adjust to their new API. I found it very useful for documenting API changes on an intra-company dependency where the library developers said, "Oh we don't change the API", but actually changed the API in backwards-incompatible ways all the time and made everyone downstream change their code on every release.
Only as bright as the line between public API and private implementation details that are allowed and expected to change between semver minors. This is not always very clear.
