Comment by gruseom | Hacker News Reader

Comment by gruseom | Hacker News Reader

I'll pipe up with one thing nobody seems to be emphasizing. A lot depends on how good Dart turns out to be. Suppose it turns out so good that we get all four of the following:

  1. No worse a user experience in any browser;
  2. A much better user experience in Chrome;
  3. A much better developer experience;
  4. A much better server-side platform than V8.

If we get all that, standards or not, I will be jumping for joy. If Dart is that good, it will become standard, either de jure or de facto as alternatives fall by the wayside.

Of the four, #1 (a good enough Dart->JS) seems problematic. #2 may be bad for other browser vendors, but if it's good for users and programmers, why should I care? I see no virtue in a lowest common denominator. #3 and #4 are hardly objectionable. Only those who like them need bother.

I don't know how likely this win-win-win-win is, but here's why I'm indulging in the hope. These guys have been gods of fast dynamic VMs since Strongtalk. If Dart is their chance to build what they always wanted, but this time with 20 years of experience to draw on and the institutional support of a Google behind them... well, we have the chance of something insanely great. Greatness sets its own standard.

Comparisons to VBScript and Flash only kick in if what they come out with is lacklustre.

The comparison to VBScript is not technical at all. It is about single-vendor control.

Your item 1 is obviously problematic. If Dart and JS have close semantics, it's just a transpiler like CoffeeScript, which intentionally sugars JS semantics with leaner syntax.

But this does not match the leaked info and hype about Dart, and even then, such warm beer still requires you to run a tool over your primary source, which costs adoption. Lots of languages already contending in this transpiling space.

More likely, a Dart-to-JS compiler (making non-local transformations) and a JS-implemented Dart runtime (to support the novel runtime semantics, e.g. new numeric types) will be required.

This means a worse user experience in browsers that don't have the native Dart VM, because performance will lag (especially depending on the new numeric type details) and bug-for-bug compatibility will be lost.

The native VM will be the super-fast source of truth. The compiler/runtime will be a stop-gap. This brings us back to the standards table, unless the idea is to corner the browser market. See

https://news.ycombinator.com/item?id=2983157

under "On Dart: ..." about what the standards table would look like if it is anywhere near today's mix of browser vendors and other interested parties.

#2 is bad for users unless Chrome is shipping on all hardware and operating systems users use. In fact, that's the same reason any sort of web-related monopoly is bad.

Where's Chrome for PPC processors? Chrome for ARM (being worked on, but no there yet)? Chrome for whatever architecture or OS users might want tomorrow?

The right comparison here in your success scenario may not be VBScript but ActiveX, except without the security issues ActiveX had. If ActiveX were required for use of gmail today, how would you feel about it? How would you have felt about it in 2002?

If ActiveX had been insanely great, not only would I feel fine about it, it would be ubiquitous by now.

Isn't "insanely great" a Steve Jobs phrase?

I like Apple's hardware (modulo the fans running all the time on my latest dual-core i7 MBP), and some of its software (but WTF happened to Mail.app on Lion?).

Still, "insanely great" didn't make Apple-only web tech ubiquitous. That took hard, open-standards spec-work in the CSS WG. And that, to the extent it happened with help from Apple, is the opposite of the Dart plan in the leaked memo.

Stop worshipping i.g. It's never that great. Native apps on iOS use Objective-C, for crying out loud. Everyone's sh*t stinks.

I.g. is no excuse for monopoly behavior. The greatness goes away, leaving only insanity.

Well said Brendan!

Like I said in a tweet this morning, I know those Googlers know way more about JS than I do, but if they think as per the leaked mail) that devs are choosing iOS over browsers because of JS, they have their heads in the sand.

Those choices are happening due to iOS as a platform not because devs are somehow so much more happier learning/using objective-C! The best thing that Google could do is to KEEP working hard on improving the browser platform like you guys are doing with B2G and they started to do with ChromeOS.

For example, I'd love to hear from the ChromeOS team exactly what in JS is blocking them delivering all the kinds of APIs that B2G is promising to deliver.

And on the server-side, some one should tell the hordes flocking to Nodejs that they are all wrong! As you pointed out, serverside everyone can choose to use whatever they want and given that choice, just look at everyone jumping on the Nodejs bandwagon. I'd love to see all those thousands of module that dev around the world have written in Go recently! (npmjs.org)

maks.

So you would be OK with requiring everyone to use Windows as their operating system, in perpetuity?

I think we have some fundamental philosophical differences about how the world should work. ;)

"So you would be OK with requiring everyone to use Windows as their operating system, in perpetuity?"

Of course I don't think that. I meant by "ubiquitous" to imply the opposite. I fear we're talking past each other.

The risks of Google behaving like a Microsoft-style monopolist here are low because (a) they have no monopoly in browsers, VMs, or OSes to abuse, (b) their culture is the most hacker-driven of any large company, (c) their interests are aligned with what is good for the web, and (d) the industry has changed since the bad old days.

Given this, and because the potential value of this project is so high, I'm willing to give them a chance.

Since making my original post, I've read a bit more about Bracha and Newspeak. Assume for the time being that Dart is an evolution of this work. We're talking about a fast, small, even-more-dynamic Smalltalk augmented with ideas from Self and E, designed for the web and multicore. That's mind-blowing. Now throw in the implementation prowess of a Bak and the institutional support of a Google, and we're talking about something potentially game-changing. To judge by their track records (e.g. the Resilient embedded Smalltalk that Bak worked on), these guys are out to correct not only the mistakes of Javascript but of Java as well. Historic stuff, which they have as good a shot at pulling off as anybody ever has.

I admit the odds are against it turning out so well. But this is the rare case where at least some optimism is well-grounded. If what they release does turn out to be an attempt at the above, it will be exciting.

