For many years JavaScript editors have been a thorn in our side.  Browser vendors are constantly improving the rich text editing capability as used by all of the free editors.  We know our editor is better, and so do our clients; most of the time it’s easy to show just how much better we are during the sales process.  Last week we completed development on a new feature that we believe takes this a step further.  We’re so confident that our editor is better, we’re willing to distribute a JavaScript editor to prove it.

We don’t advertise this on the website anywhere, but I’m going to come right out and say it; we picked FCKEditor.  It’s one of the most lightweight editors around while still providing a solid experience, and it starts up a crapload faster than other JavaScript editors through use of an image array for the toolbar icons.  Most importantly though the FCKEditor source code is high quality, easy to understand and we felt it would be the easiest to maintain out of the editors we evaluated.

I’m really proud of how well this integration turned out.  Particularly the UI; if you compare the default FCKEditor interface to the default EditLive! interface you wouldn’t think it was possible to wrangle the JavaScript editor to look anything like our Java applet.  Using some creative JavaScript and CSS we not only made it look almost identical, we did it without modifying any of the core FCKEditor files.  We even created tabs to change between design and code view, something that took me a few days to get right and the result looks just like the real thing:
EditLive! Express Edit
(click for a better look, my theme isn’t wide enough to fit the image at full size)

This integration was produced for what boils down to two basic reasons.  Some potential clients don’t want to require Java on all user machines and others are paranoid that users will freak out when the Java logo appears (I disagree, but some people really hate Java!).  Personally, I see this as a cool way to prove to the world that JavaScript editors cannot, and often will not, beat our consistent cross platform editing experience.

As an example, load up the FCKEditor demo and try this:

  • Delete all the default content and type a few words
  • Highlight the last word on the line and insert a hyperlink
  • Click at the end of that word, hit enter and continue typing

The result will depend which browser you use – in FireFox, you wind up with the hyperlink continuing on the second line whereas Internet Explorer is a bit smarter and ends the hyperlink before starting a new paragraph.

Another example:

  • double click on a word in the middle of a line
  • insert a hyperlink

In FireFox, the selection model highlights the space after the word when you do this and your new hyperlink includes the space – you get this ugly line extending out from the end of your word.  IE also highlights the space after the word but is smart enough to not include the space in the new hyperlink.

Neither of these cases are an issue in EditLive!, and fixing such “minor” problems is often more effort than it’s worth in a JavaScript editor that relies on the browser to do all the heavy lifting.  I can personally vouch for this; I worked with the IE HTML editing component in EditLive! for Windows for so many years and there were numerous frustrating bugs that I just couldn’t do anything about.

The EditLive! UI is consistent and sensible on all supported platforms, and our support team is capable of fixing even minor UI bugs.  This is the advantage Java gives us; we control the entire editing component and can even fix JRE bugs by extending the Sun classes.

For basic commands you can get away with a JavaScript editor, but once you start creating complicated HTML the little things start to bite you.  It’s classic death by a thousand paper cuts; there are many more examples than the two I provided above and nobody I know at Ephox can stand using a JavaScript HTML editor anymore.  We use EditLive! on our internal wiki and so the entire company is now spoilt by using the best WYSIWYG editor in existence.

I’m going to sound like a salesman for saying this, but there are bigger advantages over JavaScript editors than the nicer editing experience.  We replicate the MS Word table insert wizard, use 100% Java dialogs so we don’t have popup blocker issues, and have no issues with custom XML tags in the middle of HTML.  Large systems often use such custom tags as template hooks; at best a JavaScript editor will hide the tag where it can be accidentally deleted and at worst it will completely corrupt it.  Oh and did I mention that we have the best in-browser Track Changes experience I know of?

I’m not trying to say the editor is perfect; there are always things we want to improve (and every time the development team is given a chance, we do).  It’s just that nothing I’ve seen (even other Java editors) holds up very well next to EditLive!.


For anyone wanting to try Express Edit, the website demos aren’t finished and it hasn’t actually been released yet so you’ll need to download an Early Access build.