Hacker News new | past | comments | ask | show | jobs | submit login

As someone inexperienced with Dart, but ever curious about it - is there anything more you can share about that, or what might have been? I end up writing almost all my work in browser-based JavaScript so I'm curious how different my work might have been.



Had it actually succeeded and become the defacto UI language, it has a lot of nice properties that make it well suited for optimizations.

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.


I had the privilege of maintaining a 6 language cross-platform library for a while and man does the Typescript stuff ring true.

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.


Yeah... TS is just a bit weird. Seems like the language design decisions have generally been "Why not" and not "how does this improve things?" That's lead to a really complex language ripe for abuse.

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.


Thanks, that makes a ton of sense, smaller/better by design but equipped to handle the same kinds of problems that JavaScript does.

Is there any advantage to writing in Dart and transpiling that to JavaScript?


They ended up pivoting to focusing mainly on mobile. At this point Flutter is the reason people use Dart, more or less.

Their JS pipeline is really lacking as a result


It's damn good* as is, but there's one major problem, and a fork in the road where it looks like they'll focus on WASM moving forward.

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


> I would put money JS staying as is and WASM will be the web story moving forward

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...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: