> Material Design is focusing on support for Google's large-scale internal Wiz framework, and has reassigned the engineers working on Material Web Components. This places MWC into maintenance mode.
At one point, it seemed like Google was trying to move their stack toward stuff they could publicly release.
Now, they seem to be less and less interested in trying to release stuff like this publicly. At some point, if everything google uses is a proprietary stack, eventually people who have worked at google are going to have more trouble getting jobs elsewhere when all the tools they've worked with are things that nobody outside of google has heard of, and that could make it harder for Google to attract developers.
> eventually people who have worked at google are going to have more trouble getting jobs elsewhere when all the tools they've worked with are things that nobody outside of google has heard of
This has already happened. Many companies offer dictionaries to translate the names of Google tools to their tools. Open source ones exist as well: https://github.com/jhuangtw/xg2xg
An issue I’ve ran into is startups being very hesitant of hiring Googlers because of a perception that they can’t engineer without other teams of developers supporting all of their tooling. One startup specifically asked how to create a dashboard without using Plx - a wild question given the vast OSS dashboarding ecosystem - but it was still a concern to them.
Google is heading for a world of hurt with their internal web framework decisions as of late. They've been spinning their wheels for years trying to reinvent Wiz, and it's not going well.
I'm sure they've wasted literally billions of dollars in salary and opportunity costs. And in the end they're building multiple incompatible proprietary systems, with seemingly no checks on the team in charge of this effort. Even if they manage to succeed somehow, they'll have a system that no new hire will know, that doesn't have any external ecosystem, and definitely, that doesn't attract up-and-coming talent that wants experience that applies to the rest of the industry.
Funny enough, one of the new forks of Wiz can't use components from the other fork of Wiz, but _could_ use web components, because web components work anywhere HTML does.
So MWC actually was their only viable option for Material Design components. I think the Wiz team was desperately trying to find or fund another option because of how bad the managers thought this looked. Maybe you can't get a promotion embracing interoperability.
Can someone explain this crazy decision ? It makes no sense at all. This is the web framework library that implements their official and public UI design language using formal web standards.
Why in heaven's name would this go into "maintenance mode" ? Do they not want people making web-apps using Material Design anymore ? I thought the Chrome team was all gung-ho on web-components and shadow DOM as the one true, standards-compliant way of developing web-apps.
The Chrome team is indeed building all their web UI (things like settings and bookmarks) with web components and... Material Web Components! Chrome OS is also building most or all of their built-in apps this way.
They are pretty put out by this decision, and will have to maintain Material components themselves, but the Material Design team doesn't prioritize Chrome as a customer - the VPs weren't graded on helping them for some reason.
It already is an issue and it works both ways. Engineers going to companies with proprietary stacks need to spend a lot of time onboarding. And engineers moving out of companies with proprietary stacks need to reorient themselves to the open source tooling.
But to a certain extent, that's part of the job description. If you move from a company that uses RoR stack to one that uses GraphQL or Node, you're going to have to learn the ropes.
> Our long-term goal is to gradually and responsibly merge Angular and Wiz over the coming years. Our strategy is to steadily open source Wiz features via Angular and follow our open model of development, allowing the community to both influence the roadmap and plan accordingly. We’ll use the public RFC process to ensure we gather community feedback on the relevant proposed features. The primary goal is to improve the Angular framework.
This is already happening. At a previous job I saw an applicant who was struggling to figure out how to use any of the company’s standard tooling for version management and development because they spent their whole career only working with the Google internal versions.
I'm far less interested in what happens to ex-Googlers.
What's just wild about this to me is that Google does not give a crap about outside developers anymore.
None of the new plans court the outside world. Google is all in on Google tech for Googlers. ChromeOS tried to mix in some regular Linux-stack tech: dead, replaced by bespoke Android-ism forever and ever. Cutting off a toolkit used to help folks make good Google style web apps is again that cutting loose ties with the outside world, is turtling up inside their own inland empire.
In a way, it's returning to Google's roots. Before the public cloud became a thing, more of their stack was proprietary. (And without having contracts with customers, there was more churn.)
At one point, it seemed like Google was trying to move their stack toward stuff they could publicly release.
Now, they seem to be less and less interested in trying to release stuff like this publicly. At some point, if everything google uses is a proprietary stack, eventually people who have worked at google are going to have more trouble getting jobs elsewhere when all the tools they've worked with are things that nobody outside of google has heard of, and that could make it harder for Google to attract developers.