I hear most Angular projects being stuck at around version 15 due not being able to migrate away from Angular Material "Legacy".
Google: Angular and Wiz Are Merging
31–40 of 179 posts
Re: Google: Angular and Wiz Are Merging
#32Can anyone recommend a good resource discussing the interplay between highly optimized js bundles and code caching? i.e. it seems to be me that one would benefit by serving the same js blob on most / all pages even if it includes unused code because then you pretty much always utilize the code cache.
Maybe I’m misunderstanding your question but why would you want a single bundle vs multiple bundles? If you have a single blob you have to invalidate the whole thing when it updates. If you split your code out into multiple bundles you can invalidate only the bundles which contain changes. As far as I know this has been standard practice for the last decade at least.
I think it’s a good question, and the answer isn’t quite as straightforward as you suggest.
The advantage of bundling is that you can do cross-module minification and dead-strip unused code.
The extreme version of “multiple bundles” would be to minify each JS module individually, but don’t bundle them. That would clearly miss a lot of size optimisations. (And as I understand it, this is how Deno’s new package manager is meant to work, which makes me a bit suspicious.)
The opposite extreme of one bundle for the entire app is great for optimisation, but as you say, then you have to invalidate the whole thing if anything changes.
One bundle per route is tempting but then common code gets duplicated.
Vite’s default behavior (via Rollup) is to make one bundle per common module. That works pretty well but I’ve found the number of output bundles can explode in surprising ways. In a recent project I manually split the code into chunks and loaded them via dynamic import() and that worked pretty well -- good balance of size optimisation, caching and manual control.
Re: Google: Angular and Wiz Are Merging
#33I hate Angular with a passion. It's easily the most verbose, overly complex front end framework I've ever used which just takes the fun out of building web apps and make it a pure pain. I would rather work on a farm and shovel pig shit all day than work in Angular again. My last job forced Angular on me, I quit after a while (not because of solely that reason) but I told them Angular was a bad choice and they chose t…
I've been working with large Angular projects for years and I really enjoy the development experience. Especially now with the new template syntax, signals, and other recent changes.
Agreed. I think the earlier days of Angular put a bad taste in many people's mouths. Many people who complain about Angular being verbose seem to only have experience working on smaller apps.
Re: Google: Angular and Wiz Are Merging
#34Can anyone recommend a good resource discussing the interplay between highly optimized js bundles and code caching? i.e. it seems to be me that one would benefit by serving the same js blob on most / all pages even if it includes unused code because then you pretty much always utilize the code cache.
Maybe I’m misunderstanding your question but why would you want a single bundle vs multiple bundles? If you have a single blob you have to invalidate the whole thing when it updates. If you split your code out into multiple bundles you can invalidate only the bundles which contain changes. As far as I know this has been standard practice for the last decade at least.
We have a single bundle of JavaScript with all our helper functions, then a page specific bundle that uses some of the helper functions. The same helper function bundle is delivered to all pages--not a different tree-shaken version delivered to each page that only has the functions used by that page. One helper function bundle is bigger, but since every page gets it, this bundle is code cached.
Re: Google: Angular and Wiz Are Merging
#35Can anyone recommend a good resource discussing the interplay between highly optimized js bundles and code caching? i.e. it seems to be me that one would benefit by serving the same js blob on most / all pages even if it includes unused code because then you pretty much always utilize the code cache.
Bundling everything together and letting it be cached is how most single-page apps do it, yes. If the code isn't used by anything at all, it gets removed from the bundle entirely: that process is called "tree shaking". Modern frameworks like Nuxt also tend to do something called "code splitting": for example, I have a Nuxt app that contains, among others, pages like /vehicles, /drivers, and /fuel. Instead of creating a single giant js bundle, Nuxt creates several, including a file for code that's used by just the /vehicles page, a separate chunk for code that's only for the /drivers page, and so on, along with common chunks that are used by all of them. Script tags are then generated for each of these three pages so that when you hit one of the pages, you only get enough of the code for that page, and the rest is loaded when you navigate to another page. It's still a single-page app, but with multiple entry points, each one optimized to initially load only what that entry point needs, the rest being dynamically imported when needed. Each bundle's filename contains a hash of its content, so they can be cached forever (that does have consequences when upgrading though: a typical SPA has to do some some version checking and self-updating on its own, as the browser will otherwise be eager to serve stale code)
In dev though, one usually doesn't even bundle, and runs the app on a dev server that dynamically compiles and serves individual modules. When I initially load the app off the dev server, my browser makes close to a thousand requests for all those modules, but pipelining and caching make it all quite zippy regardless. Bundling is still faster and uses less bandwidth though, so for production one typically does still build a bundle (or several code-split ones).
There's gory details at https://webpack.js.org/guides/code-splitting/ (for webpack; other bundlers like Rollup work similarly) but frameworks like Next/Nuxt do it automatically as part of the build process.
Re: Google: Angular and Wiz Are Merging
#36Earlier quoted context omitted.
i'm with you, i used to use nitter with the firefox extension, but it seems to be dying, is there any alternative?
There is https://twstalker.com/ but the site is very very dodgy.
thanks, maybe that will become something later, but i am looking for an browser extension that doing the work for me
Re: Google: Angular and Wiz Are Merging
#37Exciting? Possibly for those involved. I hate to say this, as I'm generally optimistic towards most developments like this, but over the last decade I've become so apathetic towards anything and everything from Google. They've lost so much mindshare and credibility. Their org structure leads to stagnation left, right and centre. I'd rather tolerate the poor status quo in React land than take any sort of bet on Google…
Golang is one of the Google products that I consider revolutionary in programming.
But then again, it may just be because they employed the rockstars (Rob Pike, Ken Thomson, and Robert Griesemer) to work on it.
I suppose it's less about the company, and more about who the company chooses to work on the project.
Re: Google: Angular and Wiz Are Merging
#38I hate Angular with a passion. It's easily the most verbose, overly complex front end framework I've ever used which just takes the fun out of building web apps and make it a pure pain. I would rather work on a farm and shovel pig shit all day than work in Angular again. My last job forced Angular on me, I quit after a while (not because of solely that reason) but I told them Angular was a bad choice and they chose t…
I seldom see this opinion but I'm glad to read it. People complain about JSX on the React side but what on Earth am I reading when I see the templating language that Angular came up with? ngIf, ngBlah. Much worse than JSX, which is subordinate to JavaScript code, not equal. I also have been forced to use Angular at the workplace and it killed any fun making web apps had. People say Angular is great for enterprise bec…
I didn't care so much about the syntax but rather the over reliance on the subscriber pattern that you have to have like a subscriber to even read something as fundamental as query params. And the funny thing is that is will fire once and then again when the query params is actually set. So you will have an empty fire for when they are not yet set for some strange reason, presumably from when the observer is created.
The problem with Angular, especially as the app grows is that you will have many different subscribers that all listen on the same state changes, then fire them again so you will have code that just runs again and again and it's extremely hard to have a mental model on how the system work and what code runs when.
The code also easily gets super slow because you run something, it affect state, then it triggers something else that triggers something else that just happen to affect the first state, whoops now you have a loop. Even if the loop resolves, it's pretty much inevitable to get a loop sometimes if the app is complex enough, at least in my experience working with several other devs.
Re: Google: Angular and Wiz Are Merging
#39I hear most Angular projects being stuck at around version 15 due not being able to migrate away from Angular Material "Legacy".
This seems to be true for many and happened to me. It is an absolute nightmare trying to upgrade Material. Now I’ve convinced my team to move to a different framework.
Re: Google: Angular and Wiz Are Merging
#40Ugh, this isn’t Angular anymore. This will be just like the v1 -> v2 transition. Presignal -> signal. The second they start deprecating the previous syntax, we will hit very difficult migrations