Hacker News new | ask | show | jobs
by wnsire 2879 days ago
Reading the few comments here is really interesting.

Every-time there is a discussion about Dart , people talk about Flutter... they very rarely talk about Dart on the Server or on the Web...

A while ago I considered using Dart to build a Web API. I was shocked by the non-existent ecosystem around this language.

The Redis package has been un-maintained for almost three years now, and Angular Dart is always a few version behind the TypeScript version and doesn't support SSR.

I was also very surprised that Google during dart conf never commented on using Dart on the server but instead always insisted on using it for their clients (Web and Mobile). I think I'm not lying by saying that a huge part of Google runs on JVM , Go or Python but definitely not on Dart VM.

For me Dart is the language that developer needed , but never wanted to use. It failed miserably when it was introduced few years ago, since then JavaScript took off and has become almost a universal language.

This is very frustrating seeing how much the language is efficient and well structured but it the same times doesn't mean much now seeing how mature JavaScript is becoming.

For me Dart took long to become what is it now , and today the only thing that would make people using this language is really Flutter.

Beside that , I'm afraid they are very little reason to use this language.

[0]https://github.com/dartist/redis_client/tree/master

8 comments

I think what killed Dart is that they emphasized their plans to make Dart a first-class scripting language of Chrome, so that you could use <script type="text/dart"> instead of JavaScript. This had a lot of backlash from literally everyone, I think mostly because they were bit too hard by IE doing the exact same thing just a few years before. Only after a few years the Dart team changed courses and said "never mind about that VM-inside-Chrome thing, we're just going to compile to JS like everyone else" but it was too late and nobody cared about Dart anymore and all the excitement and enthusiasm was gone. I think people don't realize just how much excitement and enthusiasm from a potential community makes or breaks a project when it's first announced.
I'm on the Dart team and I agree with pretty much all of this.

Personal opinion time:

Lars and Kasper, the original leads and creators of the language came out very confidently with this mission to get Dart natively supported in the browser based on the assumption that the language was so good and the VM would be so fast that users would clamor it.

They had the best of intentions — they really did want to make a delightful, productive, fast language. They intended to move the entire web forward the same way V8 had when it first launched, and they believed deeply that Dart would enable that.

But I think they really underestimated how vastly different designing and marketing a language is from simply implementing an already-successful one.

It's not enough to just have a good product. The way you present it is often more important. And you don't even have the luxury of defining "good product" — you must be mercenary in letting your users' needs override your personal preferences. All of that was a real struggle for them.

For what it's worth, there's been a lot of staff changes over the years since Dart first launched. Lars and Kasper have left to try the startup thing again (which I think is a better fit for their skills and desires than evolving a big open source language). The team we have now, I believe, is much better aligned with what you're saying.

It sucks that we do have this baggage, but I hope we can improve our reputation over time. I'm hopeful we can — it took Java several tries before it found its footing.

I think a lot of what people found off-putting about Dart is that Google already recently came out with a new language that has become very successful. Announcing another one, which at first glance looks like yet another curly brace language not that far from Java, was a step too far for people to be interested.

Nowadays, the only thing driving Dart seems to be Flutter, which again is head-scratching. Like, "Flutter sounds interesting but in addition to learning Flutter I need to learn a brand new programming language for it that's really only used for Flutter?" People only have so much bandwidth for new things and there's already so much to constantly learn in our industry.

I could be wrong, but I don't believe the existence of Go was much of a problem. Go and Dart are very different languages aimed for very different use cases. If anything, I think Go helped us because we could point to it as a successful language that Google hasn't cancelled.

> not that far from Java

This is something that hurt us, I think. You can write Dart code that looks a lot like Java, and many of our early public examples did. To make matters worse, for no good reason, Dart 1.0 didn't do any type inference, so even though you could use "var" for local variables, doing so would give you a worse user experience.

But you don't have to write Java in Dart. You can write really elegant, clean code in Dart in a way that Java doesn't enable. You don't have to stuff everything inside classes. We've always had nice terse lambdas, higher-order functions, collection literals, etc.

