Live data from Hacker News

Angular 9.0

blog.angular.io

231–240 of 308 posts

Re: Angular 9.0

#231

Earlier quoted context omitted.

Maybe the disdain comes from the fact that people don’t like getting a whole house (like angular) built on shaky grounds, but prefer a clean basic foundation (like react) where they can lay whatever bricks they like on top (routing, data management). It feels cleaner and more solid.

"Built on shaky grounds" needs a citation and additional explanation. I mean I hear what you're saying, but Angular is an opinionated framework whereas React is not, and many people end up reinventing the wheel (or an application framework) in the process. There is value in being opinionated.

The churn between angular versions, stemming from the limitations and inconsistencies of two way data bindings and others, are what I mean by «shaky grounds».

Yes there is value in being opinionated, but it is less risky to decorrelate the opinion from the foundation. There are opinionated frameworks built on top of react and it is very nice like this. But react itself should not be opinionated.

Re: Angular 9.0

#232

Earlier quoted context omitted.

Here's another newbie question, if you don't mind: What would be the optimal place to hook to get a callback to draw something in a canvas whenever the DOM is updated? I'm currently subscribing to changes in a BehaviorSubject instance variable of my selection service "god object": selection service: public user$: BehaviorSubject ; my subscribing component: constructor( public selectionService: SelectionService ) { th…

You can use ngOnChanges callback to react to changes in the angular framework - i.e. if bindings/@Input()s/etc have changed and you want to do something special there when they change. But for just generic DOM changes happening outside of the angular framework that wont work (since angular does not know about random other DOM stuff going on elsewhere in the page and outside of the framework). E.g. if there is some st…

Thanks, that sounds like the right approach. I don't need to react to all DOM changes, but I have one jolly callback for changes to my one big happy god-owns-the-user-owns-the-world object (the observable), but the component has view-level properties like hiding and showing details, zoom and pan, etc, that aren't in the observable model, and I'd still like to redraw the canvas when they change. It doesn't take long to draw, but I just don't want to miss any updates, or have to pepper the code with explicit calls to redraw it every time I think something might have changed (causing a lot of pointless redrawing).

Fortunately my app is simple enough that I can just redraw everything whenever something changes, as long as I'm not doing it 37 extra times.

Re: Angular 9.0

#233
post #224

Earlier quoted context omitted.

I have the exact opposite opinion. React is the only sane way to do web development. All other approaches are deeply flawed by either relying on imperative mutations of the DOM instead of clean declarative code, or by relying on ugly templating syntax and data attributes instead of just using JS basic constructs like react. The power of react is just at its beginning, as we can see with things like react-three-fiber…

The alternative to React is not Angular or another JS framework. That was not just my anti-React rant, it was an anti-SPA rant in general. I still fail to see why people need to build an entire application twice, once on the server, and again on the client, except perhaps when you have very frontend-heavy interactivity requirements (like photoshop-in-the-browser or games). SPA's attempted to rebuild the entire HTML w…

>> I still fail to see why people need to build an entire application twice, once on the server, and again on the client

I fully agree, and this is why I can’t understand why in 2020, some people still don’t understand that react/SPA and node backend for server side rendering are the best solution.

With react and server-side rendering you code your front end only once, of course. And the same codebase can be rendered on the server or on the client transparently. Same JS libraries can be used in the server, in the browser, in mobile apps with react native.

There is just the API on one side, and the frontend on the other side. Where the frontend is rendered does not matter.

Re: Angular 9.0

#234
post #139

Earlier quoted context omitted.

People who despice react because of redux(Boilerplate) should try mobx.

Or you know, use Redux because the boilerplate is gone... https://redux-toolkit.js.org/ You don't have to create actions or constants anymore, you just create your reducer functions and selectors, then use hooks to select and dispatch in your components. Never got why people took up a completely different paradigm just because they couldn't figure out how to reduce their boilerplate...

Or use XState as Redux is only a half implementation of a state machine. It get's the job done but a state machine gives you far more structure and comprehensibility around state management.

https://github.com/davidkpiano/xstate

Re: Angular 9.0

#235
post #207

Earlier quoted context omitted.

