12 ms·

Angular 5.0.0

189 points by d2kx 9y ago

merb 9y ago
`ng serve --aot` will be default? thanks... please fix: https://github.com/angular/angular-cli/issues/6742 https://github.com/angular/angular-cli/issues/6742 before..
- fknop 9y ago
  You can still use --no-aot (or something similar) in the meantime
- fknop 9y ago
  They actually reverted aot by default on serve because for really large project it might slow down the reload time.
racl101 9y ago
I haven't used Angular in a while, so I haven't heard about Angular 3 or 4. What's even weirder is that most people I know using Angular are still using version 1.
ainar-g 9y ago
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?
- hanspragt 9y ago
  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.
  - kierenj 9y ago
    Dare I say - but you can use Typescript with other frameworks too.. just because it's built in here / there are more resources?
    - foota 9y ago
      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.
      - eunoia 9y ago
        As I commented above, you might want to take a look at https://github.com/wmonk/create-react-app-typescript https://github.com/wmonk/create-react-app-typescript. It’s really helped reduce some of that 3rd party lib / buildchain JS fatigue for me.
      - WorldMaker 9y ago
        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: declare module 'libraryname' declare module 'libraryname/**/*' 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.
      - nawitus 9y ago
        You can easily install types from @types these days: https://www.npmjs.com/~types https://www.npmjs.com/~types 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).
    - eunoia 9y ago
- d2kx 9y ago
  I love it. 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.
  - microcolonel 9y ago
    > It is small if I want to 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.
    - relearn 9y ago
      It's been possible for quite some time. Hard to say why you weren't able to without more information.
      - d2kx 9y ago
        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.
        fareesh 9y ago
        There was no clear way on how to do this if you wanted to use universal though. The CLI never supported it for ages. Does it support it now?
        fknop 9y ago
- hateful 9y ago
  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.
  - microcolonel 9y ago
    > 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.
  - botskonet 9y ago
    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.
  - ZoeZoeBee 9y ago
- Bahamut 9y ago
  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.
  - FLGMwt 9y ago
    That's surprising to me! My main complaints of Angular 2+ are around testing, but I've had nothing but love for React testing (enzyme, chai, karma) EDIT: whoops, mistyped. We don't use karma anymore in our React testing stack. It's mocha now.
    - vilmosi 9y ago
      Chai and karma aren't specific to react. I remember using them with angular 1.x back in the day.
      - ivankolev 9y ago
        I thought Karma was specific to Angular in fact!
      - FLGMwt 9y ago
        Aye, I didn't mean to imply that, I was listing my React testing stack :) Hah, looking now, I realize I mistyped. We use mocha, not karma. Was conflating things
    - Bahamut 9y ago
      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.
- pfooti 9y ago
  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.
  - pfooti 9y ago
    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.
- skydv 9y ago
  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 . And I think Angular is winning anyway by a large margin: https://trends.google.com/trends/explore?date=all&q=Angular%20tutorial,Vue%20js%20tutorial,React%20js%20tutorial https://trends.google.com/trends/explore?date=all&q=Angular%...
- JTenerife 9y ago
  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. For the same reasons I'd choose for larger teams.
hanspragt 9y ago
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.
- rickcnagy 9y ago
  I have for my day job, but it's _hard_. There isn't a lot of good info out there. Here are a few good sources that I found helpful: https://medium.com/@isaacplmann/getting-your-angular-2-library-ready-for-aot-90d1347bcad https://medium.com/@isaacplmann/getting-your-angular-2-libra... http://dbarnes.me/writing-an-aot-compliant-angular-library/ http://dbarnes.me/writing-an-aot-compliant-angular-library/ https://angular.io/guide/aot-compiler https://angular.io/guide/aot-compiler https://angular.io/guide/metadata https://angular.io/guide/metadata
- tashoecraft 9y ago
  Yes, but it can be terrible. Suggestion is to take one of the angular library generators. They really need proper docs on how to set this up properly.
- harunurhan 9y ago
  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.
  - hanspragt 9y ago
    > 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.
jbigelow76 9y ago
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.
diminish 9y ago
5.0.0? - such precision in versioning for a library or framework seems both too quick and too precise at the same time.
- evmar 9y ago
  They are following semver: http://semver.org/ http://semver.org/ 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.
  - usrusr 9y ago
    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
    - fknop 9y ago
      They do actually use every number of semver in a meaninful way.
    - dragonwriter 9y ago
      > But did semver really set out to eradicate all distinction between minor incompatibilities and complete architectural reboots? It's explicit terms do, whether or not that's the intent. Backward incompatible is a bright line. OTOH, I think that exact bright line is the central purpose of SemVer.
      - usrusr 9y ago
        > Backward incompatible is a bright line. 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.
Yabood 9y ago
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.
- k__ 9y ago
  Could be worth your while to look into Cycle.js It's written in TypeScript and, like Ng2, also heavily based on observables
  - TheWiseOne 9y ago
    Second this. It takes a little getting used to but CycleJS is worth a definite look.
- sixbrx 9y ago
  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.