Here's a random little program of mine:

    import 'package:hauberk/src/engine.dart';
    import 'package:hauberk/src/content.dart';

    main() {
      var content = createContent();
      var save = content.createHero("blah");

      while (true) {
        var watch = Stopwatch();
        watch.start();

        // Generate a dungeon at each level.
        var count = 0;
        for (var i = 1; i <= Option.maxDepth; i++) {
          var game = Game(content, save, 1);
          for (var _ in game.generate());

          // Read some bit of game data so the JIT doesn't optimize the whole
          // program away as dead code.
          if (game.hero.pos.x >= -1) count++;
        }

        watch.stop();
        print("Generated $count dungeons in ${watch.elapsedMilliseconds}ms");
      }
    }
It's not the most beautiful code in the world, but I do think it's a good bit simpler and cleaner than it would be in Java.
The thing is, this is almost identical to well written JavaScript. In fact you could do almost all of this in JS even before ES5. So the non-Java-like features you're using here were already present, which again suggests that Dart isn't really getting past the "Good Enough" problem.

It's also something you could do in Java, with the exception of having to wrap main with the obligatory EntryPoint class.

I think this just goes to show that good code can be written in almost any language (except Perl of course) because writing good code almost always just means writing obvious code, which necessitates avoiding cleverness and obscure features (literally all of Scala), twisting control flow (I'm looking at you State monads and call/cc), or adding too many indirections due to limitations of the language (Java).

> In fact you could do almost all of this in JS even before ES5.

Well you do get static type checking if you write it in Dart, but I see your point. :)

Why was "except Perl of course" needed here? Do you have any data to back up that you can not write well written code in Perl? Or are you just simply venting your prejudices?
> I could be wrong, but I don't believe the existence of Go was much of a problem.

It wasn't so much Go per se, but the fact that Google was pushing two new languages at the same time. It created the perception, for me at least, that Google was pushing out new languages to see which ones stuck and kill those that didn't. Google had/has the reputation for killing off projects that it lost interest in. And I wasn't willing to learn new a new language and its ecosystem only to be marooned there a few years later.

So, while I was definitely interested in alternatives to JS, there was no way I'd pick up on Dart.

Totally agree. Also, Go was refreshing. Intentionally limited, yes, but simple-yet-powerful. Then they show off Dart and it looked like yet another 90's-style curly-brace language, and I'm sure I'm not the only one who asked "why bother?".
That is nice. It's also almost indistuishable from Java 10. The string interpolation at the end is the last big syntactic nicety Java is missing - at least relative to this example.
Yes it is a little nicer than Java 11, but not so much to really make a difference, while throwing away all the Maven central goodies.

    import engine.*;
    import static content;

    import static java.lang.System.out;

    public class Demo {
        public void main(String args[]) {
            var content = createContent();
            var save = content.createHero("blah");

            while (true) {
                var start = System.currentTimeMillis();

                // Generate a dungeon at each level.
                var count = 0;
                for (var i = 1; i <= Option.MAX_DEPTH; i++) {
                    var game = new Game(content, save, 1);
                    for (var ignored : game.generate());

                    // Read some bit of game data so the JIT doesn't optimize the whole
                    // program away as dead code.
                    if (game.hero.pos.x >= -1) count++;
                }

                var stop = System.currentTimeMillis();
                var elapsedMilliseconds = start - stop;
                out.printf("Generated %d dungeons in %dms\n", count, elapsedMilliseconds);
            }
        }
    }
> I do think it's a good bit simpler and cleaner than it would be in Java.

Is it really? My Java is rusty, but now that Java has type inference it looks nearly exactly like what you'd type in Java (minus `public static void`, `new`, etc.)

