Switch to using DDC for every compile

[vsmenon]

The two web compilers don't always give consistent results, and that can occasionally lead to confusion where DartPad prints different results for seemingly inscrutable reasons:

https://twitter.com/_vsmenon/status/1355943391675072513

The underlying dart2js issue for @timsneath 's example is: dart-lang/sdk#44818

[domesticmouse]

Yup, I think the correct answer to this confusion is #1714

[RedBrogdon]

I think #1714 is part of it. That's about aligning on a single SDK version, which is definitely a good idea. This is issue, though, is suggesting we align on a single compiler?

We've been using dart2js for non-Flutter Dart mostly because that's how it's always worked. We could, though, switch to dartdevc. The null-safe version of DartPad used that pipeline for a while, and it wasn't a huge pain to make the switch.

[vsmenon]

FYI @sigmundch @devoncarew

Aligning would make sense if it simplifies our life long term. Do we get benefit out of using dart2js for small examples?

[RedBrogdon]

I didn't notice much difference in speed when we were wiring everything through dartdevc on the null safety DartPad. I don't have a profiled result to back that up, though, so take it with a grain of salt.

The one noticeable difference would be that you're required to take the network hit and download the pre-compiled Dart SDK at least once to run pure Dart code. Anyone who was also using Flutter in DartPad would already have dealt with that, though.

[domesticmouse]

Fwiw, my vote is to go with ddc everywhere if it gives a more consistent experience for new developers

[sigmundch]

I don't have a strong leaning either way.

@devoncarew were there other reasons to pick dart2js earlier on that should be considered?

For example, was the performance of the generated code relevant (e.g. is dartpad sometimes used as a comparison against other languages)? Or the possibility of caching the compilation result as a single file?

In contrast, are there any thoughts or plans to expose Dart Devtools features in dart-pad, like the widget inspector or expression evaluation? If so, ddc would be a better fit.

FWIW, a CL fixing the original issue that triggered this conversation is underway :), but it is a good idea to use one or the other consistently to avoid surprises on other issues in the future.

[timsneath]

I have a recollection that browser compatibility was historically one of the driving forces here? That DDC was less tested on non-Chrome? But perhaps DartPad is proving that this isn't so much of an issue as we feared?

[sigmundch]

Ah, indeed, good point! We still see periodically reports of a DDC limitation in Safari. Could we use site analytics to determine how commonly dart-pad is used from Safari?

[devoncarew]

@devoncarew were there other reasons to pick dart2js earlier on that should be considered?

Yeah, the initial consideration was mostly related to download size of the compiled JS. The compiled dart2js output was on the order of hundreds of KB (250-300kb?) and the compiled DDC output was on the order of megabytes (5-6MB?).

[RedBrogdon]

Could we use site analytics to determine how commonly dart-pad is used from Safari?

It's a few percent, certainly enough that I wouldn't be comfortable telling those folks they were required to use another browser.

If DDC were a problem for our Safari users, though, I'd expect to see complaints about Flutter not working, which we aren't.