The web, as a platform, sucks
The web platform sucks.
Don’t get me wrong. With Ruby on Rails, developing web applications is actually a whole lot more enjoyable than writing desktop client software! The web is a wonderful platform for writing for simple information processing systems that do not require very complex user interaction. Its main strength lies in its universal aspect - everybody can use it without installing annoying client software. But web applications get nasty and hacky very soon.
At the moment, I’m enrolled in a course at my university called “Ontwerpproject” (”Design project”). We’re developing a system for facilitating the storage and the transfer of knowledge inside as well as between student organizations. This is all fine and dandy. Displaying documents is very simple. Storing and displaying organizations, tags, etc. is very easy, and with scriptaculous effects, it looks cool too.
One of the requirements for the system is that it must be possible to enter knowledge on a website (as opposed to, say, uploading Word documents). We chose to use one of those “web based rich text editors” (I’ll call them WBRTE from now on). And this is where things go downhill. There aren’t much options. Probably the most widely-known open source WBRTE is FCKEditor. There’s even a Ruby on Rails plugin for it. There are commercial alternatives as well, but they’re very expensive.
FCKEditor works, but:
- It’s slow.
- It’s slow.
- Only works in Firefox and IE (though 2.5 beta supports Safari and Opera as well)
- If I press Reload or the Back button and then Forward again, the text I entered previously is gone.
- Spell checking only supports 1 language simultaneously.
- Spell checking button interferes with Firefox’s built in spell checking. By default, FCKEditor disables Firefox’s built in spell checking. Spell-check-as-you-type is a good thing and is easier to use than a spell check button. The end users for our system are Dutch, and if they have Firefox installed, then they usually have the English version. So they’ll want to switch to the Firefox Dutch dictionary by right clicking. But if they that, then they will - tadaa - get the FCKEditor popup menu instead! They can bypass that by holding Ctrl while right clicking, but it’s not intuitive. I had to insert a tip at the editor page to notify them about that, but I would prefer if that wasn’t necessary.
- Did I mention it’s slow? And by “slow” I mean “it takes a long time to load and generally feels clunky and less responsive compared to client word processing software”
I’m not sure whether 1 (and 2 and 7) can be fixed. If you look at how FCKEditor and other WBRTEs are implemented, you see that they usually do that with an iframe in which they create DOM elements.
3 is a solvable issue. Not sure about 4.
5 cannot be solved without serious changes in the browsers. Right now there is no way to integrate your own rightclick-popups with that of the browser. In the case of FCKEditor spell checking, this sucks - a lot.
My point is, if you look at some things, you’ll see how hacky the web platform actually is. FCKEditor, while working well in many circumstances, is a big hack in my opinion. A very clever hack, I’ll admit. Other WBRTEs are essentially hacks too and have similar problems. The web platform was never designed for these sort of things. And as a user, I can notice that a lot in the form of reduced performance.
A few more gripes I have:
- Lightboxes with a transparent black background that fades in. The fade in animation is slow, VERY slow. In both Firefox and Internet Explorer. This could be just an implementation issue - I figure things could be a lot faster if browsers use hardware accelerated graphics rendering. But still, this reeks like a “hack” to me.
- File uploading. Let’s say you’re uploading a 30 MB JPEG file, which has a corrupted header. The server can only tell you that the file is corrupted after you’ve finished uploading the entire 30 MB. Furthermore, batch uploading is not supported. While you can wrap things in a zip archive, a lot of casual people don’t know how to create .zip files. So web developers work it around with Java applets, which load very slowly.
- No support for server pushing. You usually don’t need this, but it’s useful for some websites, such as web-based multiplayers online games. Clients have to be constantly notified of updates, and polling the server with Ajax is very inefficient. I realize that there’s Comet, but when I look at how it’s implemented, it feels like a big hack.
I’m not criticizing FCKEditor or WBRTEs in general or light boxes; absolutely not, they provide very useful tools. I’m criticizing the web as a platform. It’s been so many years, isn’t it about time that browsers provide some good built in support for rich text editor components, instead of letting people hack one together with iframes? I think WHATWG had a specification about that, but I’ve never heard anything from WHATWG ever since it was established. It’s about time the web becomes less hacky.
Michael Daines said,
October 30, 2007 @ 8:08 pm
Why was one of your requirements that it must be possible to write things on your website? What about having people email attachments to your knowledge-gathering system?
Does “the web” always have to be what’s inside the browser? I guess email isn’t “the web”, but what about that application Flickr has for uploading pictures? I feel that’s less of a admission of the web’s shortcomings and more of just using something else where using a browser wouldn’t be appropriate. I think Shoes may mean more programs like that.
While “rich-text” editing may be broken on the web currently, I don’t think that means it shouldn’t be there in some form. I think one of the big problems is that the DOM isn’t all that great for programming a text editor, and that for some reason, people love to copy Word’s interface. Is Word really the best example we have of a tool for writing on the computer?
Trevor said,
October 30, 2007 @ 8:09 pm
Have you looked at Flash or Silverlight based Editors?
This one looks promising http://www.oblius.com/?projects.obedit
Looks like its free and open source, though i didnt look all that deeply at it. And there might be better ones out there…
Craig said,
October 30, 2007 @ 8:45 pm
Hi
I generally agree - I have reently implemented an articles system and used Xinha - while it worked (and I was quite happy with it as a developer, and compared to what I was expecting, but then I looked at it from the users point of view compared to there desktop word processors - uck!) it was slow and clunkly.
But I wonder if this can not be approached from the other direction - way can’t the browser implement a “rich-text” editor - in the same way that they implement edit boxes, combo boxs (ok maybe Combo Boxes is not a good example) etc - I guess what I mean is if a rich text editor was a widget of the browser (or more likely a plug-in) that we had a good chance of knowing was there would that not make a start to solving this? - (the other alternative is to keep implementing better JavaScript and/or Flash/Silverlight etc options)
Bryce Thornton said,
October 30, 2007 @ 10:01 pm
The YUI Rich Text Editor is still in beta, but it looks to be a fairly clean, easily extensible implementation. I don’t believe it uses iframes.
http://developer.yahoo.com/yui/editor/
Hongli said,
October 30, 2007 @ 11:41 pm
Michael Daines:
Emailing people with attachment is too much hassle. I can’t say too much about my assignment, but the end users that we interviewed have all stated that they want a web interface for editing documents.
And yes, you are correct that “the web” is not only what’s inside the browser. For convenience, any reference to “the web” in this article actually refers to whats inside a browser (i.e. HTML + DOM + JavaScript + CSS), and not “everything built on top of TCP/IP”.
Don’t get me wrong, I’m not saying the web shouldn’t have a rich text editor. It certainly should, but right now the web isn’t a very efficient platform for implementing one. I hope the situation will improve in the future.
Trevor:
Cool! Thanks for letting me know. I’ll check it out.
Craig:
Yes, I’m thinking about that too. And I believe that’s what the WHATWG specification was about. Unfortunately I haven’t seen any concrete results yet.
Bryce Thornton:
Thanks but I’ve already checked out YUI Rich Text Editor. Unfortunately, they said it’s beta, and they were not kidding! The YUI editor doesn’t work inside XHTML document, only HTML. And even then I found many bugs that prevented me from using it. A pity really.
Ninh said,
October 31, 2007 @ 12:24 am
As Hongli’s teammate for this assignment, I wholeheartedly agree on the things Hongli is trying to point out in this article. But unfortunately, as Hongli and I know firsthand, even though a lot of us seem to agree that the web needs a lot of work –and know where there is room for improvement– progress in this area seems to go slow… FCKeditor slow
E.g. JavaScript 2.0 comes to mind, for which several specs and propositions were made years ago, but up to this very day, we still have no (browser) implementation for it.
The main reason for this I think is the established user-base (which, like many other things, eventually boils down to time and money). In the case of the web, many web applications have already been developed using the techniques we know today and for the most part, already knew about yesterday. Migrating to a real ‘web 2.0′ isn’t something to be established overnight.
Also, we must keep in mind that the web was never designed for the things we consider common nowadays. For example, in the beginning, the web was designed to be stateless in order to serve as many people as possible with the limited computing power people had back then.
Also, its main goal was to provide users with information, very similar to the way newspapers do this, and for this, the stateless model was an excellent choice.
But as time progressed, we’ve seen new needs arise and from this –among other things– users implicitly demanded for the web to have a notion of state. To accommodate these needs while attempting to retain as much compatibility and server efficiency as possible, solutions/hacks such as cookies/sessions and more recently, comet/ajax-support have found their way to our browsers. They’re all built on top of the stateless architecture that is the web, and the real question to be asked here is how long we can continue stacking up functionality on something that may be fundamentally outdated by the time of this writing to begin with.
In summary, what I think Hongli is trying to say is that we may need to start thinking about a true successor to the web as we know today, seeing as the current one solves our problems poorly. Maybe, just maybe we’re starting to see the limits of the current web. The most interesting part will probably be seeing how a possible transition to a new architecture would take place.
Ian Hickson said,
October 31, 2007 @ 1:59 am
The WHATWG is quite active, we now have a really detailed and very long specification for the next version of HTML5:
http://whatwg.org/html5/
Feedback is welcome! Browsers are starting to implement this stuff, so now’s a good time to send feedback. See the top of the spec for details on how you can take part in the work. You can also just mail me your requests directly (ian@hixie.ch).
Cheers!
lucmars said,
October 31, 2007 @ 11:46 am
I agree with Ninh, one should take the problem fundamentally: how can we avoid to hack upon a stateless foundation?
From my point of view, the web affords an additional storage easy to share; that doesn’t imply by itself any kind of application as a rich-client. There’s some hype in the wording Rich Internet Application, we are still in a situation of all or nothing: either everything on the client, either everything on the server.
The actual web 2.0 tries to manage the both, but I think that’s a stalemate and the main obstacle is the browser indeed. This one should act as a terminal, a sandboxe where the RIAs are downloaded enabling some remote control.
Ideally the browser shouldn’t have to render anything: it just manages the queries and deal with the OS to provide some hardware’s capacities.