4 ms·
So this article [1] matches my own recollection. Like many projects that originate from Google, it always struck me as a solution looking for a problem. The fi
by cletus 7y ago
So this article [1] matches my own recollection. Like many projects that originate from Google, it always struck me as a solution looking for a problem.
The first "problem" was Javscript.
At one presentation about this I recall that Lars Bak (IIRC) took quite a beating about DArt, just in terms of the questions asked, to the point that someone had to point out just how much he'd accomplished (ie V8). This was, in essence, an appeal to authority.
I recall the Ads PA basically stepping in to save the project. I can only speculate why but my best guess is the AdWords TL woke up one day and decided to rewrite AdWords in Dart (as he allegedly had with GWT some years before). But all that's pure speculation.
The second "problem" that Dart solved was using the same code on client and server, something Google is inexplicably obsessed with (eg GWT). I don't know what caveats came with Dart but GWT had plenty (eg for many years it wasn't possible to use the same protobuf classes on client and server).
I believe the intent with Dart was, at one point, to run natively within Chrome (the article mentions Dartium). This worked out really well for vbscript. No one wants to write different languages for different browsers. Again, I speculate here, but my strong suspicion is the Chrome team killed the idea of shipping a Dart VM in Chrome and that was the end of that.
Maybe it's just me but TypeScript just seemed far more sane.
So... Flutter. I don't know why a UI library needs to be language-specific but it strikes me as a bad idea. Now, the counterpoint is that Flutter is an SDK And more akin to, say, React Native (albeit with significant architectural differences) but I don't think it started that way.
:UI frameworks, libraries and SDKs just don't seem to be in Google's wheelhouse (as opposed to, say, infra, which very much does). I can only speculate as to why but my best guess is Google engineers (disclaimer: Xoogler) can't see passed something as an engineering problem, so much so that they take on philosophies no one asked for or needed (eg same code on client and server), which come with a huge cost and no tangible benefits.
[1]: https://insights.dice.com/2019/03/27/fall-rise-dart-google-javascript-killer/ https://insights.dice.com/2019/03/27/fall-rise-dart-google-j...
- sebe 7y ago> my strong suspicion is the Chrome team killed the idea of shipping a Dart VM in Chrome Yeah in a video last year, Lars said "then the whole mobile shift happen and there was no room for extra stuff in chrome" https://www.youtube.com/watch?v=mPna6D21Eqg&feature=youtu.be&t=502 https://www.youtube.com/watch?v=mPna6D21Eqg&feature=youtu.be...
- saagarjha 7y agoShipping a new language in your browser is no trivial task.
- Rury 7y agoCan't similar things be said for node.js and other tech? Electron apps perhaps? What problems did these technologies solve? Mostly I agree with you, but coming from desktop development, I also sometimes feel like javascript and the web in general is a mess, and prefer things in a familiar format. As so I don't find things like "DArt" or "Flutter" as surprising...
- cletus 7y ago> node.js I don't have a strong opinion on Node. > Electron apps perhaps? Hate them with a passion. > What problems did these technologies solve? Node.js to is primarily a platform for high-concurrency event-driven request handling where each request itself is a single thread. In my day job I primarily write Hack (PHP) nowadays. PHP embraced this model years ago and I, personally, think it's pretty much ideal for something most often used to service HTTP requests. You almost never want to be in the business of starting and coordinating threads. It gains you a lot of complexity and a lot more failure modes for very little benefit over the single thread per request model (combined with async/await programming, in particular). Electron is, in my opinion, trash. It's a cheap and crappy way for people to create desktop apps that have a much larger attack surface than any native desktop app (being the entire Chrome runtime) and a huge memory footprint all for the privilege of being able to use HTML/CSS to layout your app. > and prefer things in a familiar format So this explains a lot of the things you see from Google. Google engineers, in general, look down on Javascript. There's actually a hierarchy. The C++ engineers look down on anything that isn't C++. Java engineers look down on anything that isn't C++/Java (and sometimes even C++ is looked down on) and so on. A lot of Google JS is written for the Closure compiler. This was an early effort to add type hints to JS code. If you look at the code you can tell it's written by Java engineers. I like to quip that "Closure puts the Java into Javascript". The JsDoc comment format is basically Javadoc. The type system is familiar to those coming from Java. So you have GWT, which seemed to appeal to people who though tit would allow them to not need to know anything about JS [insert standard reference to the Joel Spolsky's "leaky abstraction" essay]. Closure tries to remake JS into Java. What these things tell you is the people coming up with these ideas don't really understand Javascript and more to the point, they don't think they have to nor do they want to. > I also sometimes feel like javascript and the web in general is a mess Everything is a mess if you look closely enough.