Hacker News Reader

Comment by michaelwww | Hacker News Reader

I think a few points are worth emphasizing. Dart produces JavaScript that is closer to being correct https://news.ycombinator.com/item?id=5424680

Dart can produce JavaScript that is faster http://news.dartlang.org/2013/03/why-dart2js-produces-faster...

The JavaScript output of Dart2js works across all modern browsers (IE9 and above, among others.) No browser hacks required.

Having said that, I wish they would stop working on advancing Dart and ship a 1.0 version. It's been 1.5 years since it was announced. Make the advancements in the 1.1 or 2.0 and give the tool developers a solid target to optimize for in 1.0. Let us not have to sell clients on a beta development system, even though that's what I'm doing and it's working, despite some panic when Dart developers break things with breaking changes (which is often.)

View on HN

If your browser requirements are IE9+, then there's little need for things like underscore (and, arguably, even jQuery) since you can count on x-browser support for things like document.querySelectorAll() and other niceties that jQuery typically levels the playing field for.

For example, why would there have been confusing over _.each vs. $.each when you have perfectly consistent native support for [].forEach? Nothing against Dart... it's cool and all, but I'm not sure the JavaScript "fragmentation" rationale is all that strong when you have the luxury of only dealing with such modern implementations.

My understanding is that people continue to use jQuery because it makes DOM manipulation that much easier. The Dart authors kept this in mind and said jokingly on http://www.dartlang.org/articles/improving-the-dom/ One area where the DOM has a bunch of baggage is finding elements. Today’s DOM has a pile of methods for finding stuff. All of this piled up before jQuery appeared on a mountaintop to give us the revelation that Thou Shalt Find Nodes By Using CSS Selectors. With the One True Way in hand, we’ve stripped it down to just two (!) methods: query() and queryAll().

I'm all for simplicity, and, again, this isn't an argument against Dart. But I would still contend that merely shrinking your DOM API surface area is only of marginal significance.

Historically, the hardest part of interacting with the DOM has been the inconsistencies (and missing functionality) amongst ancient browser versions. We've had standardized methods for a long time now that make DOM interactions relatively trivial if you have the luxury of working with browsers that support them.

> Historically, the hardest part of interacting with the DOM has been the inconsistencies (and missing functionality) amongst ancient browser versions.

Even newer browsers have a surprising amount of DOM inconsistencies, especially for newer HTML5 APIs that are still evolving. While this is an ongoing job, the Dart DOM API tries hard to polyfill that so that you get a single API that works across most browsers.

Querying is only a small part of it, though. jQuery provides result sets as proxies for the actual objects. So this:

    $(".foo").css("color", "green");

will actually apply the CSS to all matches. This becomes doubly handy when doing things like attaching event handlers, removing nodes, etc.

Looking at Dart's API, I don't see anything like it; queryAll() returns a List<Element>. In order to act on a collection of elements, you have to use iteration mechanisms such as for loops.

The whole concept behind jQuery's $() is that it's a DSL.

I think the language is done. After listening to this FLOSS episode, I think they're just finishing off the libraries.

http://blog.sethladd.com/2013/03/dart-on-floss-weekly-from-t...

Sounds like 1.0 might be a Google I/O announcement.

There's still a small amount of language evolution going on. We recently added mixins, for example, and there's a couple of minor things still being batted around.

However, we are making very few breaking language changes right now. Most of the fast-paced evolution is in the core library. Unfortunately, the corelib was essentially stagnant for close to a year, so now that people are working on it, they are feverishly playing catch-up to get it to a good place before 1.0.

IE9+. I hope people don't miss this keyword.

That satisfies all mobile development as far as I know. The loss is on Windows XP desktop for those stuck on IE8 and below. So far, I'm doing ok telling people to run Chrome or FireFox on XP as most of them are anyway.

To give some perspective: we were lucky to have less than 2% of traffic coming from IE, most of those visits via IE9+. This made the decision to switch easy in terms for browser support in our case.

YMMV of course but it definitely makes sense to look into your target audience. For some people Firefox 3 and IE6 might still be user bases that are worth supporting, we are glad to have a product for web and mobile developers :)

I wouldn't be surprised if this decision also makes sense for a lot of other target audiences, especially when you consider that you are in it for the long term.

Reply on news.ycombinator.com