6 ms·

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

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.

err4nt 3y ago
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.
- cogman10 3y ago
  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.
  - err4nt 3y ago
    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?
    - no_wizard 3y ago
      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
      - refulgentis 3y ago
        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
        cogman10 3y ago
        > 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.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP...
jmull 3y ago
It's hard to see how that would have worked. 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.
- no_wizard 3y ago
  I realize why it failed (everything you just iterated, plus WASM was around the corner in earnest) 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
- throwaway894345 3y ago
  WASM isn't the same as Dart in the browser because "Dart in the browser" means the Dart VM and standard library are already compiled and installed on your browser while WASM means the VM and standard library must be shipped from a server to your browser and compiled before the program can run.
  - jmull 3y ago
    Well, you're trading one problem -- apps need to include their own dependencies -- with a more thorny problem: everyone has to somehow have already installed your app's dependencies. Of course, they don't, so you bundle your dependencies anyway, as polyfills or otherwise, and transpile, etc.
- 3y ago
afavour 3y ago
I work with JS every day and am somewhat ambivalent about it but I absolutely do not want to see a language controlled by one vendor (in this case Google) to become a browser standard. It would be like the JS equivalent of Google trying to get everyone to make AMP pages instead of regular HTML. 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.
- lern_too_spel 3y ago
  JavaScript was controlled by Mozilla. Standardization into ECMAScript only came later after pressure from Microsoft and a mostly compatible reimplementation called JScript. Dart is also an ECMA standard, though only Google contributes because nobody else cares about it. AMP was far less controlled by Google in practice when it was relevant. https://github.com/ampproject/meta-tsc/commit/4f18f83794ed251bea7dcf8459bef9ad9bae65dd https://github.com/ampproject/meta-tsc/commit/4f18f83794ed25... 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.
munificent 3y ago
I work on Dart and I'm honestly glad that didn't happen. It would have frozen the language in time and features like the better type system in Dart 2.0 and sound null safety in 2.12 would have been unlikely to happen.
- deleted 3y ago
  [deleted]

err4nt 3y ago

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.

cogman10 3y ago
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.
- err4nt 3y ago
  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?
  - no_wizard 3y ago
    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
    - refulgentis 3y ago
      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
      - cogman10 3y ago
        > 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.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP...

jmull 3y ago

It's hard to see how that would have worked. 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.

no_wizard 3y ago
I realize why it failed (everything you just iterated, plus WASM was around the corner in earnest) 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
throwaway894345 3y ago
WASM isn't the same as Dart in the browser because "Dart in the browser" means the Dart VM and standard library are already compiled and installed on your browser while WASM means the VM and standard library must be shipped from a server to your browser and compiled before the program can run.
- jmull 3y ago
  Well, you're trading one problem -- apps need to include their own dependencies -- with a more thorny problem: everyone has to somehow have already installed your app's dependencies. Of course, they don't, so you bundle your dependencies anyway, as polyfills or otherwise, and transpile, etc.
3y ago

afavour 3y ago

I work with JS every day and am somewhat ambivalent about it but I absolutely do not want to see a language controlled by one vendor (in this case Google) to become a browser standard. It would be like the JS equivalent of Google trying to get everyone to make AMP pages instead of regular HTML. 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.

lern_too_spel 3y ago
JavaScript was controlled by Mozilla. Standardization into ECMAScript only came later after pressure from Microsoft and a mostly compatible reimplementation called JScript. Dart is also an ECMA standard, though only Google contributes because nobody else cares about it. AMP was far less controlled by Google in practice when it was relevant. https://github.com/ampproject/meta-tsc/commit/4f18f83794ed251bea7dcf8459bef9ad9bae65dd https://github.com/ampproject/meta-tsc/commit/4f18f83794ed25... 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.

munificent 3y ago

I work on Dart and I'm honestly glad that didn't happen. It would have frozen the language in time and features like the better type system in Dart 2.0 and sound null safety in 2.12 would have been unlikely to happen.

deleted 3y ago
[deleted]