Not sure if the whole WebGL thing will take off? Check out the video above which shows a simple scene constructed in blender and exported to GLGE for use in a WebGL capable browser.
GLGE is a javascript library intended to ease the use of WebGL; which is basically a native browser JavaScript API giving direct access to openGL ES2, allowing for the use of hardware accelerated 2D/3D applications without having to download any plugins.
The aim of GLGE is to mask the involved nature of WebGL from the web developer, who can then spend his/her time creating richer content for the web.
When I talked about some snow related CSS3 experiment, I could not imagine @Natbat was already preparing something like snowflakes, an almost fully CSS3 featured snow FX created for clearleft, specially suited for Chrome and Safari.
And what about @zacharyjohnson? He put snow all over the network via its Winternetizer, the first snow proxy I have ever seen.
Am I missing anybody? ... sure, me!
Above FX is dedicated to all Ajaxian readers and created via some CSS3 rule handled via JavaScript for a partial cross browser implementation. WebKit based browsers, included Android and iPhone, plus Firefox 3.6, should render properly, while the most interesting thing, snow a part, is that for the first time rather than browser sniffing, I have implemented a sort of "screen resolution to power computation" sniff:
Probably not perfect, the aim is to avoid same number of flakes in mobile devices, netbooks, or desktop PCs.
I guess one day we'll have exposed CPU model and RAM amount as read only userAgent properties, so that all new effects could avoid stress for web surfers.
Something like System namespace in ActionScript, with capabilities for audio and video and extra info about the current navigator ... maybe just an AS to JS bridge 'till that day? We'll see, today the important thing is simply one: Have Fun!
Want to show how to use your layout library? Why not mimic a well known layout and show how easy it is? That is what Volodya Kolesnikov has done with his Google Wave layout in 100 lines of code sample.
UKI is a fast and simple JavaScript user interface toolkit for desktop-like web applications. It comes with rich view-component library ranging from Slider to List and SplitPane. Here are some examples:
Uki works with IE6+, Opera 9+, FF 2+, Safari 3+, Chrome. And it looks the same on any of them.
Uki is still in its infancy. There may be bugs. No docs available. Certain features like disabled are still missing. Nevertheless it is already capable of build complex layouts in hours.
Steve Hanov has produced a Canvas-based drawing tool with a hand-drawn look. Lines can be drawn with a "sloppiness" option, with possible values "Draftsman", "Artist", "Cartoonist", "Child", and - perfect for this time of year - "Drunk" :). The FG Virgil font, applied to text elements, adds to the cartoon vibe.
Jeremy Ashkenas is experimenting with a new language that translates down to JavaScript. The language is CoffeeScript and I kinda like the syntax.
Jeremy told us:
I've been working on a little language with a Ruby/Potion-esque syntax that compiles into JavaScript. It tries to enforce "the good parts", convert statements into expressions automatically, and adds some extra goodies like array comprehensions and conditional assignment.
Think of it as JavaScript's less ostentatious kid brother — the same genes, roughly the same height, but a different sense of style. Apart from a handful of bonus goodies, statements in CoffeeScript correspond one-to-one with their equivalent in JavaScript, it's just another way of saying it.
The code looks like this:
I particularly find interesting the JSON style elements (assigment, etc) and how well the code reads without function() all over the damn place. There are nice examples of easy reading in general... for example: launch() if ignition is on.
The infamous Christian Effenberger has a new library to share:
TransM.js 1.0 allows you to add programmable image transitions to your webpages. Features 113 transitions, 32 tweenings, individual corners, overlay graphics and event actions. Requires no plugin/extension or any other external resource! It uses unobtrusive javascript to keep your code clean.
Chrome and Firefox will soon be supporting WebSocket, so WebSocket (for better or for worse) will soon be available in the wild.
So if you can’t beat them, join them. Having failed to convince others to create a better protocol, I’m now determined for Jetty to provide the best implementation of the protocol and to become the server of choice for WebSocket Comet development, deployment ( and experimenting with improving the protocol).
Jetty’s async IO architecture is ideally suited to providing a very scalable implementation of WebSocket that is well integrated with standard server-side java application environments. Thus Jetty-7.0.1 now includes a WebSocket server.
Michael Bolin formerly of Google has created Closure Lite as a way to let developers get their feet wet in the Closure library without having to go into the compiler and the like (but they should do that eventually!).
Closure Lite itself consists of the following subset of APIs:
Lloyd Hilaiel of Yahoo! BrowserPlus fame, has a little holiday gift for us. He has created a simple library called Orderly that "is a textual format for describing JSON. Orderly can be compiled into JSONSchema. It is designed to be easy to read and write."
I am sure MathML took off somewhere, but I never really saw it. MathJax seems to have a chance at being a practical solution that offers a high quality display of LaTeX and MathML math notation in HTML pages.
You can embed the following LaTeX right in your page:
MathJax grew out of the popular jsMath project, an earlier Ajax-based math rendering system developed by Davide Cervone in 2004. In the intervening time, there have been many significant developments relevant for web publication of mathematics: consolidation of browser support for CSS 2.1, Web Font technology, adoption of math accessibility standards, and increasing usage of XML workflows for scientific publication. Consequently, Cervone and others are designing and developing MathJax from the ground up as a “next-generation” platform, while still benefiting from the extensive real-world experience gained from jsMath.
John Gruber of Daring Fireball says that the HTML5 video element, simple as it is, always autobuffers on Safari, Chrome, and Firefox. It's something others have also come up against. Any videos on the page will start downloading right away, regardless of the "autobuffer" attribute's setting:
The HTML5 spec defines an autobuffer attribute for the video and other media elements (bold emphasis added):
The autobuffer attribute is a boolean attribute. Its presence hints to the user agent that the author believes that the media element will likely be used, even though the element does not have an autoplay attribute. (The attribute has no effect if used in conjunction with the autoplay attribute, though including both is not an error.) This attribute may be ignored altogether.
It would appear, in my testing, that all three of these browsers take the spec up on the aforebolded offer to ignore this attribute. Even if you do not explicitly turn this attribute on, Safari, Chrome, and Firefox will still auto-buffer the content for your <video> (and <audio>) elements. There is no way to suppress this using HTML markup.
As Gruber points out, this might seem like a good thing for fast UI: videos start playing as soon as the user wants them to. That would be true in a world of unlimited bandwidth, but for now, this feature is likely to be a massive bandwidth hog. There is a nice workaround, albeit one that peels back the utter simplicity of a single <video> tag:
In the HTML markup, rather than a <video> element, instead use an <img> element with the intended poster frame.
Add an onclick JavaScript handler to the <img> element, which, when invoked, does some DOM jiggery-pokery to remove the just-clicked-upon <img> element and replace it with a <video> element that sources the intended video files.
And, in fact, that is exactly what I resorted to for my PastryKit videos. Do a View Source on that page to see the solution.
It's difficult to see <video> becoming the web's standard video component if every video buffers as soon as the page loads.
We knew that we needed VCS support for Bespin. We also knew that we wanted to have support that is richer than just having command line access. Since we are in a rich UI environment we can do more, and one of the features I was excited to play with was diff visualization.
Well, the Atlassian FishEye crew just popped up with a preview of side by side diffs in the browser and the looks great, similar to FileMerge and the like. Pete Moore takes us on a walk through:
"If you squint, Chrome Extensions and webOS applications look similar" -- a wise friend
Having now written webOS applications and Chrome Extensions I have been struck by how similar they are, and could be.
It may seem weird to see similarity in a browser extension mechanism and a mobile application runtime, but when you look at it, there is plenty to share at a high level:
Breaking out of the sandbox
Both worlds need to break out of the web browser sandbox. Extensions can't be restricted to the same limitations and Chrome Extensions have various API that relate to UI elements in the browser, as well as getting access to more.
On webOS we have exactly the same issue. When building native applications on webOS you can't have the same restrictions and thus new APIs, UI widgets, and services.
This issue goes beyond even these too worlds, and is one of the big challenges for Web runtimes in the near future. I expect my runtime to be able to do a lot more and to get access to my data not just through third party server side services, but locally too. This all brings us to...
Permissions
The Web needs a permissioning model. The sandbox doesn't give us enough, and although people quickly talk about security (which is critical) we forget what happens if the user can't do something through the Web. They often will download an .exe to their local computer and will just run it, not knowing anything about what it does.
A big challenge for us is to come up with a model that doesn't Do A Vista and drive our users nuts. We have to balance the desire to not ask the user for something all the time, while making sure the user knows what is happening. For power users at least, I favour the idea of showing me what is going on. Even if I grant an application a lot of power, if I could see when and what it was doing it would help. Of course, being able to restrict access to APIs is fantastic, especially when you get to layer social trust on top of the technical security. The Mozilla team talked a lot about just this and I look forward to more of their ideas and implementation.
The permissions and other metadata need to live somewhere. We have a appinfo.json file that has you declare info on your app. Chrome has a manifest.json.
On the Web we don't really have this. You hit a URL and you bootstrap from there. The HTML5 manifest does tell the browser which files are in scope for caching and the like, but that is about it. Applications and extensions can tell the system much more. You have ids, versions, pointers to update, icons, main launching points or not...
Headless Chickens
You don't often think of a headless web app. You can think of headless applications and extensions though. How many services are running on your computer now that have no UI? On webOS you can noWindow away and still provide value through the various services that we offer, the obvious being the rich and varied notification styles. Background apps are nicely supported.
Chrome Extensions have the notion of a background page as a way to manage a long lived lifecycle. Your background page is a singleton:
In a typical extension with a background page, the UI — for example, the browser action or page action and any options page — is implemented by dumb views. When the view needs some state, it requests the state from the background page. When the background page notices a state change, the background page tells the views to update.
In webOS and the Mojo framework we have a rich MVC system with a detailed lifecycle as well as the simple ability to define models, views and controllers.
And on
The more I look at these worlds, and others like them (e.g. Jetpack) the more I hope we come together. There are similar needs, and when you look from Chrome Extensions to Chrome OS, you can see a potential progression if done right.
From the moment I saw qooxdoo, I felt they had an excellent & very polished set of functionality as well as insanely rich UI controls but I never took the time to look at the commitment that the team had put into this project. So when qooxdoo project lead Andreas Ecker buzzed me to tell me that the framework had reached 1.0, I decided to take a peak at the history of the project (at least in terms of first available downloads). I looked at the QooxDoo download repo and was surprised by how mature this project is. When you consider that the project was first registered on SourceForge in January, 2005 and made their first available version of qooxdoo on May 9th, 2005, it shows that an incredible amount of effort & dedication has gone into cultivating the project and framework.
The results are very obvious as qooxdoo v1.0 sports one of the richest feature sets of any JavaScript framework. Apart from the standard JavaScript syntactical sugar and DOM traversal/manipulation capabilities found in all JS libs, qooxdoo's suite of UI controls are outstanding and are comparable to any of the best UI libs available. Looking at their showcase of demo apps, you can see how appealing the controls & layout capabilities are.
And it really does focus on the "framework" aspect of things with support for internationalization, dependency resolution, integrated unit & functional testing, build management and more.
There is much more offered in qooxdoo, however, than just a large set of widgets, powerful layout managers and virtually unlimited theming capabilities. As a full-fledged application framework, it comes with an integrated, platform-independent tool chain that covers the entire range of app development and deployment - code validation, JS compiling and linking, compression and optimization, just to name a few. Other built-in tools allow for easy unit testing, automated GUI testing, searchable API reference, or cross-browser debugging a la Firebug. Mastering large-scale JavaScript applications is greatly facilitated by build process features such as automatically combined images ("sprites") or transparently breaking up an app into various parts that are loaded on-demand.
So congratulations to the qooxdoo for reaching a major milestone in your project. The methodical approach for your releases has certainly paid off as qooxdoo v1.0 looks great!
Following their recent acquisition by Google, AppJet announced they would open source EtherPad, the collaborative, real-time, notepad. That's now done, and you can find the project home at - surprise, surprise - Google Code.
What's especially cool about this is that Etherpad is Javascript on both sides of the wire. In a new ReadWriteWeb article on Server-Side Javascript, I wrote that EtherPad is probably the most popular site powered by Javascript (anyone want to up the ante?). As server-side Javascript is getting interesting again, with Comet a major driver, it's a big deal that we now have the entire source tree for a Comet-style, server-side Javascript, application that's been proven in the real world.
AppJet also released appjet.jar when they discontinued the general server-side Javascript platform earlier this year. Unfortunately, the download link is broken on AppJet.com, so I don't know if there's any way to get hold of the official version. It does, however, live on as a cloud-hosted offering at JGate.
