The TinyMCE 3 editor that we used in DrFront v2 works pretty well. But we wanted to make better use of workspace area, choosing inline editing directly on the front seemed the natural way to go and the timing seemed right since WYSIWYG editors had been evolved.
In September 2012 we did some research and came to the conclusion that Aloha was the best of the existing editors. We picked Aloha because of several reasons. Number one, it was an open-source project. It had good plugin architecture that we felt was important to not be restricted by the core too much. It had a large and active community (or at least it felt so), and it was used on big projects like Typo3 and Drupal also acting as contributors.
We had most of the features working pretty well but when trying to fix the last things we encountered more and more stuff that was very hard to fix because of missing parts in the Aloha core. We spent much time trying to get these things fixed but the core team didn’t show very much interest when trying to get it merged their codebase. Here’s some of the reasons why we got tired of Aloha:
- The fact that they say it’s the “World’s most advanced HTML5 WYSIWYG Editor” on their homepage and haven’t implemented proper undo yet says it all.
- The lack of good documentation about the API was very frustrating and we was always ending up with digging into the source code.
- A totally broken undo implementation.
- No support for video embedding.
- A totally broken test suite that never passed the tests as far as we know.
- Many of the bundled plugins sucked and we ended up writing our own.
- Very basic functionality was missing like source editing and a color picker.
- Lack of API for doing formatting of the markup like adding CSS classes to a text selection.
- Huge codebase and a mess to integrate properly.
- Spagetti code with huge methods which is a sign of bad API design and lack of reusable methods.
- Based on heavy and non-modern build tools.
When another Aptoma team mentioned that they tried TinyMCE 4 for a project recently and that it had inline editing support we got very interested. Our gut feeling about Aloha said that if we stick with it, we will spend much time on bug fixing and adding workarounds in the future. So we decided to take TinyMCE 4 for a spin and see if we got a better gut feeling about that one. And we did! We were able to have it running in about one hour and did some testing for a couple of days. We then decided to go for TinyMCE and had everything working in a couple of weeks.
Here’s some reasons to why TinyMCE feels so much better.
- Well tested and proved stable for many years.
- Very good code quality and not very big codebase (they use AMD now).
- An awesome formatting engine that makes is very easy to do formatting of a text selection.
- Good plugin architecture and event system for extending the functionality.
- Good documentation about the API.
- Passing test suite based on modern tools.
- A media plugin for handling video.
- Much functionality out of the box with the bundled plugins.
- We had much experience with TinyMCE from before and the API hadn’t change that much.
- Very easy to integrate.
So what have we learned?
Be more critical about the quality of the documentation and how active and responsive the community is. If you start to dig into the code for “documentation” too often or, you should consider it a bad sign. If your pull requests are ignored or the project has over 2 years old open issues on GitHub that’s a bad sign too. And the most important of all, you can always count on swedish developers (main developer of TinyMCE “Spocke” is from Skellefteå in Sweden).
Patrik Henningsson, DrFront team