Live data from Hacker News

Angular v8.0

github.com

111–120 of 210 posts

Re: Angular v8.0

#111
post #88
post #69

While the effort by the Angular team deserves praise, I think for the vast majority of use cases it is a mistake to do it all client side. With some exceptions, there is really no benefit in making a SPA but there are many drawbacks. I don't say this lightly. I used AngularJS in 2015 and since then I've been making SPAs in React, Vue, and Inferno + Mobx.

Small, internal business apps have been a good use case for me. I'm working with few dev resources (me, myself & I), so the "batteries included" approach of Angular is nice, and knowing it's always served over a fast corporate network alleviates the filesize concerns somewhat. Plus, we're in a situation right now where some of our clients are being sort of amorphous on what server platform they'd like to migrate to a…

> Plus, we're in a situation right now where some of our clients are being sort of amorphous on what server platform they'd like to migrate to and when, so the browser is a more stable target (ironically).

Right, but you could still do server side rendering by consuming a third party API instead of a DB directly.

Maybe bloating is not an issue in some use cases, but client side rendering can have a major impact on the CPU.

Re: Angular v8.0

#112
post #106
post #72

Angular is really a great framework. I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. I also wish the Angular team had just called Angular 2 something else, since the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back. I also understand that people just have different preferences, which is fine, too. Out of the box, you get: routing with la…

I've been using Angular for a few months now and it's mostly been a good experience. We've been using Angular 7. My biggest gripe, and this might just be my inexperience, is fighting the change detector to try and ensure reasonable performance when displaying a large number of elements. There are certainly mechanisms to do this but it does seem to take some work.

FWIW, the Angular team is aware that this is a pain point. There were several talks at NG-Conf a few weeks ago that referenced replacing or removing zone.js-powered change detection for increased performance and/or smaller build sizes. They're trying to avoid another Angular 2 situation though, so it may take a while for a backwards compatible solution to surface as the default.

Re: Angular v8.0

#113
post #65
post #57

Earlier quoted context omitted.

https://reactjs.org/docs/hooks-intro.html edit: Lol apparently two React devs ears were burning at the same time.

well 16.8 (which basically was the latest version) also btw: https://reactjs.org/docs/hooks-faq.html#do-i-need-to-rewrite... and I still have no idea how I only do stuff on the client in a SSR environment (stuff that i did in componentDidMount)

Btw, totally agree about classes. I still like the 'look' of them for stateful components.

Re: Angular v8.0

#114
post #95
post #5

This release is awesome, here is a summary from the Angular team blog - https://blog.angular.io/version-8-of-angular-smaller-bundles... The main feature among many is differential loading, that will load different versions of the application depending on the capabilities of the browser. This will avoid installing polyfills without the need for them and reduce the bundle size. There are reports of 40kb reduction in bu…

> There are reports of 40kb reduction in bundle size, which is a lot. It would be for libraries like react or vue that are already small. Angular is still big enough that even after being 40kb slimmer it's still fairly huge (I think the typical build is like ~550+kb).

It's just the first step. With both differential loading and Ivy, build sizes for a minimal app can drop close to 14kb, iirc. That's the goal, anyway.

Re: Angular v8.0

#115
post #106
post #72

Angular is really a great framework. I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. I also wish the Angular team had just called Angular 2 something else, since the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back. I also understand that people just have different preferences, which is fine, too. Out of the box, you get: routing with la…

I've been using Angular for a few months now and it's mostly been a good experience. We've been using Angular 7. My biggest gripe, and this might just be my inexperience, is fighting the change detector to try and ensure reasonable performance when displaying a large number of elements. There are certainly mechanisms to do this but it does seem to take some work.

You should be using OnPush everywhere, then your struggle will change to only getting changes detected in certain scenarios. Still a pain sometimes but not as bad as the Default change detection strategy.

Re: Angular v8.0

#116
post #106
post #72

Angular is really a great framework. I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. I also wish the Angular team had just called Angular 2 something else, since the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back. I also understand that people just have different preferences, which is fine, too. Out of the box, you get: routing with la…

I've been using Angular for a few months now and it's mostly been a good experience. We've been using Angular 7. My biggest gripe, and this might just be my inexperience, is fighting the change detector to try and ensure reasonable performance when displaying a large number of elements. There are certainly mechanisms to do this but it does seem to take some work.

Switch to OnPush, use async pipes and immutable data structures. Add to that some of the virtualization components that ship with @angular/cdk and you're pretty golden most of the time.

Re: Angular v8.0

#117
post #30

I wonder what's the story behind delays of Ivy? Can somebody elaborate? It was first scheduled for v6 (don't remember , then for v7, now there is v8 and it's again rescheduled for v9.

It needs to be backwards compatible and it is tested with google internal applications and needs to be approved by said applications.

To add to this, the Angular engineers at Google are responsible for updating all however-many-hundred of those internal applications if they make any backwards incompatible changes.

Re: Angular v8.0

#118
post #72

Angular is really a great framework. I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. I also wish the Angular team had just called Angular 2 something else, since the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back. I also understand that people just have different preferences, which is fine, too. Out of the box, you get: routing with la…

> There's no need to evaluate different routers, form libraries

That's a great thing about Vue, too. vue-router and vuex are well-designed and well-supported / integrated. Makes a huge difference.

Re: Angular v8.0

#119
post #78
post #72

Angular is really a great framework. I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. I also wish the Angular team had just called Angular 2 something else, since the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back. I also understand that people just have different preferences, which is fine, too. Out of the box, you get: routing with la…

As a long time React developer, I second this. Especially this part: > There's no need to evaluate different routers, form libraries These two things have been the bane of my React development experience ever since the days of "flux". Every new React project I start I end up using a different set of libraries, and it's not just me either -- a very experienced React dev I work with just switched our React e-commerce S…

Everyone's experience is different here, but I've grown to hate these all-encompassing frameworks -- somehow I always run into their limits. As far as I understand, Angular has its own module system, its own dependency injection, its own test framework. If you have any special requirements for any of those, you usually can't rely on the vast JavaScript ecosystem because Angular doesn't play well with many common JavaScript techniques. React also has a precompile step with JSX, but that's simple syntactic sugar, and besides that, React is really just a well-behaved library with a surprisingly small API surface. It doesn't try to do everything and it plays well with non-React libraries, at least in my limited experience. I usually find that in any context, taking such a mix-and-match approach is a lot more flexible in the long run than using a large framework.

Re: Angular v8.0

#120
post #19

Earlier quoted context omitted.

I've been burnt by the non-Euclidian enormity of ExtJS, so I understand the desire for something simpler. On the other hand, when you leave the world of progressive enhancement and widgets (ie. jQuery), you find yourself needing a lot of common infrastructure and picking and matching that can be quite tedious (never mind dependency hell), which is something that react always had issues with -- and that seems to exten…

WebAssembly is still a couple of years away, sadly.

Yes, then we'll get native J2EE in the browser instead of JS copies…

The whole interaction model is just a lot more tedious than desktop UI development. One of the few approaches that I actually liked (not just tolerated) was Seaside, but that went away when the blood-dimmed tide of JS was let loose.

Post reply on HN