Java 10 only has type inference for method-scoped vars.
I removed everything that seems redundant. Less syntax means less to break, and less for new programmers (who are 10x the volume of existing programmers) to learn:

    import 'package:hauberk/src/engine.dart'
    import 'package:hauberk/src/content.dart'

    content = createContent()
    save = content.createHero("blah")

    while (true) 
    watch = Stopwatch()
    watch.start()

    # Generate a dungeon at each level.
    count = 0
    for (i = 1; i <= Option.maxDepth; i++) 
        game = Game(content, save, 1)
        for (_ in game.generate())

            # Read some bit of game data so the JIT doesn't optimize the whole program away as dead code.
            if (game.hero.pos.x >= -1) count++      

    watch.stop()
    print("Generated $count dungeons in ${watch.elapsedMilliseconds}ms")
how are the semicolons in a for loop redundant? Without them it's extremely difficult to parse what's going on.
Separating variable declaration and reassignment at a glance makes code more clear. Indenting loop bodys makes code more clear, and the curly braces won't suddenly break. Keeping lines short makes it nicer to work with in various editor setups.
It's a shame, I was a HUGE dart for backend proponent. I made libraries and even middleware for API servers and such. I was constantly fighting to get ANY focus on the backend standard libs. In the end, I had to give up and stopped fighting. I still maintain my uuid, base32, and otp libraries, just upgraded them for 2.0, but Its a shame because Dart could have so easily competed with Node.js and it was a major replacement for it for me.
A language by itself is almost never useful, every language needs a killer app, a concrete tangible thing that that language can do better 100x better than any alternative. Like how Ruby had Rails or JS had browsers or Python has ML. That’s not to say you can’t do other things with these, just that their competitor is good enough and has momentum and mind share. It sounds like Dart now has Flutter and I think that’s going to be a huge deal moving forward.
> A language by itself is almost never useful, every language needs a killer app,

I don't understand why this myth is still around.

C++ never had a killer app to start its momentum.

Neither did Javascript. Nor Java really (or maybe applets, back in the days?).

Languages can succeed on technical merits alone if they come out at the right time and fix real problems that programmers experience on current mainstream languages.

I think you need at least one of three things to get a new language off the ground:

1. Extreme compatibility with the current entrenched language so you can incrementally migrate. C++ from C. CoffeeScript and TypeScript from JavaScript. Kotlin from Java.

2. A killer app (well, framework). Rails for Ruby. WinForms for C#. Applets and J2EE for Java (later Android).

3. A new platform where you must use the language to target it. C for UNIX. Objective-C for iOS. JavaScript for the browser.

There are a few exceptions here and there, but the above are the typical well-trod paths to success for a language.

I listed two clear counter examples to claim #2, C++ and Javascript. I'm even tempted to put C in that list, because C was already popular before Linux.

What was Python's killer app?

What is Rust's killer app?

Go's?

Kotlin's?

Java is a counter example to your claim #3 since it not only does it run on all OS'es but you can also develop it on all OS'es.

> C++ never had a killer app to start its momentum.

C++ was immediately adopted by all major C compiler vendors as it came from AT&T as well.

Microsoft C/C++ 7.0 for MS-DOS was the very last one to adopt C++ on the toolchain.

It was the lingua franca of all major desktop OS GUI frameworks, leaving C just for their lower layers, MS-DOS (Turbo Vision), OS/2 (C/Set++), Windows (OWL, VCL, MFC), Mac OS (PowerPlant, MacApp), BeOS, Symbian.

If you were doing plain C GUI programming you were doing it wrong.

> Neither did Javascript.

JavaScript owns the browser, there is hardly any other alternative regarding "browser systems programming".

> or Java really (or maybe applets, back in the days?).

Java's portability was a gift compared with C compilers still in the middle of migrating from K&R C to ANSI C, C++ compilers which were silos with their GUI frameworks and a standard still a couple of years away to be fully defined.

These days it's mostly about apps, because apps are the main thing that facilitate the transfer of $$$. In the 80s and 90s, enterprises were full of $$$ and needed fast and safe languages for writing all their software. C++ came out to solve this need, and Java came out saying it could do it better. Today enterprises are moving many of their internal tools to the web. Enterprises don't need apps per se, but they do need the tech needed to build internal apps and apps to bridge between them and their partners. Consumers are using desktops less, and mobile or web more. Apps are basically the current de facto software "product". But a lot more goes into making apps today than 30 years ago. An example is how most apps need ML for spam protection and recommendation algorithms, or they are instantly going to be considered outdated and behind the times.
>In the 80s and 90s, enterprises were full of $$$

