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.

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!

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.

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.

http://developer.yahoo.com/yui/editor/

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)

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…

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?