Live data from Hacker News

Angular v8.0

github.com

161–170 of 210 posts

Re: Angular v8.0

#161
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…

How do you guys keep up with these frameworks? You get stuck on one project or in one startup for 2 years and Angular has moved 6.5 whole number versions all while the rest of the job market is confused but kind of tolerating why you jump around jobs so much if I'm using Angular, my "side project" isn't going to be using a higher version of Angular every 6 months. Its going to be using React or something to see what…

Because angular versions are like chrome versions. 1->2 was a full rewrite, now the new major versions always have some small upgrades and even smaller amount of breaking changes, it's not a big deal at all to upgrade.

You don't really have to upgrade every time a new version is out btw.

Re: Angular v8.0

#162

Congratulations on the release! For all the talk of React and Vue I still like the 'batteries-included' approach of Angular. I mostly do Kotlin in my day job so Angular aligns fairly nicely with the way applications are structured. I don't get the militant need for terseness that's seen in approaches like React Hooks. I also don't need the choice between multiple backwards-incompatible (or competing) routers, nor do…

Ah...Kotlin on the backend? Can you share more details about your stack/experience? I've been keeping an eye out for it to crop up in production backend stacks, so I'm very interested in learning how well it works for you...

Re: Angular v8.0

#163
post #108
post #99

Earlier quoted context omitted.

> It's also interesting to see the React community move towards some of the things that Angular has been doing for years: embracing TypeScript, extracting business logic to services (or you can call them Hooks), creating injectable shared state (or you can call it Context). Huh? Hooks are just a way to use component lifecycle in absence of classes (note how React is pushing towards having components as functions as o…

Definitely correct me if I'm wrong, but I also thought hooks were for factoring out common logic and sharing it among functional components. I see lots of "hooks" libraries floating around. For Context, like you said, it existed before, but everyone was told not to use it. After the new API came out, people started suggesting ditching Redux for Context, and I know a lot of people did that. Using Context in that way i…

I agree that the pattern of "services" is a good one. But you don't really need Angular's DI for this in javascript. You can just use an ES6 module.

Re: Angular v8.0

#164
post #106

Earlier quoted context omitted.

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.

This is precisely what I don't like about Angular. That there is all this stuff. And I have to care about what it is doing under the hood (and this is complicated and not especially well documented).

In React if I have performance issues, then it's pretty easy to work out what's causing them.

Re: Angular v8.0

#165
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 really enjoyed Angular. Typescript is a no-brainer now, and now that I'm starting to explore RxJS a bit more, it's impressive how powerful it can be once getting over the large learning curve. Being able to subscribe to an observer, and make a web request, and make sure that only the latest request is taken, and being able to do so out of the box is really, really nice.

Re: Angular v8.0

#166
post #111
post #88

Earlier quoted context omitted.

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 th…

The "server" part of the "server side rendering" is necessarily on premises, and likely to move to... something? Soon? I deliberately wrote it as thin as possible, because it will need to be rewritten, without question. The db, fortunately, is on a stable platform.

I don't disagree with the bloating issue, but in this case, these are all decently capable desktops, and it hasn't been even close to a problem.

Re: Angular v8.0

#167
post #78

Earlier quoted context omitted.

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…

If you were new to React or Angular, but needing to choose one for a single developer project, which would it be now in 2019?

Angular is easier to get up and running. Then you also have a very solid foundation that can be picked up easily by new devs starting on the project. Whereas, React seems to work only for more experienced front-end developers since you have to make more choices. If someone is just starting out it can turn into a mess pretty quick.

Re: Angular v8.0

#168
post #108

Earlier quoted context omitted.

Definitely correct me if I'm wrong, but I also thought hooks were for factoring out common logic and sharing it among functional components. I see lots of "hooks" libraries floating around. For Context, like you said, it existed before, but everyone was told not to use it. After the new API came out, people started suggesting ditching Redux for Context, and I know a lot of people did that. Using Context in that way i…

I agree that the pattern of "services" is a good one. But you don't really need Angular's DI for this in javascript. You can just use an ES6 module.

Unless you care about the scope/lifecycle of the service. Or want to easily replace its implementation in different contexts (like tests).

Re: Angular v8.0

#169

Earlier quoted context omitted.

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.

This is precisely what I don't like about Angular. That there is all this stuff . And I have to care about what it is doing under the hood (and this is complicated and not especially well documented). In React if I have performance issues, then it's pretty easy to work out what's causing them.

You can largely ignore what Angular is doing under the hood, tbh. If you're having performance issues, the answer is often related to change detection (aka, Zone.js).

Re: Angular v8.0

#170

Earlier quoted context omitted.

I agree that the pattern of "services" is a good one. But you don't really need Angular's DI for this in javascript. You can just use an ES6 module.

Unless you care about the scope/lifecycle of the service. Or want to easily replace its implementation in different contexts (like tests).

Most test frameworks allow you to stub imports. DI is just one of the many wheels Angular has reinvented.
Post reply on HN