More than today?

Golang and Rust also didn't have any killer app.
Rust definitely has Firefox
Go has Docker
Go has a bit of a niche, and Rust is trying real hard, but they aren't Javascript or Java, or C#, or Python, or Rails, or PHP, or C++, or Objective-C or... Out in the wider world, they are very much playing catchup, and have a very far way to go.
Javascript had the web. And, Java had the JVM. A killer 'app' is not necessarily singular & discrete.
Off topic but... are there any plans to adapt Flutter for desktop apps?
I'm the lead dev on just such a project: https://feather-apps.com/
Looks great!

I beat the Reversi app on first try. I'm guessing it's not very strong. :)

Thanks :)

Haha yes I weakened the AI somewhat compared to the original version created by RedBrogdon. It's not fun to be constantly thrashed by an opponent who takes 0.2 seconds per move! Despite my changes I still lose about 3 out of every 4 games :(

There is an unofficial implementation for it.

https://github.com/google/flutter-desktop-embedding

I agree. In addition because Dart shared some superficial similarities with Java, some people just assumed it's Java and criticized the language for it. For example Dart variable declaration is of the form "String a" vs "var s:string" - the former syntax looks like Java so Dart must be Java. It certainly felt like people were willing to 'pile-on' criticism because they felt that JS ecosystem was threatened.

The language itself is very well designed and pleasurable to write code in.

I think your points about Dart being treated unfairly are legit. OTOH, Google certainly invited criticism - early Google efforts on the web were VERY "let's make JavaScript into Java", and as the JS community matured this attitude was viewed with less and less favor. I think it's notable that the community that DID end up having strong influence in the JS world (Node & npm) had much more of a Ruby background than Java.

None of which invalidates Dart, but I know I was less than excited when Dart was announced as it seemed more Browser Wars crap rather than an improvement. Nowadays I'm more inclined to hold Google's history of not supporting products consistently (or at all, in most cases) against Dart than anything about the language specifically,

>early Google efforts on the web were VERY "let's make JavaScript into Java"

That was never the case. Ever. Google was the first company to really take JavaScript seriously and launched the client-side JavaScript revolution with Maps and Gmail.

This criticism was leveled at Dart because as I argued, when Dart was launched some people (purposely) found certain parts of the syntax superficially resembled Java. It was also a time when front-end web devs haven't rediscovered the benefits of compile-time type checking (there was a time, believe it or not, when static typing was disparaged by frontend web-devs)

The irony is that Dart is a better language than JavaScript and the world would have benefitted had Dart become a browser standard (though Apple, Microsoft and Mozilla were never going to just accept a language designed by Google - so that was a pipe dream).

> Google was the first company to really take JavaScript seriously and launched the client-side JavaScript revolution with Maps and Gmail.

True! Google Maps was a revolutionary use of AJAX. However, that is totally orthogonal to if JS was being written like JS, or like something else.

> This criticism was leveled at Dart because as I argued

