Seth Ladd's Blog

I wrote a simple HTML5 game for my Google IO 2011 Introduction to HTML5 Game Development talk. The original game was written in JavaScript, and as an exercise I just ported the game to Dart. This post contains some lessons learned from the process. Background : The original JavaScript code for the game is open source, as is the new Dart code . Note : The Dart version doesn't have sound working, as the Web Audio API isn't currently working in Dart. Straight forward port The executive summary of the porting process is: it's pretty dang easy. Dart had two primary design constraints: it must be familiar to JavaScript developers, and it must compile to JavaScript. Having just ported over 574 lines of JavaScript to 554 lines of Dart, I can say that those two design constraints are being satisfied quite well. To be fair, I wrote the first JavaScript version with structured classes in mind (using JavaScript's prototype system) so it was easy to port to Dart's na

(This is Part 3 in a series about Dart. Check out Part 2, Function in Dart .) Warning : We expect the Dart libraries to undergo potentially sweeping changes before Dart goes to alpha. This document is relevant as of 2011-12-22. Intro Dart is a "batteries included" effort to help app developers build modern web apps. An important "battery" is the bundled core Dart libraries, providing common and rich functionality. Dart is building a solution for large, complex web apps, and providing well tested, integrated, and common libraries is key to helping a web app developer be more productive out of the box. The Collection libraries are a crucial set of APIs that Dart developers get for free. Much more than simple arrays and maps, the Collection library includes standard ways to filter, iterate, inspect, compose, and sort your data. This post specifically looks at List<E> , Dart's ordered, indexable collection of objects. Aside: The Dart project is lucky

Some slight clarifications, if I may, following a recent article on nettuts.com : Jeremy said: ” In addition, Dart retreats from the dynamism of JavaScript, and instead exists as a somewhat static language, where types can be checked at compile time, but are erased at runtime. ” While there are many ways to interpret “dynamism”, it’s true that Dart doesn’t have extremely dynamic features like “eval” or the ability to arbitrarily change object structure. However, it’s important to point out that Dart is an optionally typed language, allowing a developer to write as much or as little static type information in the code as they wish. This was a pragmatic decision (as there are plenty of web developers that have been writing great untyped code, and who probably don’t want to see a type), however we also think optional typing allows a program to grow over time (as complexity increases, types can help with documentation and tools.) Types aren’t erased at runtime, values still have th

(This is Part 2 in a series on Dart. See Part 1: Variables and optional types in Dart ) While it's true that Dart is an object oriented, class based, single inheritance language with interfaces, there's nothing forcing you to use classes. If you haven't seen a class in your life, or you don't want to use classes, you will be pleased to see that Dart can function quite nicely with, well, just functions. Basics The most simple function I could come up with: hello() => 'world'; The  => e  syntax is shorthand for a function body of the form  {return e;} . The above is the same as: hello() { return 'world'; } Notice how the return type is omitted. Dart is an optionally typed language, so the programmer is free to omit static type declarations. The above is the same as: Dynamic hello() { return 'world'; } The Dynamic type is the "unknown" type. From the spec: "If no static type annotation has been provided

I've been talking to different people interested in Dart , and a pattern is emerging. It's becoming more clear that Dart is appealing to application developers who are interested in building modern web apps. My theory is that Dart's adoption will accelerate most quickly from developers looking to build apps. Bringing more apps to the web is a very good thing and is crucial for the long term success of the web. Right now, it's easy to argue that when software developers hear the word "apps" they think of mobile native apps. This is dangerous for the web, because if developer mindshare shifts away from the web as a place to deliver high fidelity and engaging application experiences, the web runs the risk of slowing its evolution and remaining stuck as a document platform. Of course, the web has done tremendously well as a document platform. It's clearly the most successful and widely distributed information platform we've seen. To be fair, the web is