This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of Real-World Software Development: A Project-Driven Guide to Fundamentals in Java and have Dr. Raoul-Gabriel Urma & Richard Warburton on-line!
See this thread for details.
Win a copy of Real-World Software Development: A Project-Driven Guide to Fundamentals in Java this week in the Agile and Other Processes forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Bear Bibeault
  • Liutauras Vilda
  • Devaka Cooray
  • Knute Snortum
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
  • salvin francis
  • Frits Walraven
  • Piet Souris

Questions on Dart for Chris Buckett

Posts: 1843
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Chris Buckett wrote:Dart is a new web language from Google, and aims to solve a similar set of problems that GWT solves,

Can you tell us some of the particular problems? Or, why is this language necessary/what gap does it fill? Does your book address those questions?

Dart runs in all modern browsers, whether using the Dart VM, or converted to "minified and treeshaken" JavaScript (which reduces deployed code size).

(Emphasis added.)

So, in other words, "this site optimized for browser X" (which embeds the Dart VM)? What's your stance on the issue of the potential for Dart to promote fragmentation?
Posts: 16
Google Web Toolkit Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

I come along and change function foo by removing parameter b:

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: )

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

permaculture is giving a gift to your future self. After reading this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!