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