Comment by intellix | Hacker News Reader

Comment by intellix | Hacker News Reader

Been using Angular.js and 2+ exclusively for almost a decade now. Keep reading how the compiler allows static type checking and superior tree-shaking at build time but I'm just not seeing any sort of fruition after years of promises.

Every ngconf there's talk of the magical 2kb hello-world and bundle improvements with every major, yet the only bundles getting reductions are the hello-worlds and monster projects.

It seems we're in the medium bundle category and it's just disappointing that every version our bundle size hasn't moved or increased slightly.

We're currently at 2mb main/vendor after spending A LOT of time optimising and making everything lazy and then a team of 1 at our sister company release a Next.JS/React app with a main bundle about 1.3mb than ours using zero effort.

There's never anything obvious when it comes to analysing the bundle and it seems we're using everything we need: Angular, Material, RxJS, ApolloClient. Most of our forms use Formly (huge savings from repeated HTML)

All of our competitors are running React and have bundles about 1mb smaller than ours.

Every year I install the VSC Language Service plugin and have to disable it the same day due to it continuously crashing and killing the editor so it seems we'll never get to benefit from that.

Then I see a continuous stream of core developers leaving the Angular project due to toxic behaviour from Igor and it feels hopeless and depressing.

The one saving grace is that the entire ecosystem is written in TypeScript and it's nice seeing everything typed to perfection.

Angular team member here :)

>our bundle size hasn't moved or increased slightly

Please make sure you are using the latest version of our compiler and runtime. Many developers observed significant improvements after the v9 release. Here's just one [example](https://news.ycombinator.com/item?id=22260864).

>Every ngconf there's talk of the magical 2kb hello-world

Currently, it's absolutely doable to get very small bundle size (<7-8KB) for a hello-world application. This, however, relies on private APIs. We haven't made them public yet, because not many folks are building hello world apps, but in the future we'll be exploring how to reduce the footprints of the framework even further for smaller apps.

>We're currently at 2mb main/vendor after spending A LOT of time optimising and making everything lazy

It is shocking for me that you're spending that much effort on optimizing your app, but you can't get your bundle below 2MB. I'm spending large chunk of my time looking into apps and thinking how to make them smaller & faster. I'll be more than happy to connect and brainstorm the same for your case. Please reach out to me on my hackernews username @google.com

>Every year I install the VSC Language Service plugin and have to disable it the same day due to it continuously crashing and killing the editor so it seems we'll never get to benefit from that.

Sorry to hear you had such an experience with the language service. If it keeps crashing, definitely report the problem here https://github.com/angular/angular/issues. We'll be very thankful if you share reproduction steps.

>Then I see a continuous stream of core developers leaving the Angular project due to toxic behaviour from Igor and it feels hopeless and depressing.

Folks leave and and others join. I can't comment on my co-workers experiences, but after 2 years working on Angular I haven't experienced any of the behavior you're referring to.

>The one saving grace is that the entire ecosystem is written in TypeScript and it's nice seeing everything typed to perfection.

Oh, I wish everything was that perfectly typed :). This is something the team and the community is constantly working on, but we still have a long way to go until we reach perfection.

For reference, a former maintainer wrote about toxicity in the Angular dev team.

https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-t...

Yes, I've worked with Jeff and I'm familiar with the post. In fact, Jeff was the one who first invited me to apply for a role at Google after our collaboration on the Angular mobile toolkit and it was great working with him :)

It's not easy to share such a personal story publicly. I'm sorry he had such experience and I'm not saying he does not have the right to be upset. He knows the best what he went through and how he feels.

I'm just saying that it's not correct to generalize and gave myself as an example for someone who can't relate to his experience.

Very positive response! It sounds like you don’t think there is any truth to what he is saying. That seems interesting given that he is not the only one saying it.

There's no way for me to know what happened without being part of the team back then. What I'm certain is that he had a bad experience which impacted him negatively and I'm sorry he had to go through this.

The only thing I'm saying is that it is not correct to generalize, giving myself as an example for someone who haven't experienced anything similar.

