Angular 9.0 • Hacker News Board

Re: Angular 9.0

#201

Post by Cthulhu_ » Fri, Feb 07, 2020, 11:25 AM UTC

crubier wrote: post #147

Phenix88be wrote: post #136

After 2 years of Angular madness I will send my resignation and I hope I will never work with it again. My app is a big stack of workaround stuff that might break anytime. Because that is how angular work. Some stuff work in a context and doesn't in an other. Nobody's know why ! They have so much issue on Github that they need a bot to close them after a while. They hope the bug disappear by himself ?

Meanwhile, the web apps I wrote in 2014 in react still work flawlessly. Join us, you’ll enjoy the ride!

I wouldn't expect anything else to be honest; as long as the underlying JS / HTML does not change, anything written 10, 20 years ago should still work now. Browsers (= your application runtime) are pretty good with backwards compatibility, and not touching your application should not break things.

Unless it's doing unsafe or nonstandard stuff in the first place, like idk, cross-domain requests or weird stuff with iframes or whatever it was Google tried to do when it added an extension that tried to do preloading and stuff like that.

Re: Angular 9.0

#202

Post by Cthulhu_ » Fri, Feb 07, 2020, 11:27 AM UTC

crubier wrote: post #197

dragonsh wrote: post #175

Earlier quoted context omitted.

On HN in general there is a disdain for anything other than react, probably more people of Facebook generation and admiration of it's technology like open graph, react and few other products. Based on personal usage of React, it's no easier than angular or any JS based framework like Vue (which in my view more sensible than react). You add state management, templates, router and 1000's of npm packages to do anything…

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.

Re: Angular 9.0

#203

Post by mattlondon » Fri, Feb 07, 2020, 11:30 AM UTC

qwerty456127 wrote: post #187

mattlondon wrote: post #163

Earlier quoted context omitted.

I have not done much react apart from a "hello world", but I have been using Angular2+ for years, having previously used AngularJS. Here are a few thoughts: The learning curve is steep I agree. There does feel like there is a lot of ceremony and boilerplate required for even the more basic "hello world". Also if you are not familiar with RxJS before learning Angular then that is a second learning curve that you need…

> Also if you are not familiar with RxJS before learning Angular then that is a second learning curve that you need to know too and it is a challenge. You are not the only one mentioning this here. Do you believe it's wise to start with learning RxJS before you even approach Angular if you are a VanillaJS/JQuery "dinosaur" looking forward to learn Angular?

Yep it might help to learn some RxJS "in isolation" before encountering it for potentially the first time in Angular.

No need to master it - probably spend an hour or two on RxJS tutorials & samples to get to know it before jumping in with Angular so you know where the join is between Angular + RxJS.

Re: Angular 9.0

#204

Post by DonHopkins » Fri, Feb 07, 2020, 11:34 AM UTC

DonHopkins wrote: post #185

mattlondon wrote: post #174

Earlier quoted context omitted.

> Is there a standard way to define local variables in an Angular template so you don't have to repeat the same redundant expression again and again I usually define something in the component, and reference that. If you need to lazily evaluate it you can just reference a function in the component (e.g. "...{{ someFunction() }}...", and have the function do whatever lazy work and/or memoisation you need there. If you…

Thanks, that's great advice! Angular is really great when I can get away with just not worrying about the bomb -- it's amazing what little effort it takes (I just wish ng-component was spelled with only one or two letters). But there are still those things I'm used to being very easy to do in Genshi, that seem incredibly complicated in Angular, and don't leverage JavaScript. Granted they both have extremely different…

I just ran into another problem with Angular templates that illustrates the value of a templating system at least supporting the underlying implementation language's straightforward syntax and semantics for loops and conditionals and parameter passing, before going off and inventing all kinds of totally new unique special custom control structures, domain specific languages and micro-syntaxes, indirect ways to name and pass parameters, and other linguistic whoopee cushions:

How do I make an ngFor loop iterate through a range of numbers, without actually defining a literal array of numbers in the component for it to loop over?

https://stackoverflow.com/questions/36354325/angular-2-ngfor...

With Genshi, you simply do it the standard python way, since Genshi for loops are equivalent to Python for loops: $i

But I can't figure out how to, for example, use ngFor to iterate from 0 up to n, since it requires an array argument, and there isn't a c-like form like for (init; condition; repeat), or a standard JavaScript way to make a range like python's range(n).

Should I just give up and make a "range" utility method on my "God" service object that I'm passing in anyway? The more gaps like that I have to plug with my God, the more it becomes a God-of-the-gaps object.

https://en.wikipedia.org/wiki/God_of_the_gaps

Re: Angular 9.0

#205

Post by spaceribs » Fri, Feb 07, 2020, 11:35 AM UTC

crubier wrote: post #152

izietto wrote: post #149

Earlier quoted context omitted.

> from a developer point of view at that point you could be using a react based framework and your experience would be the similar to vue with JSX It will not, because Vue has a better integration with the data source (Vuex) and a better integration with the routing (Vue Router) I mean, I agree that React is an awesome framework implemented upon great design ideas (pure functions and plain JS templates), but it has i…

For routing react-router is just perfect. And for data source/state management there is plenty of choice, I use Apollo for global state/data source and useState for small state full interactions, I can’t see how it could get simpler. But whatever floats you boat really, the point is that the nice part of vue are inspired by react anyway. I wish the two community merged, to be honest, I see no point in dividing for su…

> But whatever floats you boat really

You specifically argued against that, your arguments seem to be highly religious in nature.

I don't know how many years you've worked in the industry but if you think React will be the dominant way of building apps for the next ten years, I have some Adobe Flash developers who I'm sure would like to say a few words.

Re: Angular 9.0

#206

Post by mateuszf » Fri, Feb 07, 2020, 11:35 AM UTC

qwerty456127 wrote: post #188

ChicagoDave wrote: post #59

Earlier quoted context omitted.

Opinionated (professionally engineered structure) vs. Simple template system. There’s no good or bad. As in any architectural adoption, it should’ve based on your team’s capabilities and support capabilities. Experience matters too. There are good reasons to use either platform.

Doesn't opinionated and professionally engineered structure mean "better"? Clearly most of the JS coders don't have expertise sufficient to engineer their structures professionally on their own - isn't it better to embrace a professionally engineered structure done for you for free?

> Doesn't opinionated and professionally engineered structure mean "better"?

No, if it's overengineered.

Re: Angular 9.0

#207

Post by ghego1 » Fri, Feb 07, 2020, 11:35 AM UTC

crubier wrote: post #197

dragonsh wrote: post #175

Earlier quoted context omitted.

On HN in general there is a disdain for anything other than react, probably more people of Facebook generation and admiration of it's technology like open graph, react and few other products. Based on personal usage of React, it's no easier than angular or any JS based framework like Vue (which in my view more sensible than react). You add state management, templates, router and 1000's of npm packages to do anything…

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.

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 rethinking the foundations of the app, as they are provided by the framework, which is Google guys, which means most likely people with a lot more experience than the average front end dev.

On the contrary, react leaves basic choices (the bricks you mentioned) to the user. While freedom can be good, it also implies that errors will be made, so you are a lot more likely to build on shaky foundations.

Re: Angular 9.0

#208

Post by gridlockd » Fri, Feb 07, 2020, 11:42 AM UTC

dragonsh wrote: post #175

crubier wrote: post #147

Earlier quoted context omitted.

Meanwhile, the web apps I wrote in 2014 in react still work flawlessly. Join us, you’ll enjoy the ride!

On HN in general there is a disdain for anything other than react, probably more people of Facebook generation and admiration of it's technology like open graph, react and few other products. Based on personal usage of React, it's no easier than angular or any JS based framework like Vue (which in my view more sensible than react). You add state management, templates, router and 1000's of npm packages to do anything…

> You add state management, templates, router and 1000's of npm packages to do anything simple...

You don't actually have to do that. React just turns your data into DOM elements, most of the time it's a simple transformation.

Otherwise, how you architect your application is up to you. You don't need to overcomplicate things by following the latest trends, you don't need a ton of dependencies to do simple things. You don't need templates at all.

Angular is complicated by default. It makes design decisions for you that you probably wouldn't have made, and then sometimes it reverts those decisions, making you clean up the mess. React code very rarely breaks.

> Ivy tree shaking compiler will give a fight to upcoming compiler framework like svelte and keep the size smaller and may be in some cases much smaller than react app bundles, will wait for the benchmarks and size comparisons.

Angular bundles are huge by default, it has a long way to go. Tree shaking already works with React, you just need to set your build up that way. Also, don't assume that a compiler will make your build smaller, it may well inline a lot of stuff and end up larger.

Re: Angular 9.0

#209

Post by mattlondon » Fri, Feb 07, 2020, 11:42 AM UTC

DonHopkins wrote: post #195

mattlondon wrote: post #174

Earlier quoted context omitted.

> Is there a standard way to define local variables in an Angular template so you don't have to repeat the same redundant expression again and again I usually define something in the component, and reference that. If you need to lazily evaluate it you can just reference a function in the component (e.g. "...{{ someFunction() }}...", and have the function do whatever lazy work and/or memoisation you need there. If you…

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 static JS code in the page doing stuff to the DOM, angular won't trigger ngOnChanges for that.

For your approach, that looks reasonable to me in the 5 lines we have to look at :-) ... so long as you are consistent with the SelectionService and make sure all the changes go through that, you should be fine and your component will get all the updates.

This sort of requirement for consistent management of things like this - i.e. the application state - is a weakness of Angular I think. It is easy to start simple and end up coding yourself into a corner with god services etc. I have used a thing called NgRx in the past for managing state - its the redux pattern and seems to be quite good at making sure state is a bit more sane and well-mananged in the app (at the cost of some boilerplate). One day I hope that there is an official state management mechanism.

Re: Angular 9.0

#210

Post by DonHopkins » Fri, Feb 07, 2020, 11:58 AM UTC

qwerty456127 wrote: post #187

mattlondon wrote: post #163

Earlier quoted context omitted.

I have not done much react apart from a "hello world", but I have been using Angular2+ for years, having previously used AngularJS. Here are a few thoughts: The learning curve is steep I agree. There does feel like there is a lot of ceremony and boilerplate required for even the more basic "hello world". Also if you are not familiar with RxJS before learning Angular then that is a second learning curve that you need…

> Also if you are not familiar with RxJS before learning Angular then that is a second learning curve that you need to know too and it is a challenge. You are not the only one mentioning this here. Do you believe it's wise to start with learning RxJS before you even approach Angular if you are a VanillaJS/JQuery "dinosaur" looking forward to learn Angular?

RxJS is very cool and well designed, and stands on its own. Worth learning about even if you don't use Angular, but definitely if you do! The basics are easy to understand, but there are a whole lot of deep profound operators that it will take a long time to master, although you don't need them all at first.

https://rxjs-dev.firebaseapp.com/api

Reading the guide and pondering the following table helped me understand how other mechanisms in JavaScript work together and relate to each other, and the corner that Observable occupies:

https://rxjs-dev.firebaseapp.com/guide/observable

>Observables are lazy Push collections of multiple values. They fill the missing spot in the following table:

            SINGLE      MULTIPLE
    Pull:   Function    Iterator
    Push:   Promise     Observable