Except I wasn't leveling that criticism at Dart. I'm talking about Google efforts in general at the time. You can see it in GWT, you can see it in the first generally accepted JS styleguide (done by Google), and you can REALLY see it in the articles and efforts of Google at the time where person after person laboriously tried to make JS _behave_ like Java (so we're not talking syntax). The late 90s and early aughts were a battle between those that wanted to recreate Classical OOP in JS and those that wanted JS to be what it has ended up being.

I don't even KNOW Dart to criticize it about anything, but I knew what I was seeing from Google at the time and why I wasn't swayed that they were creating something that would be accepted by the community and other browser makers.

> (there was a time, believe it or not, when static typing was disparaged by frontend web-devs)

...and it continues to this day in many corners - the issue (generally) isn't static typing but instead the cost/benefit involved - are enough runtime errors prevented to cover the cost of me informing a type system. There's a reason JS has spread so far - the time cost of static languages is just as real as the runtime risks of dynamic, and pretending that this equation should always favor proven correctness just results in more work being done in the dynamic camps.

> There's a reason JS has spread so far

The large number of people who had to know it because of its status as the only reliably-available cross-browser web client language, and the focus engines got because of its web client role, mostly.

>I'm talking about Google efforts in general at the time.

Ok, but just to be clear, at no point did Google actually try to replace JavaScript with Java.

>You can see it in GWT

Oh come on. GWT was transpilation tool with a built-in component framework. It solved a real problem for specific use-cases and was primarily adopted by enterprise developers. It was never a replacement for JavaScript.

>and you can REALLY see it in the articles and efforts of Google at the time where person after person laboriously tried to make JS _behave_ like Java

Can you provide an example of this? I have no idea what you're referring to.

>The late 90s and early aughts were a battle between those that wanted to recreate Classical OOP in JS and those that wanted JS to be what it has ended up being.

And Google was a non-factor in the development of the web technologies and standards in the late 90s and early 00s (Chrome wasn't released until 2008. Ajaxy Gmail was released in 2004). Also, nobody gave a crap about JavaScript in the 90s and early 00s (Crockford's JS:The Good Parts wasn't released until 2008). Maybe you're thinking of the development of ActionScript 3.0 which had OO constructs and was supposed to be a replacement for JavaScript before (I believe) Microsoft balked and left Adobe hanging. Which is a shame because AS3 is also superior to ECMAScript 5 and world would have been better with AS3 in the browser (and don't get me wrong, AS3 is very quirky language).

But regardless, the whole "Google is trying to replace JavaScript with Java" was pure paranoia not grounded in fact.

> the issue (generally) isn't static typing but instead the cost/benefit involved

You can build in optional typing if you really want to (AS3 had that). Having said that, I cannot see what time you lose by enforcing type constraints. And dynamic languages are not faster or more productive. At best it's a no-op. At worst you're dealing with runtime errors which are 100x painful and costly than dealing with a compile-time error.

>There's a reason JS has spread so far

It's the lingua franca of the web because it's the only language supported by major browsers. That's why it spread so far, not because it is a great language. In fact, the plethora of transpilation tools should give you a clue how shitty this language is.

It's more than superficial, I struggle to see how using Dart would be at all different from how you would architect an app in Java. It's an OO language with an almost identical set of type system features besides the fact that it has inference. It's not as if it borrows much from the ML lineage; I don't see any examples of pattern matching and currying in the Dart docs. It's all class based polymorphism.
> I struggle to see how using Dart would be at all different from how you would architect an app in Java.

It's not really an architectural difference, I'd agree (outside of isolates vs. threads): Dart is mostly about ergonomics compared to other class-based OO languages. Unification of class, interface, and mixin; method cascades for “free” fluent interfaces; the syntactic support for sync and async generators along with async/await, really transparent (binary, not just source-level like C#) getters and setters; named and factory constructors; the whole deep consideration of const-ness, etc., are all ergonomic features, not major changes in architecture / paradigm.

So to you OO means Java?
> I think mostly because they were bit too hard by IE doing the exact same thing just a few years before.

It's pretty simple, in my view: JS developers were happy with the language and didn't want a browser vendor trying to replace it. Remember that it was announced around the time that the new ES6 ("Harmony") features were generating a lot of excitement about the future of JS.

I think Dart started internal development around the same time CoffeeScript gained major popularity and brought attention to JS's desperate need to evolve, but they released at a bad time: when JS finally did start to evolve (as Harmony) which was a reaction to CoffeeScript in the first place. So CoffeeScript served its purpose of pushing JS forward, and most other compile-to-JS languages had no more purpose. I say most because some serve a different purpose than just being a slightly nicer JS, like how Elm piggy-backs on the familiarity of Haskell and provides a niche no-mutation environment, and TypeScript adds type-checking for those of us who can't write code as confidently without it. But the rest served their purpose, and Dart's dream of having its own VM inside Chrome was probably what killed it so quickly.
If Google had paved some cowpaths:

- CoffeeScript was hugely popular at the time - it was even mandatory at GitHub to make new applications in CS not JS

- Typescript was immediately well recieved. JS folk liked optional typing.

- Ruby was popular amongst the web community

Google would have done a lot better than making a new road and wondering why there's nobody on it.

> - CoffeeScript was hugely popular at the time - it was even mandatory at GitHub to make new applications in CS not JS

We'd probably really be regretting that choice since CoffeeScript use is dwindling and the programmer ecosystem has generally turned towards static types.

> - Typescript was immediately well recieved. JS folk liked optional typing.

Dart was an optionally typed language and is actually older than TypeScript.

But, the original creators were very focused on getting a native Dart VM in browsers and were willing to sacrifice seamless JS interop to get that. There's good arguments for that since great interop often means adding ugly features to your language in order to play nice with the existing one. Dart was intended to be a bigger leap forward from JS.

If the VM wasn't part of the plan, then Dart probably would have hewed much closer to JS and been very similar to TypeScript. That probably would have been good for us then, but it might have been a limitation long-term. TypeScript is a really nice language, but it's got a lot of baggage that it inherits from JS.

Dart is, I think, a much nicer language if you don't need to reuse and interop with a big corpus of existing JS code.

> - Ruby was popular amongst the web community

Is the "was" part of that intentional? I like Ruby a lot, but it's luster seems to have faded some in the past couple of years.

I think what all of your points show is that if you pave cowpaths when doing language work, you end up optimizing for what users did several years ago. Languages take a long time to develop, so I think you have to aim for where you think users will be, otherwise you end up irrelevant by the time you launch.

> We'd probably really be regretting that choice since CoffeeScript use is dwindling

BecauseJS eventually got better and everyone moved to new versions and Babel. If you'd offered an alternative, maybe they would have moved to that.

> Dart was an optionally typed language and is actually older than TypeScript.

OK.

> Is the "was" part of that intentional?

Yep, a lot of Ruby folk moved to node, now they're in Elixir or Go.

> I think you have to aim for where you think users will be, otherwise you end up irrelevant by the time you launch.

I totally agree, but I think those cowpaths give you a good idea of where the ball is moving, particularly syntactically. And it doesn't seem like Dart paid any attention to that signal at all.

Lars (and company) approach to implement a Dart VM in Chrome was just ahead of its time. WASM is an attempt to accomplish a similar goal and implement a common VM. Perhaps, in the near future, Dart can be a syntax to compile to WASM and accomplish Lars' intentions.
Don't forget Clojurescript which heavily influenced the development of React. Clojure is unique in the landscape of modern programming languages.
What I don’t understand is why people are excited about the new features of JavaScript. The problem with JavaScript has never been that it doesn’t have enough features or syntactic sugar. The problem with JavaScript is that it has a rotten, unsafe core. Its very nature is antithetical to writing robust software, yet we need it to create dynamic UI applications.
I’m not convinced Javascript boils down to anything worse than other dynamically-typed languages.

Except it has features other langs don’t like async/await and async-everything.

This is why many people including myself use Javascript even on the server. For example, I’d consider Python a downgrade.

I point this out because it seems to be news to you that many people find Javascript pleasant and disdain for its “unsafe core”, whatever that means, extremely oversold.

> What I don’t understand is why people are excited about the new features of JavaScript.

They're excited because new features are useful to lots of people.

> I think what killed Dart is that they emphasized their plans to make Dart a first-class scripting language of Chrome, so that you could use <script type="text/dart"> instead of JavaScript.

Funny, that's what I saw as the core attraction. The fact that they never pushed for adoption in other browsers and fell back on transpilation removed the benefit you'd get from an alternative scripting environment.

Thankfully, we now have web assembly.

For me it was that google had burned all their credibility with me on GWT. I’m not taking any more career risks on their projects. Too much corporate ADD over there.
Flutter is probably the last attempt to get some Dart popularity.

When Dart came out, Google build it to improve on JavaScript, by replacing it with a whole new language. Microsoft built TypeScript to integrate with JavaScript. I thought, "MS, right? Cobbling together some JS add-on, who will use that? Better get a whole now language that doesn't carry around that baggage from JS :D"

I think Dart brought not enough new/better on the table, while having a worse JavaScript-interop than TypeScript. I mean it doesn't even have non-nullable types, which seems to be a standard feature in modern type-systems (Rust, Flow, TypeScript, Reason, etc.)

My feeling is, some people will hype it a bit, because Flutter has a better architecture than alternatives like React-Native, but with projects like Fabric and Reason, nobody will care about it in a few years.

But well, I also was wrong with my TypeScript prediction :D

Fabric and reason have a native render target that doesn't involve browsers or wrapping some other UI library?
Fabric is the effort to make RN more competitive.

And Reason is just another syntax for OCaml, so it can compile to everything OCaml can, that includes "native".

I was a backend/cli developer for Dart, most of us were ignored when we asked for support in helping build out the Node.js aspect of Dart. So many left. I still maintain my few libraries but I lost of a lot of interest when they went full throttle on frontend only until it failed.

I hope Flutter restores some popularity. If it does, those libraries will start getting updated.

AngularDart is a hard fork. You shouldn't compare version numbers with original Angular since they are independent projects now.
I wasn't aware of this , thanks for the info.

Nonetheless , the API seem to be behind the original. Hence interop with JavaScript seems incredibly messy and time consuming.

Even the APIs are not necessarily related anymore. AngularDart is an entirely independent project in every way. I'm a long-time AngularDart dev, and the JS interop thing isn't as important as you'd think. For one thing, it's actually not that hard to do, and for another, you don't need to very often at all, since Dart covers so much of what external JS packages do.
Well, google itself calls it now 'a client-optimized language' and product manager of Dart is also a product manager of Flutter at the same time, brought in from Microsoft. Tells you everything you need to know where they're aiming - where React (Native) is. The farm is bet on Flutter's success now, it seems.
It just doesn't provide enough value over Flow or TypeScript for most people. I'd love to use Flutter, but the tools I want to build I need to be desktop apps. Not everybody is focused on the app store gold rush.
With Google’s history of abandoning efforts like this, I wouldn’t spend too much effort using any language developed by them.
> With Google’s history of abandoning efforts like this, I wouldn’t spend too much effort using any language developed by them.

Well , to be fair Go is becoming a major server side language and I don't see Google abandoning it any time soon.

That being said , Dart is basically on "life support" has of now , there is no SDK what so ever beside Google + Firebase , and I haven't heard anything from AWS / Azure or others vendors to support Dart + Flutter.

I feel like everyone is basically waiting for the language to take off to actually invest in it.

I'm afraid it will end up like Xamarin , a niche tech that will eventually die out because very little people accept the ecosystem that is forced on them by using the framework.

Xamarin is not dead and being actively developed. It just doesn't intersect with the startup scene because of its enterprise roots.
You don’t need more AWS support really. You can use any language that technology that AWS supports as the backend for a flutter app.
Not if you want to use Lambda. You could write your own wrapper for the AWS API's for other use cases, but you could also repeatedly hit your head with a hammer.
I wouldn’t focus my medium term career prospects on Xamarin, but if I could quickly ramp up and do mobile development using it, I would.
From what I understand, AdWords is written in Dart. This alone means it's not disappearing anytime soon.
And the server component of iTunes and the App Store is written in WebObjects.....
WebObjects isn't open source, Dart is.
How has the open source nature of Dart helped so far?

Open source is not a panacea for a project that’s not popular and doesn’t have an active vibrant community around it.

Although it's not a guarantee that it'll stick around, the fact that it's open source greatly increases the probability.

GWT is actually still very much alive even though Google abandoned it years ago.

Adwords frontend was completely rewritten in Dart. It's not going anywhere anytime soon.
Did you stop to think that the reason you like dart so much is that you're coming from javascript?

JS is not a real language, coming from python.