Yikes. Blink twice if you need someone to send help.

> It sounds like you don’t think there is any truth to what he is saying

I've no idea how you reached that conclusion given that the comment you're replying to says

>> I'm sorry he had such experience and I'm not saying he does not have the right to be upset. He knows the best what he went through and how he feels.

It’s very quite simple - Mgchev is careful to validate only Jeff’s feelings, and absolutely nothing else about what he says.

Indeed he goes on to make this clear: “The only thing I'm saying is that it is not correct to generalize”

This invalidates everything about Jeff’s piece except for his feelings, since the entire piece is an argument that there is a systematic problem with the team that other people have experienced too. There are tweets and quotes to support this.

Jeff does generalize, and he does reference other people who had similar experiences. Jeff’s entire reason for writing the piece is to generalize. He doesn’t say ‘I’m sure this is just me’. He argues quite the opposite.

If it is ‘not correct to generalize’ - as Mgechev says, then Jeff must be wrong about there being a problem with the team, therefore Mgechev does not believe Jeff.

You’ll notice that Mgechev repeats this ‘not correct to generalize’ here: https://news.ycombinator.com/item?id=25072705

Mgechev also says they “can't relate to his experience”. They also make no reference to (or validate) any of the other people who apparently had similar experiences or views of the team.

It’s pretty reasonable to conclude that Mgechev doesn’t think there is a problem with the team and wants to convey that to us.

"I did not have that experience" in no way implies "No one had that experience."

No, but repeatedly saying “it’s not correct to generalize”, does.

No, it really does not.

It does unless you take it out of context.

https://news.ycombinator.com/item?id=25073264

Not sure why you're linking me your own posts, which I have read. You're determined to assert things that nobody but you said, which I guess is fine, but I don't think this conversation is constructive or useful. I would suggest you take a hard look at your behavior, though. But that's up to you.

I linked to my post because it provides the context you ignored.

Here are the tactics you have used so far:

1. Narrow definition.

2. Ignoring context.

3. Gaslighting.

4. Personal attacks.

This is the other side of the coin from Mgchev‘s comment.

Best of luck moving forward.

Nice and positive!

Generalization literally means to apply the point to all involved. So no, it's quite appropriate for mgechev so reject generalization if the point doesn't apply to them. And that in no way a rejection of the facts presented. The same way that the generalization "apples are red" can be rejected by the presence of green apples without denying the existence of the red apples.

Outside of a mathematical context, you are not correct about the meaning of ‘generalization’:

https://www.merriam-webster.com/dictionary/generalize

It has nothing to do with ‘applying to all’

It means ‘to draw a general conclusion’.

Mgechev is telling us not to draw a conclusion from Jeff’s piece.

It is completely reasonable to assume that Mgechev doesn’t believe Jeff’s conclusions, and is asking us not to either.

> to draw a general conclusion

> Mgechev is telling us not to draw a conclusion from Jeff’s piece.

You're really going to pull out a dictionary on me, then blatantly ignore the emphasized word in your chosen definition that is exactly the word that makes my statement true?

https://www.merriam-webster.com/dictionary/general

> general: involving, relating to, or applicable to every member of a class, kind, or group

1. You are the one who brought ‘literal definitions’ into this. I brought the dictionary in because you definition is not a commonly used one.

2. Exactly one out of the 7 definitions on the page you list supports your position.

3. The top definition on the page you linked is consistent with the meaning I am using.

4. Saying the definition you have chosen is my chosen definition is a misrepresentation.

Therefore: You are the one selecting a narrow definition to suit your purposes.

Toxic and abusive people are not toxic and abusive with every single person. You might have not had the same experience, but pointing that out does not really help. The linked article cited many people who suffered the same, so it is an important thing for anyone who might want to be involved in Angular development to know.

The author brings his own toxicity by a) trying to milk his relationship with the angular team (he hated working with so much!) on twitter and b) making inappropriate and confusing jokes about an unpleasant topic (would he be allowed at that summit despite being a conaultant?). Igor and him just seem to be a really bad mix.

This could be true if it wasn't for many, many other former members of the Angular team confirming it's a problem. There's a very long list of core team members who quit.

This seems like a good example of productive discussion! While this won't necessarily solve the original poster's problems in of itself, it does give actionable steps on how to address them!

As for anyone interested in real world comparisons of many of the popular frameworks (though not necessarily the most bleeding edge versions), feel free to have a look here: https://github.com/gothinkster/realworld

The last time someone did a writeup on the results was in the March of 2020, but even then Angular wasn't necessarily that big in the bundle sizes that it generated: https://medium.com/dailyjs/a-realworld-comparison-of-front-e...

Though the situation can indeed worsen as you introduce more and more libraries into the mix and as the project grows.

FWIW, I recently left a project with quite a lot of Angular (2+) code (not massive project but good chunk of code for three developers), and mostly it was a real pleasure as most of the stuff was strictly typed. One extra reason that smoothed the experience was that our Spring Java/Kotlin endpoints have corresponding client typescript API (and data structures) generated automatically by custom tool http://github.com/evidentSolutions/apina i.e. Having defined endpoint controller with methods, you have automatically Angular service that has the same methods with the similar types. (One may need to define some custom datatype de/serialization but not much)

If I had to say two things that I would like to get improved: 1) better typing related to Reactive Forms and Angular Material (e.g. IIRC Material dynamic table definitions were declared in a way that it lost IDE navigation and static analysis) 2) Faster compiling times, but we got this to be good enough for hot-reloading which matters most.

RxJS Observables with Push ChangeDetection was heavily used.

Personally just thanks for your contribution to make web developing more enjoyable!

It seems that Material + CDK accounts for about 625kb of our bundle. Screenshot of source-map-explorer output: https://imgur.com/a/pGNlMZU

Our site is entirely data-driven via CMS and each of the Material components are available for use from there, which is why they're all in use.

We're using the latest of everything (v10 atm) as we're using Renovate so it's all correct etc

If you care about javascript bundle size you have to avoid everything that comes from google (besides angular core & common of course). Material, animations, cdk, ... everything is just horrendously over engineered and nothing optimized for size. E.g. just look a sourcecode for material checkbox! https://github.com/angular/components/blob/master/src/materi...

Don't get me wrong, I like those bundles - and I like my frameworks over engineered. They take care of edge cases. And if I'd write a CMS I'd be all over those packages. But if your constraint is bundle size, you have to avoid them.

Agree. My last experience with angular (and ionic in particular) is it's hard to archive both good DX and UX.

There are tools that produce smaller bundle size (e.g. stencil and react) but angular has much better DX.

Svelte maybe better but not used it in production yet.

I will just chime in to say that we love Angular on our team. We love the opinionated, batteries-included philosophy of angular, and it does keep getting better over time. We don't want to have to make the decisions that are required for React applications. For teams of 3+, I think Angular is the better choice most of the time. It is easy for us to make well maintained, fast applications across platforms. I think you've made reasonable choices over time. Thanks for your work.

our main bundle is at 2mb as well. unless you have a cdn lazy loading is a pain. react is so much smaller.

>Every year I install the VSC Language Service plugin and have to disable it the same day due to it continuously crashing and killing the editor so it seems we'll never get to benefit from that.

I've heard my partner swear at least a couple of times a week over this since we've started working from home due to corona.

> Currently, it's absolutely doable to get very small bundle size (<7-8KB) for a hello-world application. This, however, relies on private APIs. We haven't made them public yet, because not many folks are building hello world apps, but in the future we'll be exploring how to reduce the footprints of the framework even further for smaller apps.

This answer doesn't quite cut it. Every project starts out as an "hello world" type application. How do you audit the cost of each additional package if you didn't even start out with a "small bundle size" from the beginning?

I believe you guys have made great strides and I appreciate your efforts immensely. I wish you the best of luck, I hope you're able to actually address the large size of deployment in a meaningful fashion.