- pythonaut_16 9y ago
  Vue.js can be a good option for shops coming from Angular 1.x.
  - IgorPartola 9y ago
    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.
    - superasn 9y ago
interlocutor 9y ago
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.
- mikeryan52 9y ago
  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.
  - whitefish 9y ago
    Can you put a breakpoint in the template? 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.
- rickcnagy 9y ago
  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!
fareesh 9y ago
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.
KaoruAoiShiho 9y ago
Just use Vue. Angular is just dead for a large part of the community.
drraid0 9y ago
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.
- fknop 9y ago
  CLI should be pretty much instant to reload a page.
  - drraid0 9y ago
    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.
maxpert 9y ago
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.
- romanovcode 9y ago
  Should be pretty easy to migrate from ng2 to ng5.
- ptmcc 9y ago
  There's very few incompatibilities from the 2.0 release onward. 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.
- baristaGeek 9y ago
  HttpClientModule is probably one of the most visible incompatibilities, and it's one that is worth the migration process.
- jmkni 9y ago
  Moving from Angular 2 to 5 is like moving from AngularJS 1.2 to 1.5.
hockeybias 9y ago
Uncle.
nikolay 9y ago
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.
afromobile 9y ago
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.
myth_drannon 9y ago
Unfortunately Angular lost the market momentum they had and other frameworks picked up the tab. No matter how many amazing features they add.
philippz 9y ago
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.
- cpursley 9y ago
  > ng5 fixes major issues from ng2 Good grief, this is insanity. I'm still dealing with major issues in ng1.
  - philippz 9y ago
    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)
- skydv 9y ago
  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%20tutorial,Vue%20js%20tutorial,React%20js%20tutorial https://trends.google.com/trends/explore?date=all&q=Angular%...
  - yaseer 9y ago
    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). https://github.com/vuejs/vue https://github.com/vuejs/vue https://github.com/facebook/react https://github.com/facebook/react https://github.com/angular/angular https://github.com/angular/angular
tannhaeuser 9y ago
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.
- chrisco255 9y ago
  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.
yatinkal 9y ago
When Angular 1 was left for dead I went to Knockout.
simook 9y ago
Still a fan of 1.x, not sure why they think new major versions will convince me to move forward.
Yuioup 9y ago
I really don't get the hate for Angular 2+. Been using it for almost a year now and I love it. Fantastic stuff.
- jmkni 9y ago
  Likewise. 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!
  - Yuioup 9y ago
    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.
bjconlan 9y ago
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?)
EugeneOZ 9y ago
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.
botskonet 9y ago
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.
gungoman 9y ago
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)
azr79 9y ago
Fantastic release, congrats to the Angular team!

189 points by d2kx 9y ago

merb 9y ago

`ng serve --aot` will be default? thanks... please fix: https://github.com/angular/angular-cli/issues/6742 https://github.com/angular/angular-cli/issues/6742 before..

fknop 9y ago
You can still use --no-aot (or something similar) in the meantime
fknop 9y ago
They actually reverted aot by default on serve because for really large project it might slow down the reload time.

racl101 9y ago

I haven't used Angular in a while, so I haven't heard about Angular 3 or 4. What's even weirder is that most people I know using Angular are still using version 1.

ainar-g 9y ago

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?

hanspragt 9y ago
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.
- kierenj 9y ago
  Dare I say - but you can use Typescript with other frameworks too.. just because it's built in here / there are more resources?
  - foota 9y ago
    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.
    - eunoia 9y ago
      As I commented above, you might want to take a look at https://github.com/wmonk/create-react-app-typescript https://github.com/wmonk/create-react-app-typescript. It’s really helped reduce some of that 3rd party lib / buildchain JS fatigue for me.
    - WorldMaker 9y ago
      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: declare module 'libraryname' declare module 'libraryname/**/*' 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.
    - nawitus 9y ago
      You can easily install types from @types these days: https://www.npmjs.com/~types https://www.npmjs.com/~types 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).
  - eunoia 9y ago
d2kx 9y ago
I love it. 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.
- microcolonel 9y ago
  > It is small if I want to 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.
  - relearn 9y ago
    It's been possible for quite some time. Hard to say why you weren't able to without more information.
    - d2kx 9y ago
      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.
      - fareesh 9y ago
        There was no clear way on how to do this if you wanted to use universal though. The CLI never supported it for ages. Does it support it now?
        fknop 9y ago
hateful 9y ago
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.
- microcolonel 9y ago
  > 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.
- botskonet 9y ago
  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.
- ZoeZoeBee 9y ago
Bahamut 9y ago
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.
- FLGMwt 9y ago
  That's surprising to me! My main complaints of Angular 2+ are around testing, but I've had nothing but love for React testing (enzyme, chai, karma) EDIT: whoops, mistyped. We don't use karma anymore in our React testing stack. It's mocha now.
  - vilmosi 9y ago
    Chai and karma aren't specific to react. I remember using them with angular 1.x back in the day.
    - ivankolev 9y ago
      I thought Karma was specific to Angular in fact!
    - FLGMwt 9y ago
      Aye, I didn't mean to imply that, I was listing my React testing stack :) Hah, looking now, I realize I mistyped. We use mocha, not karma. Was conflating things
  - Bahamut 9y ago
    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.
