> but sorry you need to learn Dart
At this point in my career I'm definitely not intimidated by having to pick up some new syntax -- especially if it is straightforward and sensible.
At this point in my career I'm definitely not intimidated by having to pick up some new syntax -- especially if it is straightforward and sensible.
And it's not just 'learning' it, the language itself, it's library availability and the general ecosystem. Which is obviously a bit of a chicken-and-egg problem or tautological even that '~nobody wants to use it because ~nobody uses it'.
Exactly, there’s a whole universe in a bottle that comes with each language, and I think that is what is the largest source of friction these days when developers consider using a language, especially when the language has little to nothing unique to offer in exchange.
It's just so utterly pointless, Dart doesn't bring anything to the table as a language and isn't used for anything else. I have no idea what internal Google politics made Flutter go with Dart, but it would have been way better if they had used Go. I say that as a certified Go skeptic, at least that is a widely used language.
You seem to think that the framework designers at Google just decided to pick a niche language called "Dart" to write Flutter in when they could have picked Javascript to write Flutter in.
No.
They decided to make the design of Flutter as a framework so clean and pure that they would have to work backwards to figure out what language it would need to be written in and then they created Dart.
You're not supposed to use Dart for any purpose other than Flutter -- that's not a drawback to learning Dart -- that's the whole point. An entire team at Google literally created a language to make it easier for you as a developer to express yourself in this domain, and you think that's a drawback? That's like thinking being given a ladder is a drawback when you want to get up on the roof.
Sure, you could just assemble a big pile of rubble and scramble up it to get on the roof, and it is true that you might be able to later use the rubble for other purposes (whereas a ladder is built for a specific purpose) -- but that does not make the ladder the more limiting tool.
If there is one repeated comment I hear about Flutter it is "wow, it seems like such superior technology, I wonder why it isn't more widely used".
To which the answer I keep hearing is "it is only superior for doing the thing it is built for -- it isn't superior for other things."
Those who would give that answer consider Javascript, on the other hand, an (inferior) tool not only for this problem, but also for other problems, so it is the more generalizable tool and therefore it makes more sense to use Javascript.
The argument seems to be that at least if you're using the same crappy tool for everything then you can claim the efficiency of never having to change your tool.
"Only a fool would use the best tool for the job", is the implication of those who disparage Dart.
Dart was a JavaScript alternative that was started back in 2011. It's evolved a lot since then but in no way was it created for Flutter.
(I worked physically adjacent to the Flutter team for a couple years)
https://docs.flutter.dev/ui/layout/tutorial#step-2-implement...
There's not even a JS alternative required here, this step is showing purely an HTML & CSS alternative?
Flutter in my mind is 'competing' with Tauri or Electron, which give me an HTML/CSS/JS (or any equivalent traditional web) frontend cross-platform. But I haven't actually used Flutter (or Dart), just looked at docs, so maybe I'm wrong?
That’s definitely revisionist history. Dart was first intended for use in the browser, it’s why Dart has JS interoperability. Google even planned for the direct use of Dart in Chrome:
https://techcrunch.com/2015/03/25/google-will-not-integrate-...
> then they created Dart
Dart’s first release was in 2013. Flutter wasn’t even announced until 2015. It was created as a JS replacement, it was not successful in that goal, then it was used for Flutter. Which is all fine! But let’s not rewrite history.
In retrospect, it seems like an obvious choice. It could be that Go wasn't what it is today back in 2015. Go was just finding it's footing in the cloud native stuff back then. Maybe they would have gone with Go or Kotlin Native if they had to do it over again today