This has largely been my experience too.

I was development lead for an angular shop. We did all the government Ministry of Health forms in Angular, millions of residents would use our forms every year. Our frontend team I lead fluctuated from 5-8 people over the years. We had to work on basically every device, making sure it'd work on IE11 and for blind users running screen readers is something we'd do every single release. I say this not to brag, but just to say I lived and breathed angular for years, I was hired as the "angular guy", and I even wrote an npm-publiished library of re-usable components specifically to match Ministry of Health forms.

My opinion of the Angular team and their stewardship of the project had ranged from mildly impressed, to disappointed, to alarmed. They frequently missed their own targets, the big one being Ivy, their compiler, which got pushed back 2 full releases and was constantly plagued by issues. (I left that job right as Ivy was released. Is anyone using it? Has it been a success?)

Like you, I saw the Angular team constantly speaking to compiler optimizations, but never once saw those benefits manifest. To be honest, it just felt like they were using the typescript compiler (tsc). I never saw any performance benefits over tsc. In fact, now using React/tsc/webpack, I feel like the compiler is more configurable and powerful.

In around 3 years of Angular updates the only feature we really used was the improved lazy loading of modules. I also used a bit of their codegen stuff ("Schematics"), which was promising but incomplete. Even though they were in release notes at the time, they lacked documentation and seemed like the team was bragging about features that weren't ready for light of day[0]. In the same timespan (~2016-Jan 2020), React got: server side rendering, pure components, hooks, profiling tools, improved lazy loading, and many _measurable performance increases that benefited projects across the board_[1].

Also, the Angular team began to increasingly focus on Material integration. We were a Bootstrap shop (ministry, at the time, required bootstrap styling). It was disappointing to see all those updates and know we couldn't use them.

I will say that generally speaking Angular's opinionated, more enterprise-y approach to frontend absolutely has a place. For certain workplaces, like my former big corp one, having an opinionated enterprise-y language made onboarding easier and devs more consistent. The most disruptive devs we had were hotshot react devs who wanted to make our Angular code base look like their flavour of React. I use React now, and love it, but there are pros and cons to having an opinionated framework/library (not having that fight).

And worst of all, the team itself seems to be imploding and toxic as you've alluded to.

I left that job for other reasons, but I'm glad I'm working with React and Vue more heavily now.

[0] https://medium.com/@lifenshades/difference-among-angular-8-7...

[1] https://en.wikipedia.org/wiki/React_(web_framework)#History

edit: The other great part about the Angular community is it's TS first. I miss that about React/Vue.

I was really hopeful for Ivy due to the bundle size improvements and was kind of expecting a silver bullet and saw around a 2% improvement. From their blog post:

- Small: 30% - Medium: 2% - Large: 25-40%

Our initial Angular 1 bundle was around 1mb. After updating to Angular 2+ it was around 2mb and after leaving the company in the hands of developers who were fairly junior I can see that their main bundle has now grown to 2.8mb. Another project with various junior devs has 2.9mb.

This is what is frustrating when I see our sister company pull out a 1mb react app with little effort... No matter how much effort I put in, it's never going to be achievable. Our package.json is extremely conservative as well.

https://blog.angular.io/version-9-of-angular-now-available-p...

Our app went from 3.5 MB to 2.3 MB when we switched to Ivy. Our app is ~73k lines of code (not sure what "size" that makes it) and uses Angular Material heavily. It's a corp app though, not too concerned about bundle performance (yet).

As an outside observer, to me Angular seems to be an unending chain of quests solving issues introduced by a previous quest: https://news.ycombinator.com/item?id=20040877

yep, it looks to be the case. Actually I was fully on board with the whole static typing and compiler stuff until I opened up a React project and saw all of the benefits being touted are already there. All variables in the view are already referenced from TS/JS so you don't need any additional tooling. I suppose when TS started supporting JSX/TSX it was no longer a problem

> My opinion of the Angular team and their stewardship of the project had ranged from mildly impressed, to disappointed, to alarmed.

