The Browser as Word-Processor

Like, I think, most web developers, I assumed that making a decent WYSIWYG editor that works inside a browser is difficult and tedious, and assumed the best solution was to use something off-the-shelf — especially since there are what look like pretty good free options such as TinyMCE and CKEditor.

Upon close — or even superficial — examination, these editors (and there are a lot of them) seem to pretty much suck. As a simple pons asinorum try the following test (incidentally, the editor in the latest version of WordPress scores quite well here):

  1. Create a simple document with a heading and a couple of paragraphs of text.
  2. Bold a couple of words in one of the paragraph (not two consecutive words).
  3. Now, while observing the editor’s toolbar, try a series of selections:
  • Select a bold word
  • Select a plaintext word
  • Select from a bold word to some plaintext
  • Select within the different paragraphs and headings
  • Select across two paragraphs with different styles

If you didn’t encounter several WTF moments then either the state of off-the-shelf JavaScript text editors has improved markedly since I wrote this or you’re not paying close attention.

Google Documents — errr Google Drive — handles all this with aplomb, which is to say it behaves exactly like Microsoft Word (which is kind of dumb, but at least (a) what users probably expect, and (b) reasonably consistent). E.g. if you select a mixture of bold and non-bold text the bold toolbar icon will be “unlit” indicating (my colleague and I assume) that when you press it the selection will turn bold. In most of these editors either the bold button exhibits random behavior or goes bold if the selection starts in bolded text. (The latter at least accurately foreshadows the behavior of the bold button: more on that later.)

Assumed Hard, Left Untried

My experience as a JavaScript coder has been that there are only really two levels of difficulty for doing stuff in JavaScript — not that hard and practically impossible (and every so often someone will surprise me by doing something I assumed was practically impossible).

I knew that there’s a trick for editing any web page, e.g. the following scriptlet will allow you to edit any web page (with spellchecking for bonus points):

javascript: document.body.contentEditable = true; document.body.attributes[“spellcheck”] = true;

So, I knew that something like this was easy. What I didn’t realize was that at some point in the browser wars Microsoft implemented pretty much all of Microsoft Word (modulo some UI glitches) into Internet Explorer, and then everyone else simply implemented most of their API.

So, for example, the following scriptlet used in conjunction with the preceding one allows you to bold the current selection in any web page:

javascript: document.execCommand(“bold”);

If  nothing else, you can have a lot of fun defacing web pages and taking screenshots:

CKEditor Home Page (Defaced)While I knew about the contentEditable “trick”, I didn’t put all this together until — frustrated by the huge and unwieldy codebase of CKEditor (which, at bottom, is really just a custom UI library that calls execCommand) and unimpressed by alternatives (aside from Redactor.js, which looks pretty good but is not free or open source) I found this thread on Stackoverflow.

editor.js in action on its documentation demo page

