Closed vsmenon closed 1 year ago
fyi - @nshahan - if we go this route, we could stop packaging all dart_sdk.js
.
This may also be the cleanest way to facilitate the Flutter Web team's req for fast iteration on dart:ui
.
If we remove the "Potentially" qualifier for the "fast iteration / hot reload on dart:* packages" feature, then the Flutter team could get behind this request. We currently need to jump through hoops to get a reasonable dev environment for the Web engine.
I don't believe there is any known issue that would prevent exactly the same fast iteration (and even hot restart) behavior as you get when developing packages. I think @vsmenon was just being conservative with the "Potentially" wording given we don't even have a proof of concept at this time.
If we couldn't enable those things, we almost certainly would not do this. The only motivation at that point would be download size of the sdk.
Additional one-time startup cost to compile the SDK.
This would be once per "clean build" - so it would happen on every pub upgrade
as well as SDK upgrades.
Technically it only happens on pub upgrade
if a package imported by the build changes, but that is pretty likely to happen :).
"Potentially" removed from initial post. We should focus on solutions that enable fast iteration.
fyi @sigmundch
Some notes:
core_patch.dart
, js_helper.dart
, etc) - not VM or DDC.So, we probably could switch this over to (or just add) DDC specific sources.
Pretty sure we do this now :)
We may want to consider building the Dart SDK (i.e., the JS files) from sources instead of using the prebuilt dart_sdk.js.
We already ship sources with the SDK (need to check for which backend - I suspect it's
dart2js
).Some advantages:
dart:*
packages.Disadvantages:
fyi - @jakemac53 - per earlier conversation.