Archive for the ‘Web Apps’ Category

File Under: Browsers, Mobile, Web Apps
Aug
24
2011

Mozilla’s WebAPI Wants to Replace Native Apps With HTML5

By

Mozilla has launched an ambitious new project aimed at breaking down the proprietary app systems on today’s mobile devices. The project, dubbed WebAPI, is Mozilla’s effort to provide a consistent, cross-platform, web-based API for mobile app developers.

Using WebAPI, developers would write HTML5 applications rather than native apps for iOS, Android and other mobile platforms.

Mozilla isn’t just talking about WebAPI, it’s already hard at work. It plans to develop the APIs necessary to provide “a basic HTML5 phone experience” within six months. After that the APIs will be submitted to the W3C for standardization.

Among the APIs Mozilla wants to develop are a telephone and messaging API for calls and SMS, a contacts API, a camera API and half a dozen more.

If those APIs sound vaguely familiar it might be because the W3C’s Device APIs Working Group is covering similar ground.

So, why the new effort from Mozilla? Well, Mozilla’s WebAPI is a part of its larger Boot to Gecko Project, which aims to eventually develop an operating system that emphasizes standards-based web technologies. With that end goal in mind, WebAPI may end up somewhat different than what the W3C is trying to build.

It’s also possible that Mozilla simply doesn’t want to wait for the Device APIs Working Group. Mozilla wants WebAPI up and running in a mere six months, the W3C’s Device APIs Work Group is unlikely to move that fast. But “the idea is to collaborate with W3C and all players and together form a good solution, and not just dump it on them,” says Mozilla Technical Evangelist Robert Nyman in a comment on his post announcing WebAPI.

The dream of write-once, run-anywhere software is nothing new and, if history is any guide, Mozilla’s WebAPI efforts may well be doomed. The open source giant does have one thing going for it that most other efforts have not — the open web. Most write-once, run-anywhere attempts have come from companies like Adobe and were built around proprietary frameworks. WebAPI doesn’t suffer from vender lock-in the way some projects have. WebAPI’s main roadblock is convincing other mobile web browsers to support the APIs.

For WebAPI to appeal to developers, Mozilla will need Apple, Google and other mobile browser makers to implement the APIs so that WebAPI can compete with native applications. Before you dismiss that as an impossibility, bear in mind that Apple’s original vision for iOS app development was based around HTML applications, and you’d be hard-pressed to find a company more eager to embrace web apps than Google. Whether either company will devote any resources to implementing WebAPI remains to be seen. But if Mozilla can get WebAPI standardized by the W3C other browser makers would likely support it.

Mozilla’s plans for WebAPI are certainly ambitious, but the company is putting its money where its mouth is — Mozilla is currently hiring several full time engineers to work on WebAPI.

See Also:

Tags: , , ,
File Under: Multimedia, Web Apps
Aug
15
2011

Make Waves with WebGL Demo ‘Water’

By

WebGL Water Running in Chromium 14Web Developer Evan Wallace has released one of the more impressive WebGL demos we’ve seen.

Provided you’re using a capable browser (Firefox, Chrome or Safari), head on over to Wallace’s WebGL Water demo and be amazed.

If you stay abreast of the latest and greatest in web browsers you’ve probably heard of WebGL, an API for adding hardware-accelerated 3D rendering to the HTML5 Canvas tag. The WebGL API is based on OpenGL, a desktop graphics standard, which means WebGL will run on many different devices — your laptop, your phone, even your TV.

Firefox 6+, Google Chrome and the latest version of Apple’s Safari all support WebGL (in Safari you’ll need to enable WebGL under the developer tools menu). There’s also an experimental build of Opera with WebGL support.

If you’re stuck with Internet Explorer, Vimeo user Ivan Enderlin posted this video which shows Firefox rendering the WebGL Water demo.

WebGL water, by @evanwallace from Ivan Enderlin on Vimeo.

Also, be sure to check out rest of Wallace’s website for some other WebGL demos, games and experiments.

See Also:

Tags: ,
File Under: JavaScript, Web Apps
May
18
2011

Yes Virginia, That Is Linux Running on JavaScript

By

Linux running in a JavaScript-based emulator

JavaScript never seems to get any respect. It’s not a real programming language, detractors complain, it’s just some script language that runs in the web browser. We’re not sure what makes JavaScript less “real” to some, but thanks to today’s web browsers, JavaScript has become a very powerful language. Powerful enough to run Linux in your web browser.

French developer Fabrice Bellard has built a JavaScript-based x86 PC emulator capable of running Linux inside a web browser.

If you’d like to try it out, point Firefox 4 or Chrome 11 to the demo page. Keep in mind that this is just Linux, no X Window or other graphical interface, just the command line, a small C compiler and QEmacs, Bellard’s emacs clone. Still, it’s really Linux, really running in your web browser, really using JavaScript to emulate hardware.

For more info on how Bellard did it, as well as what the hardware emulator supports, see Bellard’s technical notes.

Because the hardware emulation is built around the Typed Array spec, Bellard’s Linux experiment only works in those browsers that support JavaScript typed arrays, namely Firefox 4+ and Chrome 11+ (though a bug in Chrome 12 prevents it from working in the latest version of Chrome ).

Bellard is probably best known for founding the FFMPEG project, but unlike that very useful project, Bellard says his JavaScript-based Linux experiment has no real goals. “I did it for fun,” writes Bellard, “just because newer Javascript Engines are fast enough to do complicated things.”

That said, Bellard does have a few possible uses in mind, including serving as a benchmark for JavaScript performance (how fast can your JavaScript engine boot Linux?), client-side processing and perhaps, with a few improvements, running old DOS games and other software in the browser.

See Also:

File Under: HTML5, Multimedia, Web Apps
May
12
2011

Angry Birds Attacks Web … Web Wins

By

Angry Birds, currently one of the most popular games for iOS, Android and other platforms has made the leap to the web. Rovio, the company behind the game, has unveiled a web-based version of Angry Birds at Google’s I/O conference in San Francisco.

You can install the new Angry Birds for the web as an app in Google’s Chrome browser, or just play from the URL, chrome.angrybirds.com, which works just fine in any modern web browser. Just don’t hit that link if you’re planning to get any work done today.

Behind the scenes, the web incarnation of Angry Birds is powered primarily by HTML5. However, if you happen to have ditched Flash, you’ll notice that Angry Birds on the web won’t work.

What’s interesting is that the offending code appears to use gwt-voices, a cross-browser audio shim from Google. In theory gwt-voice only falls back to Flash when needed, but using the Aurora release of Firefox brings up a “You need to install Flash Player” message for Angry Birds (most likely because Firefox does not ship with mp3 support).

Calling Angry Birds an HTML5 app, is, in that regard, somewhat of a stretch.

Still, the primary rendering and logic of the game does use HTML5 elements like canvas, and HTML5 APIs like localStorage. The latter is interesting because it makes Angry Birds on the web hackable.

As per Rovio’s releases on other platforms, Angry Birds for the web offers in-app purchases for additional playing levels. But because Angry Birds uses the localStorage API, a clever dose of JavaScript will, at the time of writing, unlock the extra levels sans payment.

Welcome to the web, Angry Birds, where everything is hackable.

See Also:

Tags:
File Under: Programming, Web Apps, Web Services
Apr
25
2011

Lessons From a Cloud Failure: It’s Not Amazon, It’s You

By

Chaos Monkey will eat your cloud.

Amazon’s cloud-hosted Web Services experienced a catastrophic failure last week, knocking hundreds of sites off the web. Some developers saw the AWS outage as a warning about what happens when we rely too much on the cloud. But the real failure of Amazon’s downtime is not AWS, but the sites that use it.

The problem for those sites that were brought down by the AWS outage is the sites’ own failure to implement the one key design principle of the cloud: Design with failure in mind.

That’s not to say that Amazon didn’t fail rather spectacularly, taking out huge sites like Quora, Reddit, FourSquare and Everyblock, but as Paul Smith of Everyblock admits, while Amazon bears some of the responsibility, Everyblock failed as well:

Frankly, we screwed up. AWS explicitly advises that developers should design a site’s architecture so that it is resilient to occasional failures and outages such as what occurred yesterday, and we did not follow that advice

But perhaps the most instructive lesson comes from those sites that were not affected, notably Netflix, SimpleGeo and SmugMug. Netflix published a look at how it uses AWS last year and, by all appearances, those lessons served the company well, because Netflix remained unaffected by the recent failure.

Among Netflix’s suggestions is to always design for failure: “We’ve sometimes referred to the Netflix software architecture in AWS as our Rambo Architecture. Each system has to be able to succeed, no matter what, even all on its own.”

To ensure that each system can stand on its own, Netflix uses something it calls the Chaos Monkey (no relation). The Chaos Monkey is a set of scripts that run through Netflix’s AWS process and randomly shuts them down to ensure that the rest of the system is able to keep running. Think of it as a system where the parts are greater than the whole.

The photo sharing site SmugMug has also detailed its approach to designing for failure and why SmugMug was largely unaffected by the recent AWS outage. SmugMug co-founder and CEO Don MacAskill, echos Netflix’s redundancy mantra, writing, “Each component (EC2 instance, etc.) should be able to die without affecting the whole system as much as possible. Your product or design may make that hard or impossible to do 100 percent — but I promise large portions of your system can be designed that way.”

MacAskill also has strong words for those who think the recent AWS outage is a good argument for sticking with your own data center: “[SmugMug's] data-center related outages have all been far worse … we’re working hard to get our remaining services out of our control and into Amazon’s.”

“Cloud computing is just a tool,” writes MacAskill, “Some companies, like Netflix and SimpleGeo, likely understand the tool better.”

If you’d like to learn more about how designing for cloud services differs from traditional data-center setups, check out this excellent post on O’Reilly. Also, be sure to read Netflix’s advice and learn from Everyblock’s downtime by following the guidelines in Amazon’s own documentation.

Photo: Technically not a monkey. (DBoy/Flickr/CC)

See Also:

Tags:
« OLDER POSTS