I cleaned up the example and had a working text editor in a few dozen lines of code. (I’d post them but they’re written for a client. I believe the whole project will eventually be open-sourced, but right now it hasn’t been. If and when it ever gets open-sourced, I’ll link the code. Failing that I may write my own simpler version for personal use (and integration with Foldermark).

document.execCommand implements most of the functionality you need to write a perfectly good word-processor from scratch in a browser. In fact, if you’re willing to put up with some UI quirks, pretty much all you need to do is implement some trivial UI components. Almost all the implementations out there create a complete blank document inside an iframe by default, but it’s perfectly viable to edit inline in a div, especially if you’re planning to use the ambient styles anyway.

The beauty of writing your own word processor using execCommand is that the browser gives you fine-grained access to all events, allowing you to arbitrarily fine-tune the low-level behavior of your word-processor. Microsoft Word, for example, has always had unfathomable UI quirks.

What don’t you get?

First, you do get pretty solid table support.

You don’t get fine control over styling, although there’s nothing to stop you from implementing a CSS editor of some kind (disguised or not). From my point of view, the default behavior of the browser word-processor is to be very styles-driven, and that’s a good thing. It’s not so easy out-of-the-box to, for example, set a specific point size for text.

Some execCommand commands don’t work very well. E.g. you can implement a “hiliter” using execCommand(“backColor”…) but there’s no way to toggle it off (unlike bold) so to properly implement it you need to directly mess with the DOM, which — given the way selections are represented, can be a tad ugly.

There’s stuff that is simply difficult because you’re in a browser. E.g. without implementing some kind of service platform (or perhaps leveraging an existing one) you’re not going to be able to drag-and-drop a picture from your desktop into a document. It would be fairly straightforward, I suspect, to integrate DropBox with a word-processor to allow drag-and-drop images and attachments — anything that can be represented by a url is, of course, golden.

Most of the missing features from the free word-processor in your browser are what you’d expect. E.g. anything to do with overall document structure: automatic index and table of contents generation, footnotes, endnotes, headers, footers, and so forth. None of this stuff is hard to do in a browser. The real problem is support for printing — browsers generally suck at targeting printers — so you’re not going to replace Quark or InDesign — but if you’re targeting ePub rather than paper, I don’t see why you’d want to use anything else.

Final Thoughts

The advantages of “owning” your word processor’s codebase are enormous, especially if you’re trying to integrate it into a complex workflow. You can fine-tune exactly what happens when a user hits delete (e.g. we need to track dependencies — was this paragraph based on that paragraph template or not?), and what is editable or not. You can do validation inside input fields while allowing other text to be edited free-form. It’s pretty wonderful. One day, perhaps, there will be free off-the-shelf editor that solves key UI and workflow integration issues, but we’re a ways from there.

 

PHP json_encode replacement

I ran into a problem with RiddleMeThis recently — the new online runtime needs to generate JavaScript structures on the server to hand over to the client. To do this I used the json_encode function, which requires PHP 5.2. Until now, RiddleMeThis hasn’t made many assumptions about the PHP runtime, but it turns out assuming PHP 5.2 is not a good idea. There’s a chunk of PHP you can get somewhere or other that will replace json_encode, but it’s annoyingly inconvenient.

Anyway, it turns out I wrote my own jsencode() function in order to deploy an earlier version of the runtime on a Mac OS X 10.5 server (which doesn’t have PHP 5.2, argh). This was a quick and dirty effort which served the purpose but is kind of evil (it wraps quotation marks around numbers, for one thing, and doesn’t quote the symbols — which is fine for JavaScript but not allowed for JSON, especially if you’re using a strict parser as found in jQuery 1.4.

Feel free to use either of these snippets as you please.

function jsencode( $obj ){
	if( is_array( $obj ) ){
		$code = array();
		if( array_keys($obj) !== range(0, count($obj) - 1) ){
			foreach( $obj as $key => $val ){
				$code []= $key . ':' . jsencode( $val );
			}
			$code = '{' . implode( ',', $code ) . '}';
		} else {
			foreach( $obj as $val ){
				$code []= jsencode( $val );
			}
			$code = '[' . implode( ',', $code ) . ']';
		}
		return $code;
	} else {
		return '"' . addslashes( $obj ) . '"';
	}
}

So, here’s a better version. It allows you to encode for JSON or (by default) JavaScript (useful for passing stuff from PHP server-side to JavaScript client-slide):

function jsencode( $obj, $json = false ){
	switch( gettype( $obj ) ){
		case 'array':
		case 'object':
			$code = array();
			// is it anything other than a simple linear array
			if( array_keys($obj) !== range(0, count($obj) - 1) ){
				foreach( $obj as $key => $val ){
					$code []= $json ?
						'"' . $key . '":' . jsencode( $val ) :
						$key . ':' . jsencode( $val );
				}
				$code = '{' . implode( ',', $code ) . '}';
			} else {
				foreach( $obj as $val ){
					$code []= jsencode( $val );
				}
				$code = '[' . implode( ',', $code ) . ']';
			}
			return $code;
			break;
		case 'boolean':
			return $obj ? 'true' : 'false' ;
			break;
		case 'integer':
		case 'double':
			return floatVal( $obj );
			break;
		case 'NULL':
		case 'resource':
		case 'unknown':
			return 'null';
			break;
		default:
			return '"' . addslashes( $obj ) . '"';
	}
}

To send the information from PHP to JavaScript, you’d write something like this:

<script type="text/javascript">
      var foo = <?php echo jsencode( $some_variable ); ?>;
</script>

To generate a JSON feed using this code you’d write something like this:

header('Cache-Control: no-cache, must-revalidate');
header('Expires: Mon, 26 Jul 1997 05:00:00 GMT'); // some time in the past
header('Content-type: application/json');
echo jsencode( $some_associative_array, true );

Go (The Programming Language)

go-logo-black

There’s a companion post to this piece in which I pretty much lay out my experience of programming languages. If you’d prefer to avoid reading through all that crap, I can summarize by repurposing one of my favorite lines from Barry Humphries (“I’m no orator, far from it, I’m an Australian politician.”) — I’m no systems programmer, far from it I’m a web developer. Go is explicitly a systems programming language — a tool for implementing web servers, not web sites. That said, like most programmers who live mainly in the world of high level / low performance languages, I would love to program in a lower level / higher performance language, if I didn’t feel it would get in the way. At first blush, Go looks like it might be the “Holy Grail” of computer languages — easy on the eye and wrist, readable, safe, and fast. Fast to compile, and fast at runtime.

What’s my taste in languages? Something like JavaScript that compiles to native binary and has easy access to system APIs. Unity’s JavaScript is pretty damn close — except for the system APIs part (it’s also missing many of my favorite bits of JavaScript, and not just the stuff that’s hard to write compilers for). Actually if I really had my druthers it would be JavaScript with strict declarations (var foo), optional strong typing (var foo: int), case-insensitive symbols, pascal’s := assignment, = a binary comparison operator, syntactic sugar for classic single inheritance, and ditch the freaking semicolon.

Of course, I am not — as I have already said — a systems programmer, so things like the value of concurrency haven’t really been driven home to me, and this is — apparently — one of Go’s key features.

Highlights

  • Clean syntax — it looks easy to learn, not too bad to read, and certainly easy to type. They seem to have managed to climb about as far out of the C swamp as is possible without alienating too many people (but I’m a lot less allergic to non-C syntaxes than most, so maybe not).
  • Explicit and implicit enforcement of Good Programming Style (via Gofmt in the former case, and clever syntactic tricks such as Uppercase identifiers are public, lowercase are private in the latter).
  • Compiler is smart enough to make some obvious ways of doing things that turn out to be serious bugs in C into correct idioms.
  • Safety is a design goal. (E.g. where in C you might pass a pointer to a buffer, in Go you pass an array “slice” of specified size. Loops use safely generated iterators, as in shiny but slow languages like Ruby.)
  • Very expressive (code is clear and concise, not much typing, but not too obscure — not as self-documenting as Obj-C though).
  • Orthogonality is a design goal.
  • Seems like a fairly small number of very powerful and general new “first class” concepts (e.g. the way interfaces work generalizes out both inheritance and (Java-style) interfaces, channels as a first class citizen are beautiful).
  • It really looks like fun — not hard work. Uncomplicated declarations mean less staring at a bunch of ampersands and asterisks to figure out WTF you’re looking at. Fast (and, I believe, simple) builds. It makes me want to start working on low level crap, like implementing decent regex… Makes me wonder how well Acumen would work if it were implemented as a custom web server, how much effort this would be, and how hard it would be to deploy…
  • What look like very fast compiles (and in his demo video (above) Pike recompiled more code in less time on a Macbook Air) — but then I’ve seen insanely fast C++ compiler demos that didn’t pan out to much in the Real World.
  • Really nice take on OO, especially interfaces (very elegant and powerful).
  • Almost all the things you want in a dynamic language — closures, reflection — in a compiled language.
  • Really, really nice support for concurrency and inter-process communication. Simple examples — that I could understand immediately — showed how you could break up tasks into huge numbers of goroutines, perform them out of order, and then obtain the results in the order you need to, without needing to perform mental gymnastics. (Lisp, etc., coders will of course point out that functional programming gives you these benefits as well in a simpler, cleaner way.) The 100k goroutine demo was pretty damn neat.

Lowlights

  • To quote a friend, “The syntax is crawling out of the C swamp”. So expect the usual nonsense — impenetrable code that people are proud of.
  • Concurrency is way better supported in the 6g, 8g, 5g version than the GCC (the first muxes goroutines into threads, the latter uses one thread per goroutine).
  • They promise radical GC, but right now it’s a promise (and no GC in the gcc version yet).
  • Pointers are still around (although, to be fair, largely avoidable, and reasonably clearly declared).
  • No debugger (yet), obviously very immature in many ways (weak regex, and see the point about GC, above).
  • The syntax seems a bit uncomfortably “open” (nothing but spaces where you are accustomed to seeing a colon, or something), but it’s a matter of familiarity I suppose.

Unknowns (at least to me)

  • How well does it compare to evolutionary improvements, such as Obj-C 2.0 (which is garbage-collected) combined with Grand Central Dispatch (for concurrency support and hardware abstraction, but at library rather than language level) and LLVM?
  • Will GC actually work as advertised?
  • Is someone going to step up and write a good cross-platform GUI library? (It doesn’t need to be native — it just needs to not suck — something that has conspicuously escaped both Java and Adobe.)
  • Will we have a reasonable deployment situation within — say — six months? E.g. will I be able to ship a binary that runs on Mac / Linux / Windows from a single source code base?
  • Will it get traction? There’s a lot of other interesting stuff around, albeit not so much targeting this specific audience (and it seems to me that if Go delivers it will appeal to a far broader audience than they’re targeting since it’s essentially very JavaScript / Python / PHP like with — what I think is — obviously bad stuff removed and better performance.

Conclusion

I’m not quite ready to jump on the Go bandwagon — I have some actual projects that have to ship to worry about — but it does look very, very attractive. More than any other “low level” language, it actually looks like fun to work with. The other newish language I’m attracted to — for quite different reasons — is Clojure. Because it lives on the Java VM it’s a lot more practical now than Go is likely to be for some time, and because it’s essentially “yet another Lisp” it affords a chance for me to really build some competence with a fundamentally novel (to me) programming paradigm. In a sense, Go is more attractive because it’s closer to my comfort zone — which speaks well for its chance of success. Clojure because of its conceptual novelty is almost guaranteed to remain obscure — the latest Lisp variant that Lisp adherents point to when complaining about <insert name of language people actually use here>. Time will tell.

Javascript Dick Waving FTW

Ars Technica’s rather gushy coverage of Squirrelfish Extreme (and the somewhat critical comments on that coverage) prompted me to do some of my own testing. Certainly, Squirrelfish Extreme keeps Webkit (and, ultimately, Safari) among the contenders for best endowed web browser, but my results were a little less definitive.

Google’s V8 benchmark suite is here. The Sunspider benchmark suite is here. Domaeo (the Mozilla test suite) is here. You might like to check them out in a few browsers. I just tried the current Safari release, the current Firefox release, and the Webkit Nightly Build. As I understand it, the Webkit speed claims are based on testing the JavaScript engines in isolation from the command line. Of course, very few folks run JavaScript this way…

The following are my very slipshod results obtained by firing up browsers and trying each benchmark once or twice. (I wasn’t careful about shutting stuff down, minimizing background activity, closing extra tabs, etc.)

Google’s V8 Benchmark Suite

This set of benchmarks takes less time to run and appears to be less thorough. (It certainly produces less immediately intelligible results… you just have to accept that big numbers are a good thing.)

Firefox 3.0.1 (OS X 10.5.5)

  • Score: 213
  • Richards: 226
  • DeltaBlue: 238
  • Crypto: 205
  • RayTrace: 162
  • EarleyBoyer: 245

Safari 3.1.2 (OS X 10.5.5)

  • Score: 218
  • Richards: 124
  • DeltaBlue: 173
  • Crypto: 187
  • RayTrace: 309
  • EarleyBoyer: 401

WebKit r36685 (OS X 10.5.5)

  • Score: 1312
  • Richards: 1317
  • DeltaBlue: 990
  • Crypto: 2553
  • RayTrace: 575
  • EarleyBoyer: 2035

This is just wonderful. (I tried to download a Firefox Nightly to check out Tracemonkey for myself but figuring out how took more than ten seconds, so I gave up. Here are some stats from Windows (note that these are running under VMWare Fusion, so it’s not fair to compare to the Mac figures directly).

Firefox 3.0.1 (Windows XP Professional/VMWare Fusion)

  • Score: 208
  • Richards: 207
  • DeltaBlue: 264
  • Crypto: 157
  • RayTrace: 180
  • EarleyBoyer: 251

Google Chrome (Windows XP Professional/VMWare Fusion)

  • Score: 2117
  • Richards: 2593
  • DeltaBlue: 2482
  • Crypto: 1692
  • RayTrace: 1456
  • EarleyBoyer: 2685

Internet Explorer 8.0 Beta 2

Note: IE8 interrupts each run with a “script is running slowly” dialog. I tried to click this off as quickly as I could but it definitely hurt the benchmark slightly. I ran it three times, dismissing the dialog as quickly as possible and took the best score.

  • Score: 58
  • Richards: 47
  • DeltaBlue: 52
  • Crypto: 50
  • RayTrace: 69
  • EarleyBoyer: 75

Sunspider

Sunspider’s results are really detailed, and I’m not going to post the whole things here, but I got the following bottom line results from a single run of each. In the Webkit case, this was with half a dozen tabs open (including this blog entry), while Chrome had two tabs open, one of which was displaying the results of its earlier benchmark (not very taxing, I expect).

Webkit r36685: 1614.6ms +/- 7.5% (running native under OS X)

Google Chrome: 1458.2ms +/- 0.4% (running under XP/VMWare; yes, faster is better)

Dromaeo Results

Again, the results are very detailed and also seem very real world (they use code from a lot of widely used JavaScript libraries such as ExtJS, Dojo, and Yahoo Widgets as part of the suite). You can see them for yourself here (Webkit) and here (Chrome). During the Chrome run, Chrome kind of seized up, whichwas probably Windows XP’s fault. So the overall result may be garbage, but if you look at the details you’ll find that V8 is clearly faster at some things and Squirrelfish at others. What this says to me is that both have quite a bit of headroom even yet.

Webkit r36685: 6652.60ms (running native under OSX)

Google Chrome: 10540.80ms (running under XP/VMWare)

So on both Google’s and Apple’s preferred benchmarks, I’m seeing better performance out of Google Chrome, but not by much. Dromaeo, which is a very DOM-intensive suite and also appears the most comprehensive, favors Webkit. (And, yes, IE8 is pitiful. No, I am not going to try Sunspider or Dromaeo on IE8.)

The really annoying thing is that Apple isn’t very aggressive about pushing advances in webkit out to the masses. Or, to put it another way, they use new versions of Safari to sell new versions of Mac OS X*. Chances are Squirrelfish Extreme‘s performance will be a key selling point of Snow Leopard when it ships, instead of a free upgrade to Safari, which is what it ought to be. In the mean time, we’ll probably need to use some other Webkit-based browser or Webkit Nightly, or simply use Firefox to enjoy better performance.

Note: as a comment — rather rudely — points out, Apple doesn’t charge for Safari upgrades. But it does hold new features back so it can announce them as though they were new OS features. (Edit: and, actually, it doesn’t support Safari on versions of Mac OS X before 10.4.x, so technically I was completely correct and the aptly named “bs” was full of bs.) A case in point is the debugging functionality added to Webkit over a year before it became available in Safari as part of Leopard. (And yes, you can get it for Tiger, but the marketing would have you believe it was a Leopard feature, and you simply can’t get it for Panther or earlier.)

And the really puzzling thing is that Microsoft seems to be happy to allow JavaScript performance to suck dog’s balls under IE8.

So, Javascript is fast now?

This site is the most interesting attempt I’ve found to seriously compare execution speed across languages. It should obviously be taken with more than a grain of salt since, apart from all the usual issues with benchmarks (artificiality, etc.), the quality of the code written in each language may vary greatly, as may the actual algorithms, and different algorithms may favor different languages, and different languages are used for different things and, obviously, benchmark comparisons try to force everything to do the same thing. Still, it is interesting.

Based on some quick spelunking, JavaScript (Spidermonkey) is comparable in speed to PHP or Ruby, perhaps a third as fast as Python, a fifth as fast as Lua, about a hundred times slower than Java, C# Mono, or Lisp, and a hundred and fifty or so times slower than C++.

What that says to me is that JavaScript should easily be able to get two or three times faster than Spidermonkey (because it has a lot in common with Python), but then it will get tough. It also speaks rather well of Lisp (which manages to be truly dynamic and still competitive with the big guns). Since it looks like Squirrelfish Extreme and V8 are both around twice as fast as Spidermonkey, and that if you took the best bits out of each from the detailed benchmarks and combined them you’d maybe get 50% faster again, it looks like we’re nearly out of low-hanging fruit in the JavaScript engine race.