Hacker News Reader

To be fair, the first one you cited is for Chrome packaged apps, so I feel like it's a little different than special APIs exposed to normal web page javascript. It's the difference between saying "build apps for our browser, we give you powerful features" and "build web pages that only work in our browser."

Now, if you think it's bad that Chrome is trying to entice browser app developers with powerful feature sets, that seems like a related but different complaint.

It's possible I'm unclear on the scope of the Open Web movement. When it refers to web technologies, does it mean technologies employed in the service of presenting web pages (i.e. everything you can do with javascript, html, css, etc.), or any technologies that a browser serves as a platform for? Because the latter seems like a wider scope that encompasses more than just web pages.

It's not just this though, there are even more damaging cases of embrace extend extinguish going on right now like With PepperFlash for example.

There Chrome has broken video recording three times the past year by pushing untested code, it's not possible to permanently disable it and the last change actually requires users to click both the Flash allow box and the WebRTC allow box!

That's without even mentioning the bug that if a user doesn't notice the second allow and refreshes the page, like every user does, the Allow box is never shown again.

One wonders if users would even have Flash installed if it weren't sandboxed.

http://www.cvedetails.com/vulnerability-list/vendor_id-53/pr...

I think other folks covered this one, but yeah the difference here is that this expanded notification API is for Chrome apps, much like Mozilla has non-standards track APIs that are targeting Firefox OS apps. Chrome supports the W3C standard Notifications API: http://caniuse.com/#feat=notifications as well as edits the spec for it: https://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.h... This works today in Chrome, Firefox, Opera.

The permission model on packaged apps is completely different, and allows for APIs that have a lot more power (raw USB, TCP access) and as such, it's hard to find a way to expose them to the open web without permission bar overload. :/ I'd personally love to find a way to bring some of the powerful APIs that browsers are developing and exposing them to the web, but it seems like we're not there yet.

For Dart.. think of it as another compile-to-JS language that was designed for large app authoring & maintenance productivity. Its performance as compiled JS seems to be pretty good already so you can target all modern browsers with Dart apps already.

But, ultimately, I'm an open web kind of guy. My money's on APIs that the web shares and I see compatibility across the web as the characteristic that drives its power and reach. Chrome's working on a lot of APIs for the open web platform (see my links above) and is constantly working with other browser vendors to get feedback, buy-in, and identify the best APIs that the web can share.

It's worth noting that all of the APIs you mention in (1) are only available to Chrome packaged apps. These are essentially the .exe files of Chrome OS. They cannot be hosted on webpages (otherwise Google calls them hosted apps, and they can't access these APIs) and can only be distributed and accessed via the Chrome Web Store.

It's essentially not much different from Windows having Windows-specific APIs for downloadable programs. "Chrome Packaged Apps" are the downloadable programs of Chrome OS.

>Dart - obviously a way to create a two-tier web with Chrome being the only option for performance. (You can bet it will be incredibly difficult for other browsers to package/integrate the Dart VM easily).

Doesn't the same logic apply to Mozilla's asm.js?

asm.js was implemented very quickly, in about a month, and V8 is already implementing optimizations for it (though without "use asm").

It's not an optimization for asm.js if you ignore the "use asm". It's just javascript then.

Which is what asm.js is mostly. Subset of javascript.

No, it's an IR that happens to have an identical representation in JavaScript. But that clever hack gets muddy already with things like Math.imul. And it's going to diverge far more given the demand for e.g. threading, sync primitives, shared memory, and vectored operations. I honestly don't see how asm.js can be made into anything beyond its current demo state without major changes to the JavaScript language and APIs.

Those changes would benefit regular JavaScript as well, so it's not a divergence. Regular JavaScript developers are already asking for SIMD (and that's why Dart is implementing it, after all). They were asking for more predictable math operations, and Math.imul is good for that. Threading too. Changes made for asm.js lift all boats.

The parent comment said that asm.js was a subset of JavaScript. You said "no", but none of the things you said contradict that. asm.js is, right now, a subset of JavaScript. Which, of course, is its entire raison d'être.

My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode. It's a clever hack to use an equivalent subset of JavaScript as an IR (accepting a few polyfills). However, it's not exactly honest to frame it as "just JavaScript."

What really does worry me is the ugly things that will be necessary to make asm.js genuinely viable as a platform. Yes, some proposals will have general utility for JavaScript, but many will not. And some will be downright dangerous. For example, how are you going to address pthreads compatibility, which e.g. Epic is saying they need?

> My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode.

I'm afraid your statement really wasn't correct. asm.js is both syntactically and semantically JavaScript. OdinMonkey is a pure optimization; any observable divergence in behavior (other than timing, which of course all engines are allowed to do) is a bug that will be fixed. The fact that SpiderMonkey uses a prolog directive (not a keyword), which is also of course valid ECMAScript, to trigger a different kind of optimization does not change the fact that it is a valid implementation of JavaScript.

I'm sorry if I'm coming across negatively. It's not my intent. And please don't presume that my concerns about asm.js are in any way tied to projects that other people in Google/Chrome work on, or that I'm entirely supportive of them. That said, I am curious if you really are committing to to future versions of asm.js not using any divergent APIs or observable divergent behavior from JavaScript as used on the web?

Diverging from JS would require standardization, but it's too early to consider something like that. I don't know what our ultimate plan for threads will be or where asm.js will eventually end up; there are plenty more discussions to be had.

Thanks, that's a bit of helpful context. I appreciate that it's too early to say where exactly asm.js will go. I'm just afraid of private APIs or other divergence from JavaScript in order to mainstream asm.js. Sorry if that apprehension came across as overly negative.

I also want to add that the "it's just JS" thing is not somehow an argument of the shining nobility of asm.js. It's purely practical as what we believe is a viable approach to moving the web in the same direction that e.g. the PNaCl team has been trying to move it. I get so disheartened at these mud-flinging contests. Our companies want the same things for the web (and we <3 the PNaCl team and have friendly conversations with them!). We share the same goals. We just believe that asm.js is a more viable approach to getting the web there.

I'm pleased to hear that - my perception has been that Mozilla has been moving in a more isolated, NiH-ish direction of late (not just dart but e.g. h264 support in <video&rt;). Does this mean there's a chance of PNaCl support being added to firefox if it shows itself to be effective in practice?

Dart and PNaCl have been rejected by not only Mozilla but also upstream WebKit (Apple) and Microsoft. In other words, Google is the only proponent of these technologies. I have no idea how you could paint that as "isolated" or "NIH".

"use asm" is not a keyword. It can be ignored, as V8 does. This is possible because asm.js is JavaScript as defined by ECMA-262. It executes according to the semantics specified in that document.

I don't really want this to turn into a back-and-forth, but it's unfortunate that this has devolved into outright accusations of dishonesty.

Note that I framed it as "not exactly honest" rather than saying it's an overt lie. Because I don't consider it an overt lie, but it's hard not to read it as a bit equivocal to claim that asm.js as just JavaScript.

And really, I'm far more concerned with the future plans, particularly with regard to things like multi-threading APIs. I don't see how those can be incorporated in a way that supports asm.js as an easy target for existing code while not causing it to diverge from JavaScript as used in the browser.

Yes, threading is definitely the main challenge for asm.js. I'm not as pessimistic as you about it, though. :)

To be clear, I really do think those of you working on asm.js have the best of intentions and really want to make something that works for the Web. However, I expect that supporting existing codebases and commonly used APIs is going to mean compromises. They'll start small and polyfills will work well enough, but I just don't see how asm.js doesn't eventually diverge in significant ways from normal JavaScript, or end up introducing special purpose hacks. Maybe I'm wrong, but I don't see my position as unrealistic.

Could you please justify your claim that "it's not exactly honest to frame it as "just JavaScript."" ?

The fact is that asm.js runs and as of recently, does so performantly in Chrome which does even implement the aot optimisations in odinmonkey.

To my mind given the above fact it seems perfectly reasonable to make the assertion that asm.js is just javascript.

It's an IR that currently is compatible with JS, but that's not necessarily the case longterm. And I personally don't see how it can retain that property while adding some of the things the platform needs (e.g. thread support that works for existing codebases). I asked dherman this elsewhere in the thread, and it seems like diverging from JS hasn't been ruled out. https://news.ycombinator.com/item?id=6023902

So, my concern here is that asm.js will either be forced to diverge from JS to make it generally useful, or it will need to add APIs to JS that are not appropriate outside of asm.js. If it gets to that place, then I feel that the compromises necessary for asm.js were a waste, and it would have clearly been better to just introduce a new IR that wasn't bound by the constraints of asm.js.

asm.js is a subset of javascript. Nothing more. If you implement the optimisations without needing the "use asm" then you just have the same benefits for non asm tagged code -- and all the benefits of asm.

The "use asm" is totally optional functionality wise.

Did you actually want to say "OdinMonkey was implemented very quickly, in about a month"?

I am not sure I understand what people try to prove or imply when they say that.

OdinMonkey takes an extremely limited statically typed language with an almost non-existent runtime library as an input, checks the types and pipes fully typed IR further through the existing backend (IonMonkey). Does it come as a surprise to anyone that this can be implemented quickly?

Yes, I meant to say Odin, sorry. Thanks for the correction.

asm.js works on all standards compliant browsers.

Dart is a new language / VM and it's not standardized.

So the logic is definitely not the same.

> Dart - obviously a way to create a two-tier web with Chrome being the only option for performance.

The performance of the generated JavaScript is okay. Typically, it's somewhere around 75% of the performance of handwritten JavaScript and it's still getting better.

Those -25% may sound like a big deal, but it's comparable to the performance from JS engines from last year.

I'm pretty sure dart2js runs faster than Dartium. Dartium is just for reducing the time the edit/test cycle takes and from what I've read on the mailing list, not intended to be something that end-users will ever see. In that respect, Dart is exactly like CoffeeScript or the many other attempts to fix Javascript.

The Dart FAQ says:

Q. Is Dart going to divert community effort from JavaScript-based web development?

If people like Dart and use it, then to a certain extent, yes, but isn't this true of any improvement to existing web development? Nothing is zero-effort to learn or 100% back-compatible to legacy browsers, so people use both new and old. You might look at it this way: Google is putting significant effort behind both Dart and JavaScript, choosing to develop Dart while at the same time using JavaScript extensively, and working on JavaScript tools, implementation, and language spec. We're doing both because we think Dart is worth it.

Server-side web programming finds room for many languages: does Python divert effort from Perl, and does Java undercut C++? Again, to a certain extent, yes they do, but people generally consider that a healthy situation, better than if we all used a single programming language. Multiple languages have allowed for faster change than any single language has achieved through a standards process. Furthermore, languages coexist in different niches: does Groovy really compete directly with C++? People face different engineering tradeoffs and choose different languages to meet them. Ultimately, we think client-side developers should have this kind of flexibility.

Q. Is Google planning to put Dart under the control of a standards body?

Yes, we hope to. Once Dart reaches a certain level of maturity and acceptance, we expect that a standards process will be the next step.

As for the various APIs you describe above, those are all for packaged apps, which really have nothing to do with the web except that they happen to run inside Chrome. It's like complaining that iOS in-app purchases go through Apple, or that Gnome has Bluetooth support. (Or even that Firefox extensions don't work in Safari.)

>I'm pretty sure dart2js runs faster than Dartium.

Not according to the benchmarks they give:

http://www.dartlang.org/performance/

Dart VM (Dartium) is about 2x as fast as Dart2JS (which is around 80%-90% of JS).

You're right. I'm still pretty sure Dartium isn't supposed to end up in the hands of end-users, but is more of a benchmark to see how much dart2js can be improved. But since this is HN and there are always the conspiracy theorists around, I really have no idea what the plan is.

(Remember that you can write server-side software with Dart, too, so the VM can exist for that purpose without being some evil scheme to eliminate Javascript. Not that I would mourn the passing of Javascript :)

>You're right. I'm still pretty sure Dartium isn't supposed to end up in the hands of end-users, but is more of a benchmark to see how much dart2js can be improved. But since this is HN and there are always the conspiracy theorists around, I really have no idea what the plan is.

I'm not sure. If that was the case, I don't think they'd put a hot ass team (including Lars Bak IIRC) on the Dart VM and spend millions on it.

I believe Google would very much like Dart (the VM) to succeed, but they know that realistically it can not for now, and so they invest in the JS translation in order for it to be a credible player.

As you mention, one way that Dark can make a dent, though, is on the server side. It's a decent dynamic language, that's an order of magnitude faster than Python/Ruby. With enough library support, it can get places that even node, tied as it is to the async callback model, might not. A decent web framework, for example, could have Dart see a lot of adoption.

That said, it's still too early to tell -- it's not even out of beta yet.

The whole point of dart is to have a dynamic language for the web that is type-safe and super fast by default. If Dartium never gets into Chrome, then that would make Dart kind of useless. The plan is to implement Dartium into Chromium once Darts stabilizes.

Dart is already very useful, so I disagree with that assertion. It's the Dart compiler that handles type-checking, not the runtime. If you write "String foo = 42; return foo + 8;" and compile without type checking, you generate code that will work fine. But if you turn on type-checking, you get the type error at compile-time.

Furthermore, the compiler is responsible for resolving the dependencies your main program uses ("tree shaking" to remove stuff you don't actually use [1]), so there has to be a compiler even if your browser had a Dart VM built in.

[1] http://blog.sethladd.com/2013/01/minification-is-not-enough-...

I use Dart because it allows me to organize and test my code in a way that is very inconvenient with Javascript. Any speed improvements or IDE support is incidental, I have not yet had any speed problems in Javascript and I don't use their IDE :) The type-checking, library system, and the language itself is wonderful, though.