pfooti 9y ago
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.
- pfooti 9y ago
  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.
skydv 9y ago
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 . And I think Angular is winning anyway by a large margin: https://trends.google.com/trends/explore?date=all&q=Angular%20tutorial,Vue%20js%20tutorial,React%20js%20tutorial https://trends.google.com/trends/explore?date=all&q=Angular%...
JTenerife 9y ago
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. For the same reasons I'd choose for larger teams.

hanspragt 9y ago

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.

rickcnagy 9y ago
I have for my day job, but it's _hard_. There isn't a lot of good info out there. Here are a few good sources that I found helpful: https://medium.com/@isaacplmann/getting-your-angular-2-library-ready-for-aot-90d1347bcad https://medium.com/@isaacplmann/getting-your-angular-2-libra... http://dbarnes.me/writing-an-aot-compliant-angular-library/ http://dbarnes.me/writing-an-aot-compliant-angular-library/ https://angular.io/guide/aot-compiler https://angular.io/guide/aot-compiler https://angular.io/guide/metadata https://angular.io/guide/metadata
tashoecraft 9y ago
Yes, but it can be terrible. Suggestion is to take one of the angular library generators. They really need proper docs on how to set this up properly.
harunurhan 9y ago
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.
- hanspragt 9y ago
  > 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.

jbigelow76 9y ago

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.

diminish 9y ago

5.0.0? - such precision in versioning for a library or framework seems both too quick and too precise at the same time.

evmar 9y ago
They are following semver: http://semver.org/ http://semver.org/ 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.
- usrusr 9y ago
  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
  - fknop 9y ago
    They do actually use every number of semver in a meaninful way.
  - dragonwriter 9y ago
    > But did semver really set out to eradicate all distinction between minor incompatibilities and complete architectural reboots? It's explicit terms do, whether or not that's the intent. Backward incompatible is a bright line. OTOH, I think that exact bright line is the central purpose of SemVer.
    - usrusr 9y ago
      > Backward incompatible is a bright line. 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.

Yabood 9y ago

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.

k__ 9y ago
Could be worth your while to look into Cycle.js It's written in TypeScript and, like Ng2, also heavily based on observables
- TheWiseOne 9y ago
  Second this. It takes a little getting used to but CycleJS is worth a definite look.
sixbrx 9y ago
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.
pythonaut_16 9y ago
Vue.js can be a good option for shops coming from Angular 1.x.
- IgorPartola 9y ago
  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.
  - superasn 9y ago

interlocutor 9y ago

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.

mikeryan52 9y ago
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.
- whitefish 9y ago
  Can you put a breakpoint in the template? 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.
rickcnagy 9y ago
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!

fareesh 9y ago

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.

KaoruAoiShiho 9y ago

Just use Vue. Angular is just dead for a large part of the community.

drraid0 9y ago

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.

fknop 9y ago
CLI should be pretty much instant to reload a page.
- drraid0 9y ago
  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.

maxpert 9y ago

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.

romanovcode 9y ago
Should be pretty easy to migrate from ng2 to ng5.
ptmcc 9y ago
There's very few incompatibilities from the 2.0 release onward. 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.
baristaGeek 9y ago
HttpClientModule is probably one of the most visible incompatibilities, and it's one that is worth the migration process.
jmkni 9y ago
Moving from Angular 2 to 5 is like moving from AngularJS 1.2 to 1.5.

hockeybias 9y ago

Uncle.

nikolay 9y ago

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.

afromobile 9y ago

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.

myth_drannon 9y ago

Unfortunately Angular lost the market momentum they had and other frameworks picked up the tab. No matter how many amazing features they add.

philippz 9y ago

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.

cpursley 9y ago
> ng5 fixes major issues from ng2 Good grief, this is insanity. I'm still dealing with major issues in ng1.
- philippz 9y ago
  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)
skydv 9y ago
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%20tutorial,Vue%20js%20tutorial,React%20js%20tutorial https://trends.google.com/trends/explore?date=all&q=Angular%...
- yaseer 9y ago
  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). https://github.com/vuejs/vue https://github.com/vuejs/vue https://github.com/facebook/react https://github.com/facebook/react https://github.com/angular/angular https://github.com/angular/angular

tannhaeuser 9y ago

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.

chrisco255 9y ago
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.

yatinkal 9y ago

When Angular 1 was left for dead I went to Knockout.

simook 9y ago

Still a fan of 1.x, not sure why they think new major versions will convince me to move forward.

Yuioup 9y ago

I really don't get the hate for Angular 2+. Been using it for almost a year now and I love it. Fantastic stuff.

jmkni 9y ago
Likewise. 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!
- Yuioup 9y ago
  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.

bjconlan 9y ago

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?)

EugeneOZ 9y ago

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.

botskonet 9y ago

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.

gungoman 9y ago

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)

azr79 9y ago

Fantastic release, congrats to the Angular team!