Showing posts with label javascript. Show all posts
Showing posts with label javascript. Show all posts

Saturday, October 17, 2009

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 !

Wednesday, April 15, 2009

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.

Saturday, April 11, 2009

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).

Wednesday, April 08, 2009

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:
Update: already got my invitation, now just need time to experiment with it !

Sunday, April 05, 2009

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.

Thursday, April 02, 2009

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.

Sunday, March 29, 2009

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.

Thursday, March 26, 2009

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.

Monday, March 23, 2009

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.

Saturday, March 21, 2009

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.

Wednesday, March 04, 2009

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.

Saturday, February 28, 2009

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.

Wednesday, February 25, 2009

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.

Tuesday, February 24, 2009

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)

Sunday, February 22, 2009

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

Thursday, February 19, 2009

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.

Monday, July 21, 2008

10gen: Cloud hosting platform offering serverside Javascript

There was some speculation that Google will offer it once they open up the App Engine Platform to more languages, there were some small-scale attempts with serverside Javascript (including the mine, with http://erlyjs.googlecode.com, which is currently receiving very little attention from my side) but now 10gen (with well known Java hacker and director of the Apache Software Foundation Geir Magnusson as CoFounder) plans to offer cloud-based hosting solution with any language running on the Java VM (at least that is what I am reading between the lines of their press release) and the funny thing is they don't start with Java itself, no they offer as first Language Javascript. The guys at 10gen also seem to like django, a quick look at one of the tutorials reveals they are providing a thing called djang10, django inspired framework for creating web applications purely in Javascript.

Saturday, June 14, 2008

Javascript syntax highligting for Firebug

The syntax highligting capabilities of CodeMirror, my favorite Javascript based code editor (for Web IDE-type applications) found their way into Firebug, currently available as additional extension.

Monday, May 26, 2008

Notapad - the start of a dojo based WebIDE

Niccola Rizzo has been working for a couple of months now on the CodeTextArea dojo widget for in-browser Javascript code editing and he has just launched a public demo and test site named notaPad.

The editor provides Javascript syntax highlighting and additional functionalities with the following key bindings:

CTRL + space - autocomplete
CTRL + l - GOTO LINE
CTRL + b - GOTO MATCHING BRACKET
CTRL + c - COPY
CTRL + x - CUT
CTRL + v - PASTE
right click on the row numbers - BOOKMARKS

Saturday, May 24, 2008

js2-mode - the second most important Javascript tool

I have been using js2-mode (an Emacs Javascript mode) for a couple of weeks now. I started using it out of curiosity, at the time I gave up on TextMate as all-purpose editor and turned back to Emacs, mainly because Emacs has so much better Erlang support. Now I consider js2-mode as the second most important Javascript tool (nothing can beat Firebug of course, and Firebug 1.2B1 on Firefox 3RC1 really rocks !). It fits perfectly into my work flow, you don't have to learn anything specifically to use it, it shows on-the-fly any syntax errors, global variables (which usually are unintentional), does a great job of line indenting, but because line indenting is often a question of personal style, js2-mode offers several possibilities you can cycle through via TAB. And in case you don't like how js2-mode works out-of-the-box, there are tons of customization options.

The only thing I am missing: I would like to use js2-mode as well as minor mode in HTML, but that doesn't seem to work yet.

Update: After writing this post, I just discovered another recent article about js2-mode with focus on syntax highlighting.