If you look at projects that try to be all-encompassing (e.g., like MeteorJS or Angular), you'll see a similar story line. To achieve everything they set out to do, the stars must align: ample staffing of the team, good architecture/design decisions that need not be reverted later, etc.

Having gone through this with multiple technologies, I am now skeptical of projects that over-promise or are too widely scoped.

Came here to say that Formly is fantastic! It's pretty much the only thing left i like about Angular. Any future projects will be written in Svelte if my team has anything to do with it, though.

To join in the gripe session because Angular has been hurting me for months: I'm in a consulting firm and generally we have a lot flexibility on project stacks. I've been really happy with React on the projects I've done with it. I've recommended React on every following project. Lately I've been getting a lot of pushback from some clients that it "has to be" Angular because "they know it", and got a lot more pushback from colleagues that they wanted it to be Angular because "they know it". Find out a few months later that everyone "knows it" only in the Stockholm Syndrome bare minimum "checkbox on a resume" fashion and suddenly I've become the expert on Angular in the company because I have problems to solve and know one else that supposedly "knows Angular" actually knows how to solve them. The more I become an expert on Angular the more I hate Angular and would rather be back in React. (But of course it is too late to switch stacks now, given project deadlines, etc.)

> There's never anything obvious when it comes to analysing the bundle and it seems we're using everything we need: Angular, Material, RxJS

Yeah, that's exactly the major sources of bloat in Angular. Angular's runtime and core components are extremely fat despite how much they keep claiming is compile-time optimized. I'm terrified to look at the source for HttpClient because I cannot imagine how it possibly is big enough to explain its huge {minimized, gzipped} bundle size. That's just one Angular component in the vendor chunk that "has to be there".

Angular Material is another huge source of bloat and a lot of what I've been doing is removing it as much as possible. It seems like everyone throws in Angular Material feeling like it is a "best practice", but "no one" seems to like its styling or behaviors out of the box, put a ton of work into redoing its styling/behaviors in a complicated and bespoke way in nearly every usage and end up burying the already extremely bloated Angular Material components under whole new onion layers of their own bloat. Every time I dig into one of these bloat onions I seem to find it easier to write a fresh component from scratch and get rid of the Material dependency altogether.

RxJS is also huge, and it's a grand source of continuing disappointment with Angular how wishy-washy it has been with respect to Observables. If you are going to require a giant library like that, at least commit to it. Of course if Angular actually committed to Observables that might lead to using a lighter library instead of bundling the kitchen sink that is RxJS. (For several years I worked in an Observable focused React-like called CycleJS and one of the big moves CycleJS did primarily for bundle size reasons was switch to an "RxJS-lite" library named xstream.)

As someone that actually understands (and heavily uses Observables) it just absolutely floors me at how bad Angular is with them, almost like it is designed to encourage the worst practices for RxJS/Observable code. I see so many components manually (and badly) subscribing and unsubscribing from Observables that should never need to, sometimes simply because the authors weren't aware of the "| async" Async Pipe. (And why should they be, pipe documentation is almost hidden and yet another twisted part of Angular's template syntax with no relation to Typescript syntax despite appearing in places designed to look like Typescript?) Async Pipe is mentioned like a footnote in the Observable documentation that nearly everyone skips past. It should have been the default (or better yet the only way) in the template language: you have Observables, change detection, even "AOT compiled" change detection shouldn't be necessary! Observables should easily replace change detection. Zone.js is nearly entirely bloated redundant nonsense that shouldn't ever exist side-by-side RxJS, and would never be necessary if everything were Observables. It's almost a painful joke at this point how badly Angular makes use of Observables, how it works twice as hard to do half as well if it merely committed to Observables and only Observables instead of this half-Observable slash old school template change detection beast that it is today. Pick one and commit to it and so much bloat in Angular would just go away.

My gripe with RxJS is how difficult it is. I've put thousands of hours into learning it and I just know the rest of the team don't understand the long chains I've written with it.

