Skip to content

Dart apps can't load until dart.js is done loading, causes startup delay #18495

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sethladd opened this issue Apr 28, 2014 · 15 comments
Closed
Labels
closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug

Comments

@sethladd
Copy link
Contributor

Was looking at some real-life Dart apps. dart.js needs to be loaded and parsed and executed before the app itself can start to run. In some cases, this is a 90ms delay.

Can we do anything to speed up the initial load of Dart apps?

Some ideas:

* transformer to inject the JS file directly into the page

  • transformer to inject the contents of dart.js directly into the page (saves a fetch)

Thanks!


Attachment:
[Screenshot 2014-04-28 at 10.26.37 AM.png](https://storage.googleapis.com/google-code-attachments/dart/issue-18495/comment-0/Screenshot 2014-04-28 at 10.26.37 AM.png) (61.93 KB)

@sethladd
Copy link
Contributor Author

Not sure where to route. I initially suspect this is a deployment issue. Please help me re-route if Pub is not the right Area. Thanks!

@nex3
Copy link
Member

nex3 commented Apr 28, 2014

I think this is a good use for an external transformer, but I'd be uncomfortable automatically inlining script tags by default. Even if we could guarantee that the semantics were identical, there are tradeoff decisions between linking and inlining that I don't think we should make on behalf of our users.

@sethladd
Copy link
Contributor Author

Before I track this down, are there any existing ideas for handling dart.js, the script tags, and pub? Don't want to stomp on anything that might be in the works...

@nex3
Copy link
Member

nex3 commented Apr 28, 2014

You might want to look at issue #15808. No work has begun on it, but it contains some ideas about rewriting script tags.

@sethladd
Copy link
Contributor Author

Thanks!

@vsmenon
Copy link
Member

vsmenon commented Apr 28, 2014

For startup, the ideal is if the server detects whether the browser supports the Dart VM and serves up the right html file immediately: i.e., all occurrences of:

<script type="application/dart" src="foo.dart">

are replaced by

<script type="text/javascript" src="foo.dart.js">

server side for non-Dartium browsers.

@sethladd
Copy link
Contributor Author

That is ideal, but trying to think of a solution that doesn't require live server-side manipulation. That burden is too high for all developers, and we'd need to get the caching and Vary headers right. Definitely an option, though, for skilled developers.

@nex3
Copy link
Member

nex3 commented Apr 28, 2014

Barback doesn't support serving different files to different browsers, since that can't really be serialized to the filesystem. It could perform that replacement in release mode, though, since we expect most users won't want to support Dartium in production for now.

@vsmenon
Copy link
Member

vsmenon commented Apr 28, 2014

How about generating both:

foo.html (with the dart2js path inlined / optimized)

and a

foo-dartium.html (with the dartium path inlined / optimized)

@sethladd
Copy link
Contributor Author

But then something needs to redirect from one or the other. :) That redirect is another connection.

@DartBot
Copy link

DartBot commented Apr 29, 2014

This comment was originally written by @sethladd


I've been doing a little research. If we really want to keep the semantics of dart.js for deployed apps, and we want to improve startup time, it looks like we could do this:

* put the script tags before the CSS

  • move the script tags to the head
  • inline dart.js

See the two screenshots. The quicker of the two has this in the <head>:

<!DOCTYPE html><html><head>
    <meta charset="utf-8">
    <title>Pub transformer test</title>

    <script async type="application/dart" src="pub_transformer_test.dart"></script>
    <script data-pub-inline="packages/browser/dart.js">
(function() {
if (navigator.userAgent.indexOf('(Dart)') === -1) {
  var scripts = document.getElementsByTagName("script");
  var length = scripts.length;
  for (var i = 0; i < length; ++i) {
    if (scripts[i].type == "application/dart") {
      if (scripts[i].src && scripts[i].src != '') {
        var script = document.createElement('script');
        script.async = true;
        script.src = scripts[i].src.replace(/.dart(?=?|$)/, '.dart.js');
        var parent = scripts[i].parentNode;
        document.currentScript = script;
        parent.replaceChild(script, scripts[i]);
      }
    }
  }
}
})();
</script>

    <link rel="stylesheet" href="pub_transformer_test.css">
  </head>

BTW, some extra info here: http://molily.de/weblog/domcontentloaded

Also, not sure this is a pub issue. Probably an issue for the skeleton apps that we create.

@DartBot
Copy link

DartBot commented Apr 29, 2014

This comment was originally written by @sethladd


For testing:

Traditional way to deploy a Dart app. I added async:

https://dl.dropboxusercontent.com/u/316685/example/pub_transformer_test.html

New way, inlined, scripts at top:

https://dl.dropboxusercontent.com/u/316685/example_inline/pub_transformer_test.html

@sethladd
Copy link
Contributor Author

FYI here is a transformer that addresses this: http://pub.dartlang.org/packages/dart_to_js_script_rewriter

@sethladd
Copy link
Contributor Author

Doesn't look like pub itself will handle this, and there's now a transformer we can use.


Added NotPlanned label.

@DartBot
Copy link

DartBot commented Jun 5, 2015

This issue has been moved to dart-lang/pub#966.

@kevmoo kevmoo added type-enhancement A request for a change that isn't a bug and removed priority-unassigned labels Mar 1, 2016
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

5 participants