Hacker News new | comments | show | ask | jobs | submit login
Angular 5.1 and More Now Available (angular.io)
46 points by mikeryan52 11 months ago | hide | past | web | favorite | 40 comments

Can anyone speak to their successes with Angular post 2.0? I feel like any time it comes up, it's mostly horror stories about the transition or how shops have just moved on to Vue, etc. Is it worth still considering / where does Angular shine where React and Vue come up short?

I've worked with Angular 2-5 and it's nice; IMO a lot nicer than Angular 1.x, which I still do have to work with (supporting a customer-facing 1.6.5 app). I haven't done a big app with it yet, but from the small ones I've done I am highly confident that "modern Angular" is now better than Angular 1.x in all important ways (breadth of capabilities, reliability, tooling, etc).

So I don't think there will be horror stories with Angular 5 for new projects, unless you just don't like Angular/TypeScript. It's definitely not like "going the wrong direction" from Angular 1.x, although I don't personally have any read on how it compares to Vue, or React, or Aurelia or what have you.

I also haven't gone through a 1.x→modern transition (yet), so I can't really speak to that, but in preparation for doing it I've read everything I can, on this forum, various blogs, etc.

I'm not looking forward to it, but on the other hand part of me thinks of course it's easier, or at least more fun, to move to something like Vue, because it's like a rewrite, or half-greenfield project.

It's almost always more fun to rewrite something, although usually not advisable from any other business perspective.

We don't see as many people talking/blogging about Angular anymore, but I think that's mostly because it's gotten boring. Which can be a good thing.

Getting from 1 to 2 was quite an experience. Much discussed here and elsewhere.

Thereafter though, they have been just relentlessly polishing, improving, smoothing rough edges, making bundle smaller, making compilation and execution faster, etc. It is really a model of exactly what you would want, in terms of a joint respect for backward compatibility with forward progress.

I don't understand the "haters" in some peer comments. There are certainly interesting things to consider in terms of feature and approach differences between Angular and its competitors. You could certainly find bits where a simpler approach taken by one of the competitors is a quicker learning curve and smaller size.

But at the same time Angular has a substantial feature footprint, it has significant swaths of functionality that the competitors don't address. We've been using (leveraging like crazy!) the Angular forms system. Many enterprise and non-enterprise applications have lots and lots of forms. Not forms in the trivial sense of, some controls on the screen. Complex interconnected behavior. Angular brings a lot to the table here.

Agreed - I have had a pretty pleasant experience with Angular in general, although it wasn't without its issues. Tests ran clearly slower than in AngularJS for example - the overhead in compiling TypeScript and setting it up is greater. Dynamically creating components was a painful experience for getting things done just right - I created a very flexible drag and drop module with it, I had to create some machinery on my own for performance reasons, namely for managing binding to document instead of repeated elements to avoid perf problems (there's an open issue I had filed in the past on that problem, I think it is still present). File size was larger than I liked as well, the initial load could be better IMO.

On the flip side, I have found I missed some things about Angular that I don't have with libraries like Ember and React - Angular has the superior testing story for ability to control granularity of testing without sacrificing architecture. Complicated pure functions can be tested with ease in Angular due to its injector, but painful in other scenarios because one cannot easily mock out dependencies so easily or requiring some fairly poorly documented/written about tricks. Managing state in Angular isn't really a difficult issue, and yet it becomes exacerbated in other ecosystems due to their delegation of tools to the community and each of the tools not providing good examples/documentation on blessed ways to wire them together, leaving a lot of dev shops with lesser solutions.

At this point, I see the major libraries/frameworks as having a set of more minor tradeoffs for devs to weigh - Angular, React, or whatever will get you where you want to be given the time/resources. With whatever is chosen for the view layer, you will be making time tradeoffs of where you'll spend more time when using Angular, or React, and you will create restrictions as a result. That said, it is perfectly possible to accomplish probably almost everyone's needs with Angular in a timely manner, and probably would be faster to initial market to get a moderately complex app than something like React IMO due to not needing to build certain types of boilerplate/refactoring as much due to lack of foresight about needing a particular system in place in the app.

Note: I have almost 5 years of experience with Angular, and currently have almost a half year of experience leading a very complex React project.

So if I have no preference of my own, you'd suggest Angular over React? I want to get the product out soon and focus on generating business value rather than the framework itself.

All depends on your team - my current project is in React since it leveraged the team’s strengths/preferences in an optimal fashion. That calculus is different for different teams. I will say that it feels like using React demands more from the developers using it because it’s easier to create suboptimal abstractions, and we’re fortunate that we have developer talent that is much better than you get at most companies.

I did a project or two in React, then worked with Angular 2+ for our in-house project.

I like React because it's easier to set up and get working; you don't need some ridiculous dev environment just to say "Hello world". I think React does one thing and does it really well, and its flexibility makes it easier to mix and match packages to do what you need to do.

Angular is ridiculously opinionated, and very complete. But for big projects or for multiple projects with different people coming in and out of the project this can be a strong asset. We've had some big React projects where you have to go out and get Redux, then start thinking about observables, maybe you want TypeScript but maybe you want Flow, etc. Angular already thought about all of that, made decisions for you, and structured it in a standard way so that once you learn the conventions it's pretty easy to reason about any Angular project.

And as a front-end dev who got started on the Web in the Netscape days, I appreciate that Angular doesn't treat CSS as a bug to be fixed. React (and the kinds of people who work on React) seem to desire a pure JavaScript world, while Angular keeps a more familiar HTML/CSS convention on the template level.

We are working on 4-5 large admin apps (60-80 screens) using Angular and PrimeNG. After initial training the team (8-10 programmers) was very productive. The bundle size is a little large. But it has improved a lot with Angular 5.

Quite happy so far.

I tried it along with Vue and React and it was my least favorite by far. Feels very overengineered and the level of complexity relative to the others doesn't seem worth it. Probably the least flexible of the three too.

That being said, it's still a big improvement over everything else I've used that isn't React or Vue.

Angular 1.x interop seems like the only compelling thing about it in my opinion.

I have been working on an internal, form-heavy, app for a bank client for the past 6 months as my day job. I wouldn’t say I love Angular 2/4/5, but it does get the job done. Since Angular has a rather steep learning curve, having someone who has experience with it on the team will help avoid a lot of headaches and gotchas.

There are certainly some issues with Angular. For example, starting Webpack Dev Server is really slow (a minute or longer). Running a lot of tests with Kharma can be slow. If you know what the issues are and can either live with or work around them, then it is not that bad.

Angular is _fine_, but it's largely a "me too" framework that brings nothing new to the table. On the other hand, it insists on using a non-standard language, which breaks all of the tooling used in the rest of the JS ecosystem.

React and Vue are reasonable options, but as someone using Angular in production I'd urge you to stay far away from Angular and TypeScript.

You're entitled to your opinion, but for many people (me being one) first-class TypeScript support is absolutely a compelling feature.

I may not choose Angular for every project, but I would certainly never again use untyped JavaScript over TypeScript, for an app of any size, unless there was some unusual and very compelling reason.

(And it would have to be a really unusual reason; I can't even think of a hypothetical one.)

In my own experience, TypeScript is a huge advance over JavaScript without types, in both productivity (how quickly functionality gets implemented) and reliability (how many bugs ever make it all the way to a customer).

I will spice up that factual statement with a bit of speculation that will perhaps be more controversial: in my experience watching other developers move to TypeScript, I think the productivity and reliability gains generally apply to their work too, whether or not they personally like TypeScript.

> as someone using Angular in production I'd urge you to stay far away from Angular and TypeScript

Say what you will about Angular, but why the hate on TypeScript? I've found using TypeScript one of the better experiences I've had in the Angular ecosystem.

I understand the Angular part but why Typescript?

It shines by being extremely opinionated, but imo the tradeoffs are not worth it.

I was initially very curious about Angular2, but our relationship ended very quickly with the discovery of modules and dependency injection. It feels like some kind of arcane over-engineering compared to React's (and vue's) simple and sufficient import-and-use model.

We use it on an app that's a bit over 100k lines of our own code. It works fine, there are some gotchas but overall it's as decent to work with as any other framework. Build setup is a bit of a bear but that is largely due to our own requirements and patterns.

Even if you never use Angular you can thank them for finding and fixing a huge Webpack memory leak:


Which version of webpack is this fix included in?

3.10 I think.

The notable part of the “and more” is the first stable release of the Material theme/UI library.

I created a new project using @angular/cli 1.6 which the release says is tied to Angular 5.1: https://github.com/angular/angular-cli/releases/tag/v1.6.0

But all npm package.json dependencies are still anchored on the same ^5.0.0 dependencies that ng v1.5.0 had and still depends on typescript "~2.4.2", basically ignoring the 5.1 announcement.

How can we create a new Angular 5.1 App using ng? Are we meant to manually change all dependencies to ^5.1.0

I manually updated the typescript dependency which breaks the build, even when manually upgrading the compiler-cli to ^5.1.0, so basically 5.1 doesn't work with typescript 2.5.3 as indicated in the announcement.

I also don't get the point of upgrading to the latest angular-cli v1.6 and using it to create the same 5.0.0 app that v1.5 did.

Is the way to create a v5.1 ng app is for everyone to manually update all dependencies to ^5.1.0?

the caret ('^') will update a minor version[1]. So ^5.0.0 will install 5.1.0.

[1] https://bytearcher.com/articles/semver-explained-why-theres-...

The question is what's the best way to create an ng 5.1 app? i.e. what was just announced. I've just manually updated all deps to ^5.1.0.

If you grab the latest angular-cli and do `ng new foo`, you will get the latest 5.1.0 update. Or if you have an existing app, run `npm install` but make sure you update your package-lock.json file.

It’s pretty good but react is better. There is still no documentation on the details of projection which is super frustrating.

As I see it and know about it, React is a library which does a small set of things very very well. Angular on the other hand is a behemoth framework that does a lot of things, all reasonably well. I am sure there would be use cases where Angular is a better choice than React. Not having used React, I am not sure of such cases.

I'm still on 1.0.

Not changing either.

Would you let me know the reasons for not upgrading? I am on Angular 1.6 and would like to upgrade to Angular 2 and beyond, but it is not a straight forward upgrade. What would keep you on Angular 1.x?

Which 1.0 are you using? I'm on 1.6

Not OP but I'm still on 1.2 because I still had to support IE8 when 1.3 dropped it out of the blue (I wouldn't have used 1.2 if I had known the Angular team planned to drop IE8 support). Shortly after, Angular 2.0 was announced and at the point where IE8 was no longer a requirement Angular 2.0 was still not stable but not far away enough to justify spending energy upgrading the codebase to another 1.x release in the meantime (especially as AtScript was still a thing and there was no clear upgrade path yet).

The app is still in production but parts of it have been rewritten in React since. Despite the added weight of another library, introducing React ironically helped reduce the file size (mostly because it allowed us to remove dependencies that were no longer necessary and the build process changed with bower being replaced by yarn).

EDIT: Another factor in the decision not to upgrade to 1.x when we were able to drop IE8 support as a requirement was that the removal of IE8 support came so abruptly that we decided not to trust Angular to support any browsers that aren't on the latest version (i.e. we expected them to drop IE9 support equally sudden and it seemed clear that Angular 2.0 wasn't going to be built with compatibility in mind).

For comparison, when we added React to the project two years later (when IE8 was no longer a requirement), React still supported IE8 and only several months later announced that they would drop support with the next release. But even then "dropping support" meant that bugs were deprioritised whereas the AngularJS announcement heavily suggested that existing code for IE8 would be intentionally removed or rewritten in a way that breaks compatibility outright and the code should be expected not to work in IE8 at all.

So based on how the announcements were made and what "dropping support" entailed in each library, React seemed the safer bet.

To no other framework?

I thought this was some kind of joke... until I realized they skipped v3. But still, v5 already? Or did I just get used to Bootstrap 4 being in Alpha for years?

4 -> 5 included some new cool features but was a smooth upgrade. 6 is coming out in March and then a new "major version" is scheduled every 6 months.

This is common for end-user apps but feels very weird for developer libraries and frameworks.

We are used to X.Y.Z releases where X are "major rewrite", Y are significant updates, and Z are bugfixes.

That said, Angular's new scheme could be technically correct strict "semantic versioning". In semver X.Y.Z, Z releases are supposed to be bugfixes with no feature additions, Y releases add features but with perfect backwards compatibility, and X releases introduce breaking changes. A backwards incompatible change, no matter how small and easy to adjust for, should be a major version bump according to semver.

It'd be interesting to see Angular join the React bandwagon and embrace codemods. React has broken compatibility several times (though you now get deprecation warnings on the final minor release before a breaking major) but Facebook has an internal policy that if React breaks compatibility, the React team has to fix the application code it breaks -- which has lead to every breaking change coming with codemods which can automate the necessary adjustments, making upgrades significantly smoother.

> 6 is coming out in March and then a new "major version" is scheduled every 6 months.

I work in a large corporation and they're still planning their transition to 1.5 and then to 2. I'm keeping up by building stuff in my off time, but trying to keep a fortune 200 corporation on a six month upgrade track? Not happening.

I've already heard rumblings from upper management of going back to some open source Java frameworks like Spring MVC, Vaadin or gulp Struts because of how fast they are releasing major versions and the time and cost of keeping up.

My fear is Angular will be regulated to startups, medium sized businesses or small autonomous business units within larger companies. When faced with a six month upgrade schedule, many larger organizations I fear are going to balk and just drop it in favor of something they are already comfortable with. . ergo my company wanting to go back to Java since 95% of everything built here is done with Java.

> I work in a large corporation and they're still planning their transition to 1.5 and then to 2.

Angular 1 -> 2 is an actual "major release". "Rewrite all your apps from scratch" major.

But starting from Angular 4, the "major version number changes" doesn't mean a major effort to update. There's a decent chance that 4 -> 5 -> 6 -> 7 etc will work without any code changes. But as long as there is a backwards-incompatible change, no matter how small and in how obscure submodule, it requires bumping the version number according to semver.

Most enterprise users will probably skip multiple versions between upgrades, just as they skip Ubuntu releases and Django releases and Rails releases and so on.

Still playing catch-up. React is already on 16.

Joking aside, apart from semver another reason for the weird versioning in Angular is that it's a rather large collection of modules, especially if you include things like RxJS (which technically aren't exclusively part of Angular but affect APIs due to their widespread use). So it's fairly easy to get a semver major version bump because of an implementation detail you likely wouldn't care about but that breaks backwards compatibility with some older library in some way.

They changed to semantic versioning. From what I remember they intended to keep their development style of breaking backwards compatibility where convenient, though. The consequence is that you’ll regularly see major version bumps.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact