Skip to content

Instantly share code, notes, and snippets.

@LOG-TAG

LOG-TAG/why-or-why-not-dart.md

Created October 16, 2018 05:54
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save LOG-TAG/e3322f0973b1369173c532c1de3f5522 to your computer and use it in GitHub Desktop.
Save LOG-TAG/e3322f0973b1369173c532c1de3f5522 to your computer and use it in GitHub Desktop.
Download ZIP
Why or why not Dart?
Raw
why-or-why-not-dart.md

Why or why not Dart?

This is my analysis of the Dart language. Overall, some parts I like, some parts I don't like and my overall view of it all.

My background

Depending on what my employers have required on the backend, I've used C#, node.js, PHP, Python & dashes of Ruby. I personally enjoy Javascript, and I'm especially a fan of node.js. I also really like CoffeeScript, and now that it has source maps, it could very well become something I use daily.

Below are my thoughts on Dart:

Modularity

To import a package in Dart (let's say the HTML package), you do this:

import 'dart:html';

This makes me sad because it imports all public identifiers into the global namespace, and you have no idea what they might be. Node.js (specifically CommonJS modules) forces you to assign any imported functionality to a local name.

fs = require('fs');
fs.readFile(file, ...);

You might have to type in a few more characters, but readability is so much better.

However, the following is supported in Dart:

import 'dart:html' as html;

So it's not too bad. Perhaps someone will write "Dart: The Good Parts" and include a linter with that.

Modularity take 2

"Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function." - John Carmack

In node.js, many modules work like this:

module.exports = function(...) {
  ...
	return blah;
}

// in the code that uses the package
var functionName = require('module');

Some might barf at the thought of publishing one function as a package, but hear me out...

  • It limits bloat significantly.
  • It focuses your code at a specific abstraction level.
  • And more importantly, you don't feel stupid publishing a package with one function.

All this makes your code much easier to read (almost fun, dare I say).

In Dart, it's not possible to do this nicely. You do have:

import 'library' show function1;

But this is ugly, plus you cannot rename the function without writing another assignment statement, which then makes your code look dumb because you're polluting your namespace with duplicated functionality.

I hope there will be a way to rename imported functions in the import statement itself.

Modularity anti-pattern

This is an abbreviated example taken from http://www.dartlang.org/docs/dart-up-and-running/contents/ch02.html#libraries-implementing.

library ballgame;

part 'ball.dart';
part 'util.dart';

// ...Code might go here...

The second file, ball.dart implements part of the ballgame library:

part of ballgame;

// ...Code goes here...

The third file, util.dart, implements the rest of the ballgame library:

part of ballgame;

// ...Code goes here...

Enough said...

No actually, let me explain.

IMHO, I'm not sure why this functionality was included, because it limits "findability" in a very big way. I would see this sort of code as a smell.

For example, you're looking for a specific function in a library. But it might be in the one of many text files linked to the library. So you not only have to do a "find" in one file, but you'd have to repeat it in many files. For people who like vim, Sublime or Textmate, sorry but you're royally screwed without plugins.

Now, the Dart guys will turn around and say, "Hey, you can use our free & cool Dart Editor and press F3 to go to the declaration under cursor". But I can tell you that if you can't use a simple text editor, you're making things too complicated and alienating a whole bunch of developers.

Plus if enough newbs think this is an awesome feature and stuff a ton of functions into one library through a hundred part of files (OK slightly exaggerating), we won't have modular libraries, but big ugly libraries that make the world a sadder place.

Now imagine debugging this sort of code in a web browser.

Or better yet, reading it in Bitbucket or Github...

This is a big one for me. I would have to say that reading other people's node.js code in Github has been a really great experience. I would probably include Python in there as well (except for code with import *). Other languages usually have me wondering where a particular function exists, which is a big time waster.

I can see Dart failing at this with its global import, part & part of statements. For a decently sized project, you'd have to clone the source code and use the editor to jump through various files to understand what is going on.

In the spirit of being terse...

I could expand alot more on the points below, but this article would get ridiculously long. Instead, I've provided links and my personal thoughts where necessary:

Making Javascript less weird = awesome!

  • Effective Javascript is a good book, but it's also why Javascript is painful for newbs.
  • Truthy and falsy values are simplified in Dart, which IMHO improves readability.
  • Forgetting the new keyword for constructor functions in Javascript results in unpredictable behaviour. Dart doesn't have that problem.
  • Some may like the prototype system in Javascript, but I think it's probably caused more trouble than it's worth (and yes, I'm very familiar with how it works). Dart goes back to a more traditional OOP paradigm.

Dart wins

  • cascade operator (..)
  • named parameters
  • operator overriding
  • optional typing
  • multi-line strings & string interpolation (CoffeeScript already does this well, but Javascript doesn't yet)
  • Better debugging with Dart Editor

Details for the above are covered in http://www.dartlang.org/docs/dart-up-and-running/contents/ch02.html and other places.

Promises

One area where I feel Dart shines is taking futures/promises & streams seriously. Compared to node.js, I feel that promises read better than callbacks.

Now someone in the node.js community might say, "we have loads of awesome promises libraries". I'd say that's great, but I'm reluctant to use them.

Why? If not implemented natively, promises do impact performance. Dart has it in core, so my guess is that the VM will optimize it to the hilt. But don't quote me... can someone do a benchmark and let me know whether Dart futures are at least equivalent in performance to callbacks? :-)

Performance is a feature, and a damn important one

What's needed

  • Indentation sensitive syntax (I seriously think this is a big win - eliminating all the various types of brackets makes code much faster to type & easier to read)
  • Profiler
  • REPL

Looking ahead

Javascript was forced upon the world because it was the only language available for client-side scripting. It was initially super horrible, but has improved by leaps and bounds over the years. It won by default.

Now Dart has come to compete with Javascript. I really like this. I don't get why Brendan Eich, Douglas Crockford, Microsoft, etc. are hatin' on it. Well, I know why they do, but it only keeps Javascript honest.

But how will Dart win? I can talk all day about the language and its pros and cons, but this is probably how it'll play out. Once Chrome is the dominant browser (already is in many parts of the world), Dart is available in stable Chrome (soon) and important apps like Gmail, etc. use it and demonstrate major performance improvements (especially on mobile devices), many others will jump on board. Plus with a quiet achiever like Lars Bak (who brought the world the Java Hotspot VM and V8), I think their chances are very good indeed over the next few years.

References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment