I'd like to correct several misconceptions that you seem to have:
Very few people, I'd say. Editize relies on a server-side language being present to be useful, just like all our competitors. Editize however does not tie you to one PARTICULAR server-side language.
Originally posted by philwong
Who actually gets a hosting without either a server side language, like php or asp???
Compared to what? And slow in what way? In our testing, Editize runs almost as quickly as a browser/platform-specific, native solution like an ActiveX control. On current systems, the difference is all but imperceptible. The only significant additional overhead of a Java applet in terms of speed is the startup time, which is about 3-4 seconds longer the first time an applet is used in each browser session due to the time it takes for the Java VM to start up. In a content management system for a large site that is used constantly and repeatedly throughout the day, this startup time is insignificant compared to the productivity gain. So by going with a Java applet, you are trading those 3-4 seconds to get a cross-platform/browser solution. If you don't need, say, Mac OS X or Linux support, and you don't mind pinning your users to MSIE, then by all means use any of the free or next-to-free tools that are available!
Using a java applet is really slow.
There are zero prompts displayed by Editize after the initial setup, assuming "Always Grant" is chosen in the security prompt. ActiveX controls do the same thing.
I also java applets anoying, when you get serveral prompts to authorize the java session and download new files in order to make a application run.
Allow me to reiterate: Editize relies heavily on server-side languages in the same way as those products do. It simply doesn't tie you to any particular one.
I find this kinda anoying personally. Im with M. Johansson on this one. I think the benifits of using a server side language for EditWorks or cfdev are benificial to the expansion of apps such as a WYSIWYG editor.
You are confusing two different things here. Both of the other products you mention have client-side components that are automatically downloaded and installed by your browser the first time they are run. The fact that they rely on a server-side script to deliver those client-side components is irrelevant, as that is exactly what Editize does as well.
Also server side has the advantage of being quick and fast to load.
Again, Editize is intended for use in situations where the editor will be used on a daily basis, and where cross-platform/browser support is an important consideration.
I checked out the demo of Editize, and was disapointed by the need to download a 5mb java file. While this doesnt effect me, my clients who are still using 56k and even slower modems, dont have the time to download such a big file, its even worse when there connection drops out, since a 5mb file, would take about an hour via modem.
In such cases, a 5MB download is trivial compared to the productivity delivered by Editize. For example, our editor Georgina had to download the Java VM over a year ago when we first started using early prototypes of Editize in the SitePoint CMS. She has used Editize to keep SitePoint up to date almost every day since, without ever having to install a new Java VM. I'd say she got a lot out of that one 5MB download.
If you told your clients they could administer their Web site's content with a WYSIWYG editor that provided a familiar, word processor-like interface, and all they had to do was download a 5MB program to do it, I'd be willing to bet they'd have no complaint. Why should they complain, then, if that program just happens to be the Sun Java Plugin?