Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

May 18 2012

Why I haven't caught ereader fever

iPad 2 illustrationO'Reilly GM and publisher Joe Wikert (@jwikert) wrote recently about how he can't shake his ereader. I read his story with interest, as I can't seem to justify buying one. I was gifted a second-generation Kindle a while back, and it lived down to all my low expectations. The limitations were primarily the clumsy navigation and single-purpose functionality. I loaned it to a friend; she fell in love, so my Kindle found a new home.

At this point, I do all my ereading on my iPad 2: books, textbooks, magazines, news, short form, long form ... all of it. I will admit, I found the new Nook Simple Touch with GlowLight that Wikert acquired somewhat tempting. The technology is much improved over the second generation Kindle, and though I haven't yet played with one in the store, I bet the execution is much more enjoyable. Still, my original hang-ups prevail.

First, I don't want to be locked in to one retailer. On my iPad, I have apps that allow me to read books bought from anywhere I choose. I can buy books from Amazon, Barnes & Noble, Apple and other smaller retailers, and they will all work on my iPad. True, this spreads my library around in a less-than-ideal organization, but the ability to buy books from anywhere is more important to me.

Also, I'm not so sure ebooks and ereaders will have a place down the road, making the value proposition of the investment that much less appealing. Much like the music journey from records to MP3s, digital reading technology is advancing, and perhaps at a much faster pace than its music counterpart. Jani Patokallio, publishing platform architect at Lonely Planet, recently predicted the obsolescence of ebooks and ereaders within five years, suggesting the web and HTML5 will become the global format for content delivery and consumption. And publications such as the Financial Times and MIT's Technology Review already are dropping their iOS and Android apps in favor of the web and HTML5.

I doubt my iPad will become obsolete any time soon. I look forward to the day books are URLs (or something similar) and we can read them anywhere on any device — and that day may not be too far off. I think I'm so attached to the iPad experience because it simulates this freedom to the best of its ability.

Ereader shortcomings also are likely to present a rich content hindrance, even before a shift to a web/HTML5 format gets underway. In a separate blog post, Wikert talked about a baseball book that missed its opportunity by not curating video links. He wrote: "The video links I'm talking about would have been useless on either device [his Kindle or Nook], but if they were integrated with the ebook I would have gladly read it with the Kindle app on my tablet." As publishers start realizing content opportunities afforded by digital, I think my iPad will serve me better than a single-purpose ereader.

Another hang-up I have, and this is likely to do with my general aversion to change, is the form factor. Most ereaders are somewhere around mass-market-paperback size, and the Nook Simple Touch and Simple Touch with GlowLight are nearly square. I prefer hardcover or trade paperback size — about the size and shape of my iPad. I might be able to get past this particular issue, but given the others I've mentioned, I just can't justify trying.

I will have to surrender to Wikert on the battery life and weight points — the one thing I really liked about the Kindle was its feather-light weight and the fact that during its short stay with me, I never had to charge the battery. I expect the surrender to be temporary, however. I have faith in our engineering friends — two years ago, a research team at MIT was using carbon nanotubes to improve the battery-power-to-weight ratio ... I can't imagine it will be too much longer before life catches up to research. In the meantime, I expect to remain happily connected at the hip to my iPad.

The future of publishing has a busy schedule.
Stay up to date with Tools of Change for Publishing events, publications, research and resources. Visit us at oreilly.com/toc.

Related:


March 21 2012

What is Dart?

By Kathy Walrath and Seth Ladd

Writing a web app can be lots of fun, especially at the beginning when you experience instant gratification: code, reload, repeat.

Unfortunately, finishing and maintaining a web app are not so fun. JavaScript is great for small scripts, and it has the performance chops to run large apps. But when a script evolves into a large web app, debugging and modifying that app can be a nightmare, especially when you have a large team.

Enter Dart, an open-source project that aims to enable developers to build more complex, highly performant apps for the modern web. Using the Dart language, you can quickly write prototypes that evolve rapidly, and you also have access to advanced tools, reliable libraries, and good software engineering techniques.

Even though Dart is young, it already has tools such as Dartboard (which lets you write and run Dart code in your browser) and Dart Editor (which lets you create, modify, and run Dart apps). A recently released SDK contains command-line tools such as a Dart-to-JavaScript compiler (which produces JavaScript that you can put in any modern browser) and a Dart Virtual Machine (the VM, which lets you run Dart code on servers). The latest tool to become available is a build of the Chromium browser, nicknamed Dartium, that contains a built-in Dart VM.


(Note: Dart is still changing. This article is correct as of March 2012,
but facts might change and links might go bad. For the latest information, see the Dart website.)

Why did Google create Dart?

We want you to be able to create great web apps. Great web apps improve the web, and when the web does better, everyone wins.

Engineers at Google have been thinking about web apps for a long time. We've written a bunch of complex and widely used large-scale web apps (think Gmail, Google+, and Google Docs), so we're quite familiar with the challenges of architecting web apps. We've also written a browser (Chrome) and a JavaScript engine (V8), so we've thought a lot about how to make web apps run faster.

Basically, we created Dart because we think it'll help bring more great apps to the web, and we think it should be easier to create more complex web applications.


Does the web really need another language?

App developers from all platforms should be able to build for the modern web, but many non-endemic web developers have different expectations and requirements from their language, tools, and development platform than what is available today. We believe there is room for a new platform, one that is not encumbered by 15 years of cruft, that is familiar to developers of different backgrounds, and that is structured to enable the larger, more complex apps that users are demanding.

We don't think JavaScript is going away. In fact, Google is actively working with TC39 to improve JavaScript, and new features are already landing in V8 and Chrome. However, our commitment to improving JavaScript doesn't prevent us from thinking about other solutions. For example, Dart will take advantage of the continued work on JavaScript, because Dart programs compile to JavaScript to run across the entire modern web.

We believe Dart is a compelling and familiar platform that meets the needs of developers from different backgrounds and experiences, including endemic web developers. We believe that Dart brings fresh ideas to web programming, and that innovation in both Dart and JavaScript will help push the web forward for app developers and users.


Show me the code

Enough talk, let's see some code. Whether you know JavaScript or Java, Dart code should look familiar. Here's an example of a simple web page in Dart:

hi.dart:

#import('dart:html');

main() {
document.query('#status').text = 'Hi, Dart';
}

hi.html:

...
<h2 id="status"></h2>
<script type="application/dart" src="hi.dart"></script>

<!--
If the browser doesn't have an embedded Dart VM,
you can compile Dart code to JavaScript.
-->
<script type="text/javascript" src="hi.dart.js"></script>
...

Now let's look at some Dart code that uses functions:

send(msg, to, from, [rate='First Class']) {
  return '${from} said ${msg} to ${to} via ${rate}';
}

main() => print(send('hello', 'Seth', 'Bob'));

> "Bob said hello to Seth via First Class"

The => syntax used to implement main() is a nice, compact way to implement a function that evaluates and returns a single expression. Without =>, the implementation of the main() method would look like this:

main() {
  print(send('hello', 'Seth', 'Bob'));
}

In the send() method implementation above, rate is an optional parameter with a default value. That method also illustrates string interpolation at work (${var}).

Here's some Dart code that's more object-oriented:

class Point {
  Point(this.x, this.y);
  distanceTo(other) {
    var dx = x - other.x;
    var dy = y - other.y;
    return Math.sqrt(dx * dx + dy * dy);
  }
  var x, y;
}

main() {
var p = new Point(2, 3);
var q = new Point(3, 4);
print('distance from p to q = ${p.distanceTo(q)}');
}

This code should look pretty familiar if you've ever used a class-based language.


How can I play with Dart?

The easiest way to try out Dart is to use Dartboard, a way to execute Dart code interactively in any modern browser. Dartboard is embedded in the Dart site, at www.dartlang.org. You can also use Dartboard by going directly to try.dartlang.org. Here's a picture of what you'll see on that site:

Dartboard

Change the code as you like, and then click the Run button (at the upper left). You'll see the results of your code in a new area below:

Dartboard

The URL at the upper right of the Dartboard is a link to the code you just ran.

Like most things related to Dart, Dartboard is still changing. For the latest information, see the Dartboard tutorial.


How about a real editor?

When you outgrow Dartboard, try Dart Editor. It's a downloadable editor for Windows, Mac, and Linux that lets you write, modify, and run Dart web apps. Dart Editor can run your Dart code via the VM, or it can compile it to JavaScript and launch it in your browser. Here's a picture of what Dart Editor currently looks like:

Dart Editor

To run any program in Dart Editor, just click the Run button while any item in that program's library is selected. If your program is a web app, Dart Editor launches Dartium (Chromium with an embedded Dart VM) to run the program. When you are ready to ship to production, the Dart Editor can compile it to JavaScript, making your app available to the entire modern web.

Dart Editor has several features to help you edit Dart code, and we expect more features soon. As you can see from the screenshot above, Dart Editor highlights Dart syntax. Dart Editor also supports auto-completion, and it can quickly take you to where types and other APIs are declared. You can also get a quick outline of your program's classes, methods, and fields.

See the Dart Editor tutorial for download instructions and a walkthrough.


What's new about Dart?

Now that you're all tooled up, let's talk about the language. We're not going to go into Dart's features and syntax in detail—you can read about all of that on www.dartlang.org—but here are a few of the more interesting features of Dart.

Optional typing: You can use types or not, it's up to you. Types in Dart code don't change the way your app executes, but they can help developers and programming tools to understand your code. You might not bother with types while you're developing a prototype, but you might add types when you're ready to commit to an implementation. An emerging pattern is to add types to interfaces and method signatures, and omit types inside methods.

Snapshots: Currently, browsers need to parse a web app's source code before that app can run. Dart code can be snapshotted—all its state and code recorded at a certain point in time—which can speed up startup considerably. In initial testing, a web app with 54,000 lines of Dart code started up in 640ms without snapshotting. With snapshotting, it started up in 60ms. When your Dart program is running in the Dart VM, it can see significant startup time performance improvements, thanks to snapshots.

Isolates: Dart supports concurrent execution by way of isolates, which you can think of as processes without the overhead. Each isolate has its own memory and code, which can't be affected by any other isolate. The only way an isolate can communicate with another isolate is by way of messages. Isolates allow a single app to use multi-core computers effectively. Another use for isolates: running code from different origins in the same page, without compromising security. For more details see Isolates, below.

Interfaces with default implementations: Ignore this one if you've never used a language that features classes and interfaces/protocols. Still here? OK. If you take a look at the Dart libraries, you'll notice that they use interfaces in cases where some other languages would use classes—for example, for Date and HashMap. This is possible because a Dart interface can have a default implementation—a class (usually private) that is the default way to create objects that implement the interface. For example, even though Stopwatch is an interface, you can call new Stopwatch() to get a default stopwatch implementation. If you look at the API doc or source code, you can see that the default implementation of Stopwatch is a class named StopwatchImplementation.

Generics, but easy: Generics have been done before, but they've been confusing. Dart takes a new approach by designing a generics system that's more understandable. The tradeoff is sacrificing a bit of exactness, but we believe that enabling developers to be more productive trumps ivory-tower language design. For more details see Generics, below.

