I am guessing noone has avoided noticing the financial crisis in the news, going through the world like a wave through an arena crowd. Can’t really say we have noticed it on our end though, this month will be a record in visitors for the TinyMCE website, as well as a monster amount of bandwidth being pushed out since we moved examples from the Wiki website to the TinyMCE website.

We certainly do not feel like we will be affected much by the financial crisis, on the contrary, perhaps the IT budgets are more slimmed and that makes companies look for Open Source alternatives, and finding that some of these projects are more structured, more tested and more stable than their commercial or home made version.

Currently we are busy doing major work on the MCFileManager and MCImageManager, planing to release 3.1 final during next week, with major behind the scenes rework of the graphical user interface, as well a few new features. We are also working on a secret new Open Source project we just came up with (stay tuned for that).

We will see what the future holds.

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.

TinyMCE is not always the perfect match if you need something really small and simple. TinyMCE is designed to be a CMS editor and it has all the features that you might need for such a task.

Some times you want something really small and simple for example on a forum or comment system. This is where PunyMCE comes into the picture it’s designed to be small and simple but yet extensible. It comes with a number of plugins that extend the functionality of the editor.

The size of PunyMCE is “puny”, about 9kb gzipped or 16kb minified. It’s library independent so it can be used with common frameworks like jQuery, Prototype, YUI etc.

But it’s important to understand that PunyMCE is not designed to be an replacement for TinyMCE nor will it ever be. TinyMCE is focused on being a robust CMS editor that produces valid output and takes care of all browser quirks. PunyMCE is focused on being small and simple, it might still have lots of browser quirks and output issues some of these can be corrected by using serverside technology.

This project was a result of a partnership with Freewebs. Kickapps has also joined the project and will help out internationalization.

So check the PunyMCE project out at:

PunyMCE
Google project

I think I have found the answer, noone reads it anyway, if you look at the TinyMCE forum, 75%-90% of the questions have direct answers in the documentation (or even the FAQ), and the replies to it is simple “check the documentation” followed by a “brilliant, thanks!”.

In my opinion, TinyMCE is quite well documented, thanks to ppl helping out and keeping it up to date and free of typos. It has taken a lot of time to make this documentation good, and it feels kinda sad that ppl do not take the time to read it.

Everyone does not have the same way of thinking, but at least when it comes down to solving an issue with a 3rd party software, these are the simple steps I follow.

1. Check the documentation to the product, the readme, install.txt, wiki etc.
2. Try a few different Google querys to find out if someone else has had the same problem.
3. Search in forums/mailinglists etc for a solution.
4. Try to contact someone or post in public forum/mailinglist etc.

Seems like a lot of ppl just skip to step #4 right away.

Well I guess it is better to have than not to have in the end, hopefully some ppl developing more advanced integrations get a lot of help from the API documentation etc.

As you may have noticed we now have a proper logo for TinyMCE.

In other news, we are working hard on a new version of the MCFileManager and MCImageManager, quite a lot of code re-working but not so much on the outside look and feel. Also expect a small update to TinyMCE to correct some minor bugs found in current version.

Also noticed we passed 2 000 000 downloads on Sourceforge since TinyMCE project start, add that to the 1 800 000 downloads of Wordpress (2.6 only) with TinyMCE pre-installed and there is no doubt that TinyMCE is the most popular WYSIWYG editor at the moment.

The last work on our office is currently being done, and the new furniture has been ordered.