I have the same problem where people are doing backflips to do simple things and I'll come in afterwards like... What ARE you trying to do here? And why are you not cleaning these up?

Originally I was trying to stay away from behaviour subjects as recommended by the RxJS purists but now I just want to use them everywhere so its easier for everyone else to get values out of a stream

Sure, and that's pretty much exactly why Angular seems to refuse to commit. The EventEmitter in Angular's core is a really odd BehaviorSubject duck, and it shows. That says everything about their commitment to RxJS purity, and that behavior "from the top" leads to how much Angular pushes everyone to want to abuse BehaviorSubject, to do a lot of bad RxJS and never learn to do it right, because it's that rotten to the core. That impression that RxJS is too difficult for mortals becomes the self-fulfilling prophecy that Angular is right not to do RxJS right or commit to it, because it makes doing RxJS right in Angular harder.

Half the component examples I see in the wild use RxJS wrong or badly, and of course that stuff gets copied and pasted everywhere.

I've already sent patches to at least a few documentation examples that are supposed to be "best practice" that failed to actually live up to best practices because Angular failed them in setting a good example to live by.

Angular has created the worst of both worlds that makes RxJS harder than it should be by failing to use it properly (providing too many bad habit escape hatches and failing to commit to it), but also making it almost impossible to avoid and subsequently polluting the entire ecosystem with bad examples, worse documentation, and terrible habits (all of which goes right back up to the top and terrible design decisions such as Angular core's EventEmitter).

If Angular committed to being an AOT change detection only system it would probably be much more like Svelte. If Angular committed fully to RxJS it would be something different entirely [0] and maybe sure it would be harder for a lot of devs to grasp at first, but instead of the pit of failure that currently awaits devs trying to learn RxJS in place in Angular, maybe they'd have a pit of success that a lot more devs would learn RxJS given a safe place to do it with fewer papercuts and bad examples to learn from.

[0] It probably wouldn't be CycleJS either, as they'd still probably avoid Virtual DOM techniques. This thread has me picturing what you could do with a compile-time template Observable pipeline and I'm almost curious enough now to build a prototype of it just to show Angular how dumb it is and what it could be.

I really can't stop thinking about an Observable-only AOT compiled template language-based framework. You could achieve a compile-time version of React's Suspense framework incredibly cheaply (from a user developer standpoint) entirely in the way you compile-time compose, schedule, and subscribe Observables in a template and its child templates. So much of the work that React's Suspense has to do at runtime, such as scheduling things to arrive at requestAnimationFrame() time, debouncing/throttling updates, coordinating (composing) related updates in child components, all have simple RxJS operator equivalents, and you could declare all of that simply in templates leaving the compiler to do the final RxJS operator compositions and most users of the templates to not have any idea how complicated some of those final compiled compositions may be, but directly gaining the benefits of them (such as cleanly debounced AOT-compiled DOM updates at requestAnimationFrame time; complexly coordinated multi-component update patterns). It's an amazing sounding framework in my head. Very worried I at least need to build a prototype of it now or it will continue to haunt my dreams.

How much of a differentiator is the bundle size for your customers? Do they notice this 1mb?

Google's own lighthouse suite runs everything through network/cpu throttling for scoring so to download a bundle that started at 2mb and parse it really penalizes you compared to a 1mb bundle (even after gzip and you're getting screwed on parse performance of lower devices).

Then you have the way universal replaces all content when it bootstraps and you get penalised for that. We're also seeing issues where the site isn't ready yet and clicking a link just opens a new tab cause the JS wasn't downloaded/parsed yet.

You can use the preload library but guess what: doesn't work. As usual it was always: this'll get fixed with ivy and it wasn't. It seems all libraries we depend on were initially made by staff who were driven out of the team. - universal - animations - forms

Our clients use the Google performance scores and ask why none of the performance improvements we're doing has had any effect and then point to a React competitor's lighthouse score

What sort of toxic behavior?

There's this from Jeff and then countless "metoo" tweets about it: https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-t...

How do you like breaking the web one page at a time with angular?

Reply on news.ycombinator.com