3 ms·

Is this a limitation of Dart in general, or just the Dart2JS framework? Doing whole-program analysis seems like it would restrict your deployment methods, righ

by lmkg 14y ago

Is this a limitation of Dart in general, or just the Dart2JS framework? Doing whole-program analysis seems like it would restrict your deployment methods, right? It's fairly common in the JS world to be calling into libraries that are split into separate files and hosted on external servers. Something like jQuery you do it for the load times, something like Google Analytics you do it so that Google can push updates without you needing to redeploy your script. There are also possible use cases with lazy-loading libraries for load times, or only loading scripts on certain pages. Does the whole-program compiling approach mean that I would have to import whole libraries into my own project in order to use them, and that I can only deploy single script files? How does the whole-program approach interact with event handlers embedded in HTML, which it would not have visibility into? I would expect that some of these restrictions could maybe be eased in a native-Dart client. But given that for the foreseeable future most Dart projects will have to target non-Dart-enabled clients, in practical terms Dart as a whole will have to be shackled to any limitations in Dart2JS. I'm curious what your thoughts on this are and if you have any plans to address it.

floitsch 14y ago
This is a property of dart2js. (I wouldn't call it a limitation nor a feature). Dart2js takes your whole program and compiles it to JavaScript. Dart2js needs to see all the libraries that are used. It performs tree-shaking to remove unused parts and then compiles the rest to JavaScript. By default dart2js produces one big JavaScript file, but it can cut your program on library boundaries that can be loaded lazily. This is still work in progress (only allows to split into 2 files so far) but looks promising. The lazy loading needs to be done by the user before parts of the lazy library are used. I don't see how event-handlers change the game. The html-library is a library like any other.
- lnanek2 14y ago
  There are a lot JS frameworks nowadays where there is no HTML, really, just a little something to trigger the script. Everything else is JavaScript generated and inserted HTML. I don't see how this could handle something like a new anchor being added with an javascript: href, or even just the eval command, for example. Doesn't seem smart to break JS compatibility like this if the language wants to win any mind share.
  - sethladd 14y ago
    [disclaimer, I work on the Dart team] While I do believe our Dart/JavaScript interop story will continue to be refined, I do want to point out that the days of javascript: URLs and eval are nearly over. The Web is getting a stronger security model through CSP [1] (content security policy). New restrictions put in place by CSP include turning off eval, new Function, inline JavaScript, and more. This is a very good thing, because it reduces the attack vectors for XSS and more. [1] http://www.html5rocks.com/en/tutorials/security/content-security-policy/ http://www.html5rocks.com/en/tutorials/security/content-secu...
munificent 14y ago
> It's fairly common in the JS world to be calling into libraries that are split into separate files and hosted on external servers. Sometimes, but I think it's actually more common to do the opposite: minimize the delay by concatenating and minified all of your JS files into one big blog. That way there's only one network roundtrip. dart2js follows that path. > something like Google Analytics you do it so that Google can push updates without you needing to redeploy your script For stuff like this where you just have multiple completely independent scripts, you can just have separate <script> tags. > How does the whole-program approach interact with event handlers embedded in HTML, which it would not have visibility into? We actually do have visibility there. Dart has its own DOM library and dart2js has pretty deep insight into how to interact with the DOM.
- lmkg 14y ago
  Thanks to you and floitsch for answering. My concerns have been allayed about the DOM, and cutting up a program into components. I don't want to focus overmuch on the specifics of the Google Analytics example, but it's illustrative so I'll continue. While GA can be isolated, if you want it to track any events that involve your script code, they need to call out to the API that GA loads onto the page. Its their intention that they can push code updates to my page (which may change how it communicates to GA servers), without me needing to redeploy my own code. The analytics world is now proliferating with a number of script-loader services that serve the same purpose: update tracking (including interacting with other parts of the page), without integrating into the deploy process. There are plenty of arguments that this is a Bad Thing, but nonetheless enough people are willing to pay for this service to keep afloat multiple companies where that is their only product. It's totally possible to load scripts like that in via the JS FFI, especially ones with a well-defined API. But, if both parts are separately Dart, it would be nice if they could integrate more easily than round-tripping through JS. Among other things, it would be nice to have the type information carry through. So that's where I'm coming from, and the use cases I'm interested in. And if you say that those development practices are something you don't want to encourage I wouldn't entirely disagree. It does seem like something rather different than the approach your taking, and the best way to reconcile it would be for library authors to publish a header file for functions/types that Dart2JS could assume to exist. Dunno if that's a route you would want to go.

by lmkg 14y ago

floitsch 14y ago

This is a property of dart2js. (I wouldn't call it a limitation nor a feature). Dart2js takes your whole program and compiles it to JavaScript. Dart2js needs to see all the libraries that are used. It performs tree-shaking to remove unused parts and then compiles the rest to JavaScript. By default dart2js produces one big JavaScript file, but it can cut your program on library boundaries that can be loaded lazily. This is still work in progress (only allows to split into 2 files so far) but looks promising. The lazy loading needs to be done by the user before parts of the lazy library are used. I don't see how event-handlers change the game. The html-library is a library like any other.

lnanek2 14y ago
There are a lot JS frameworks nowadays where there is no HTML, really, just a little something to trigger the script. Everything else is JavaScript generated and inserted HTML. I don't see how this could handle something like a new anchor being added with an javascript: href, or even just the eval command, for example. Doesn't seem smart to break JS compatibility like this if the language wants to win any mind share.
- sethladd 14y ago
  [disclaimer, I work on the Dart team] While I do believe our Dart/JavaScript interop story will continue to be refined, I do want to point out that the days of javascript: URLs and eval are nearly over. The Web is getting a stronger security model through CSP [1] (content security policy). New restrictions put in place by CSP include turning off eval, new Function, inline JavaScript, and more. This is a very good thing, because it reduces the attack vectors for XSS and more. [1] http://www.html5rocks.com/en/tutorials/security/content-security-policy/ http://www.html5rocks.com/en/tutorials/security/content-secu...

munificent 14y ago

> It's fairly common in the JS world to be calling into libraries that are split into separate files and hosted on external servers. Sometimes, but I think it's actually more common to do the opposite: minimize the delay by concatenating and minified all of your JS files into one big blog. That way there's only one network roundtrip. dart2js follows that path. > something like Google Analytics you do it so that Google can push updates without you needing to redeploy your script For stuff like this where you just have multiple completely independent scripts, you can just have separate <script> tags. > How does the whole-program approach interact with event handlers embedded in HTML, which it would not have visibility into? We actually do have visibility there. Dart has its own DOM library and dart2js has pretty deep insight into how to interact with the DOM.

lmkg 14y ago
Thanks to you and floitsch for answering. My concerns have been allayed about the DOM, and cutting up a program into components. I don't want to focus overmuch on the specifics of the Google Analytics example, but it's illustrative so I'll continue. While GA can be isolated, if you want it to track any events that involve your script code, they need to call out to the API that GA loads onto the page. Its their intention that they can push code updates to my page (which may change how it communicates to GA servers), without me needing to redeploy my own code. The analytics world is now proliferating with a number of script-loader services that serve the same purpose: update tracking (including interacting with other parts of the page), without integrating into the deploy process. There are plenty of arguments that this is a Bad Thing, but nonetheless enough people are willing to pay for this service to keep afloat multiple companies where that is their only product. It's totally possible to load scripts like that in via the JS FFI, especially ones with a well-defined API. But, if both parts are separately Dart, it would be nice if they could integrate more easily than round-tripping through JS. Among other things, it would be nice to have the type information carry through. So that's where I'm coming from, and the use cases I'm interested in. And if you say that those development practices are something you don't want to encourage I wouldn't entirely disagree. It does seem like something rather different than the approach your taking, and the best way to reconcile it would be for library authors to publish a header file for functions/types that Dart2JS could assume to exist. Dunno if that's a route you would want to go.