Why size matters

October 24th, 2008 by Spocke

There have been lots of fuzz and development of small rich text editors lately and I think it’s time to comment on the these. I will try to explain why size matters.

Some users argue that TinyMCE is bloated and that it can be written way smaller if we rewrite it using JQuery, Prototype or some other library out there. This is not the case, we have calculated that we would gain about 5% in size for the core API. In other words 5k but we would on the other hand loose the library independence so TinyMCE will not be ported to any of these libraries since there isn’t much to gain. Most of the logic in TinyMCE is not related to normal library things like CSS selection, event handling, dom manipulation these parts are pretty small in size the large chunks of code are related to HTML Serialization, URL handling, browser workarounds for editing and those can’t be found in any library out there.

Another common thing we see is “TinyMCE has to much features that’s why it’s bloated, this other mini editor is just 1000 lines of code”. I just have one thing to say about that, TinyMCE is extensible most of the features are placed in plugins so if you remove all those plugins there isn’t that much bloat anymore. The other thing is that most of the logic in TinyMCE is related to browser issues and quirks none of that can be covered with 1000 lines of code.

We are trying to make a stable editing solution crossbrowser that will work the same and this is a very tricky task and that task will require more than 1000 lines of code. Trust me on this we have developed rich text editors in JS for 7 years so we have came across hundreds of browser bugs over the years. So it’s not possible to make a stable editing solution small and still fix the bugs. Not until all the browsers starts to work the same way and there isn’t anything pointing to that in the near future since there is no good specification on how editing in the browser should work. The HTML5 specification doesn’t really cover this.

The size of TinyMCE can also be dramatically improved if you use the GZip compressor package we provide . It will reduce the size by 70% and reduce the number of requests with a equal amount. So if you think TinyMCE is to large use that component.

There are situations where small size matters more than the browser quirks and the output. And then TinyMCE might be overkill to use this can be comment systems on blogs, forums and other situations where valid output isn’t required since the server will process the content anyway. This is why we created PunyMCE, we call it the bastard brother of TinyMCE. It’s small, extensible but not that competent and it will never be since that’s not the goal of that project. It will not turn into another big editor, it’s focused on small size it’s only 9kb in size.

So my suggestion is to choose the right editor for the right task. If you need an editor for CMS systems or blogs TinyMCE is a good fit since it will try to produce valid XHTML/HTML output and has all the features you might need. If you need something for a comment system and doesn’t care about valid HTML and have a backend that will parse the editors output choose a smaller editor like PunyMCE.

So finally there is one thing I have left to say. Size matters but there are also more important issues to take into account when choosing an editor. Does it have a large userbase, is it extensible, does it have unit tests, good documentation and active community? If I where to choose something other than TinyMCE I would look at FCKEditor or YUI Editor. These other editors also have what you would need for serious production usage, the smaller ones don’t.

Posted in Development, Software, Work

8 Responses

  1. Ian Hickson Says:

    HTML5 will probably cover more stuff related to editing within the next year or so. Feel free to send feedback to the lists saying what you need. :-)

  2. leo Says:

    So true – thanks for your continued work on TinyMCE! Keep it up!

  3. Jean Moniatte Says:

    Thanks a lot Spocke for posting this. I was reading the 37s announcement with all the tinyMCE bashing and could only think “good luck guys”, for all the reasons you mentioned. The only question I had was about the port to jQuery, but you answered that. Thanks again for tinyMCE!

  4. Bjim Says:

    Spocke, thanks a lot

  5. Spocke Says:

    @Jean: Yes, that blog post was the one that tipped over my barrel.

    But I’m not against these smaller editors as in fact TinyMCE was one of them but back then it was buggy very buggy too. :)

  6. Spocke Says:

    @Ian: I will look into that to see if we could try to make some detailed specification. I think the HTML 5 spec is getting to large it should be divided into smaller chunks. It’s easier then to both adopt the changes for browser vendors and also easier for people like us to contribute.

  7. Speednet Says:

    Nice job Spocke!

    I’ve been a raging fan and user of TinyMCE for nearly the entire 7-year period. You and Afraithe have been two pioneers in this area (text editors) as well as the whole JavaScript-based plug-in model. You took the product an amazing leap forward with 3.0, and we are all beneficiaries of your efforts.

    You guys find some really creative ways around all the various browser glicthes and differences, and you’re always open the new ideas.

    Your obviously well-informed views outlined in this blog entry are the result of a lot of hard work and dedication. My hat’s off to you!


  8. Spocke Says:

    Thanks man, you have been an essential part of the TinyMCE community by your bug testing, patches and ideas.

    Yes, we really took the API to a whole other level with the 3.x release. It was time for a complete rewrite, but I’m not doing that again it was a major task to rewrite everything. :)