WhitherApps is a bandwagon-busting experiment. I believe there are far too many native client apps which could have been far better written as mobile web apps. What we’re going to try and do is take a few examples, apply a little reverse-engineering, and rewrite them, warts and all, with web technologies.
James has already produced three blog posts rewriting the BBC iPhone app but with HTML5 (Part I, Part II, Part III). I encourage you to read them. He’s already gotten impressively far; here is a screenshot of the HTML5 app so far:
The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes: a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code, ports of popular open source projects like zlib, Lua, and libjpeg, and a few samples that will help you get you started developing with the NPAPI Pepper Extensions. Taken together, the SDK lets you write C/C++ code that works seamlessly in Chromium and gives you access to powerful APIs to build your web app.
Salt and Pepper indeed. A friend at a browser vendor was looking into Pepper and thought that the specs were definitely….. thorough shall we say? Take Pepper Audio by itself. A bit of a beast! :)
It is interesting to watch Google give C/C++ developers (and legacy code) a different path to the Web (beyond NPAPI and… ActiveX!). You can imagine this being increasingly important when you think about Chrome OS.
Ideally, the Web platform itself evolves fast enough that this project is always an onramp for legacy code…. what do you think?
You would have guessed at most of these, but maybe not the WebSimpleDB/IndexedDB one. If a project has “simple” in the name, it normally isn’t…. just like when a project has “open” in the name. It is a strange name since we have simple storage through localStorage and friends.
IndexedDB is a better name, and it is interesting stuff. Instead of the SQL databases that require standardizing on a version of SQLite (which is insane) it is JSON native. You work with the data store like this:
and you can go native JSON with the object store:
Take a look at all of the low level cursor code and you may cry a little :)
Back to Firefox 4. The media loves a binary black vs. white view of the world. Flash is Dead. HTML5 is saviour. Chrome is “the winner”. IE is over. Regardless of any actual numbers.
Alpha geeks are big on Chrome these days, but Firefox has massive numbers and is still doing well, despite the fact that, in my opinion, better days are to come. Firefox will catch up on the technology side with multi-process and their new JagerMonkey VM work. Performance will become table stakes yet commodity. Where Firefox can shine is where no other browser will go. Mozilla is mission based and cares about users in a more holistic way. This is the empower goal. You should own your data. Your browser should do more for you (not just get out of the way). Firefox is uniquely positioned for this, and you can see the start of the work via the Contacts work from Mike Hansen.
Also note how the team is discussing Firefox 4. Totally in the open. What will Safari 5 have? Chrome 6? IE9 is doing a better job…. but no one does it like Mozilla. Fully open… and YOU can make a difference.
I look forward to the continued browser competition. Great news for us developers!
It was a busy day for Google news for web developers, in very different areas.
ANGLE
This is exciting. On the Chromium blog Henry Bridge announced a new open source project called ANGLE which is implementing OpenGL ES 2.0 on top of Microsoft Direct3D APIs for Windows folk. This is a big deal as you can’t assume good OpenGL drivers on Windows… but with ANGLE live could be better.
Why is this related to Chromium? WebGL:
We’re open-sourcing ANGLE under the BSD license as an early work-in-progress, but when complete, it will enable browsers like Google Chrome to run WebGL content on Windows computers without having to rely on OpenGL drivers.
Current browser implementations of WebGL need to be able to issue graphics commands to desktop OpenGL to render content. This requirement isn’t a problem on computers running OS X or Linux, where OpenGL is the primary 3D API and therefore enjoys solid support. On Windows, however, most graphics-intensive apps use Microsoft Direct3D APIs instead of OpenGL, so OpenGL drivers are not always available. Unfortunately, this situation means that even if they have powerful graphics hardware, many Windows machines can’t render WebGL content because they don’t have the necessary OpenGL drivers installed. ANGLE will allow Windows users to run WebGL content without having to find and install new drivers for their system.
Because ANGLE aims to implement most of the OpenGL ES 2.0 API, the project may also be useful for developers who are working on applications for mobile and embedded devices. ANGLE should make it simpler to prototype these applications on Windows, and also gives developers new options for deploying production versions of their code to the desktop.
NaCl allows you to gcc some code and have it run in a browser. Wooah :) The big news from that camp is new support for ARM which means NaCl for mobile….. and Chrome OS:
When we first released Native Client a year ago, we supported all popular operating systems (Windows, Mac OS X, and Linux) but only on machines with x86 processors. Today, we’re happy to say that you can build and run Native Client binaries for all of the most popular processor architectures: x86-32, x86-64, and ARM. Even better, our initial benchmarks indicate that Native Client executables perform at 97% of the speed of an unmodified executable on both ARM and x86-64 processors. These results indicate that a browser running on virtually any modern computer or cell phone could run a fast, performance-sensitive Native Client application.
However, we recognize that just running on today’s most popular architectures isn’t enough; if a new processor architecture emerges, it should be able to run all Native Client modules already released without requiring developers to recompile their code. That’s why we’re also developing technology that will enable developers to distribute a portable representation of Native Client programs using LLVM bitcode. Using this technology, a browser running on any type of processor could translate the portable representation into a native binary without access to the source code of the program.
Skipfish
For the security concerned …. how about running Skipfish “a fully automated, active web application security reconnaissance tool.”:
High speed: pure C code, highly optimized HTTP handling, minimal CPU footprint – easily achieving 2000 requests per second with responsive targets.
Ease of use: heuristics to support a variety of quirky web frameworks and mixed-technology sites, with automatic learning capabilities, on-the-fly wordlist creation, and form autocompletion.
Cutting-edge security logic: high quality, low false positive, differential security checks, capable of spotting a range of subtle flaws, including blind injection vectors.
Some cool news all around…. all Web… and all open source.
