The one fork of history I wish I could have seen come to fruition was Dart in the browser (natively) as was originally proposed. I'm very curious to see how web development would have evolved if that had come to pass.
Google can put anything it wants in Chrome, but why would Safari or Firefox have done this? I don't see how they even could from a practical perspective, since they'd each either have to maintain a separate implementation (you really find out how good your specification is only once it needs to support multiple independent implementations) or import the Google one wholesale. Rinse and repeat every time Google changes Dart.
If Google puts it in Chrome and pushes it, most likely it simply dies there. But perhaps it catches on, furthering the reality that Chrome (and therefore Google) is the web. That's the worst case scenario for everyone (except Google, of course).
Anyway, WASM is here, and doesn't have these drawbacks, so we're all free to enjoy using Dart in the browser, if we want to (to the extent they support it). Not to mention Javascript is in quite a different place than it was when the idea of native Dart in the browser came up.
Simply as a thought exercise though, it would have been interesting to see a world where Dart did produce a specification and other browser vendors saw value in implementing and maintaining with it, is all.
Its a great language with a lot of good features
As it is there are two simple answers for Dart anyway: it transpiles to JS and WebAssembly offers the possibility to use it 'natively' too.
JavaScript is an awful language, with many warts that are impossible to fix while maintaining backwards compatibility, but as one of your sibling commenters mentioned, the original Dart had problems too.
Javascript is a hard language to optimize and the current javascript engines have gone to heroic efforts to get there. Dart took what made javascript hard to optimize and removed it (mostly removing dynamism around types, you can't just add/remove random fields and functions to an object).
Dart was (at least initially) designed by some of the engineers behind V8 specifically for the purpose of "let's make something that can be fast without a 10 MLoC super JIT".
The other nice thing about dart is it was entirely boring. If you know Java/C# you know Dart. There weren't a whole lot of weird surprises around what "this" is, how `var` scoping works, or wrapping your mind around prototype inheritance. It was just pretty plain OO programming.
That "boring" nature of dart makes it easy to maintain and to write nice IDEs around.
Even today, Typescript has some neat things but by god do I hate it when devs make an uber complex macros impossible for my IDE to grok. (littering the code with red squiggles). All because they've done a bit too much Haskell. When the type signature spans multiple lines because "any" was too lose, but they did want to support anything which could be turned into a string, was undefined, could be null, could be a number, and also stuff that has a method `foo` that can be invoked on easter.
Is there any advantage to writing in Dart and transpiling that to JavaScript?
Their JS pipeline is really lacking as a result
The major problem is...you can't use an Isolate on web, put more simply, everything** is on the main thread unless you go to extremes of segmenting out the code you want on another thread, compile that to JS separately, then call into it from a web worker in JS that you invoke from Dart. I'm told web devs comfy with JS don't see this as a huge deal but for me with a mobile-only background, it's convoluted and fragile
They have a preview of compiling to WASM working, web apps already feel _slick_ but apparently they're seeing a 3x speedup. I don't know enough to know if this fixes the problem above, but I would put money JS staying as is and WASM will be the web story moving forward
* if i read grandparent as "what's the quality of a Dart web app?"
** there's caveats here, ex. I'm 90% sure things like network loads and image loads arent literally on the main thread, i.e. the browser implementation of the APIs flutter calls into is non-blocking. It doesn't really matter though, unless your app is so simple you either don't have custom operations that run long enough to cause significant frame drops
Ditto.
WASM needs just 1 piece to be pretty much widely generalizable, GC. Once that happens, things will get pretty exciting. Access to a platform garbage collector will allow pretty much any language imaginable ship to WASM with some pretty minimal runtime overhead.
And GC for WASM is due to hit pretty soon. I'm looking forward to the revival of Applets :D
[1] https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP...
Dart was the best. Java without the Enterprise JavaBeans Injection Factory Factory. Swift without the ObjC compat baggage and fundamental design flaws like the typechecker that can infinite loop and regularly takes 200 ms for methods. Kotlin without the slapdash IDE developer side-project language stuff, "here's 20 kinds of syntactic sugar and 10 methods that do the same thing. Use your favorite sugar/naming convention for convenience"
The only ones I genuinely feared were TS and C++, C++ because a deep respect and fear of manual memory management. TS was just...weird, lot of half-baked stuff.
I was having a true TS engineer do code reviews, and they had what should have been minor bike-shedding about constructor formatting. That broke parameter doc comments displaying on hover. All I could find was people pointing this out without answers, and TS reviewer was kinda busy, gave me stock answers and didn't grok there was a genuine issue.
A week later, I finally found an issue explaining some long convoluted thing that made it impossible.
C++ sort of suffers a similar problem though thankfully it's gotten way better (probably because it's old and not super appealing for less experienced devs). There's also healthy fear in C++ because, like you point out, misuse can lead to hard to find security holes.
And I'm someone that prefers a more feature rich language in general. But I want that to mostly write boring code with the "neat" escape hatches to help when it makes things clearer.