Getting started with WebGL 3D magic

Firefox trunk build and webkit nightly builds both support WebGL, the upcoming Standard for hardware accelerated web browser 3D graphics. So I wanted to get my feet wet with this new technology and after short analysis, I did the following steps as possibly fastest solution to get a working demo (in my case on a mac):

• updated my nightly build of webkit
• in a terminal, issued the following command:
  defaults write com.apple.Safari WebKitWebGLEnabled -bool YES
• opened one of the currently popular demos / showcases.

and then you get a smooth rotating object, all coded in Javascript !

Back on business

After some longer absence from the blogosphere and open source communities in general due to some personal disruptions, I am back, this time with focus on serverside Javascript, webkit-specific client-side stuff (for iPhone web apps, of course) and more. Right now I have just learned that super slick Cappuccino web framework is starting its Atlas-Web-IDE beta program on November 15. Exciting times ahead.

Develop native iPhone apps in Javascript

With phonegap you can today write iPhone webapps which run on an embedded browser and with a bit of clever CSS styling and JS trickery you can makes those apps smell and feel like native apps. Why not just writing normal browser based web apps for the iPhone ? Well, first you can't sell web apps on the app store and second, phonegap exposes many additional APIs to Javascript based apps.

Soon there will be a new flavor of JS / phonegap iPhone apps: Mike Nachbaur is working on a phonagap branch, which allows (or hopefully soon will allow, I haven't tested yet) to create in JS native Cocoa UI widgets such as tabbars and toolbars. Apple often just follows with Apple-branded versions of what smart developers do ahead of time, so if this will happen in this case as well, I would expect many of the iPhone developers to switch from Objective-C to JS.

CodeMirror browser editor got a Lua parser

Try it out. Unfortunately it might take a little while until it will find its way into bespin, because right now, CodeMirror based syntax highlighting in bespin tip is disabled due to some one restructuring of the canvas paint function.

Helma NG serverside Javascript framework on appengine

Helma is one of the few Javascript server-side web frameworks, and it's next generation version runs right out-of-the-box on Google appengine. I followed the tutorial and easily got my own Helma NG demo running on appengine. Because Helma NG is a complete rewrite of standard Helma (which doesn't run on appengine), it is very simple, no persistence yet, mostly just request wrapping and routing and a simple template engine (no template inheritance and other fancy feature you find e.g. in django). If this is all one needs then Helma NG on appengine is now probably the easiest way to run javascript at client and server side. So let's hope that those who need a bit more, will contribute to Helma NG development to make it competitive with PHP, django and RubyOnRails, or come up with a new framework (RhinoOnRails ???).

And for those who need less than Helma NG, this article might be helpful.

Update: I was wrong about template inheritance, Helma NG does support it, via the "extends" tag. And the development branch has now also appengine persistence support (demo).

Javascript on appengine

Was offline yesterday, therefore missed to be among the first 10K to try it out, but a bit of web research revealed that it should work right out of the box:

• Dynamic languages on appengine - summary
• Rhino Javascript on appengine - first working example
• JRuby

Update: already got my invitation, now just need time to experiment with it !

Experimenting with lexical auto-indentation for bespin

While the basic features of the codemirror syntaxengine now are part of bespin (and that is just syntax highlighting), I started today to experiment to add an advanced feature: Auto indenting of current line or a selection based on lexical analysis. The user just has to press CTRL + TAB (but could be any other key binding of course). The information about what codemirror thinks is the correct indentation is already internally stored for each line of the source document, all I had to do was to add some code which inserts or deletes some whitespace at the begin of those lines the user marked for auto-indentation. That is at least what I thought. Unfortunately it doesn't work yet reliable (and that is my fault, because the original codemirror editor does perfectly auto-indent) and also is not yet integrated into bespins undo/redo system, so it needs another iteration, before I can submit a patch, but if anybody wants to help working on it, take a look at the auto-indent code I added.

Adding python syntax highlighting to bespin

Support for Python got recently added to Codemirror, thanks to Timothy Farrell. So I grabbed those sources and ported them to bespin.

It doesn't work yet perfect in every case one can think of, but it does highlight Python.

The current features are (summarized from original demo page):

• Token-based syntax highlighting - currently very little lexical analysis happens. Few lexical errors will be detected.
• Use the normal indentation mode to enforce regular indentation, otherwise the "shift" indentation mode will give you more flexibility (not used yet in bespin).
• Parser Options: Python version, error display

The patch with python support is now applied at my repo at bitbucket.

Javascript based parser generator system

I hope this is real (because April 1 is approaching, see my previous post): The first ever LALR(1) parser generator system written in and for Javascript. Would be interesting to add this to bespin, declarative grammars (as used in flex/yacc) are relatively easy to define, compared to codemirror which I used for the new, alternative bespin syntax engine and which is an interruptible-resumable continuation-passing style parser and needs to be written programatically for each language.

Similar to the narcissus parser implemented by Malte, such LALR(1) based parsers could be used for generating outline views and syntax checks running in a background worker thread. What it can't be used for is syntax highlighting, because LALR(1) based parsers need to reparse the whole file for every change to a document and that makes them too slow for syntax highlighting in realtime.

Internet Explorer Eightpril.1 with Webkit/Gecko rendering option !

I guess this is an April 1 joke leaked out too early and with perfectly photoshopped screenshots. If it is not a hoax, then, according to this article, the new Internet Explorer 8.1 will also allow to use Firefox extensions ! Ha ha !

iBespin

Now that my bespin syntax engine is more or less working and got added to the main repo, I experimented again with inline previews, but this time I think the result is a bit more in line with what one actually needs:

I added a preview setting. Using previews is the same as always, either click on the icon, or type the command: preview.

Below are the new settings:

• set preview window - default, an external window, as we have now.
• set preview inline - instead of editor canvas we have an iframe containing the preview
• set preview iphone - a non-modal popup containing an iframe with dimensions of the iPhone screen. Of course you should use Safari for this.

With ESC key the previews get closed / toggled off.

Now this just needs to be cleaned up a bit and turned into a patch or pushed to my repo at bitbucket.

Update: Bugzilla ticket

Java on AppEngine (or serverside JavaScript for the masses) !!!

But let's wait first for confirmation of the rumor.

Update: Following the first comment on this post ("Java != JavaScript"), it might look like I am confusing things, so let me clarify for those who can't remote read my mind (hopefully most) and are not familiar with Rhino, which is a JavaScript implementation written in Java, and allows serverside scripts to be written in JavaScript. And maybe just coincidentally, a few days ago a new release of Rhino has been pushed out. And for those who don't know, Norris Boyd, the main developer of Rhino is a Google engineer. So for me at least it makes sense to assume, JavaScript is part of Google's Java App Engine plans. But let's not forget, this is all based on speculation, and the only difference between now and the very same rumors "leaked out" by a Google engineer a few months ago, is that Michael Arrington has a lot of readers.

Cross-browser offlining

I just tried to find out what needs to be done to make a web application (let's take bespin as example) work offline. Unfortunately a google search for cross browser offlining did not point to any magic solution. So let's start with what I knew already about this:

• offlining the static resources is the easy part and modern browsers and google gears provide all kind of support for that.
• offlining the dynamic requests is extremely difficult. The server logic needs to be modeled on clientside and the risk of getting data inconsistencies is big. So let's leave that part for another day.

Unfortunately all the popular browsers (I tested with the newest betas) and google gears provide different ways of how to handle the offlining of static resources:

Firefox 3.1beta

Supports the HTML 5 offline API and has a menu option to simulate the offline mode. The static resources need to be listed in a manifest file:

CACHE MANIFEST

/index.html
/default.css
/images/logo.png

and that manifest file name becomes an attribute of the html tag of the app start page:

<html manifest="/tests/th/cache-manifest">
<head><title>test</title></head>
<body>test</body>
</html>

Safari 4beta

Also supports the HTML 5 offline API, therefore everything the same as with Firefox, except there is no easy way to simulate the offline mode. Just turning off the internet connection does not help if you use a server on localhost for development.

Google gears for all the other browsers

Now it's getting a bit more complicated. First you need to find out whether gears is installed, and if yes, load the cache manifest file, which unfortunately has a different format (JSON) than the HTML 5 version:

// cache-manifest.gears
{
  "betaManifestVersion": 1,
"version": "site_version_string",
"entries": [
    { "url": "/index.html" },
{ "url": "/default.css" },
{ "url": "/images/logo.png" }
  ]
}

And the loading of the manifest has to be done in Javascript:

if (google && google.gears) {
var localServer = google.gears.factory.create('beta.localserver');
var store = localServer.createManagedStore('test-dev');
store.manifestUrl = '/cache-manifest.gears';
store.checkForUpdate();
}

Because the HTML 5 / gears manifest files have a different format and easily grow beyond manually manageable size, a tool (or a custom build step) is necessary to create and update the cache manifest file for complex apps.

Finally ported CodeMirror syntax engine to bespin

I have written before about my attempt to port the CodeMirror syntax highlight engine to bespin. I got it mostly working now (for Javascript, HTML, CSS, PHP and even all these languags mixed together as in PHP) and have submitted an initial patch for review.

The port required quite a few structural changes of the code because, on bespin the syntax engine is running in a background thread if webworkers are available (FF 3.1beta, Safari 4beta, Webkit nightly) or gears is installed, otherwise it is still running asynchronous, triggered by a Javascript setTimeout() with value 0. This all has only been possible thanks to the groundbreaking work of Malte Ubl.

So if you wanna try that patch out today, you need of course a local installation of bespin, then apply the patch and use the command-line to enable / disable the syntax engine:

set syntax2 on / set syntax2 off

And don't expect it to be not even near as fast as the default engine. It is just an initial port, caching and other tricks to make it fast are not enabled or implemented yet.

Bespin, Mercurial and keeping your patch up-todate

While hacking on bespin I experimented some of the possible ways to keep a patch in sync with tip (this is how they call "trunk" in hg land).

Just cloning the repo for developing the patch

this is the easiest, and seems quite popular. Unfortunately you are switching physical directories when you switch between clones, and in the case of bespin, where running server-instances are tied to a physical directory, it requires either a smart approach for running the instances in parallel or easily shutting down one and starting up he other. And if you are working on different unrelated patches, it can get quite messy to do manual merges when tip changes. To sum up, easy to get started with, but lots of disadvantages.

Using branches

Branches are easy to create and easy to switch between them and they have one big advantage compared to cloning: You stay on the same physical directory if you switch branches. However, the pain of manual merges when tip changes seemed to me even worse than with cloning.

Using queues extension

this is currently my preferred way. With queues extension you have always a clean tip, can develop patches, apply them, remove them, apply /remove patch-sets and easily change the order of the patches in the set. Updating tip is as easy as:

hg qrefresh # update current patch with local changes
hg qpop -a # remove all patches
hg pull
hg update
hg qpush -a # apply all patches

What I haven't figured out yet is how to use bundles with queues extensions.

Update:
By enabling rebase extension, rebasing with tip got even easier. The lines above got reduced now to:

hg qrefresh # update current patch with local changes
hg pull --rebase

Update II:
Lately I just push my local repo with applied MQ patches to my personal public repo at bitbucket, with the purpose of facilitating the pull of my patches.

More on the new syntax engine for bespin

And so here continues my journey in porting the CodeMirror parser / tokenizer to the bespin syntax engine. While at my first iteration I basically just merged the codebase and managed some initial nicely-colorized rendering, I bypassed the mechanism which actually makes CodeMirror parser / tokenizer an interesting choice for bespin: the interruptable / resumable parsing. Now this is halfway working so let me explain it in detail:
The default bespin syntax highlighter works on a per line base and is extremely fast (magnitudes faster than any approach involving real parsing) and its performance is independent from the document size. But if we wanna have real syntax analysis in real-time, there is a price to pay for it and this price is a slower syntax engine. But with some real computer science (many dissertations have been written about parsers) and a lot of tricks, the user hopefully won't perceive any loss in responsiveness.

The streaming tokenizer / parser approach

While most parsers need to read the full document to parse it then all at once, CodeMirror is more like a streaming pipeline engine: it can start at any line in the document, after processing that line, the engine spits out immediately the tokens containing the syntax coloring information and in the near future callbacks for indentation and maybe even code-completion. So how does this engine work ? The main trick is that the parser stores its state at each line, so it can resume its operation at any line. Of course with all the details, it is a bit more complicated:

First we have our document, bespin internally represents it as an array of lines of text. Then there is a StringStream wrapper, which allows us to treat the document like a stream. Then there is a stream traverser which goes forward through the stream, passing the stream content to the tokenizer, which splits the stream into tokens and the last element in the pipeline, the parser does the main job of further analyzing those tokens. For every line the parser attaches a copy of itself (or better: its internal state) to he line. So once the document is initially parsed up to a certain line Y and the the user changes something at a previous line X, the engine retrieves the stream starting at line X, grabs the parser which has been attached to line X and continues its job there.

Of course there are a lot of things which can go wrong. For example the engine loosing sync between the stream representing the actual text lines, the document itself and the stored parsers. If this happens the document needs to be fully reparsed, which is a performance disaster. And this happens right now, because a few parts are not implemented yet, but I am working on it.

I am very excited about integrating the engine with Malte Ubi's work: offloading the engine to webworkers / gears for async background syntax analysis and merging it with the upcoming thunderhead editor component, which is optimized for calling the syntax engine only when really necessary. Right now I am messing with caching (otherwise the parser would block the UI, arrghh !!!), I try to detect whether calling the syntax engine is necessary, if not I provide cached results if available.

So the next week will be very interesting, to see how these things rapidly evolve.

Porting CodeMirror syntax parser to Bespin

The first screenshot (or the second, if the images are in a row) shows the current bespin syntax highlighting engine. It applies on a per-line base regular expressions to highlight the different parts. This approach is very fast, and new language color definitions can easily be added, but the engine is not aware of the internal structure of the code the user is typing in, and therefore such an engine cannot be extended to show in realtime syntax errors and provide intelligent code indentation and completion. The engine splits code into the following elements for colorizing:

• comments
• C-style comments
• keywords
• strings
• punctuation

The second screenshot shows an early stage of a new approach I am working on, a syntax engine which uses a real tokenizer and parser (borrowed from the CodeMirror project), fully aware of the structure of the code. So far the initial coloring is fine, but to get it work continuously and smooth and with large files, there are a lot of problems and a lot of work to solve them ahead.

The second screenshot (or first, if the images are in a row) also shows that a few more Javascript code elements got identified and colored:

• atoms
• variables
• variable definitions
• local variables
• properties
• operators

I have chosen Javascript as the first language to port to this new syntax engine, because it is the most important one for me and maybe for web apps in general. But JS is a dynamic language and syntax analys is tricky. The good thing about CodeMirror is that beside of JS there exist already tokenizers / parsers for:

• CSS
• HTML mixed (with JS, CSS)
• PHP mixed (with JS, CSS, HTML)
• Django mixin (my proof-of-concept, never got officially released)
  

This new syntax engine, if I ever get it working in an acceptable way, is not supposed to replace the existing one. If desired and enabled, it will try to provide a better user experience, but will use the original syntax engine as fail back.

Bespin - experimenting with embedded preview

While a browser based text editor or web development environment has many disadvantages compared to the desktop variant, there a also some great possibilities which haven't been explored yet with bespin. Possibilities such as having direct browser DOM access for previewing and possibly manipulating content and that is not limited to text. Images (img tags and background images) can also be edited live (with a bit of canvas magic, as e.g. in pixastic) and server round trips are only required to store the edited images. Traditional editors can only dream of this and adding this possibilities to monster IDEs makes them even more complex.
So here is my proposal (including fully functional early stage prototype) for a live preview, see the screenshots above, just clicking on the eye icon at the toolbar and at the place of the editor canvas with the HML source code, a preview panel gets blended in. Unfortunately there are a few issues. Lets take a look at the style definition of the example. It has defined properties for the "body". But we don't want to change the bespin body properties. So what I am doing to prevent a visual and usability disaster is parsing (not really in the lexical sense) the HTML template, extracting styles and injecting them as filtered CSS rules into the page when rendering the preview and removing the rules when switching off the preview.

So far this is only for HTML templates. But my idea is to have a pluggable template parser system so we can expand PHP, django or other templates. While this is not easy, I have done it before (ErlyDTL, the Django template language for Erlang) and I have used a javascript template system before: dojox.dtl - dojo django rendering. So why not use dojox.dtl for bespin template rendering ? Well, first it is specific for django, second it is text and node based (for performance reasons). That is good for an app where template parts get swapped frequently, but just for preview we don't need a node based template system, at least not for now because it adds a lot of complexity.

And one more thing to consider are the edge cases in which this approach won't work. Hopefully with enough trickery the embedded preview will work good enough in most cases. The bespin toolbar and commando line will anyway prevent a full-browser preview, unless they are blended out as well, which is currently not implemented and I am not even sure whether it would be a good idea to do so.

If you wanna contribute to the technical discussion, please user the google bespin core group.

Does now web development start to move into the browser ?

The browser has always been the most common tool to consume content from the internet. It also has served to create simple text based content (CMS). But now the tools start to appear for creating more complex content like web applications direclty in the browser. Let me list what I have tried out (or just heard of) recently.

• bespin the super-cool and wicked-fast browser code editor (which since today contains a few lines of code I have contributed)
  
• 280atlas, just been announced yesterday, an amazingly awesome looking visual builder for cappccino web apps, not available yet, except of the screencast.
• Wavemaker, they have been around for a while, very enterprisy, it did not work for my out of the box when I tried a few months ago (isn't the first impression what counts most ?).
• AmyEditor. Looks like an online version of TextMate. That is good, because TextMate looks and feels great and people just love TextMate, but is bad because I believe the browser is not the right place for embedding a desktop app alike. And when resizing the browser, that app did not resize, so that was the early ending of my exploration of that otherwise probably great app.
• Coghead. Was a cloudbased visual app builder. They failed, are on the deadpool now. At least they could sell some of their IP to SAP. AFAIK, Coghead was not open source, halfway flash based and had a lot of proprietary things, even a proprietary programming language. Maybe that is not the way to go, unless you have more salesmen than developers in the team.
  

Beside of bespin these web apps all seem to look like desktop apps. I am not sure whether this is what developers will feel most comfortable with. Look at gmail, greader and other highly successful web apps. They don't look like and feel like desktop apps.

There are also cool graphics apps from aviary, for creating artwork. They are flash based and take more time to load than Pixelmator on my laptop.

bespin now dojo-powered

well, at least on my laptop, but I submitted a patch, so if the Mozilla guys like it, I hope it goes into trunk. The screenshot shows bespin running on the brand new Safari 4 beta.

There are still things to do related to the port, for example eliminating global variables outside of dojo and bespin namespace, dojo build profile and fixing the zillons of bugs I probably have introduced (but at least one I fixed, mousewheel works on Firefox as well)

Porting bespin to dojo - 90 percent done

No I try to break the number one rule in software development: the last 10 percent take 90% of the total time. The dashboard works, except the command line sometimes having hiccups. The editor lets me type in text, but anything else breaks. I also replaced all third party libraries (in the external folder) with dojo equivalents. Here my experience in regard to prototype:

• It's an absolutely fantastic framework if you wanna simple things get done quickly and you don't care about JS design philosophies (name spaces, native object extension).
• There are a lot of utility functions for string, array and enumerable manipulation, but some of these functions are "opinionated" as all the great things from the 37systems guys. In dojo you end up cooking together your own one-line solutions for the simple stuff. It is additional work, but results in a customized and optimized solution.
• The huge amount of string utilities suggests that prototype is targeted to developers who prefer not to deal too much with regular expressions.

So what else is missing once the bug fixing is done:

• Name space cleanup: I used a all-lowercase namespace (e.g.: "bespin.editor"), because that is how dojo name space and file hierarchy looks like. I regret that, because it violates the bespin coding guideline and worst of all, requires a lot of slave work to update the documentation, so I will refactor to a name space mostly identical to the current one from bespin trunk (e.g.: "Bespin.Editor")
• There are still some global variables (in the startup scripts), but before I even suggest how to change that I need some feedback from the bespin architects.
• Testing (I introduced lots of bugs ...)
• Build script to create minimized JS/CSS for production, maybe as paver task.

Update: I found a cheat sheet for conversion between dojo <->prototype

Exploring bespin - and porting it to dojo

After some months absent from blogging and open source software involvement, the launch of bespin motivated me to get back to fun-hacking and blogging. Bespin is a browser based code editor which feels and smells like a real editor (vim, emacs, textmate), and not like a form on a webpage as all of the other browser based code editors (including an experimental one I hacked together myself). Internally bespin uses canvas and therefore currently only runs well on Firefox or webkit nightly. As JS lib Protoptype was choosen, but that might change in favor of dojo. So I thought I will give it a try, to port bespin to dojo and learn about the internals of bespin. And it might serve as suggestion in case bespin officially gets ported to dojo.

So where we are so far ? The screenshot at right shows that dashboard canvas rendering halfway works already, but with scaling dimensions something went wrong. Prototype makes the simple things very simple, dojo doesn't care much about the simple things, so I had to hand code a few things which had ready-to-use counterparts in prototype. But the really ugly thing about Prototype based javascript development is the global name space pollution and the extension of native objects, that is so much better handled with dojo and its class system. Of course nobody cares about those details once an app is up and running. Will finish the port and submit it to bespin bugzilla, but it might take a few days to iron out the bugs.