Your argument is flawed with a very opinionative starting point, which is that Angular wouldn't provide a solid foundation. This is, at the very best, very debatable. In my experience, it's the very opposite. Angular gives you very solid foundations as it's a proper framework that ships everything you need to build scalable apps. So you start from something small, and as you grow you know you can do so without rethin…

The real difference between the two frameworks boils down to developer happiness. In Angular, all of the choices are made for you. For some, the lack of autonomy and agency when writing Angular applications makes those developers sad. It's hard to take pride and ownership in your work when 90% of everything has been decided for you, and if you try to eject from the "Angular" way of doing this, you end up just writing…

This is the biggest “meme” about angular and it’s so unbelievable wrong. It shows that you haven’t used the framework if you think all the choices are made for you.

Instead of spending all my time analyzing different open source packages for every single thing you do, you just have access to a first class supported solution.

IMO, lots of the react ecosystem is built on engineers trying to show off. They get fancy coming up with a solution, writing a unique library, and there’s no reason for this. Everyone likes to think their code is unique and special and great, but it’s not. We don’t need to reinvent the wheel all the time. So many of these apps are going to need to be rewritten in a couple years because of how poorly architected they are. That’s not a problem of react, but it’s a problem of react devs who take a small view library then build a framework on top of it.

Re: Angular 9.0

#237

Earlier quoted context omitted.

"Built on shaky grounds" needs a citation and additional explanation. I mean I hear what you're saying, but Angular is an opinionated framework whereas React is not, and many people end up reinventing the wheel (or an application framework) in the process. There is value in being opinionated.

The churn between angular versions, stemming from the limitations and inconsistencies of two way data bindings and others, are what I mean by «shaky grounds». Yes there is value in being opinionated, but it is less risky to decorrelate the opinion from the foundation. There are opinionated frameworks built on top of react and it is very nice like this. But react itself should not be opinionated.

There is so little churn between angular versions. Angular 1-2 was a big change and they should have renamed the framework. But you have to understand how angular 1 came into existence. It wasn’t planned to be used by everyone, it was just solving some problems experienced by a couple devs and it spread like wild fire.

The team that eventually took it over and grew around it recognized it had some problems scaling and being used for large applications. They knew they couldn’t just change angular 1 to be what it needs to be, so they made a big switch. They put in patterns that benefit large apps, typescript, observables, the choice of two way binding or one way binding, better DI system.

Everyone says react isn’t opinionated, and for developing an enterprise app that just sounds like a nightmare.

Re: Angular 9.0

#238

Earlier quoted context omitted.

I've been doing Angular for 5+ years now. I think you might be using it wrong because I never experienced anything like that.

Angular has a lot of unique concepts that people find difficult to wrap their heads around. The Observable pattern, decorators, typescript, etc. When you throw things like NGRX and effective management of state / side-effects in the mix; things get exponentially more complex and difficult to scale. I have personally witnessed companies take guys who have been slapping together "apps" in jQuery / .NET for the past 10…

Would you recommend any resources to learn how to effectively build a scalable modern web app? I haven't worked with Angular for about a year now, but I didn't use NGRX or similar alternative and I distinctly remember that managing state for the app got progressively harder as the app got more complex.

Re: Angular 9.0

#239
post #117

I have a policy of only shipping "back-end" apps because I'm worried about performance, browser compatibility and SEO. I don't know if the situation has improved in Angular 9. Does anybody here use Angular for their customer facing websites?

We use Angular for the Alabama Dept of Forensic Science's DNA Tracker and the Alabama Dept of Public Accounts. Both seem to work well and have good performance.

Re: Angular 9.0

#240
post #60

Earlier quoted context omitted.

For me, I was first getting into web development before Angular 2 was out. I thought it was super cool that I could make an incrementing counter and a to do list but just couldn't figure it all out. I then tried React and it just kind of made sense. Since then from the sidelines I've heard Angular has gotten much better but personally don't see any reason to use anything other than React at this point in time.

I’m also starting to feel like if anything will dethrone React, it’ll probably be Vue or Svelte.

I think Vue's reactivity system just fundamentally doesn't work which is why Vue 3 is basically an entirely new paradigm/framework trying to masquerade as an update. I have a feeling its going to split the community and end the way angular did.

I haven't used Svelte at all but it looks very interesting.

Post reply on HN