Hacker News Reader

Comment by bussiere | Hacker News Reader

From wikipedia :

A special version of Chromium (the open-source browser at the core of Google Chrome) comes with the Dart virtual machine, allowing it to run Dart programs.[19] As of May 2013, Microsoft Internet Explorer, Mozilla Firefox, Opera Software's Opera browser, and Apple Safari have no plan to embed a separate Dart VM.[citation needed]

Dart source code can be compiled to JavaScript, allowing applications written in Dart to run in all modern web browsers. In the M1 version, released in October 2012, the generated JavaScript reached about 78% of the performance of hand-written JavaScript while native Dart code ran about 21% faster than similar code in V8.[6]

So for me : No browser except a special version of chromium, and slower than javascript whend compiled in it. So NO ...

We have a lot of problem to have some standards on the web (css anyone ? ) , we fight with ie6, so taking such a non standard is nope.

View on HN

More recent benchmarks[1] show 85-91%. IME developer productivity has been far more important than raw performance.

Not sure where the fading away perception is coming from; looks like it's still trending up, or at least staying afloat. [2]

Some barriers to entry:

* still have to interface with old javascript libraries for anything not ported to Dart

* compilation step + debugging. I know there's probably a sourcemap, but that's still more friction than straight javascript.

* learning curve

* pioneers get arrows in their back. Everything new has gotchas people haven't found yet. Javascript has some really shitty corners, but we know all about them.

Dart's pros have to outweigh these. I've only toyed with it, and from a strictly language-vs-language I like it better than javascript. If it gains traction, it'll start with toy projects -> company intranets -> the occasional startup -> small company, etc.

[1] https://www.dartlang.org/performance/

[2] http://www.google.com/trends/explore#q=dartlang

Worth noting there's no compile step or debugging with source maps when you're developing using Dartium, which runs the Dart code directly; you'd only need to compile for deployment.

That explains why it's not used in production. What I don't understand is why the idea of replacing Javascript with something better hasn't been embraced. Maybe Dart isn't actually better but I don't see anyone arguing that and that is the interesting substantial question.

I don't think Dart is better. It is better in some ways, but it's not enough. You're not seeing arguments because currently people don't care.

Thing is, Javascript works as a target for other languages. For example ClojureScript and Scala.js are examples of compilers targeting Javascript, amongst many others. So people that want an alternative to Javascript already have options.

From a technical point of view, I think Google made a mistake in designing a new language, instead of a new VM that could be used as a more efficient target for multiple languages, because even though Google tried copying the good parts of Javascript's story, you can't beat the incumbents at their own game. And from a social perspective, Dart is seen as an attempt to fragment the web, so Google's handling of the situation was poor.

Dart does have a new VM (that's what Dartium uses after all), and it would probably make for a better compile target than JS since it has strong typing, better number types, etc.

Because:

# JS has shown surprising legs when it comes to performance improvements

# For a competitor to become popular it’d have to persuade every browser manufacturer to implement it

# Once implemented it’d have to wait for multiple years for devices in the market to implement it

# Older devices are slower devices, so having a compiles-to-JS version that lags in performance for older devices isn’t tenable either.

Basically, it makes more sense to increase the local maximum than any other path.

> # For a competitor to become popular it’d have to persuade every browser manufacturer to implement it

IMHO this is a misconception. Dart compiles to JavaScript with decent performance of the generated code. In some cases even faster than comparable hand-written JavaScript (see: http://dartlang.org/performance).

JavaScript engines getting faster also means that Dart code compiled to JavaScript is getting faster. It is a win-win scenario.

Even if other browser vendors won't ship a Dart VM tomorrow the situations is pretty awesome performance wise.

Once Chrome ships a Dart VM a huge user base gets even better and more predictable performance characteristics than would be possible in JavaScript which is incredible but I don't see the browser vendor support/performance angle as a real show-stopper for Dart.

You don't give anything up when you use Dart, you can still call JavaScript libs if you need to (e.g. we do use PubNub.js at https://www.blossom.io and we use it from Dart without any problems).

Javascript is being replaced by newer (hopefully better) Javascript. That's they only thing browser vendors can get in agreement.

There's plenty of other javascript compilers for plenty of languages.

I really wish there way a way of coding for the web that didn't require [backend language] + [front end language] + Javascript (might be the same as previous two) + HTML + CSS. If I want to write a website in Python, I still need to know Javascript, HTML, and CSS, so why bother with Python?

> If I want to write a website in Python, I still need to know Javascript, HTML, and CSS, so why bother with Python?

Libraries. Backend code can be quite different than frontend depending on your requisites.

E.g., there's no SQLAlchemy for Node.

HTML and CSS are quite different things, you can't escape that.

Sorry, I should have mentioned the "why bother with python" was rhetorical. I know the answer, I was just expressing frustration at the barrier to entry that doesn't need to exist.

"If I want to write a website in Python, I still need to know Javascript, HTML, and CSS, so why bother with Python?"

Right tool for the right job. That's why I don't think you should use css on the server! Or haskell on the client's browser!

Can you elaborate on why Haskell is not appropriate for the browser? Just for clarification, it is a general purpose language whereas CSS is not.

No particular reason. It was the first example language that popped into my head when I was thinking of "what language do I think really doesn't belong in a client browser". i.e. my personal opinion.

I'm sure it's a perfectly valid option to put in the browser, though.

I agree with you that you should use the right tool for the job. No CSS on the server :) There are a couple of projects (ghcjs, fay, purescript, haste) that make it possible to write Haskell for the browser. After maintaining JS libraries with a team over the past three years I've come to wish for Haskell's type system and compiler. It would make my job much easier. :)

Don't use Python then. Prefer a language that has compilers targeting Javascript instead. Candidates that I have tried: Clojure & Scala. And I'm sure there are others. People don't talk that much about it because Javascript being used as a compilation target is a fairly new trend.

> If I want to write a website in Python, I still need to know Javascript, HTML, and CSS, so why bother with Python?

Because you don't want to write your backend in Javascript and you prefer a different language. You don't have to know well only one language in your lifetime.

There are some GWT-like things for Python, pyjs and pyjamas. Doesn't get you away from CSS though.

Reply on news.ycombinator.com