Hacker News Reader

Comment by mratzloff | Hacker News Reader

Who is the audience for Dart? Clearly it is first and foremost Google, whose programmers spend their days writing Java and C++ in an IDE like Eclipse. But web developers, who are the primary producers of JavaScript, will happily stick with Node.js, CoffeeScript, or plain JavaScript.

For that audience, they are given a language with optional static typing (most don't want it) and an Eclipse-based editor (most don't want it).

By way of contrast, consider Go. Go is (in my opinion) an extremely successful successor to C, in terms of its design. It fixes a handful of problems with C (strings, and I would argue pointer arithmetic), and modernizes and streamlines it. The interface system is fantastic. In terms of its design, I have nothing but good things to say about Go.

Dart does not seem to improve on JavaScript in a compelling way. It adds optional static typing, and as far as I can tell, nothing else.

Is it any surprise that Dart has failed to take off?

View on HN

IDE like Eclipse

You don't need to write Dart in the Dart Editor if you don't want the IDE experience. I happily write Dart in Sublime, and Dart has command-line tools that I can use to validate the code that I write.

But web developers, who are the primary producers of JavaScript, will happily stick with Node.js, CoffeeScript, or plain JavaScript.

If web developers are happy with the tools they have, then that's just fine. The Dart team isn't trying to replace JavaScript, but instead provide another option for web development. What I think the Dart team is finding is that there are a lot of people that are having trouble with putting together all the pieces just to build a web app. This is especially true if you are new to the web platform, and you're familiar with the development from other places. Dart provides a very consistent platform that you can build web applications with, and you don't need to worry about jumping through all the hoops that normal web development requires.

In a way, this is how I see Dart too (though Dart is a much newer platform, not yet out of beta). Dart aims to fix a handful of problems with JavaScript (like better scoping semantics, a built-in module system, better toolability and static analysis tools, etc.), and then also takes the existing browser APIs and modernizes and streamlines them (for example, all of the core browser APIs use a consistent Future-based API for asynchronous values, which cleans up a lot of messy code that you'd ordinarily see in JavaScript web application code).

Is it any surprise that Dart has failed to take off?

It's not at 1.0 yet. I still think there is plenty of room for improvement, and plenty of time for adoption.

I asked the Dart team if they thought I should use Dart today. They recommended only using it on projects where I had the flexibility to wait a couple months for missing functionality to be written if it turns out my app needs something that isn't in the standard library yet.

There's definitely room for both polish and adoption.

>>You don't need to write Dart in the Dart Editor if you don't want the IDE experience. I happily write Dart in Sublime, and Dart has command-line tools that I can use to validate the code that I write.

This is the same line argument made with regards to Java too.

But the fact of the matter is, these language bring in so complexity with their whole ecosystem. Working without an IDE isn't even worth that torture.

Respectfully, I disagree.

I've written Java in plaintext editors before, and that is truly terrible. Dart is nowhere near that verbose. Dart's imports feel pretty lightweight (rather Python-esque) and the fact that the language has top-level functions and variables means that you're not always trying to juggle a bunch of classes and objects and interfaces when you don't need to. In fact, Dart's style guide explicitly recommends that you don't put things in wrapper objects just because you can. http://www.dartlang.org/articles/style-guide/

I really don't think that Dart brings in any more complexity than you'd have in a JavaScript application. I actually think it's a lot easier to hold a Dart application in your head because all the APIs have a consistent interface. With JavaScript, you often have a bunch of different libraries and you have to remember how each of them behaves.

Dart imports are a bit less verbose as you do an entire library instead of a class like java does. As well, globally scoped functions let you code without all the OOP if you don't want it.

How do you use your JavaScript libraries today? Do you have evrything memorized?

The primary audience, is web developers.

Dart is an ambitious attempt at simplyfing web development, reducing complexity and improving productivity which:

  - Provides a familiar language with clean semantics and low ceremony
  - Provides the fastest dev iteration times (there's no compile step, 
      just edit + run in Dart VM/Dartium)
  - Provides ~10x faster start-up times with snapshots (Dart VM)
  - Provides faster run-time performance, that's predictable and can take 
     advantage of real integers and SIMD instructions (VM Only) 
  - Provides a unified object model so all classes from all libraries can interoperate
  - Providing a rich, well-defined, consistent API, real collections, removing JS WATs, 
      smoothing over browser quirks
  - Provides a unified and composable IO model: Futures and Streams (repeating events)
  - Provides a new powerful way to develop client apps with Web UI (Dart WebComponents) 
      offering unprecedented levels of encapsulation and reusability 
  - Provides optimal dev and deployment options, you never have to worry about choosing 
      the smallest libs as tree-shaking ensures only code used is compiled and minified 
  - Providing "full-stack" dev environment, e.g. same language on client and server

There are many initiatives ongoing to improve web development IMO Dart is the most radical and has the most potential to provide a productive web development environment in the visible future. I hope it extends further than that and is offered as a language choice on Android (which will make me switch to Android dev).

That's not much. ES6, TypeScript, DOMFutures, FunctionFuture, asm.js, WebComponents, jQuery, r.js, node.js bring most of these features to JS. Not as slick and with some legacy warts, but it's good enough to make Dart merely an incremental improvement rather than a revolution.

It's very disappointing that the first serious attempt to replace JS after almost 20 years is merely just another Java-syntax-like JIT-compiled single-threaded dynamically-typed garbage-collected language with global, shared mutable state. It's fundamentally the same language merely with some pet peeves removed and a bit of sugar on top. It's a waste of opportunity.

Actually no, except for WebComponents it brings none of those features. Other than "fullstack" which JS already has before.

Every other attempt adds more layers and complexity and additional build times to web development, only Dart brings a clean re-write.

>Who is the audience for Dart?

AS3, C#, Java, and JavaScript developers. That's why they went with C-like syntax. It's familiar to most people.

>But web developers, who are the primary producers of JavaScript, will happily stick with Node.js, CoffeeScript, or plain JavaScript.

I'm writing JavaScript for a few years now. I'm really tired of it. It scales very poorly and there is zero tooling. For example, JSLint is mostly about formatting and conventions, because it got very little information to work with.

Also, if you want to take care of dependencies in JavaScript, you'll need boilerplate code (several flavors exist). If you want to document your code, you'll need lengthy doc comments (several flavors exist).

Finally, with JavaScript you're always discouraged to write extensive libraries, because everything you don't use is dead weight.

With Dart, you don't have any of those problems. It scales, there is proper tooling, you can use `import` and put stuff into packages, basic documentation is already done by adding some type annotations, and unused code is also removed.

Additionally, it's a lot easier to learn than JavaScript, because the language is less quirky.

>Dart does not seem to improve on JavaScript in a compelling way. It adds optional static typing, and as far as I can tell, nothing else.

Classes/inheritance, mixins, implicit getters/setters, implicit interfaces, import, lambda expressions, proper lexical scoping, a lexically scoped `this`, operator overloading, actor-like concurrency (isolates), SIMD, faster startup, better performance, const/final, factory constructors, optional positioned/named arguments... and good tooling.

Seen that "WAT" talk? None of that.

Dart is drastically better than JavaScript.

When I started seriously working with JavaScript, I decided to try to conform to community standards by using JSLint. I was shocked by how terrible JSLint was. It offered corrections for very straightforward constructs such as:

    var count = 0;
    for (var i = 0; i < arr.length; i++) {
        if (some_func(i)) {
            count++;
        }
    }

I have no idea why JSLint would tell me that I should move the definition of "i" to the top of the function (am I supposed to pretend I'm writing ANSI C for obsolete compilers?) and its insistence that "++" is evil in both uses above is equally ridiculous.

I love static analysis, I like tools that automatically format source code (indent, go fmt, emacs), but JSLint is just annoying.

JSLint recommends declaring vars at the top of the function because vars have function-scope regardless of where they appear in the function ("variable hoisting").

The ++ thing is due to the fact that JavaScript uses + for concatenation and I've run into real life issues with this, in that if someone writes something like

var foo = "The id number is: " + ++this.id + ".";

a Minifier may make that like

var foo="The id number is: "+++this.id+".";

which is a syntax error. Now of course you should be using a minifier that wouldn't be so stupid but it happened in our staging environment because some former employee used a very basic, yet aggressive minifier in the build process from Staging to Live.

JSLint gives you an option to turn it off though, plusplus:false. Same with the variable hoisting warning others have explained.

You can use JSHint to fine-tune your linting rules.

Your issue is not knowing JavaScript. No point to blame a JavaScript linter.

The real issue is that, as a programming language, JavaScript is poorly designed and quite broken. Its implementors and community have been quite unwilling to fix these issues, even after a decade and a half. As a result of this, it is still riddled with oddities in even extremely simple constructs.

Even when one understands the reasoning behind why a tool like JSLint suggests what it does, this doesn't change the fact that dietrichepp's observations are correct. JavaScript's scoping and variable hoisting are unnecessarily broken, leading to convoluted coding practices that wouldn't really be necessary if JavaScript itself wasn't so broken.

>[JavaScript's] implementors and community have been quite unwilling to fix these issues [...]

You can't really fix things. It would break the web. You can only add stuff on top.

>JavaScript's scoping and variable hoisting are unnecessarily broken [...]

It will get a bit better with ES6's `let` keyword. Annoyingly, that keyword was introduced with Firefox 2.0 (October 24, 2006) but you still can't use it.

Even Node.js needs a switch.

>Seen that "WAT" talk? None of that.

You realize Dart literally has broken generics? That the team thought covariant mutable collections was a good thing?

I literally meant none of JavaScript's flaws from the "WAT" talk.

Anyhow, JavaScript doesn't have any kind of generics or types. Do you really prefer that?

Perhaps there is a lack of appreciation of generics at Google in general. Go entirely lacks them, as another data point.

Yes, but I think it's a more wide-spread issue. Comparing languages of the European school with languages of the Anglo-Saxon school, it seems like the wide-spread anti-intellectualism in the US has a large impact on language design quality.

I remember that Dijkstra had some pretty good article about it.

I love Javascript but Dart is appealing to me.

I know there is a stream of Java / C# / C++ programmers that desire a Java-esque, improved GWT experience and loathe Javascript. But I see Dart more as a refined/upgraded Javascript -- some additional language/toolset features like Objective-C or C++ do for C.

Advantages of Dart over Node.js or CoffeeScript or plain Javascript?

1. "Batteries included" -- instead of reliance upon assortment of modules, OO system built in, better DOM utilities than jQuery (query returns a first class object), functional like Javascript sans the function keyword).

2. So nice that you can split a project across a whole bunch of code files, yet it will condense and minify into one efficient javascript file. Yes, there are tools with all the various Javascript frameworks to accomplish this, but then you're reliant upon of hierarchical library dependencies that sometimes can be brittle.

3. Can run server side just as Node.js with a powerful VM, without the need (though certainly possible and optional) to install a plethora of other libraries.

I think it hasn't taken off because up until recent months, the language and library has not been stable enough for production development -- libraries have changed a lot and most of the code in all of the Dart books published to date will not run at all now (though the Dart SDK comes with a tool that can help migrating code).

There are still some sore spots I hope get addressed -- primarily, on server side, need for built-in DB libraries and on client side, JSONP/CORS that is as easy as jQuery makes it. At least in my XP.

Do you think the Gmail or G+ team spends all their days writing backend code? Google has some of the largest and most sophisticated web apps ever developed, e.g. the newly minted Google Maps.

All of this is courtesy of the Closure Compiler, which uses optional static typing.

I think watching what Google itself does with Dart vs Closure is going to be an interesting tell.

No more than what Google does with GWT. There is no top-down dictate in Google to use a given language or framework, it is up to the various teams to decide what they want to use. Some teams uses Python (most famous of course is YouTube), some use Go, some C++, and some Java. Some groups deploy to Borg, some to AppEngine. On the frontend, some use Closure (Gmail, G+, Docs, Maps), some use GWT (AdWords, Wallet, Flights/Hotels, etc), some use AngularJS, and now, presumably, some will use Dart. In fact, some apps use a hybrid.

Sometimes people chose to use a language for a new project because of existing labor pool, that is, who they can find to work on the project and what their preferences are. Sometimes it's because they want to use an existing codebase. Sometimes, people chose a new language because they are in an experimental mood and want to try something new.

If Larry Page were to say "all future apps have to be written in Dart", it would be damaging to company morale and culture, not because there's something wrong with Dart, but because people chafe being forced to make technical or personal decisions like that.

Google can no more force you to use Dart than they can force you to use CoffeeScript or GWT, I think people need to chill out and stop aggressing against anything that threatens Javascript hegemony. I mean, sheesh, people are even rebelling against some of the changes in ES6 which fix some of the most egregious problems that drive people to create transpiled languages.

Thanks for explaining the process. I like Google's evolutionary approach, but it sounds chaotic to someone like me from a Microsoft background. The top down command hierarchical structures appear to be losing all over to the networked evolutionary approaches, so I have no complaints. But I wonder, does that mean someone inside Google could use TypeScript? This might be a blind spot.

Also, I meant it will be interesting if no team chooses to use Dart on the client, but it gains interest on the server. Presumably teams go with what makes sense and that will be interesting to watch.

> I think people need to chill out and stop aggressing against anything that threatens Javascript hegemony

They have over the last 6 months as more and more people are realizing that pure JavaScript is not entirely suitable for large scale applications that are becoming more common. As someone said, the efforts to make it so are 'heroic,' but obviously the hard way to do things, like choosing to write a large application in assembly language. Having done that once, I would never do it again, and would take someone who said this was best less seriously.

Believe it or not, there's some internal projects done in LISP and Haskell. Obviously there are limits to what you can do. If you work on some new big customer facing project, it's a lot harder to get a big team of people to agree to use Haskell, but if you are working on a 20% project, it's a lot easier to just use whatever you want.

With Google production servers, there's only a few "approved" languages. I can't just go deploy a Rails app in one of Google's datacenters, for good reason, especially when you consider security.

With app-engine or compute-engine there's slightly more freedom.

I worked in Dart for a few months and loved it, but recently had to look for something else for older browser support. I started writing code in TypeScript a few days ago and, face palm, why didn't anyone think of this sooner? Visual Studio with TypeScript and jQuery type definitions gives me most of what I need from Dart (80/20 rule). It's really fun to code with. JavaScript with types feels like a sunny day. I've been complaining a little about Dart js-interop (size and speed) and now feel my instincts were right; if Google doesn't fix js-interop, then I'm struggling right now trying to understand why I should use Dart, unless Google is more clear about a different use case for Dart on the client (Android.) If all the JavaScript 'Ninjas' discover TypeScript and have the same reaction I just did, then Dart is going to struggle on the client because it doesn't operate well in the current JavaScript eco-system like TypeScript does. Someone high up in the company and outside the Dart team needs to make a strong statement about where the Dart VM is going before the window closes.

Audience? I know plenty of programmers who hate JavaScript for not having classic object model. I make my living as PHP programmer and hate JavaScript too for exactly that reason. I did only jquery with plugins and inline code mostly with effects and ajax load coding.

I tried DART and did multiplayer online game http://shipsonline.org/ as my first "hello world" without any external code. Epic win for myself. It has more than static typing, please try write simple app and you will see. Eventualy it became stable and then became mainstream popular i hope.

Dart isn't done. Most people aren't going to use it for real projects until it's at least 1.0. Furthermore, Dart really won't shine until its vm is built into Chrome.

> For that audience, they are given a language with optional static typing (most don't want it) and an Eclipse-based editor (most don't want it).

There's also a plugin for Intellij IDEA[1], which is a great web (and other use) IDE.

[1] http://plugins.jetbrains.com/plugin/?id=6351

Gotta disagree with your panning of static typing. Dart is targeting large web applications- apps written over the course of months and supported for potentially years, by a team which changes over the course of the project.

The thing isn't static typing- it's static analysis. The ability to specify contracts in your code and have something validate your code. This is the same thing TypeScript and Closure try to address, but Dart is trying to tackle the issue at its core, with performance to boot.

I'm not panning static typing. Static typing is fine. I'm saying that most JavaScript developers seem to prefer dynamic typing.

For better or worse JavaScript is the lingua franca of the web, so if you want to go home early instead of tracking down compiler errors of the translation tool, the best way is just to use JavaScript.

Dart will never take off if the other vendors don't offer VM support on their browsers. Almost every language has JavaScript transpilers and as a Chrome only solution it won't work.

Not necessarily. Dart provides 2 options: - A strong tool supported language that translate to Javascript. So you developed large applications far easier with Dart VM in the browser, then just compile to Javascript for deployment. Debugging will happen in Dart mostly. - A multi platform Runtime (Chrome) for high performance demanding applications. Application runs on browser it is far better than writing Windows - Mac - Linux specific application to me. And more appealing than Java. Also Chrome with Dart VM will work in Android. Another plus.

Both are compelling advantages of Dart.

> Application runs on browser it is far better than writing Windows - Mac - Linux specific application to me.

Well, I am the opinion the browser is for documents.

I had that same opinion in 2003.

I am developing software since 1986, mostly web in the last 8 years, my experience in the chaotic ways of web development only reinforces my opinion.

Funny I am developing since 1986 too. One of the reasons of the chaos is JavaScript. Yet like it or not after mid 2000's many complicated apps are targeted to web only (Gmail etc). Now with the advance of new APIs Browser started to behave like an operating system - or runtime environment allowing rich-high performance application development. But JavaScript is still as ugly as before and I see Dart as a perfect high performance alternative that happens play well with JavaScript. I would gladly develop an application that run on Chrome rather than runs on Windows or Linux only.

To answer you first question: Anyone fits in "the audience for Dart", If you're ready to use CoffeeScript, why wouldn't you give Dart a try?

"It adds optional static typing, and as far as I can tell, nothing else."

And as far as I can tell you don't have a clue of what you're talking about.

> And as far as I can tell you don't have a clue of what you're talking about.

I received a lot of thoughtful, intelligent responses to my post, including many that disagreed. Unfortunately, yours was not one of them.

While I don't particularly like it (or Go for that matter) Dart is, if nothing else, a lot less idiosyncratic and plain crazy than JavaScript is.

Reply on news.ycombinator.com