Live data from Hacker News

Angular 9.0

blog.angular.io

171–180 of 308 posts

Re: Angular 9.0

#171

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 joined a company that had two fairly simple internal web apps, one in Angular and the other one in React. Both had been written and maintained by a number of devs, each on the task for a few weeks or months. Both had several issues and blunders that needed to be fixed. However, while the Angular app had a very obvious, predictable structure, with issues confined inside single components or services, the react app was a totally obscure jam of javascript and html with more javascript and more html interspersed within, tons of redux boilerplate and properties passed down three or four levels of nested components. The stuff was such a wild spaghetti mess that editing a form in a foreground modal made the text in a background static page jump around when the number of characters in the form was even.

So no, I didn't enjoy the ride, at all.

Re: Angular 9.0

#172
Just want to say that all the Angular React comparisons are dumb. It is comparing apples to oranges. Angular is a bigger framework for developing more complex stuff. Therefore of course there is a steeper learning curve. Here are comments like "react is so much more easier because it is just functions". Why not just using vanilla js because you have nothing to learn then? Or just use binary code? It is just 0 and 1.

Re: Angular 9.0

#173

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 ?

I find it deeply ironic that, judging by the stories regularly posted and upvoted, Hacker News readers supposedly value science, rationalism, evidence-based thinking, etc. Yet the same people reliably upvote these kinds of toxic, detail-free, ungrammatical, emotional rants.

By all means, upvote criticism that is properly argued and backed up with evidence. But upvoting these kinds of comments is the equivalent of posting anti-vaccination memes on Facebook.

Re: Angular 9.0

#174

I've been going down the long road of learning Angular recently, and I love it and want to learn more, but I have a couple naive newbie questions whose answers I thought should be obvious, but I haven't been able to figure out: 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 (or so you can at least give an expression a…

> 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 need things to be initialised before the template is ready, you can use one of the life cycle hooks - e.g. ngOnInit(). More details of the different hooks here: https://angular.io/guide/cheatsheet

... that said, it might be easier (depending on context) to "learn to love the bomb" and just rely on Angular's binding to update the template as soon as the value becomes ready after the template has rendered - i.e. don't sweat about getting everything ready before the template loads, just let Angular handle the data binding and let it update the tempalte when the value is ready. This is where the RxJS stuff really shines since you can forget about a lot of the sequencing and just let Angular handle getting the right value on the page when it becomes available. Unless you are doing long network calls or heavy computation, everything is usually in place by the time your brain registers seeing the page anyway so it mostly works out OK and no one notices any thrashing of templates going on under the covers (... although there is a part inside of me that dies when thinking about the performance/wasted CPU cycles).

> is there a way to easily define simple light weight macros ("snippet reuse") so you can repeat the same pattern in one or more components

I have also suffered this recently. I am not sure how this is "meant" to be done, apart from making everything a separate component. I guess the argument is, if you need to use something in multiple places then it is an ideal candidate to become a component. For these "lightweight" components I will usually just use inline templates for the component decorator (rather than referencing a separate HTML template etc), e.g.

  @Component({selector: 'snippet-one', template:`My First Snippet`}) export class SnippetOne{}
You can put a load of them into a single "snippets" module, import the "snippets" module when you need it, and then simply include that where I need it in other templates with and so on.

I agree though that sometimes it would be nice to just have a file you can just easily drop in where you need it.

Re: Angular 9.0

#175

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!

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 simple and react soon becomes an unmaintainable nightmare with emany vulnerabilities if you do not upgrade. An app is not just simple react but many of the npm packages (although it's true in general for JavaScript eco-system which is by default is insecure and maintenance nightmare unless there is an extra amount of work done to secure it).

Angular at least provide a decent complete single framework to work with and a unified documentation, there are issues with it, but react is same when you need any reasonable size app from it.

React gives you an easy start with false sense that it's easy, than becomes just too convoluted and complicated with the addition of different components as soon as app starts growing. Maintaining and upgrading apps based on react is very difficult as one version to another it introduces breaking changes. Angular had similar thing from angularjs to angular 2, but slowly they made it much better but letting compiler do more work.

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.

I am still waiting for a simpler way of developing web apps, elm looked very nice, but it is still far from ready for use in the same way as Angular or react yet.

Re: Angular 9.0

#177

Earlier quoted context omitted.

Angular really shines in Enterprise context. 13+ teams and all use the same stack. Enter React and you are in maintenance hell, is my experience.

If you have enough governance in an enterprise org to standardize on Angular, you should also have enough to standardize on a particular React stack, and not just "React".

Yes, same goes for Vue etc. You can hardly govern the freedom React provides. If you do, you can use Angular in the first place, because it has solutions out of the box. This is not to discredit React or Vue.

I am judging from my experience developing applications with 200+ developers across continents. You can write crappy code in Angular as well, but it helps you govern your architecture and your app. If you want modular components that can be reused, go for Angular. For smaller things or landing pages use Vue, React.

My experience.

Re: Angular 9.0

#178

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 ?

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 years and tell them "it's time to make the stack modern" and "we're going with Angular because we're a Microsoft house".

Things go very bad very quickly.

If you don't take the time to understand the Architecture behind scalable modern web applications you're going to have a bad time.

Anyone can slap together a quick and dirty app with Angular or React - not everyone can scale one correctly with thought given to the architecture behind these applications.

Re: Angular 9.0

#179
post #171

Earlier quoted context omitted.

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

I joined a company that had two fairly simple internal web apps, one in Angular and the other one in React. Both had been written and maintained by a number of devs, each on the task for a few weeks or months. Both had several issues and blunders that needed to be fixed. However, while the Angular app had a very obvious, predictable structure, with issues confined inside single components or services, the react app w…

Anecdotal evidence. This is just the result of bad practices. React is less opinionated than Angular I'll give you that, so I guess that subpar angular might be preferable to subpar react.

Well-managed react is incomparable in power. Try to make a library like react-three-fiber using Angular, in less than 500lines of code.

Re: Angular 9.0

#180

I've been going down the long road of learning Angular recently, and I love it and want to learn more, but I have a couple naive newbie questions whose answers I thought should be obvious, but I haven't been able to figure out: 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 (or so you can at least give an expression a…

Here is the one big important thing that Zope Page Templates (and Kid and Genshi) got right: don't violate standards and be incompatible with standard tools, for no good reason:

https://en.wikipedia.org/wiki/Zope#Zope_Page_Templates

>Zope Page Templates

>As mentioned previously, Zope Page Templates are themselves XHTML documents, which means they can be viewed and edited using normal HTML editors or XHTML compliant tools (a big advantage compared to other template languages used for Web applications). Templates can also be checked for XHTML compliance so you can be fairly confident that they will automatically expand into proper XHTML.

Post reply on HN