Chris Buckett

Congratulations everyone, and thanks for some great questions.

Can you comment on the development cycle in the context of Dartium/Chromium?

Once you have Dartium, then you can using any text editor, you would have an .html file and one/more .dart files. Press Save in the text editor, Press reload in Dartium to see the results (in other-words, a similar development cycle as with JavaScript).

Once you add the Dart Editor, though, you get extra goodies, as the Editor and Dartium have two way communication:
- Dartium logging to appear in the editor's log window
- CSS can be "live edited" in the editor, with the results instantly visible in Dartium
- You can set breakpoints in the Editor and step through code that is running in Dartium, viewing watched variables and stack tract

All this has the same workflow as any other text editor (ie, edit, save, reload), but with benefits.

While the editor is running, you can also copy/paste the URL to your app from Dartium into a non Dart browser (Chrome, Firefox, IE), and the Dart Editor will automatically convert your Dart code to JavaScript (including outputting source-maps).



(To over-egg one's pudding is to try to over-improve it)

"Easier" is a little subjective, but on the basis that (IMHO) Dart makes web programming easier by providing typing and structure to your applications, then yes, it makes WebGL easier. The same browser APIs that are available to JavaScript are available to Dart. Dart's Editor also has autocomplete functionality, which is great for helping to learn new APIs.

You might want to take a look at some of the links on this answer to a similar question to find out more about creating apps with Dart + WebGL.

Great that you managed to work out your issues, and that you're giving Dart a try. Let me know if you're having any more problems.

The api docs at http://api.dartlang.org are a great reference.

Is there a tutorial about how to create a complete WebSockets applications on Dart?

Yes - Chapter 14 of Dart in Action

How do I develop the server side application and integrate it with Dart on client side?

That's a big question, but happily the entire part 4 of Dart in Action deals with answering this exact question.

Does the Dart VM offer an easy way to develop WebSockets communication?

Yes, the server-side Dart VM has a full server-side sockets support and a websockets API that you can use to communicate with other systems (and browsers).

Hi,

There are various resources on the web for using WebAudio, and most of the APIs are similar (if not the same as) the JavaScript.

You may be interested in the simple_audio Dart library, described here, with an example here.

For a more general intro to web audio, take a look at this article on html5rocks

In other words, Dart brings structure to your apps, but the HTML5 APIs themselves are unchanged.

Hi,

According to this document: https://developers.google.com/native-client/devguide/coding/message-system, native client uses postMessage to communicate with JavaScript.

PostMessage is one of the ways (described in Dart in Action), that Dart itself communicates with JavaScript, so the same principal would also apply to NaCli.

Hi,

Unfortunately I don't know the answer to that question. I would suspect that you would get something more akin to the "immediate window" in Eclipse appearing in the editor rather than a Dart console.

This issue on http://dartbug/1406 (specifically answer #2) gives some more background.

No, and Yes!

Ok, so it depends what you mean by desktop app. If you mean something that compiles Dart code to a native .exe or binary, and has bindings for things like QT, Swing or WPF, then no, you can't build a "desktop app" with Dart.

On the other hand, if your definition of a desktop app is an app that can be installed, has it's own icon on the desktop, runs independently of a web browser, then the answer is definately Yes - using Chrome Packaged Apps.

Chrome Packaged Apps allow you to use modern web technologies to write an offline/online application in HTML, CSS, Dart/JavaScript. They are hosted in a Chrome process, but not within the Chrome browser itself. They get access to a wider range of APIs, such as USB, Serial ports, filesystem etc.. You can install chrome packaged apps for Win / Mac / Linux (from the same source-code). They have their own "skin", ie, they aren't visibly running inside a web browser. This gives you a "native" feel to the app, whilst still being able to write the app using web technologies.

(The book, Dart in Action has a chapter dedicated to using Dart to build an "offline first" application, and installing it in Chrome. The Chrome Package App is the next step on from this).

Want a demo... check out a recent blog post which contains a few video clips, some instructions, and a link to the Chrome Packaged Apps developer documentation.

Hi,

You don't need Dartium to run Dart applications: applications written in Dart will run in any modern browser.

Dartium is useful, however, to provide live debugging support and integration with the code editor - in other words, at present, it makes a great developer tool.

Rest assured, though, that the Dart VM will make its way into Chrome, however as Dart (the language, and Dart the VM) is still pre 1.0, it won't happen just yet, I would expect it to happen after some time after Dart reaches version 1.0 - earlier announced in an interview that 1.0 is hoped to happen this year - caveat: schedules always change

Once Dart does get into Chrome, you can expect the performance of the VM to surpass that of JavaScript, opening up greater possibilities for developers to perform a wider range of processing - something particularly of interest to game developers.

(And don't forget that Chrome is also available on Android, and an ARM port of the Dart VM is under way... draw your own conclusions)

Hi,

I can't comment on the "best", but I'll take this opportunity to point out that anything you can do with JavaScript you can do with Dart. This means that both the canvas and WebGL is available to Dart Developers.

What can you do to get started with 3d Dart programming?

1. Check out these samples on three.dart (a port of the three.js framework)
2. Check out John McCutchan's dartgamedevs blog
3. Watch this youtube: Developing Structured 3D Applications with Dart and WebGL.
4. Have a look at some of these lessons.

Have fun!

If you're already familiar with coding Java, then you'll find coding Dart a breeze due to it's class based nature. You can write Dart code that looks almost like Java. Example:

class Animal { int legs; // public field String _name; // private property String get name => _name; // getter set name(value) => _name = value; // setter Animal(this.legs) { // constructor, automatic initialization name = "Nameless"; } } class Dog extends Animal { // inheritance Dog() : super(4) { name = "Fido"; } } main() { Animal spider = new Animal(8); spider.name = "Incy Wincy"; print(spider.legs); // 8 Dog dog = new Dog(); print(dog.legs); // 4 print(dog.name); // Fido var otherDog = new Dog(); // var also works... query("#myDivId").innerHtml = dog.name; // update something in the browser... }

You get the advantages of JavaScript (ie, browser-based) + jquery (consistent access to the DOM with the dart:html library), node.js (Dart has a server-side VM as well), and sane library and packages.
With regards to Ruby, Dart has some of the similar functionality, especially around "noSuchMethod" - which is similar to Ruby's method_missing (which helps with much of the magic behind Rails).

So, Java-like productivity in the language, javascript+jquery access to the browser, nodejs like Dart VM on the server side. What's not to love

Hello, and Thanks!

It's interesting to watch this language grow - most other languages were released further into their development cycle, and Google have certainly not always gained great press by developing this language "in the open".

One of the great things about Dart is that you can take a server-side Java developer who's tried JavaScript and stepped away saying "don't take my tools away from me...", and put them in-front of Dart, with it's rich tooling (standalone editor, Eclipse plugin, or JetBrains IntelliJ / Webstorm plugin anyone?), traditional OO paradigms (but still with a splash of functional programming), and easy consistent access to the browser DOM, and they will "see the light" of web development open up in front of them*




(*Am I over-egging the pudding....?)

Hello!

1. Integrating with existing code.

Dart can interop with existing JavaScript, and vice-versa, but you need to have a mental model of the two worlds being separate. In practice, this is because the Dart VM and the JavaScript VM co-exist in the browser, even when Dart is converted to JavaScript. This means that calling from one to the other is an async operation, with listeners and callbacks on each side of the fence as required.

A good use case for interop with an existing app might be when you want to add a new feature to your app, perhaps distinct from existing code - think something like a live news ticker. Your page might already be receiving news feeds via ajax - you could use that same javascript to pass data over to the Dart app (or perhaps in reverse, use code written in Dart to retrieve the data and pass it over to an existing JavaScript component for display).

(I'm not able to comment directly on ClojureScript, so I'll compare with JavaScript)...
Dart is as functional as JavaScript. By this, I mean that you can write Dart code almost the same as you would write JavaScript, by ignoring the fact that Dart has classes and storing all your object's data and methods in maps, and returning closures to represent private methods, and other "hacks" like that. Dart's funtions are first-class For example, the following is valid Dart:

getFunctionMap() { var greeting = "Hello"; // assign a function into a variable var foo = (msg) { print("$greeting $msg"); // closurization of greeting } var bar = foo; // assign function to another variable // call the function bar("World"); // prints "Hello World" // store the functions in a map var mymap = {"fooFunc":foo,"barFunc":bar}; // call a function stored in the map mymap["fooFunc"]("World, Again"); // prints "Hello World, Again" return mymap; } main() { getFunctionMap()["barFunc"]("Dart"); // prints "Hello Dart" }

Part of the design rationale for Dart is that seems familar, and there are a vast number of developers who will feel at home with Dart's imperative model, but enough FP that developers can learn another paradigm if they so wish.

Thanks,
Chris.

Hi, Good questions.

1. What problems does Dart solve, what gap does it fill...?

Today you can do things in the browser that people wouldn't have thought possible 10, or perhaps even 5 years ago. JavaScript was able to provide interactivity to web pages, but coding web applications is complex. Not necessarily more complex than server-side applications, but on the server side you have the help of tools that we all take for granted - tools such as static analysis, break and continue debugging, refactoring - these were non-existent for building browser apps.

If you write your JavaScript in a particular style, then you can take advantage of modern JavaScript IDEs and other tools, but they can only go so far - because the language was never designed for collaborative, large-scale team development projects. Here's an example of some javascript

function foo(a,b,c) { return a+b+c } // elsewhere in a large application // separated by thousands of lines of code // several developers // and two years... var result = foo(1,2,3);
I come along and change function foo by removing parameter b:
function foo(a,c) { return a+c; }

But my call foo(1,2,3) is still a valid function call, even with the altered function signature foo(a,c). The application doesn't break, but something is wrong. Poor programmer Bob comes along in 6 months time, and who's to say which is correct - the function or the call?

Building server-side applications, we're spoiled by the wealth of tools to detect these errors at the time the code changes. Sure, in an ideal world, you would have 100% unit test coverage of your client-side JavaScript. Sure, in an ideal world, we'd all be uber-experts in every JavaScript API we came across, and keep track of the breaking changes between versions. Sure, in an ideal world, we'd always be able to hire other uber-experts to work on our projects.

This is just one example that developers face every day with JavaScript. You can fix parts of it with commenting, code-reviews, unit-testing and more, but why not let the tools do some of this work (Answer, because JavaScript is so dynamic, and the running code can even be changed at runtime, you can't create tools to perform 100% static analysis without actually running the code.

JavaScript is still a great language, given all these problems, but in the same way as C is a great language. Higher levels of abstraction have been built on it, such as Java or C#, which help to ease some of the pain points. And so with JavaScript. Today, there are many languages that let you write in a higher level of abstraction: CoffeeScript, Dart, TypeScript to name a few recent ones.

GWT was created to solve the problem of client-side team-development, and getting Java developers proficient in building large-scale client-side apps without needing to worry about JavaScript. Another team created Closure Compiler, which also addressed the team-development aspect, buy using code comments to enforce structure.

It turns out, though, that JavaScript, because of it's dynamic nature, means that optimizing a browser virtual machine for super-fast JavaScript is challenging to say the least - partly because you can't make assumptions about the code from its structure - for example, the following valid JavaScript represents 1+1

+((+{}+[])[+[]]+(+{}+[])[+!![]]+(+{}+[])[+[]])

(ref: http://patriciopalladino.com/blog/2012/08/09/non-alphanumeric-javascript.html )

Enter Dart

In this section, I'll address Dart as a problem solver to the issues declared above, and also address the second question:

2. this site optimized for Dart... fragmentation...?

By designing a language with large-scale web development in mind, it is possible to address both parts of the story - developers can get a language that is designed for tooling, and VM builders can get a language that makes it easier to write optimizations for. Another design constraint is that Dart must always be able to compile to JavaScript.

The Dart VM is a browser virtual machine, rather than a rendering engine, and as the language is designed to compile to JavaScript, there should be no difference how the program runs (apart, perhaps, from speed). This means that you won't find websites that say "optimized for browser X" because the user experience will be the same (although the Dart apps will likely execute faster).

For Developers like you and I, we get to code in a language that is similar to Java or C#, and has the structure and tooling that we associate with server-side languages, but also has some of the dynamic nature of JavaScript, Ruby and Python. Using Dart's optional typing, you can throw together a quick prototype, using just as much type information as you would in JavaScript (ie, none), and later, add type annotations to improve the story for fellow developers and tools. When a third-party API changes, the tools will tell you that your code is broken. Autocomplete, sometimes called a "crutch", helps greatly when learning new or changed third party library APIs.

For customers and users of our apps, the quality, speed of development, and speed of execution will improve. Quality and speed of development, because we no-longer need to battle against the language, and speed of execution because of the faster virtual machine built into users browsers.

Finally, to see a 10 second clip of Dart running in Firefox and IE, take a look here (G+)

Does the book address these questions - yes, and no. These questions (and answers) are outlined in the introduction and early chapters, but then you crack on with learning some Dart - open forums such as these are much better places for that kind of 2-way discussion

Thanks!