Live data from Hacker News

Does Angular 2 live up to the hype?

cycligent.com

41–44 of 44 posts

Re: Does Angular 2 live up to the hype?

#41
post #23

It sounds to me like it's a great framework, but "Angular 2" is a misnomer at this point. Maybe the "Angular" name will entice 1.x users to it, but it seems like the Angular team could have created "MasterBlaster 1.0, the successor to Angular" or something, still got some hype, and avoided a lot of grumpiness.

My vote was for "Angular Elizondo Mountain Dew Herbert Camacho" but the Angular team was already pretty committed to Angular 2 by then.

Didn't you hear? He lost the Pepsi endorsement. He's just Elizondo Google Angular Herbert Camacho now.

Re: Does Angular 2 live up to the hype?

#42
post #40

Earlier quoted context omitted.

How does it do with synching your route state with the redux store? I remember when I played with it (think routing has been replaced twice since) that was the real beast, though redux was a pretty nice fit other than that.

That's a good question; I didn't try it. On the bright side, if you don't mind diving one layer below the surface, the code for react-router-redux is short, well written, and easy to understand: https://github.com/reactjs/react-router-redux Even if the equivalent already exists for the current iteration, you could probably write your own in an afternoon without rushing yourself too much.

That's kind of what I did... It was not in a modular fashion though as a lot of it was trying to discover how the lifecycle worked in Angular 2... basically, I wanted to be able to trigger an effective redirect from angular or via redux action or via a route/hash change, and have the redux always reflect the current route... there were some bits with how the change detection works in ng2 that I had to tap into, apparently this is one of the bits that changed since I last used it though.

If I have to use ng2 again will take the time... aside, I really wish they'd renamed it to Angular 3 (3.0) for release, given the massive changes to "Angular 2" over its' lifetime and the number of broken blog articles and tutorials...

Re: Does Angular 2 live up to the hype?

#43
post #5

Can anyone comment on Angular 1 and Angular 2 living side by side in the same project, for the purposes of slowly migrating over to 2? I am aware that it is possible, but I've yet to read anything about someone really living with that. Everyone just talks about rewriting all code from scratch, which we're just not going to do.

I'm actually migrating a large (poorly written) angular 1 project to angular 2 using the adapter.

For the most part, its pretty straightforward. Unfortunately, if your ng1 code still uses ng-controller extensively, you'll probably be stuck at the rc4 release of Angular 2. Everytime I've tried to upgrade past that point, none of the controllers initialize.

Aside from that and the inability to mix attributes and directives from different versions, I haven't really dealt with any major problem upgrading. For any services you have which are returning promises instead of observables, I highly recommend creating a re-usable adapter class as it allows you to drop-in replace legacy implementations with new observable based services without changing the consuming ng1 code.

Re: Does Angular 2 live up to the hype?

#44
post #36

Earlier quoted context omitted.

Not GP but ionic is really solid. It helps to think of it mostly as a CSS framework with a tool chain for deployment and testing. Theres also a lot of examples and a pretty big community around angular + ionic.

Thanks. I haven't done webdev in many many years so all the new front-end & back-end frameworks are a bit overwhelming. One thing I haven't decided yet is what to use to build the "pre-login pages". The SPA itself will be only accessible after a login page, but before login there will be a bunch of pages (Home/Blog/Help/etc..). Should I use Angular for those pages as well?

The convention is usually to serve the SPA via a CDN regardless of server side authentication and then have client-side routing prohibit users from rendering authenticated pages. This assumes data is authenticated/authorized within a server side api and no privileged information is in client-side code (it never should).

In angular this is usually achieved by watching for state/route change events and deducing whether or not a route should be redirected or allowed to progress based on the status of the currentUser.

It sounds a little hairy but in my experience there are ample resources detailing the process and realistically it's about ~30 LOC.

Post reply on HN