Comment by munificent | Hacker News Reader

Comment by munificent | Hacker News Reader

Parent Full thread

> How does it know that something can never be null?

It can see every place it gets assigned. If it's never assigned from something that can be null, it can't be null. Of course, that requires global inference to determine the possible types that the RHS can be. dart2js does that with increasing sophistication.

> Maybe an external caller sends null to a method not expecting it.

dart2js is a whole program compiler so it can make closed world assumptions like this. At the point that it's compiling, there are no "external" callers. It can see every callsite in the entire program.

> Or, can you not call Dart compiled code from JS?

Yes, Dart does have a JS interop story[1]. We're still working on it, but, by design, it's not as seamless as say CoffeeScript. It's an actual interop process and not just "it's all JS so it can all call each other". I think that helps dart2js control the places where unknown values can leak in from JS.

[1]: http://www.dartlang.org/articles/js-dart-interop/

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.

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.

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.

[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-secu...

> 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.

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.

When using dart2js, you can split a program into multiple chunks, and load them separately[1]. But you need to set this up before compiling, so that's not useful for sharing a library on a CDN.

I think people often use javascript libs on a CDN because they don't want to go to the hassle of setting up a javascript package management system, or figure out which file to download and where to put it. It's not all about load time savings.

Dart's minification, combined with pub, the package management system, make the CDN usecase irrelevant for dart IMHO. A business can just ship their library on pub, and it's easy for people to use because of Dart's out-of-the-box tools.

[1] http://api.dartlang.org/docs/releases/latest/dart_async/Defe...

Reply on news.ycombinator.com