"Ubiquitous" ActiveX without Windows is a pipe dream, not a useful premise. Kind of like assuming world peace first, then resolving a lesser conflict.

With ActiveX, the interfaces that might be used are too many, and their implementations too large and complicated, to have bug for bug compatibility. Even having source code would not be enough. All-paths testing would be needed.

Someone could (and a few companies did, for COM on Unix) tediously reverse-engineer a subset of COM interfaces and components implementing them. No one ever pulled off anywhere near a full Windows workalike.

The same threat arises with delayed-open-source controlled by a single proprietor. You can port and fork such code, but you can't depend on the single proprietor, especially if it's a hostile competitor. You'll have to co-maintain if you don't make a long-term fork of your own.

Source != spec. An implementation will over-specify in its source code and API. Abstractions leak. Standards can and do turn down specificity by dropping to prose or more formal means, without overspecifying.

"The risks of Google behaving like a Microsoft-style monopolist here are low because (a) they have no monopoly in browsers, VMs, or OSes to abuse,"

Look closer: Google is a search monopoly in many locales, and they are an emerging duopoly member (the larger share than Apple) on mobile, whose growth predicts it dominating desktop.

"(b) their culture is the most hacker-driven of any large company"

That was true a few years ago. It is much less so now. Larry has cut back on the thousand flowers, and focused on a few strategic bets: Android, Chrome, Google+, Search.

"(c) their interests are aligned with what is good for the web,"

So you say (and perhaps Google people say this, but I know some who candidly admit it just ain't so any longer).

Why do you believe this? As a public company, Google has to show quarterly good results, not just great profit margins but bubbly growth, to keep its stock appreciating, to retain and recruit (see the Facebook defection problem of last year). This is a big distortion on a pure open web mission.

"and (d) the industry has changed since the bad old days."

And human nature has changed since the 20th century, or the French Revolution, or the dark ages? Yeah, right.

You're much closer to the details of all this than I am, and it's possible I've got them wrong. But I can't agree that there's nothing that can make Dart a positive long-term contribution to the web, regardless of how good it turns out to be. I'm willing to be proven wrong about that, but only by the actual outcome. In the meantime, I'm excited - purely because of the track record of the creators. If and when my hopes are dashed I'll come back and post a mea culpa.

> I meant by "ubiquitous" to imply the opposite.

In that case, I have no idea how you think ActiveX could ever have become "ubiquitous".

> they have no monopoly in browsers, VMs, or OSes to abuse

They have a monopoly in search engines (and some would argue webmail clients), and are trying hard to work on browsers and OSes, especially on mobile... Give them a few more years, and see how things look.

> their interests are aligned with what is good for the web

They used to be, for a bit. At this point, I've very skeptical that this is still true.

> the industry has changed since the bad old days

Has it? I don't see much evidence of this. Particular _markets_ have changed, but attitudes really haven't.

< I have no idea how you think ActiveX could ever have become "ubiquitous". >

You know what, scratch everything I said about ActiveX. I didn't think about it very much (it was so awful, I can't bear to), and you're probably right.

< I don't see much evidence of this. >

Really? To my mind the industry is more hacker-centric than it used to be. For example, there's a spectrum of how open and sharing Google may turn out to be with Dart. Some points on that spectrum are better than others, but nowhere on it is the possibility of an old-school closed-source implementation. That's a major change from how things used to be.

You're right, open source and the Web have both done a lot to take down old-school, straight-ahead proprietary ploys such as closed source, market-power-based de-facto standards that competitors have to reverse-engineer at very high cost. Even on Windows (itself still closed source).

The two technical/cultural shifts, open source and the open web, make for a good trend.

That's why counter-trend action such as delayed-open (Dart), delayed/partly-open (Android, e.g., but other examples are easy to find) raise hackers' hackles. At least for some hackers.

And hackers aside, the competing vendors meeting in existing standards bodies get left out. That clouds the prospects for future standardization, unless (again) based on market power. Which is not there, if the topic is Google Dart (and it is :-|).

The ironic thing about this scenario of ActiveX being required by Gmail is that XHR sort of has its roots in ActiveX -- that is, before Mozilla and others had to replicate it to remain competitive.

We reverse-engineered XHR long before it became a big competitive deal, back in the pre-WHATWG XML daze. See

http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_supp...

XHR was a good idea. Even choicer irony: MS exposed it to JScript when they gave Java the boot, to keep Outlook Web Access working!

This is sort of what gets me confused:

You say XHR was a good idea, and it's clear now that reverse engineering it and putting it into Mozilla's browser was a good move because it allowed that technology to advance the web -- but at the same time you are showing opposition to taking a similar course of action for a Dart VM because it's not an open standard.

I understand the viewpoint that you would rather have had Google focused on improving JavaScript through Ecma TC39 than creating another language with absolutely no outside influence. I also admit that this is a pretty inconsiderate move for them to make, especially as that email made it sound as this new language aimed to be a "replacement" for JS. But despite the lack of good will behind this action, I would still hate to see something as rare as a new client side language, that has a decent potential of allowing developers to think differently about solving problems on the web, die off because no one wanted to adopt it.

See my other reply on XHR. It is orders of magnitude simpler than Dart. Also, even though MS had monopoly power when they added XHR, they did not abuse it on the web. XHR was for OWA. Mozilla and Opera were not coerced by MS-inspired use of XHR on the web. We chose to implement (with some changes, see the wikipedia page) at leisure.

In contrast, Dart usage in Google web properties targeting the native VM in Chrome, per the leaked memo, would pressure other browsers to adopt or reverse-engineer a much more complex non-standard.

Reply on news.ycombinator.com