Hacker News Reader

Comment by lost-theory | Hacker News Reader

It's interesting to watch Google's moves to control every part of the stack. Browser: Chrome. Frontend: Closure compiler -> obfuscated SPAs. Transport: gRPC. Backend: Proprietary Google software written in Golang. Orchestration: Kubernetes. Hosting: Google Cloud. Etc. You can imagine a future where Google services are no longer just web apps on the same footing as anything else in the web ecosystem, but where every step of the development, deployment, and end-use is managed by Google. Can't blame them for doing that, I'm sure it's more efficient, but it's definitely moving the web in a different direction, one where Google has more control at the expense of everyone else (end users, competitors).

View on HN

They're not controlling anything by releasing open-source libraries/languages such as gRPC, Kubernetes and Go. Releasing these things don't give them control over anything that can negatively impact users; this is not Microsoft's embrace-and-extend.

Chrome, on the other hand, is worth worrying about. Unlike the other technologies you mention, it's a consumer application that legitimately lets Google apply Microsoft-style embrace-and-extend tactics, monopolizing the web and steering it in a direction that benefits Google more than anything (e.g. ads and tracking).

Kubernetes may have come out of Google, but it isn't even in their control anymore. If anything, Kubernetes is a strategic play to democratize cloud orchestration, undermining competitors such as AWS.

Good points. I don't see anything wrong with these individual open source releases. See my other comments about the larger trend this represents.

"Releasing these things don't give them control over anything that negatively impacts users" and "undermining competitors such as AWS" contradict with each other if you believe competition is good for users. The decision to release something as open source doesn't happen in a vacuum. Open source doesn't automatically make corporate activity morally good or neutral.

gRPC, Chrome and Closure are all open-source, Closure comes with source maps, and the "Proprietary Google software written in Golang" backend is pure speculation.They might turn out to be the Borg, but this release isn't part of of the assimilation process.

"It's open source" isn't the full story. Something can be open source and also used in a harmful way. You're right that gRPC-Web alone isn't a huge issue, but it's part of a larger trend of Google wanting to Google-fy the web, technology, or even society as a whole (see the leaked Selfish Ledger and Good Censor presentations).

Specifically in the case of gRPC-Web, even though "it's open source", does every gRPC service exposed on the web provide a .proto file for you to build your own client? If not, that's a big step down in terms of power given to end-users compared to REST.

Google is externalizing a lot of tools used internally for years. Use them or don't, it's your choice, but lots of time and effort has gone into making them work well so there's value there being made available for free.

To your point about .proto files for public endpoints: does every JSON HTTP endpoint exposed to the web provide documentation for you to build your own client? (of course not)

Again, I don't think this specific example is hugely significant, I'm looking at the larger trend.

Re: public endpoints. Say you're poking around a public web service, and it doesn't provide an API. Maybe you're writing a browser extension. Would you rather reverse engineer a JSON HTTP API with no documentation, or a gRPC-Web API with no .proto file?

$ grpc_cli ls <addr>

You’re welcome.

That looks useful. Do you know if that works with gRPC-Web where the underlying gRPC port is behind a service proxy?

It shouldn’t be a surprise that the company all-in on the Web has a solution for every part of the stack. It might be a surprise that they open source so many things but that’s a pleasant surprise. Every thing you mentioned has a replacement from someone else so I don’t see how you concluded “control”. And finally the great majority of Google’s backends are written in C++ not Go.

Many companies are "all-in on the web" but aren't in the same position as Google. Look at the recent Chrome profile / Google account auto-login issue. Isn't that an example of Google exercising "control" over how its users interact with the web?

If Google is effectively a monopoly, does it matter if you could theoretically replace all of its offerings? Think about other monopolies in history, I'm sure they had "replacements" too.

That is not accurate. If you went head-to-head with the Standard Oil Company they would send a guy over to blow up your house. The East India Company was based chiefly on genocide and high seas piracy. All this yip-yap about Google being a ruthless monopoly on a historic scale is completely ridiculous.

As for the Chrome login thing, being logged in on Chrome does not in any way shape or form alter the way in which Chrome interacts with non-Google sites or services. So I don't see how it is an example of how Google exercises control over the web. Certainly not in a world where I need only drag Chrome into the trash can to switch browsers (and, indeed, on a computer where Apple constantly exhorts me, in a way I cannot disable, to switch to Safari instead).

don't forget office suite:gdoc, and conferencing: hangouts/meet/whatever they force down your throat tomorrow. this is specially pernicious as they are actively using it to undermine Firefox in the workplaces. their proprietary plugin took 2 months to be available in Firefox after they rebranded hangouts as meet. and now it only supports SD video and crashes frequently.

Http/2, spdy

Reply on news.ycombinator.com