First look: remakes mobile app development

The mobile Web framework runs faster than standard HTML and takes less development time than native code -- once you get up to speed

1 2 3 4 5 Page 3
Page 3 of 5

Finally, the context is first created virtually and then rendered. All the complexity of the render tree lives in the JavaScript data. The generated HTML is a flat collection of absolutely positioned <div> tags.

Transforms. Rather than rely on the slow HTML flow-positioning engine, uses matrix3d WebKit transforms to put the <div> tags where they should go. Transforms include translation, rotation, change of scale, and composition of multiple transforms. Transforms themselves are static, but modifiers (discussed in the next section) can change the application of transforms to renderable elements over time.

If you're a game developer, this will sound awfully familiar. basically renders elements in the same way a console game engine does. If you're primarily an HTML developer, you'll need to get used to this way of thinking to develop with -- but it probably won't take you long, especially if you've had enough math to be comfortable with matrices.

Render Tree. A render tree, which lives in the JavaScript code, consists of a root context, renderables, and modifiers. In addition to a plain surface, a renderable can be an image surface, an input surface, a canvas surface, a video surface, or a container surface (used for clipping nested surfaces). A modifier acts on all nodes below it in the render tree, controlling their layouts and visibility. Modifiers can be chained, which basically means that their matrices will be multiplied. Modifiers allow for changes in the size, transform, origin, and opacity of renderable elements. These are the attributes that the framework can change at its target speed of 60 frames per second.

Views. Writing every app from the ground up using basic renderable surfaces and modifiers is possible but violates the first principle of programming: Be lazy. Views are groups of renderable surfaces and modifiers that hide their internals. Views always have input and output event handlers for communication with the "outside world." There are half a dozen pre-built views in the framework at this point, to handle common uses like scrolling elements and grid layouts. More views are under construction, and it's easy for developers to subclass views to encapsulate desired behaviors.

Animations. In, applying a modifier over a span of time leads to an animation. The framework has two kinds of animations: easing curves (currently more than 30 are predefined) and physics transitions. Easing curves happen over a predictable, defined duration, whereas physics transitions take as long as needed given the parameters of the simulation. Physics transitions include spring, wall, and snap. In general, I find that physics-animated transitions feel more satisfying than ordinary easing and tweening animations.

Physics engine. In addition to defining physics transitions, the physics engine models bodies, forces, torques, angular momentum, particles, collisions, constraints, springs, snaps, walls, drag, repulsion, and so on. Negative repulsion is attraction, so you can, for example, model magnets.

In the long term, as more designers become involved in apps, I expect the physics engine to become more prominent. Most designers can visualize physical systems, although they may not be able to visualize mathematically defined curves unless they've seen them.

Figure 2: Toolbelt
Figure 2: The Toolbelt is a command-line utility for installing and updating projects. It includes a development Web server, linting capabilities, and the packaging of finished projects. Here we are updating an existing project in a Bash shell on a Mac.
1 2 3 4 5 Page 3
Page 3 of 5