Ask HN: Why isn't Dart more popular?
Played around with a couple of the Google sponsored languages - Go and then Dart. Both exercised different parts of my brain but I feel like Dart has a much lower learning curve for anyone with Java/C# experience. I'm using it with Flutter and it's been great but wonder why it isn't more popular as a general purpose backend language?
81 comments
Dart should have been dead a long time ago, Flutter saved it.
It was supposed to be the successor of JavaScript, when that ended up like everyone expected, Dart was pretty much dead until Flutter appeared and started to have some initial success.
So.. Dart by itself, what does it offer for developers/industry to change? My take is: nothing.
It was supposed to be the successor of JavaScript, when that ended up like everyone expected, Dart was pretty much dead until Flutter appeared and started to have some initial success.
So.. Dart by itself, what does it offer for developers/industry to change? My take is: nothing.
If offers a statically typed yet flexible and safe language with familiar intiutive syntax and a decent dev.x
I thought that the DX was rather poor last time I played with Dart (not Flutter). Package docs suck when it comes to describing a package’s API and types (not sure if this is the package’s fault but I was expecting Go-like docs). I expected better from a typed language.
I also didn’t have a nice time with the package manager. I had to manually create the pubspec.yml file to even start installing packages.
Maybe I missed some crucial docs, but I was rather annoyed throughout the whole experience.
I also didn’t have a nice time with the package manager. I had to manually create the pubspec.yml file to even start installing packages.
Maybe I missed some crucial docs, but I was rather annoyed throughout the whole experience.
What does it offer that Typescript doesn't?
Compiled performance
Given the javascript frameworks we run these days apparently that isn't an issue.
Or it is an issue and why everyone is moving to compiled languages for JS tooling, like Turbopack announced yesterday as a Webpack alternative written in Rust, to join other tooling such as esbuild, SWC, and Rome.
Typescript is another amazing language. They don’t compete.
But not in a more meaningful way than TypeScript which has the advantage of being a superset of JavaScript.
> Dart should have been dead a long time ago, Flutter saved it.
Not that simple. The new Dart is a completely different language than what they published 2011 als an alternative browser language.
But as far as I've seen today's Dart is not really faster than TS/JS on V8; thus, the difference is primarily the different syntax, which is probably an insufficiently important argument for most users; the cross platform AOT feature is great but apparently not important enough for the majority of people.
Not that simple. The new Dart is a completely different language than what they published 2011 als an alternative browser language.
But as far as I've seen today's Dart is not really faster than TS/JS on V8; thus, the difference is primarily the different syntax, which is probably an insufficiently important argument for most users; the cross platform AOT feature is great but apparently not important enough for the majority of people.
Just adding on to the other explanations here. Dart has little point outside of Flutter. We have tried to use Dart to create helper tools (which we'd usually do in Python) but because of the fact that threads can't efficiently share memory means it's basically useless for anything that is remotely intensive.
Dart uses a microtask queue which the Dart VM controls. Each process you run is called an isolate, with its own instance of the Dart VM and memory stack. The only way to speak to other threads is to use Send/ReceivePorts which have a massive overhead themselves. In our mobile app we do a lot with many cryptography algorithms. Originally we had to send each item to be encrypted/decrypted/signed to a background isolate to ensure the UI thread doesn't freeze. This is fine, for small requests, but once you reach the realm of tens of megabytes this process becomes slow as all hell. The recommended solution for this is to write the file to disk and just send the file location to the isolate. Which itself incurs IO overhead.
Anyway, our use case be damned, just the fact that because Dart runs a microtask queue with non-sharable memory makes it hard to use for anything other than Flutter.
Dart uses a microtask queue which the Dart VM controls. Each process you run is called an isolate, with its own instance of the Dart VM and memory stack. The only way to speak to other threads is to use Send/ReceivePorts which have a massive overhead themselves. In our mobile app we do a lot with many cryptography algorithms. Originally we had to send each item to be encrypted/decrypted/signed to a background isolate to ensure the UI thread doesn't freeze. This is fine, for small requests, but once you reach the realm of tens of megabytes this process becomes slow as all hell. The recommended solution for this is to write the file to disk and just send the file location to the isolate. Which itself incurs IO overhead.
Anyway, our use case be damned, just the fact that because Dart runs a microtask queue with non-sharable memory makes it hard to use for anything other than Flutter.
Out of curiosity, why did you decide to pick up Dart instead of, say, Go? And what did you finally settle on?
Dart was initially targeted at web development. If you ask me, the initial benefits of Dart were surpassed by the JS ecosystem. TypeScript is fantastic, the npm ecosystem is rich and full featured and has deep network effects and all that tooling really started to get good and mature within a couple years of Dart launching (ES2015 another big improvement for JS). That left very few benefits for Dart over JS/TS.
I used Dart for a project some 8 years ago. There used to be an easy to use Dart Editor that I used and one day it just stopped working, and stopped getting updates.
Google did not provide any good alternatives, and I just gave up on the language for the lack of developer support. I have not looked back since.
Google did not provide any good alternatives, and I just gave up on the language for the lack of developer support. I have not looked back since.
If you liked dart back then, you absolutely should check it out again today. It's improved greatly and easily has the best developer experience of any language I've ever used. Not to mention one of the most rapidly improving.
Non-null by default was a massive change for Dart in terms of perf, and modern dart is quite a different (by very pleasant) beast than dart 1.x.
Non-null by default was a massive change for Dart in terms of perf, and modern dart is quite a different (by very pleasant) beast than dart 1.x.
Programming languages don't succeed/fail on their own merits; popularity is driven by externalities, the main one being "what can I do with this language"?
Dart seems fine to me; as a person who doesn't really use it, it seems "about as good" as other well-regarded garbage-collected languages I don't use (in my case, C#, Go). So it's not that I think it is bad, and therefore don't use it. It's that it isn't well aligned with the things I want to create.
Sure, you can create CLI apps if you do all the work yourself, but there isn't some big library of Dart packages out there. There seem to be a lot more examples and libraries out there in Go (and Rust, etc).
You can make GUI apps with it, but only if using Flutter does that really make sense.
So if you want to make a Flutter app, or work on Adwords, or one of Google's research operating systems, Dart is probably pretty attractive.
But I think all those people are already using Dart. So it's probably just that there aren't more people who want to work on those things.
Dart seems fine to me; as a person who doesn't really use it, it seems "about as good" as other well-regarded garbage-collected languages I don't use (in my case, C#, Go). So it's not that I think it is bad, and therefore don't use it. It's that it isn't well aligned with the things I want to create.
Sure, you can create CLI apps if you do all the work yourself, but there isn't some big library of Dart packages out there. There seem to be a lot more examples and libraries out there in Go (and Rust, etc).
You can make GUI apps with it, but only if using Flutter does that really make sense.
So if you want to make a Flutter app, or work on Adwords, or one of Google's research operating systems, Dart is probably pretty attractive.
But I think all those people are already using Dart. So it's probably just that there aren't more people who want to work on those things.
I would put it like “changing languages has a huge cost, and most feature-differences between modern managed languages are superficial at best and don’t provide a huge productivity/correctness benefit, while changing to them often wipes clear a huge library ecosystem and the hiring pool”
I used dart for a couple projects just around it's 1.0 release. I really liked it back then. They were working on some neat ideas. I remember futures and streams being really really interesting in 2013 or so. Originally Dart was competing directly with Typescript. It wasn't clear who would win at the time. Typescript focused on being a superset of JS and Dart made the mistake of trying to push its own VM into the browser which never really got traction and so transpiling to JS and depending on gwt was the only answer for dart on the web (I think) and the js output was pretty hairy. Dart web was dead. Go was already getting popular on the backend and so Dart had nowhere left to go until Flutter. Dart's fate is now Flutter's fate.
I’ve been using Dart/Flutter for over a year now building an open source iOS/Android/Web app. In general, Dart is a solid language, and we enjoy writing code in it. The package management, for example is comparable to other best in class managers, like Rust’s Cargo and a huge leap forward from languages like Python. All the tooling (linting, formatter) takes the lessons Google learned from Go and applies them to Dart.
Additionally, It’s both an interpreted (with JIT) and a compiled language. Flutter uses this to hot reload code in development, but also to ship a leaner binary in production. On the server, native binaries are great for CLI tools for easy deployment, and the JIT is great for servers where processes are longer running and performance is more important than process size. Although it’s reasonably fast either way.
That being said, it’s a pretty boring language. It doesn’t have many expressive features to reduce boilerplate. While it does have reflection, no one uses it because it can’t be used in Flutter when compiling native binaries. Very few people are willing to make packages that don’t work in Flutter. People generally resort to code gen, which is clunky and adds another process to development.
On the server, there are not many options. The ‘shelf’ package is the default, but it falls short in many areas, making developers cobble together different packages. There are others, the one I’m watching is Frog[0], but adoption is slow. However, it is pretty much just another Next.js style clone, not adding anything novel to the space.
My hope is that the cloud providers will roll out native Dart support to their FaaS products, so I can at least share my model code between apps and the backend. However, the dream (well, my dream at least) is to have a full end-to-end Dart/Flutter solution that is real-time/reactive and not REST-based. Something like a programmable Firebase where I don’t have to deal with un/marshalling data myself all the time. I think that will get Flutter devs enough reason to move to Dart on the backend.
[0] https://dartfrog.vgv.dev/
Additionally, It’s both an interpreted (with JIT) and a compiled language. Flutter uses this to hot reload code in development, but also to ship a leaner binary in production. On the server, native binaries are great for CLI tools for easy deployment, and the JIT is great for servers where processes are longer running and performance is more important than process size. Although it’s reasonably fast either way.
That being said, it’s a pretty boring language. It doesn’t have many expressive features to reduce boilerplate. While it does have reflection, no one uses it because it can’t be used in Flutter when compiling native binaries. Very few people are willing to make packages that don’t work in Flutter. People generally resort to code gen, which is clunky and adds another process to development.
On the server, there are not many options. The ‘shelf’ package is the default, but it falls short in many areas, making developers cobble together different packages. There are others, the one I’m watching is Frog[0], but adoption is slow. However, it is pretty much just another Next.js style clone, not adding anything novel to the space.
My hope is that the cloud providers will roll out native Dart support to their FaaS products, so I can at least share my model code between apps and the backend. However, the dream (well, my dream at least) is to have a full end-to-end Dart/Flutter solution that is real-time/reactive and not REST-based. Something like a programmable Firebase where I don’t have to deal with un/marshalling data myself all the time. I think that will get Flutter devs enough reason to move to Dart on the backend.
[0] https://dartfrog.vgv.dev/
Languages aren't popular by default, they're unpopular by default and need a compelling reason to become popular.
Most new backend languages fail the "what is this giving me that OCaml hasn't had for 20 years" test. (Hell, it's only recently that the question has stopped being "what basic feature that OCaml has had for 20 years is this language missing"). Dart is fine - I actually quite like the language design - but "fine" isn't good enough.
Most new backend languages fail the "what is this giving me that OCaml hasn't had for 20 years" test. (Hell, it's only recently that the question has stopped being "what basic feature that OCaml has had for 20 years is this language missing"). Dart is fine - I actually quite like the language design - but "fine" isn't good enough.
There are better languages with better ecosystems. Even the Android team picked Kotlin. It failed going into the realm of JavaScript (Typescript took that).
It's not that it's a terrible language. It isn't. There are just better languages that don't have the burden of Google who is notoriously flaky on supporting failed projects.
Flutter succeeded because the alternatives are worse and because of China which is its main source of traction.
It's not that it's a terrible language. It isn't. There are just better languages that don't have the burden of Google who is notoriously flaky on supporting failed projects.
Flutter succeeded because the alternatives are worse and because of China which is its main source of traction.
August 2017 - Android picked kotlin over java
September 2018 - Flutter release preview 2 released (can't find the date on RP1)
December 2018 - 1.0 release of flutter
Flutter is not going to be the primary framework over JVM-based for Android any time soon, these things takes lots of time. But android didn't pick Kotlin over flutter, it was just not ready to be the preferred language at that point in time. I would even say Kotlin could have been promoted even sooner then it was
September 2018 - Flutter release preview 2 released (can't find the date on RP1)
December 2018 - 1.0 release of flutter
Flutter is not going to be the primary framework over JVM-based for Android any time soon, these things takes lots of time. But android didn't pick Kotlin over flutter, it was just not ready to be the preferred language at that point in time. I would even say Kotlin could have been promoted even sooner then it was
I said Kotlin over Dart. Not over Flutter.
Flutter doesn't make sense as the native OS framework for Android.
Flutter doesn't make sense as the native OS framework for Android.
I am currently learning Dart and Flutter in my free time (using it for a hobby project) and so far, I haven't seen any real use case for Dart alone.
To me, Dart is Flutter. I don't think the Dart team have tried to make their language stand out and show its usage outside Flutter. I mean I enjoy the language a lot, it's really faschinating using it and reading the docs but it doesn't provide any value alone sadly.
I am well aware of all the fullstack frameworks poping up every second, but I think if the team created such framework in the language then that would definitely prove it's capabilities and maybe attract more people.
When I think about it, Ruby and Rails is in a similar situation. The only reason people are learning Ruby is because Rails, but to my understanding (forgot the source) but the team behind Ruby is well aware of this and is trying to prove Ruby's value outside Rails.
To me, Dart is Flutter. I don't think the Dart team have tried to make their language stand out and show its usage outside Flutter. I mean I enjoy the language a lot, it's really faschinating using it and reading the docs but it doesn't provide any value alone sadly.
I am well aware of all the fullstack frameworks poping up every second, but I think if the team created such framework in the language then that would definitely prove it's capabilities and maybe attract more people.
When I think about it, Ruby and Rails is in a similar situation. The only reason people are learning Ruby is because Rails, but to my understanding (forgot the source) but the team behind Ruby is well aware of this and is trying to prove Ruby's value outside Rails.
Why isn't zig more popular? Same reason. It does the same thing as c++. Dart does the same thing as c#, typescript, swift, etc.
Why is Rust popular? Rust does something no other programming language offers.
To win in the market, you need to find your niche. You can't just be a 3% better alternative that forces everyone to chuck their existing tools out the window
Why is Rust popular? Rust does something no other programming language offers.
To win in the market, you need to find your niche. You can't just be a 3% better alternative that forces everyone to chuck their existing tools out the window
What does it offer? Does it have a killer web framework? Great data modeling? May as well just use typescript.
Flutter.
marginally better than RN
You mean the framework that even Google doesn’t think is good enough for cross platform apps?
https://9to5google.com/2021/10/10/google-ios-apps-native/
https://9to5google.com/2021/10/10/google-ios-apps-native/
Except they do. Google Pay / Wallet is built in Flutter, and so was Stadia. It's a bit nonsensical to think that they'd rewrite every existing app they have in Flutter, even if it is their own toolkit. Google doesn't believe Flutter is the be all, end all in app development. But it is certainly the best cross platform app toolkit out there. But guess what, Gmail and their other apps don't use a cross platform framework, so the statements "Swift UI makes it easier to brand your iOS app" and "Flutter is a great cross platform app framework" aren't mutually exclusive, hell Flutter can even use SwiftUI views as part of it's Widget hierarchy via PlatformViews.
This post comes across as yet another person that's never actually investigated a tool casting aspersions on it because of what they hear online.
This post comes across as yet another person that's never actually investigated a tool casting aspersions on it because of what they hear online.
Your examples are honestly pretty weak: a formy app that's main criteria be that it works and doesn't send money to the wrong person (which you could pick almost any stack to do), and a platform that doesn't exist anymore.
> Except they do. Google Pay / Wallet is built in Flutter, and so was Stadia
Well Stadia is dead and Google Pay and Wallet are toy apps. I didn’t just make the citation up. Google themselves said they want to move toward Apple’s native UIKit
From the cited article
> Google concluded that it was time for the latter route, and that Apple’s UIKit had matured enough for internal needs
Well Stadia is dead and Google Pay and Wallet are toy apps. I didn’t just make the citation up. Google themselves said they want to move toward Apple’s native UIKit
From the cited article
> Google concluded that it was time for the latter route, and that Apple’s UIKit had matured enough for internal needs
Google is not a single entity, there are hundreds of teams that make their own decisions.
That’s not exactly the rousing endorsement that you think it is. The whole problem with Google is that they have no focus, vision or direction compared to the other BigTech companies.
I wasn't making an endorsement, it was just a statement of fact.
And that goes back to the point I made in the first place. We know that Apple isn’t going to abandon Swift while they are moving away from Objective C because the entire company is behind it.
Microsoft isn’t going to abandon C#. And you knew when they moved to .Net core they were committed to it
Microsoft isn’t going to abandon C#. And you knew when they moved to .Net core they were committed to it
I don't remember the specifics, but Dart didn't really have a good story when it was invented. It was this Google (red flag 1) language that was targeting JS (red flag 2 at the time) and while some few people I had talked to liked it, 8-9/10 people simply didn't see enough benefit to switch. This might have been around the coffeescript days still, so the people who valued small unimportant QoL improvement (yeah, sue me) were already accounted for for the most part.
That's when it already had been not popular and most of us thought it would just vanish, but then at some point Flutter came along. But I can't talk about that time, because I have no clue.
That's when it already had been not popular and most of us thought it would just vanish, but then at some point Flutter came along. But I can't talk about that time, because I have no clue.
[deleted]
As others have said, Dart is Flutter.
What they didn't say clearly, is that Flutter is in a complicated landscape of cross-platform native stacks, including chrome, react native, cordova, xamarin, unity, phonegap, et al. Because it's ground-up, it either mimics the platform components or you use the generic flutter style (or one you build yourself) - lots of work either way, to get results that don't jive with expectations around the demo table. Each stack has enough traction and community to continue, but the pace is nothing like the more standard programming models.
What they didn't say clearly, is that Flutter is in a complicated landscape of cross-platform native stacks, including chrome, react native, cordova, xamarin, unity, phonegap, et al. Because it's ground-up, it either mimics the platform components or you use the generic flutter style (or one you build yourself) - lots of work either way, to get results that don't jive with expectations around the demo table. Each stack has enough traction and community to continue, but the pace is nothing like the more standard programming models.
People were already burned by building their sites in CoffeeScript and Google Closure Tools which no one uses, why would you risk your company on Dart?
JavaScript wasn't complicated enough in the first place to warrant switching to a new language. What JavaScript was missing was typing, which TypeScript took care of fine. Actually more than fine, the typing system in TypeScript is way beyond many languages.
The latest innovation is JSX/TSX which I don't think I've seen anything like it in alternative languages.
JavaScript wasn't complicated enough in the first place to warrant switching to a new language. What JavaScript was missing was typing, which TypeScript took care of fine. Actually more than fine, the typing system in TypeScript is way beyond many languages.
The latest innovation is JSX/TSX which I don't think I've seen anything like it in alternative languages.
> People were already burned by building their sites in CoffeeScript and Google Closure Tools ..
Let's not forget Google Web Toolkit.
Let's not forget Google Web Toolkit.
Popularity is never a result of quality. In any area.
Sometimes it correlates, but mostly it's a matter of legacy, marketing and business decisions (that has nothing to do with dev. experience).
Sometimes it correlates, but mostly it's a matter of legacy, marketing and business decisions (that has nothing to do with dev. experience).
I thought typescript ate dart's lunch. There was a time a typed JS alone was enough. But like most things G it felt like it evolved in isolation from what the rest of the web dev world was expecting (remember GWT?). Dart to me felt like it could have been a framework instead of a (yet another) language. As a language enthusiast I really struggled to get what Dart brought to the table.
Over ten years ago when I was in school my prof gave us a heads up that dart would be big and we should start learning it.
They had their chance, but they turned it down at that time by failing to include a Dart VM in Chrome, whose browser engine had 30% of PC and mobile marketshare at the time.
However, now Chromium-derived browsers have 90% PC marketshare and 50% mobile marketshare. Including a Dart VM now, provided its standard library and tooling are up to par, would almost certainly spell the end of JavaScript.
Yeah, it'd still have to transpile to JS so that iOS users can still use the site, but Safari would be the only holdout. Unless MS strips the Dart VM from Chromium, which they honestly might do, but at that point people just go back to replacing Edge with Chrome, not that they don't by a large margin already.
However, now Chromium-derived browsers have 90% PC marketshare and 50% mobile marketshare. Including a Dart VM now, provided its standard library and tooling are up to par, would almost certainly spell the end of JavaScript.
Yeah, it'd still have to transpile to JS so that iOS users can still use the site, but Safari would be the only holdout. Unless MS strips the Dart VM from Chromium, which they honestly might do, but at that point people just go back to replacing Edge with Chrome, not that they don't by a large margin already.
> would almost certainly spell the end of JavaScript.
No, it would just make many people interested in Dart and start using it, but the end of JavaScript would be as close as the end of C++ or Java.
No, it would just make many people interested in Dart and start using it, but the end of JavaScript would be as close as the end of C++ or Java.
> would almost certainly spell the end of JavaScript
We'd all give up all the code we've already written and never update our current or legacy JavaScript codebase again?
I just don't think it'd happen, people need a more compelling reason to switch. Typescript merging into js seems a more likely sea change.
We'd all give up all the code we've already written and never update our current or legacy JavaScript codebase again?
I just don't think it'd happen, people need a more compelling reason to switch. Typescript merging into js seems a more likely sea change.
Google would need to make dart outside of flutter more attractive. I think making alternatives to next.js and Django would move the needle quite a bit.
$10M could pay 20 fulltime devs for 5 years to work on these projects. This investment is miniscule compared to their profits and I think that could do it.
$10M could pay 20 fulltime devs for 5 years to work on these projects. This investment is miniscule compared to their profits and I think that could do it.
It hasn't been marketed enough for the average person to know what it is.
I think people played around with flutter and what I keep hearing from people is that flutter's performance leaves much to be desired.
I wonder if there could be an opportunity for a full-stack framework like next.js but using Dart + Flutter
Flutter kills the open web by painting on a canvas.
you can pick your renderer for web --web-renderer html
What do you think the browser paints on?
On a more serious note, the open web was killed when people decided to use the browser as an application platform instead of as a document delivery platform.
The open web was killed by many things:
- minification
- node_modules
- webpack
- wasm
- react
Painting on a canvas is the proper way to render application UI.
On a more serious note, the open web was killed when people decided to use the browser as an application platform instead of as a document delivery platform.
The open web was killed by many things:
- minification
- node_modules
- webpack
- wasm
- react
Painting on a canvas is the proper way to render application UI.
You can screenscrape HTML based web apps and there are numerous applications enabled by this - from in-browser extensions (eg grammerly) to the ability of Excel to import tables from the web. DOM-based pages is an imperfect model but it has enabled vast extensionability.
Not so for canvas based apps.
Not so for canvas based apps.
> Painting on a canvas is the proper way to render application UI.
It kills accessibility and extensibility. It also kills content blockers like uBlock Origin.
It kills accessibility and extensibility. It also kills content blockers like uBlock Origin.
Because it’s built and supported by Google and it would be a dumb career move to tie your horse to anything Google creates. It will probably be abandoned.
Google has the attention span of a crack addled flea
Google has the attention span of a crack addled flea
This explanation doesn't work for me.
Google is behind Android, and there's a ton of android developers. It took off.
Google built Golang, and there's a ton of Go developers. It took off.
Google built Angular and Dart, and they each had much less success and didn't take off.
The "Dart isn't popular because it's backed by google" theory doesn't seem sufficient based on the above.
A more reasonable theory would be that the answer to "Why isn't X popular" is that the vast majority of things _aren't_ popular. Why isn't D-lang popular? Why isn't Crystal popular? Why didn't Elm take off?
None of those are made by google, but it turns out that building a user-base of a programming language is hard no matter what.
Google is behind Android, and there's a ton of android developers. It took off.
Google built Golang, and there's a ton of Go developers. It took off.
Google built Angular and Dart, and they each had much less success and didn't take off.
The "Dart isn't popular because it's backed by google" theory doesn't seem sufficient based on the above.
A more reasonable theory would be that the answer to "Why isn't X popular" is that the vast majority of things _aren't_ popular. Why isn't D-lang popular? Why isn't Crystal popular? Why didn't Elm take off?
None of those are made by google, but it turns out that building a user-base of a programming language is hard no matter what.
How is Stadia doing? Google Chrome apps? Google Chatbase? Google Poly? Google Loon? Google Fiber (where Google literally left a city’s streets in ruins https://arstechnica.com/information-technology/2019/02/googl...), Google Fibrr TV,
Google Fiber isn't dead; they still regularly do advertisements in US markets. They just haven't grown as fast as Google had hoped.
Have any new cities been added in the last 3 years? I think they stopped expanding when the utilities wouldn't give them access to poles and their shallow trenching technology was shown to be a bust. I expect one day they will be sold off to ATT or Verizon
Consumer apps are the ones that are killed off, not developer or B2B products.
The companies who invested money in Stadia may not have the same opinion.
There is also Google Cloud IOT Core, Conversation Actions, Android Things, Google Chatbase, and even the original Angular was abandoned by a completely incompatible framework.
There is also Google Cloud IOT Core, Conversation Actions, Android Things, Google Chatbase, and even the original Angular was abandoned by a completely incompatible framework.
> The companies who invested money in Stadia may not have the same opinion.
That has no relation to whether something is B2C or B2B. Stadia is a consumer product, ie for consumers.
You have a point there about those other ones, but honestly, those are so few and far between that I'm sure you had to search somewhat carefully to find them. I highly doubt many devs were actually using those (besides Angular, but it was replaced with 2+ because React came onto the scene, it didn't get deprecated with no replacement).
That has no relation to whether something is B2C or B2B. Stadia is a consumer product, ie for consumers.
You have a point there about those other ones, but honestly, those are so few and far between that I'm sure you had to search somewhat carefully to find them. I highly doubt many devs were actually using those (besides Angular, but it was replaced with 2+ because React came onto the scene, it didn't get deprecated with no replacement).
Having an incompatible replacement is cold comfort if you had a codebase written with the original Angular
Sure but if you're going to go that far, that's basically like saying we shouldn't have breaking releases ever. Sometimes, tech needs to evolve in the face of other threats, like React overtaking Angular.
“Evolving” implies slowly changing to keep it modern. C# “evolved”, Java “evolved”, the C standard library and C++ STL has been “evolving” for decades. But they all maintained backwards compatibility.
Again, that does not mean backwards compatibility is good. See how bloated C++ is in an effort to keep BC while it should have long ago broken things to be a more lean language.
Like Go Lang?
Completely reasonable to at least wait and see for stuff Google launches. Go has survived long enough to adopt. Flutter (the only reason to use Dart anymore) hasn't, and is exactly the sort of project they regularly kill off, or decide they got wrong and release Flutter 2 with no migration strategy.
This shows me you have not used nor even heard about Flutter, because not only have they released Flutter 2, they have also released Flutter 3 recently.
How many of Google’s cross platforms apps use Flutter? Google Sheets? Google Drive? Google Maps? Gmail?
Wow, it's even worse than I thought.
[deleted]
lol I hope not, it's a big chunk of what I do these days