Google: Angular and Wiz Are Merging
twitter.com
twitter.com
At least they'll be dogfooding Angular now hopefully.
It’s a lot of magic and all convoluted, it’s pathetic a company this large has this as their main offering, JSX is a positive move but it’s still lipstick on a pig as it’s not really JSX but just three Java templates under the hood for now. Signals aren’t the panacea they keep saying as they simply don’t scale in big apps since the data flow is all over the place.
Googlers use Angular at google because despite its garbage size and developer experience, believe it or not, the dev experience is miles better than Wiz. It’s also nowhere near the most popular internal usage framework idk why they say that. It’s Wiz by far.
And all this is because googlers just want React or Vue but are not allowed because they are “not sanctioned”. The same reason why you can’t SSR Angular at google, because Node isn’t even sanctioned. This is all just a Hail Mary by Angular because their NPM numbers are dropping and just got surpassed by Preact of all frameworks.
My job skills are languishing at google because I’m writing Wiz and Angular all day
Do people actually spend months prepping for Leetcode interviews to get the job? To improve tech skills? Or is it just the money? ;)
Wiz has historically favored performance over ergonomics in the extreme. None of it is open source, and to be honest even if it was it's unlikely most people would want to use the mix of Java+Soy+JS+jQuery-ish API.
Interestingly both frameworks are around the same age (if you count Angular 1.0), but Wiz was kept internal.
What Sarah is referring to is both a big shift in Wiz to get modern ergonomics and a shift in the framework strategy to avoid having two entirely separate frameworks.
This unsubstantiated claim is being paraded around by Googlers all over Twitter. And there's literaly nothing to back up this claim. Have you seen the extreme performance of the websites it apparently powers?
Here's Youtube's extreme performance: https://twitter.com/dmitriid/status/1770911027766370648
The Angular team has been doing incredible work lately.
The only thing that I still don’t like about Angular is trying to learn anything from the reference docs.
Have a reasonable developer tell me what a component viewProvider is and how it’s different from a provider using the @Component docs. It’s impossible. https://angular.io/api/core/Component#viewProviders
Whatever committee decided to silo the Angular reference docs from the usage docs has caused more harm than most of the hyperbolic non-examples I can come up with.
If you’re writing docs, please, please do me a favor and study the structure of the Django and Python docs.
Like this?
- https://angular.io/guide/hierarchical-dependency-injection#u...
- (new docs site) https://angular.dev/guide/di/hierarchical-dependency-injecti...
I linked to the reference docs, you linked to the usage docs. They're completely divorced from each other. There's not even a link from reference to usage docs.
For the reference docs to be useful you already have to know what the thing is, what it does, why you'd need it.
You can be on the component page where `viewProviders` is documented and get nothing from it if you're coming in fresh.
Why would ever design docs like that?
Angular is the only framework I've ever struggled to learn. It's a complicated framework but that's not the problem. The docs are the problem.
Oh, they don't. Some of their teams know how to write docs for some of the products. A lot of the time it's autogenerated reference with a couple of bare-bones examples
You can leave all the FlowerService related code in place as it will allow a comparison with the AnimalService.
Short story, they put Angular signals into Wiz, which powers YouTube among others. No concrete Wiz announcements besides that. If you follow the Angular changelogs and plans, the video basically recaps these in a less dry manner - the same as seen during previous ng-confs. There's a short section at the end [0] showcasing a preview of what's in the pipeline but didn't receive much coverage yet, such as less boilerplate when authoring components.
Also there's an Angular discord and they're very hostile towards anyone not fanboi-ing Angular. I was about 6 months into Vue and wrote how I prefer it, for its simplicity. Then I was constantly harassed until I was kick/banned. With another account I saw, "HEIL ANGULAR o/" written in the chat.
That's just stupid. You have to be open minded. Angular has good things, but Vue has good things too and even React does.
Never heard of Wiz before.
Almost a year ago I created an Android developer account I believe it's called and paid the bill. The name on the invoice was wrong. I wanted them to update the invoice They responded with, "This is America, we do what we like" more or less. Ok, no problem, I have better things to do. Since I haven't published anything in almost 1 year, they're now threatening to close the account, I paid the $25 for.
My adsense account, no new sites are being approved anymore, previously I could add any site without confirmation, even if it was new. I had a site that made them and me over 150k, but I got into a fight with my partner of that site and the main domain was shut down. I took the content and published it on another domain. Over 7 years of daily mp3 files and images. The 1st domain had adsense approval, the new one didn't. They didn't approve the 2nd domain. Talking to them is not possible.
Google is spiraling downward. They're essentially cutting into their own flesh. Since Darth Sundar took over it's become progressively worse. All the wrong and used hostile decisions.
I still use and like Go, but I'm afraid what will become of it in the future.
It's unlikely I'll return to Angular. It's just too time inefficient and also slower compared to the other frameworks.
We're working on making RxJS optional. In v17.3 `@angular/core` no longer has a dependency on RxJS. In the long-term we'll enable a path forward without RxJS for other core modules as well.
That said, we're providing an interop package that enables even better RxJS support for people who make the decision to use it.
But on RxJS, yes, it is conceptually complex. I never quite understood whether one should use
- a container component with value-type @Inputs passed down - a service emitting an Observable and subscribing to that, then passing value-types into the template - an Observable as @Input - now Signals? (haven't used those yet.)
Years later though I read a book on functional programming and the whole nightmare of arrays within Observables suddenly made sense.
The tldr; is that we see a lot of similar requirements from developers across Angular and Wiz, so we're looking for opportunities to reuse work. Good example is the Angular Signals library that's now used in all the YouTube Mobile Web. In a similar way, Angular is bringing more fine-grained code loading that Wiz offers.
Over time, we'll continue focusing on what's best for developers and incorporating the best from Wiz in Angular, and vice versa. At the end we can end up with one framework, or continue to coexist.
In the next couple of weeks we'll follow up with a blog post that explains our plan in more details.
We took some different trade-offs and listed the details here https://github.com/angular/angular/discussions/49683
Was basic HTML gmail deprecated because users so overwhelmingly preferred slow, bloated UIs that there was no demand for an alternative?
I’ll be happy to answer questions about Angular and our collaboration with Wiz :)
It sounds no different from Svelte borrowing concepts from SolidJS, or Vue borrowing ideas from Svelte, from you said — if it is just adding some features that Wiz has, it doesn't sound like merging? Why put a shocking title that Angular is merging with Wiz, when Wiz has no name recognition in the outer dev community — like we don't know what that means?
As an Angular developer you could expect new features and developer experience improvements. Also over time you’d see more of Angular used in popular consumer Google products.
Even though it's claimed that it powers many of Google's websites, most of those websites are very far from being paragons of performance.
Other sites like Photos are fast and performant, but I wonder if it's due to whatever perceived advantages of Wiz or due to the team actually caring: https://medium.com/google-design/google-photos-45b714dfbed1
Edit: replaced incorrect link with a correct one
Wiz is designed to make it harder to get bad metrics if performance is not your top goal.
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 to overrule me. Pretty funny now, they will have to endure the pain of migrating a large app which makes me feel good.
Make stupid choices, win stupid prizes.
It never seemed suitable for mostly-frontend devs, but it's probably perfect for mostly-backend ones.
Similar conversation 10 months ago:
The new templating syntax is simply @if () @else () ... it makes it much clearer to read in many cases.
I never had a problem with *ngIf as long as you are controlling the visibility of one element. It became messy when you needed "else" statements in there.
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.
If you have different subscribers, all on the same state change, you may not have chosen to use ShareReplay, or filter, or bothered to use a tool like ngrx that has memoized selectors.
The same problem you're complaining about is the same thing people in the react community are complaining about because they never bothered to understand useEffect, and now have massive cascading updates.
There is a very good reason they chose to make everything a subscriber, and it helps avoid pitfalls, because it doesn't hide away the async nature of everything. Signals are just a simpler way to understand and use that same async nature.
I really tried to learn RxJS, I used a lot of different methods like filter and what not but I still got into a huge amount of issues but honestly a lot of that was because angular was not really fit for the type of application we were trying to build. Especially as we relied heavily on query params for state. There were many strange behaviors of Angular Router that I ran into several times. It has some kind of own internal state and fires updates in an unexpected way. I remember sitting hours just to try to get the query params to update correctly and I was not the only one having these kinds of issues.
Even if I agree useEffect is unnecessary complex, it's still far far away from being as complex as RxJS and Angular. I remember I was trying to add some pipe service or whatever it was called and it was near to impossible to achieve what I wanted to do which would be trivial in any other framework/vanilla JS (unfortunately I don't remember what it was).
Then using third party stuff in Angular is a nightmare as well. You have to deep dive into how it's being built to make sure all the stuff is brought into the build step etc. The configuration is a nightmare if you want to do something special like making use of Angular Elements that's barely documented at all.
I never got to use the Signals feature, because I left the company before it got introduced into Angular.
Honestly the real shame is that IDEs don't present a more integrated UI for separate files, and that on the other hand in my Vue apps I still have to argue over the order of script/template/style sections. I guess Angular at least avoids that second problem.
Especially now with the new template syntax, signals, and other recent changes.
I personally find Angular to be fine - sure there is a learning curve but that is true of anything (it's not like you can just pickup modern react and make anything functional without having to know how react works and spend ages picking libraries and installing and learning how to use npm, spending 6 months in a sanatorium getting therapy after realising you have to use npm for react and accept the shit show dumpster fire you are letting yourself in for by relying on npm, and deciding if you should use hooks or not and what about JS vs TS etc etc ). I find JSX in React an uncomfortable compromise that throws out a bunch of hard-learnt best practice in computer science (mixing up and confusing presentation with business logic in the same file). Separation of concerns is a good thing.
Angular will continue to be a solid choice for large professional outfits that care about things like maintainability, repeatable builds, dependency management, readability etc etc. Having Angular be the framework that powers websites like google.com and YouTube is just going to make it even more of a "no-brainer" choice than it already is if people are picking a web UI framework.
I cannot understand how it was invented/why it exists, how smart people at Google convinced themselves to use it. I cannot understand how they let it escape into the wild or even why those not forced to use it, choose it.
I know I’ve begged before for this, and it’s pointless, but please if you’re in the position to, please consider snuffing it out and starting over.
What do you use?
That’s the reason we’re currently migrating all our remaining usages of Material components to ng-zorro.
[1] https://blog.angular.io/angular-v16-is-here-4d7a28ec680d
In the end this only buys you another 6 months but helped us get ready for Angular 18 in May.
[1] https://blog.angular.io/introducing-angular-v17-4d7033312e4b
We deprecated legacy components in v15 to be removed in v17. Even though they’ll not be part of the Angular Material v17 package, you can still update your apps to Angular v17 and use the v16 Angular Material package. This will be an option until v18, after which Angular Material v16 will no longer be compatible with newer versions of Angular.
[1] https://blog.angular.io/introducing-angular-v17-4d7033312e4b
Angular is getting partial hydration (seems automatic from the keynote but it's not clear) and deferred views which are like components that don't load until something happens (eg entering the viewport).
Performance has increased considerably too thanks to the use of signals.
Honestly I'm quite impressed. I wish Svelte had partial hydration but the team keeps arguing against it.
Please. This discussion has been going on for years Ben. Even before SvelteKit or Svelte 4 existed.
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.
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.
I confess I wasn't thinking about a particular build tool. My recent experience has been with Vite, where I took a similar approach to what you describe, but haven't had to dig deep into bundle performance because that's not a bottleneck for our application. The last time I did deeper work on the subject was years ago with Webpack.
I thought Webpack at least did dead-code elimination before splitting things into chunks. If I'm reading this random GitHub issue[1] right (and the asker is also right), Webpack does partially behave as I expected, but the pre-chunking optimization pass occurs before things like constant expression evaluation.
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.
When I was still at Google, the web dev I knew who was in touch with outside stuff, talked about Angular as if its day had passed
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 getting something "newish" right.
It wasn't always like this.
Google’s AI strategy is as clear as Nokia’s smartphone software strategy was.
May 2010 - August 2010.
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.
Okay, watching this video, and they just infantized their audience "if someone makes you uncomfortable, come find a staff" as if the conference goers aren't adults. That makes me really uncomfortable that they think adults can't handle themselves and work things out.
Java has just copied some parts of how concurrency works in Go, but that's nearly 20 years after Go was released.
It's extremely easy to start up code concurrently with "go foo()". You can start up lots of such functions concurrently, as it works in userspace. Like async code, but no "colored functions" problem.
The difference is that now red and green threads are exposed at the API level, and not an implementation detail.
Hardly copying Go.
Go 1.0 was released in 2012.
Here are a few on top of my head:
1) CSP concepts embedded deeply into the language (goroutines/channels/select) making concurrency easy to do correctly
2) Standard Library and Go toolchain providing everything that most languages use third party libraries for (formatting, testing, benchmarking, fuzzing, HTTP, crypto, etc...)
3) Compilation into a static binary that can just be copied from machine to machine without any dependencies whatsoever (even C struggles with that on Linux, due to glibc NSS fiasco)
4) Cross-compilation by changing two environment variables
5) Minimalistic distribution system - just write `import "github.com/person/repository"` - no need for packaging, pom.xml, requirements.txt, package.json, etc.
6) Interface-based modularity (structural typing), making code reuse much easier than the usual OOP-style abstract-class based modularity (nominal typing)
7) Extremely fast compilation, which makes read-modify-run development loop as fast as with interpreted languages
2) .NET, Java, Smalltalk, Common Lisp
3) Any compiled language until the mid-1990's.
4) Amsterdam Compilers Toolkit, 1980
5) Until the repo changes, forbids distribution of binary libraries
6) Standard ML, Caml Light, OCaml, Haskell,...
7) Turbo Pascal on CP/M, MS-DOS computers running at 7 MHz, with 640KB.
Additionally:
- Erlang does not implement CSP, it implements Actor model
- Java does NOT have all the listed features included in its default toolkit - hence the existence of Gradle, Maven and all other packaging/testing/benchmarking solutions
- The "until mid 1990's" is the keyword here - I'm talking about modern languages and I explicitly pointed that out
- ACT is not part of any language, it is an external tool that may or may not be reliable, but definitely does not have toolchain/standard library level of quality/stability guarantee.
- "Until the repo changes" - packages can disappear from any system, see leftpad incident
- "forbids distribution of binary libraries" - not true, see [0]
[0] https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...
---
However, if I have misread your tone, and your post was intended to be an informative list of languages Go was inspired by, then thanks for the information. But some of it is misleading or false.
I could go over those points, one by one into detail, including Russ Cox point of view on disabling binary distribution, but not feeling motivated to press the further the wound.
Implementing, sometimes quite poorly, all 7 categories does not a revolution make.
Golang looked at the past 60 years of programming evolution and decided it needed almost none of it, and ignored any developments in programming languages of the past thirty years or so. This is not revolutionary. It is, at best, reactionary.
- No tail call optimization
- No meta-programming
It is basically a revamp from those rockstars previous efforts (Limbo and Oberon based dialects).
As a Goolgle user and long time admirer, there have certainly been some disappointments and mistakes over the years. But there’s also been some major accomplishments which people sometimes overlook.
While still early, Waymo seems to be on the right trajectory and may be a key player in autonomous vehicles. Let’s not forget Googles work on transformers, which is heavily responsible for the current AI boom. That’s just two that come to mind, I’m sure there are others. Maybe these were started before Sundar, but he’s been CEO for almost 9 years now. So he gets credit.
Google may have some culture challenges to work through, brain drain, and identity issues. But I don’t think their story is written just yet. With a giant stock pile of cash they have plenty of time and resources to buy or figure their way out of any perceived issues (if that’s even what they need to do).
Microsoft did it. And if you really want to have your mind blown, go take a look at IBMs stock chart. I didn’t expect to see it approaching an all time high.
I think Google's market cap is increase _despite_ Sundar, not because. That said, Google does have enough resources to turn it around, I just don't think Sundar is the right person to do it.
> I just don't think Sundar is the right person to do it
That was sort of my point. Does Google need to be turned around? All stock metrics and revenue metrics show that they are doing well as a company.
Sure the AI model stuff was embarrassing. But it doesn’t seem to be having an impact on the value of the company. Maybe goodwill was hurt. But if we’ve learned anything from the Meta drama over the years, people will be quick to forget about it. I don’t think a few fixable and public missteps like that will sink the company. Does anyone outside of tech even know about it? It’s possible it’s indicative of a larger internal issue thats brewing. But it’s not impacting the value of the company… yet at least.
[1] https://www.statista.com/statistics/478176/google-public-clo...
If google had proper leadership, the company would easily be worth twice it's current value. Easily. Instead we have a situation where raw capitalist inertia is carrying the company forward, while active discussions of the company are ridden with grievances and frustrations. Grievances and frustrations in a market where there are competitors that users can flee to. It's a bad spot to be in.
There is no reason Google shouldn't be the ones on the cusp of releasing GPT-5 level LLMs. None. Instead however they have a middling LLM that is scared to mention white people. So back to the drawing board so they can work out the racial kinks, while the competition blasts past them.
Google needs big company technology focused leadership 5 years ago. But tomorrow would be good too.
My points were focused on the fact that the data just doesn’t currently show Google failing or declining as a company.
It’s going to be really interesting to see how the Google AI strategy plays out. I agree that they could have absolutely been the leader. They had the money, resources, and ingredients to make it happen.
I believe that AI is a threat to their current business model. How much did that influence their investment and focus on it?
At the time of this news, Google's stock fell 5 percent, so it is hurting company evaluation, at least temporarily.
Google's stock might be rising, but what is causing that? I can't point to any material success of Google in the last 10 years to explain it, seems to me Google is coasting.
https://www.reuters.com/technology/google-parent-alphabet-re...
https://libredirect.github.io/ https://einaregilsson.com/redirector/
Note the site I linked is very dodgy, so probably not trustworthy.