4 ms·
Google Cloud wanted to "eat its own dogfood", so they originally built the console with Angular v1 and App Engine instead of using more scalable and mature fram
by dub 6y ago
Google Cloud wanted to "eat its own dogfood", so they originally built the console with Angular v1 and App Engine instead of using more scalable and mature frameworks that would typically be used for those kinds of products within Google.
App Engine didn't support chunked transfer encoding so progressive data loading becomes impossible, and Angular v1 is a pathological performance and maintenance nightmare to the point where AngularJS / Angular v2 ended up being an incompatible rewrite.
The problem is, if you have hundreds of people contributing to a tool with deadlines to meet and lots of UI components you need an incremental approach if there's going to be any hope of replacing the whole architecture. Without an incremental path forward, rearchitecting is dead in the water. Management isn't going to want hundreds of people stop working on new features for months while the whole UI gets written from scratch.
- iooi 6y agoIf dogfooding is the main reason behind using Angular, it's a bit ironic that <10%? of teams at Google use Google Cloud over Borg.
- dub 6y agoThe Google Cloud team had more incentive than other teams would to be an early adopter in dogfooding their own products, in this case App Engine specifically. Ending up on Angular was likely a consequence of using app engine: all of the standard google frameworks for writing UIs have a server-side component to help deliver data and scripts to the client, and most of those frameworks would have been difficult or impossible to port to app engine (either because of the chunked transfer encoding limitation, or just the general awkwardness and annoyance of porting a framework maintained by a completely different team from borg to app engine). The codebase probably started with something that looked like an app engine example app, transferring data and code to the client in the simplest way possible, but not the most performant or scalable way.