HTML library: We also took a fresh look at how you should use the HTML DOM. (DOM is short for Document Object Model; it's the interface that lets you programmatically update the content, structure, and style of a web page.) By creating a native Dart library (dart:html) to access and manipulate the DOM, we made elements, attributes, and nodes feel natural to work with. More details are in the sections What libraries are available? and Manipulating the DOM.


Why does Dart look so familiar?

A cutting edge and unique language might be beautiful, but it would have maybe five users. Dart is designed for mass adoption, so it has to feel familiar to both scripting language users (such as JavaScripters) and structured language users (such as Java developers).

Still, Dart has some unique features for a language targeted at the mainstream. For example, interfaces with default implementations help with hiding implementation details. Optional typing, another new feature for the web, should help with more clearly annotating developer intention and interface and library contracts.


What is in the Dart platform?

Dart is more than just a language, it's an entire platform for modern web developers.

Language specification: The Dart language is familiar, with a few new features such as optional typing and isolates.

Libraries: Core libraries provide functionality including collections, dates, and math, as well as HTML bindings, server-side I/O such as sockets, and even JSON.

Compiler to JavaScript: You can compile Dart programs to JavaScript that can run across the entire modern web.

VM: The virtual machine is built from the ground up to run Dart code natively. The VM runs on the command line for server-side applications, and can also be embedded into browsers for client-side applications.

Integration with Chromium: The Dart VM has been embedded into a build of Chromium, nicknamed Dartium, allowing native Dart applications to run without first being compiled to JavaScript.

Dart Editor: This lightweight editor, complete with syntax highlighting and code completion, can launch your script in the VM or web app in Dartium. It can also compile your web app to JavaScript and run it in another browser.


Should I use Dart for my app today?

Dart is still changing, so for now, don't bet the farm on it. However, everything in Dart is open source and open to debate, so we encourage you to check out Dart and provide feedback. Once the language and libraries settle down (this year, if all goes according to plan) we expect that you'll be able to run production Dart web apps in all major modern browsers.


How do you expect people to use Dart?

You can use Dart to build complex, high-performance apps for the modern web. The Dart language is designed to work on the client and the server, which means that you can use it to implement a complete, end-to-end application.

You can also use Dart to scale your development as your program grows from a small set of functions to a large collection of classes. For instance, web development encourages extremely short development iterations. As you refine your idea and your program grows in scope and complexity, your code will probably need more modularity and encapsulation. Dart enables you to refactor from functions to classes, and from untyped code to typed code.

As for deployment, you have two options: compiling to JavaScript or using the Dart VM. For your client-side code, compiling to JavaScript enables your Dart code to run on modern browsers. A future version of Chrome will ship with an embedded Dart VM, allowing your Dart code to run directly in Chrome without first being compiled to JavaScript.


How can I compile to JavaScript?

To produce human readable JavaScript, you should use the Frog compiler (available in the Dart SDK). Still a work in progress, Frog generates JavaScript code that is small and performant.

For example, say you have the following Dart code:

class HelloWorld {
  yell() => print("hello world!!!!");
}

main() => new HelloWorld().yell();

Frog compiles that into the following JavaScript code:

//  ********** Library dart:core **************
//  ********** Natives dart:core **************
// ********** Code for Object **************
// ********** Code for top level **************
function print(obj) {
  return _print(obj);
}
function _print(obj) {
  if (typeof console == 'object') {
    if (obj) obj = obj.toString();
    console.log(obj);
  } else {
    write(obj);
    write('
');
  }
}
//  ********** Library dart:coreimpl **************
// ********** Code for NumImplementation **************
NumImplementation = Number;
// ********** Code for StringImplementation **************
StringImplementation = String;
// ********** Code for _Worker **************
// ********** Code for top level **************
//  ********** Library helloworld **************
// ********** Code for HelloWorld **************
function HelloWorld() {

}
HelloWorld.prototype.yell = function() {
return print("hello world!!!!");
}
// ********** Code for top level **************
function main() {
return new HelloWorld().yell();
}
main();

As you can see, the JavaScript code is straightforward.

To get the Frog compiler, download the SDK, which is available now in prerelease.


What libraries are available?

For now, Dart has three libraries that you can use:

dart:core

The basic APIs that all apps can count on, whether they're standalone scripts or inside the browser. These APIs let you perform operations such as:

dart:html

APIs for producing UIs for web apps. For example:

  • get global objects (document, window)
  • find HTML elements (Element's query() and queryAll())
  • add and remove event handlers (Element's on property)
  • operate on groups of objects using the built-in Dart collection interfaces

For an example of using this library, see the Manipulating the DOM section.

dart:io

Server-side APIs for connecting to the outside world. This library is accessible only when the Dart VM is running on the server. Examples:

You can see the API documentation at api.dartlang.org.

The community has also started porting libraries that you can use. For example, the crypto libraries from Closure have been ported to Dart. For game development, the popular Box2D physics engine has also been ported to Dart.


Show me more code

We've given an overview of Dart's most interesting features and shown some Dart code. Now we'll elaborate on a few of these features—types, generics, isolates, and DOM manipulation—and show yet more code.

Types

Up above, we showed this example:

class Point {
  Point(this.x, this.y);
  distanceTo(other) {
    var dx = x - other.x;
    var dy = y - other.y;
    return Math.sqrt(dx * dx + dy * dy);
  }
  var x, y;
}

main() {
var p = new Point(2, 3);
var q = new Point(3, 4);
print('distance from p to q = ${p.distanceTo(q)}');
}

You might notice that although the code defines and uses a class, it otherwise has no types. Types are optional in Dart. They don't change the way programs run, but they make the code more understandable by tools (such as debuggers and IDEs) and developers (such as your replacement, when you move on to an even better project). Think of types as annotations or documentation that can help tools and humans understand your intention better and catch bugs earlier.

We think a good place to start adding types is method signatures and interfaces—the “surface area” of your program. As more people are added to your project and more classes are generated, it's useful to know what types are used by (and returned from) methods.

Here's the previous sample with types added to the API definitions:

class Point {
  Point(this.x, this.y);
  num distanceTo(Point other) {
    var dx = x - other.x;
    var dy = y - other.y;
    return Math.sqrt(dx * dx + dy * dy);
  }
  num x, y;
}

main() {
var p = new Point(2, 3);
var q = new Point(3, 4);
print('distance from p to q = ${p.distanceTo(q)}');
}

Notice how we didn't add types to the method body of distanceTo(). An emerging pattern of idiomatic Dart is to use types for method signatures but not method bodies. Method bodies should be small enough to be easily understood, and we expect tools to perform type inference at some point. However, if you prefer to use types everywhere, you're free to change var dx to num dx, and so on.



Generics

If you haven't used generic types before—or maybe even if you have—seeing something like List<E> in the API reference might be a bit scary. Don't worry. Generics in Dart are easy peasy.

For example, if you don't care what types of objects are in a List, then you can create a list like this:

new List()

If you know that your list will only have one kind of object in it—only strings, for example—then you can (but don't have to) declare that when you create the List object:

new List<String>()

Why bother with the extra ceremony? Specifying what types your collection can hold is a good way to document to both your fellow programmers and your tools what your expectations are. The tools and the runtime can detect bugs early on.

(Fact: new List() is shorthand for new List<Dynamic>(). Dynamic is the type used behind the scenes for “untyped” variables.)



Here are examples of how Dart treats
different types and untyped collections.
If you're familiar with generics in Java,
pay close attention to the last two examples.

main() {
  print(new List() is List<Object>);
  print(new List() is List<Dynamic>);
  print(new List<String>() is List<Object>);
  print(new List<Object>() is! List<String>); // Not all objects are strings
  print(new List<String>() is! List<int>);    // Strings are not ints
  print(new List<String>() is List);          // TRUE! Every list of string is
                                              // a list
  print(new List() is List<String>);          // TRUE! It's OK to pass a List
                                              // to a method that expects
                                              // List<String>
}

The last two examples highlight Dart's covariant generics. Because you will run into untyped Dart code in the wild, the Dart language must allow you to treat an untyped List the same as a typed List, and vice versa.

As you may be able to tell from the code above, Dart's parameterized types are reified. This means that the generics aren't lost at compile time, so Dart truly knows that a List<String> is a “list of Strings”.

For more tips on using generics, see the Generics section of the Optional Types in Dart article. Also see the blog post Generics in Dart, or, Why a JavaScript programmer should care about types.



Manipulating the DOM

Revisiting the DOM to make it more Dart-esque has a lot of advantages. You can use elements and nodes as actual Dart objects, and you can loop through child nodes just like you can with other Dart collections.

For example, here's some code that finds a specific element and then performs various operations on the element and its children.

#import("dart:html");

main() {
// Find an element.
var elem = document.query("#id");

// Handle events.
elem.on.click.add((event) => print('click!'));

// Set an attribute.
elem.attributes['name'] = 'value';

// Add a child element.
elem.elements.add(new Element.tag("p"));

// Add a CSS class to each child element.
elem.elements.forEach((e) => e.classes.add("important"));
}

For more information, read the article Improving the DOM, and browse the dart:html library.



Isolates

Even though Dart is single threaded, you can still take advantage of multi-core machines by using isolates. An isolate provides memory isolation between different parts of a running program. Each isolate can run in a separate thread or process, managed by the Dart VM.

Isolates communicate by sending messages through ports. The messages are copied so that an isolate can't change the state of objects that belong to other isolates.

To illustrate isolates at work, let’s build a simple echo service. First we will define echo(), a function to run in an isolate. Each isolate has a port, which we can use to receive messages. We’ll reply to the message via the provided reply port.

The main() method creates a new isolate for the echo() function with spawnFunction(). Use the SendPort to send messages to the isolate, and listen for any responses using then().

#import('dart:isolate');

echo() {
port.receive((msg, reply) => reply.send("Echo: $msg"));
}

void main() {
SendPort sendPort = spawnFunction(echo);
sendPort.call("Hello, Dart!").then((response) => print(response));
}



Here's the output:

Echo: Hello, Dart!

We tested the preceding code on the Dart VM. In JavaScript, isolates compile to web workers so that they can run in separate processes. Isolates are still getting refactored, stay tuned for more updates.


Where can I learn more?

The main place to go for Dart information is dartlang.org.



Here are some places to get news about Dart:

You can discuss Dart at our main group.

Other official groups give you access to detailed information such as code reviews, commits to the source code repository, and issue tracker changes:

If you want to see how Dart is implemented or you want to become a contributor, check out the Dart open-source project.



And finally, here are some good interviews and videos about Dart:

Dart is getting ready. We encourage you to learn more about Dart, play with Dart in your browser, browse the API docs, enter feature requests and bugs, and join the discussion. Please give it a try. We look forward to your feedback.


Fluent Conference: JavaScript & Beyond — Explore the changing worlds of JavaScript & HTML5 at the O'Reilly Fluent Conference (May 29 - 31 in San Francisco, Calif.).



Save 20% on registration with the code RADAR20

October 28 2011

Top Stories: October 24-28, 2011

Here's a look at the top stories published across O'Reilly sites this week.

Dennis Ritchie Day: October 30, 2011
Tim O'Reilly: "I don't have the convening power of a governor, but for those of us around the world who care, I hereby declare this Sunday, October 30 to be Dennis Ritchie Day."

You say you want a revolution? It's called post-PC computing
Spurred on by a Googler's rant against his own company and Apple's release of a new phone, a new OS and a new cloud infrastructure, Mark Sigal wonders what the "post-PC" revolution really looks like.

We're in the midst of a restructuring of the publishing universe (don't panic)
Hugh McGuire, co-author of "Book: A Futurist's Manifesto," explains why publishing's digital transformation goes way beyond format shifts. He also reveals nine ways the publishing industry will change over the next five years.

"Revolution in the Valley," revisited
With "Revolution in the Valley" making its paperback debut and the work of Steve Jobs fresh in people's minds, we checked in with Andy Hertzfeld to discuss the legacy of the first Macintosh.

What to watch for in mobile web apps
Sencha's James Pearce discusses the most promising mobile web app technologies and explains why device APIs could make the web a lot more interesting.


Velocity Europe, being held November 8-9 in Berlin, brings together performance and site reliability experts who share the unique experiences that can only be gained by operating at scale. Save 20% on registration with the code RADAR20.

June 21 2011

How is HTML 5 changing web development?

Although still in draft form, HTML5 is seeing widespread adoption and implementation. But there's still a fair amount of pushback and skepticism about whether HTML5 is really ready for production.

At a session at OSCON next month, Left Logic's Remy Sharp will address this. Sharp's OSCON workshop will dive into HTML5 technologies that are already in production.

I recently asked Sharp about how HTML5 is changing development, in terms of what's developed and how. Our interview follows.


How is HTML5 going to change web apps?

Remy SharpRemy Sharp: We're going to see JavaScript being used to push further and further out of the old confines of the browser. We'll also see more applications that work without an Internet connection.

The more APIs that the browser gives us, the more the idea of the browser fades away. There are APIs to access the file system and we can do drawing and photo editing and save the files to our computers. There are APIs that are just making their way in to the wild that give us access to the webcam and microphone — all natively — with JavaScript.

We're seeing it already, but with time, I believe people won't access the web apps through the gateway of the browser. The "browser" part will be invisible and the web app will just be part of the computing experience.

What is HTML5 going to make easier? How is it going to aid performance?

Remy Sharp: I see HTML5 and related specs as heavily focused on the JavaScript. The HTML5 spec used to be called "Web Applications 1.0," and it shows given the amount of APIs that have been specified out of that process.

So to me, as a web developer who spends most of his time in JavaScript, HTML5 and related specs, this make doing a lot of things easier.

For example, adding audio and video is a doddle. Adding real-time two-way communication between the client and the server is a matter of a few lines of code and it has an extremely low barrier to entry.

OSCON JavaScript and HTML5 Track — Discover the new power offered by HTML5, and understand JavaScript's imminent colonization of server-side technology.

Save 20% on registration with the code OS11RAD

As for performance, I see it improving in two key places: first, the browser won't have to rely on external plugins for more advanced applications. This reduces the work the browser needs to do, and the amount of work JavaScript would have to do, if indeed the technology is baked directly in to the browser. More practically there's a number of APIs that allow data to be stored on the client side, allowing for local access to data or website assets. Removing this dependency on the server for data and assets (like images, CSS, JavaScript, etc.) increases the free resources the browser has for doing other things, like rendering the page and responding to the user.

Second, the time required to develop will decrease since the learning is limited to HTML, CSS and JavaScript. If my company wants me to create a branded video player for their website, it's just CSS. If I want to learn how someone has built a branded video player, I just view the source.

Developing for a multitude of browsers has long been the bane of web development. Is HTML5 going to make this simpler?

HTML5 logoRemy Sharp: HTML5 first and foremost gives developers a consistent specification that all the browser vendors can work from. HTML4 didn't have this. In fact, some of the key technologies we rely on today were reverse engineered into specs, which is why we see subtle differences. HTML5 is specified right down to the tiniest detail, ensuring that all the browser vendors are singing from the same hymn sheet. This means that new HTML5 APIs are easier to work with, since the implementations are the same.

As for making it easier to work with browsers: on-going that's certainly easier, but today's development and browser wrangling remains the same. That said, we're better off than we were 10 years ago. Developers' approaches to JavaScript have matured, and more developers are relying on clearly maintained libraries (jQuery, although having nothing to do with HTML5, is a perfect example of this).

When developing an application that solves a problem using a new technology that's part of HTML5, or even not part of HTML5 — like geo-location or Web Sockets — we developers can rely on polyfills: micro-JavaScript libraries that mimic future APIs by providing fallback support to "older" browsers. This means I can write my markup to use the new HTML5 elements, and a JavaScript polyfill can trigger IE8 to allow me to style those new elements.

Most importantly, HTML5 and related APIs provide native technology that means I, the developer, do not have to rely on Flash or some other plugin technology to solve the problem I've been faced with. I only have to learn open web technologies and I'm able to create interactive, real-time, graphics-rich web applications — should I chose to.

This interview was edited and condensed.



Related:

April 29 2011

Open question: Would you rent a laptop?

questionmarkAmid rumors that Google will soon release its Chrome OS-based netbook there are also rumblings the laptop will be available on a subscription basis. A post on technology news site Neowin last week stated:

Neowin can now confirm from a reliable source that the Google Chrome OS based notebooks will be available for "purchase" in late June/early July ... Google will be selling the devices as part of a subscription based model with Gmail to customers.

Neowin's Google source also spilled rental fee details: "$10-$20 a month per user," and this would include hardware updates and repair as necessary.

Interesting concept — a sort of laptop democratization. The expected laptop will be cloud-based and make use of Chrome apps.

This begs a couple of questions:

  • Would you rent a laptop?
  • Would a cloud-based device like this suit your laptop needs?

Please share your thoughts in the comments.



Related:


March 24 2011

Ubiquity and revenue streams: How HTML5 can help publishers

As technology makes the publishing space more and more geek-oriented, understanding how particular technologies can apply and how existing products or content can be adapted might seem to require a computer science degree.

In a recent interview, Google senior user experience designer Marcin Wichary brought one of those technologies — HTML5 — into perspective, explaining how it applies to publishers.

In design and layout, there's a lot of things that HTML5 now does natively, without you having to hold its hand. Things like multimedia are native to HTML5 — you don't need extensions or plug-ins; they're integrated really well.

We have new devices like the iPad that require new input methods like multitouch or shaking the device. All of this is or will soon be supported by HTML5. So you can imagine delivering an experience through your application or your website or your publication that rivals that of a native application on any of the platforms you want to put it on.

On top of that, it's the web. Al of the things that have been available on the web you also have as well. All the social networking, all the APIs, all the integration with other surfaces — you can just plug it in the way you want.

Wichary also explained how publishers can monetize the opportunities HTML5 brings to the table, and how it might even save money in the long run.

It's very important to recognize that HTML5 fits all the devices you can think of, from the iPhone in your pocket to Google TV to the tablets to small screens and big screens. It's very easy to take the content you already have and through the "magic" of HTML5, refine it so it works very well within a given context. You don't have to do your work over and over again. Of course, all of these different means come with different monetization opportunities, like ads on the web or on mobile devices.

In the interview, Wichary also addressed how publishing workflows might be affected by HTML5 implementation and he outlined specific advantages HTML5 can bring to digital reading. The full interview is available in the following video:



Related:


January 05 2011

November 02 2010

Four short links: 2 November 2010

  1. Lessons from the Johnny Cash Project -- When a participatory activity is designed without a goal in mind, you end up with a bunch of undervalued stuff and nowhere to put it. (via Courtney Johnston)
  2. Doom iPhone Review -- fascinating explanation of how the iPhone works for programmers, and how the Doom source code works around some of the less-game-friendly features. (via Tom Carden on Delicious)
  3. The 8 Pen -- new alphanumeric entry system for Android.
  4. Salesforce Security -- lots of information for web developers, most generally applicable. (via Pete Warden)

April 19 2010

April 02 2010

iPad and ebooks: Lots of unanswered questions

Right now people are conflating the whiz-bang demos from Wired, Penguin and the magazine world with the iBooks offering. In fact, no one can say anything right now other than that iBooks uses the EPUB format. Will books from iBooks be able to include custom fonts? Video? Audio? All unknowns.

iPad CoverageIf it's true that books in the iBookstore can include video, for example, what kind of video? Adobe promotes Flash video for use in EPUB, but of course there's no Flash in the whole iPad/iPhone ecosystem. So yes, EPUB is a standard, but the kind of content that would really showcase a tablet versus an E-Ink reader -- like video -- seems to have already fragmented before the device even hits the marketplace. That kind of fragmentation is going to deter publishers from doing much more than what they're already doing: making text-only EPUB for wide distribution, and doing the occasional book-as-app experiment (at a premium price point).

We're already seeing the tension between Apple's own interests and their control of the App Store with the announcement that many apps (notably the Kindle) won't be available in the App Store on release of the iPad because they haven't been able to test on a real device. And then ... how long until they release? That's totally up to the Apple approval process.

In our development of an HTML5-based web app, we've found that hardware profiles are key to making web apps really compete. Ibis Reader isn't nearly as compelling on an older iPod Touch as it is on an iPhone 3GS. By providing what is apparently a really sexy tablet that's capable of running video and games fluidly, Apple also widens the playing field to let web apps shine too. As the hardware increases in capacity, web apps become increasingly attractive as an end product, not just as a way for web developers to play in the app space.

December 30 2009

Four short links: 30 December 2009

  1. How to Run a Meeting Like Google (BusinessWeek) -- the temptation is to mock things like "even five minute meetings must have an agenda", but my sympathy with Marissa Mayer is high. The more I try to cram into a work day, the more I have to be able to justify every part of it. If you can't tell me why you want to see me for five minutes, then I probably have better things to be doing. There may be false culls (missing something important because the "process' is too high) but I bet these are far outweighed by the missed opportunities if time isn't so structured.
  2. Computer Science Education Week -- December 5-11, 2010, recognizes that computing: Touches everyone's daily lives and plays a critical role in society; Drives innovation and economic growth; Provides rewarding job opportunities; Prepares students with the knowledge and skills they need for the 21st century." Worthy, but there's no mention of the fact that it's FUN. The brilliant people in this field love what they do. They're not brilliant 9-5, then heading home to scan the Jobs Wanted to see whether they could earn more as dumptruck drivers in Uranium mines in Australia. CS isn't for everyone, but it won't be for anyone unless we help them find the bits they find fun.
  3. Installing EtherPad -- step-by-step instructions for installing EtherPad, the open-source real-time text editor recently acquired by Google.
  4. Victorian Infographics -- animals, time, and space from the Victorians. It's beautiful, it's meaningful, it must be infoengravings.

December 22 2009

Four short links: 22 December 2009

  1. Trading Shares in Milliseconds (Technology Review) -- With the rise of automation, the bulk of U.S. stock trading has moved from the once-crowded floor of Manhattan's New York Stock Exchange (NYSE) to silent server farms run by exchanges and broker-dealers across the country: the proportion of all trades that the NYSE handles has shrunk from 80 percent in 2005 to 40 percent today. Trading is now essentially a virtual art, and its practitioners put such a premium on speed that NASDAQ has considered issuing equal 100-foot lengths of cable to the brokers who send orders to its exchange servers. (via Hacker News)
  2. Stream iTunes Over SSH -- short script that lets you tunnel itunes from one machine to another over ssh (by default iTunes only shares on the local network).
  3. Doodle -- simple way to schedule a common meeting time. (via joshua on Delicious)
  4. Crowdsourcing -- Simon Willison's thoughtful "lessons learned" from his crowdsourcing projects at the Guardian. Crowdsourcing is not as simple as "give them a wiki and they will fill it" (this is related to the failed "everyone in the world wants to work on my broken payroll system" theory of open source), and Simon explains some of the subtleties. The reviewing experience the first time round was actually quite lonely. We deliberately avoided showing people how others had marked each page because we didn’t want to bias the results. Unfortunately this meant the site felt like a bit of a ghost town, even when hundreds of other people were actively reviewing things at the same time. For the new version, we tried to provide a much better feeling of activity around the site. We added “top reviewer” tables to every assignment, MP and political party as well as a “most active reviewers in the past 48 hours” table on the homepage (this feature was added to the first project several days too late). User profile pages got a lot more attention, with more of a feel that users were collecting their favourite pages in to tag buckets within their profile.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl