Why I chose TinyMCE
This article was written for and originally appeared on Blueprint by Tiny.
I have been using TinyMCE in projects for years. Many years. Over a decade in fact. And in that time, I have seen it evolve from being a great WYSIWYG text editor to a robust, modern, flexible, and incredibly powerful platform that goes above and beyond being just a WYSIWYG editor.
The initial project requirement was simple:
I need to allow the user to write HTML content without actually knowing HTML - a WYSIWYG editor, like a word processor, that anyone can use.
During the initial research for the project, I ended up with a shortlist of potential existing candidates, or the prospect of building my own.
Given the complexities around HTML markup, why would I consider building my own? I had my whole project to build, not just the WYSIWYG editor, so that option was discounted.
But what was it that made me go for TinyMCE over the others?
TinyMCE out of the box was advanced. And just for the record, it still is. TinyMCE offered the features that were needed - from an easy-to-use user interface for authors to edit content with a familiar word processor-like appearance through to complete and easy flexibility for developers to customize TinyMCE to look, be and do exactly what the project needed to do.
For the first project, we needed to control specific aspects of what was and wasn’t allowed - it was really important for our client that HTML markup was of a high quality. We needed to ensure HTML markup only allowed certain elements and attributes, and give authors a set of tools that best suited their workflow. Some authors had a simple toolbar, whereas the administration team had a larger suite including source code editing. Documentation for TinyMCE made it so easy to understand how to achieve what we needed, and it just worked. Documentation is such an incredible tool for developers - and TinyMCE’s documentation base keeps growing in quality and quantity, making my life easier as a developer to understand and implement different (and new) features.
In addition to great documentation, I really appreciate how the product and engineering team is dedicated to continual improvements. Some of the older editor offerings no longer exist, but Tiny keeps maturing and continues to innovate with a huge range of core and premium plugins - and not just bells and whistles either, but useful and purposeful additions including a strong focus towards helping authors create accessible content.
The appearance of the web has changed significantly over the past 20 years, with different trends coming and going. I even remember the hoops we had to jump through just to get rounded corners on a container. Developing these days is a pleasure thanks to improved tools and browser support - but even with all the awesome tools, the user interface and experience is still key.
Even when I was first selecting a WYSIWYG editor, TinyMCE’s interface felt modern. Side note: for the time. It was the little things - the way the toolbar had buttons that were purposeful but not cluttered, and dropdowns that were in the right spots. It felt like an all-in-one editor, that was purposely built, not just blank containers that you fill with buttons and hope for the best.
The aesthetics of any tool can help improve (or destroy) the user’s experience. Out of the box, very little was needed to make it fit in with the overall project’s look and feel.
The Tiny team has spent so much time on simplifying and refining the TinyMCE 5 interface - and I feel it is one that can effortlessly fit into any modern project. With such a focus on usability (and accessibility), TinyMCE 5 can be configured, skinned, and styled to fit in with any project’s aesthetic.
Extensible and Logical
As with so many projects, TinyMCE ticked most of the boxes. And for the very few boxes it didn’t tick, it did allow external plugins to be written to satisfy the remaining requirements on my checklist.
While the documentation for writing a plugin was absent at the time, and the process was more about deconstructing the core plugins to understand how they worked (and a lot of trial and error along the way), the fact that external plugins were openly supported meant that functionality could be added to meet the project’s needs - and the developers knew that.
Even instantiating the editor felt entirely logical and natural - it felt organized and modular, and incredibly self-explanatory. While the suite of options available has grown over the versions, even a newcomer looking at a tiny.init call can quite easily see, interpret, and understand what the configuration is going to do.
Version 5 of TinyMCE, while refining the way plugins are built, has created an architecture that focuses on a consistent user experience and user interface, and using components familiar to your TinyMCE users. With awesome documentation (plus a number of articles that I’ve written about writing your own plugins for TinyMCE), developing your own plugins for TinyMCE has never been easier.
I’ve written a few blog posts to help you get started building your own TinyMCE 5 plugins, and showing off some of the more advanced (yet still simple to use) features:
TinyMCE 5: Creating a Custom Dialog plugin (and with custom button icons)
While plugin documentation may have been absent at the time, community support was not. The TinyMCE community forums - which still exist today - made it easy to see how others had used, configured, extended, and solved their issues with implementing TinyMCE v2 and v3. Compared to the competition, this forum felt active and safe, with on-going input from the development team and regular posts from the community members. News of features, fixes, and updates was supplied, as well as notes and comments of the roadmap and changes.
When choosing TinyMCE, it was reassuring to know that there was an active and supportive community to find and ask for help. And remember, not just about your tech queries, that it is always OK to ask for help.
Today, with an active presence on GitHub, communities like Stack Overflow and the Tiny Community, plus passionate developers and users like myself, there is such a huge Tiny community for you to become a part of to learn, share and build something awesome.
What gives you faith in the active-ness of a project? Its update history. Even today, you might find a library of use on GitHub but see that it hasn’t been updated in years. That doesn’t give you much faith in adopting it for your project: what is your longer-term support and maintenance strategy?
TinyMCE, while still young itself at the time, had a very active voice when it came to newer versions coming out, especially compared to competitors who appeared to have stalled with support and development.
Now, with version 5, it is so exciting to see Tiny’s regular update schedule, with increasing version 5 updates adding features, fixing issues, and improving the experience. It is so easy now for newcomers to get started with TinyMCE on the cloud with a free API key- and such a time saver for on-going maintenance knowing these new patches and features will automatically be available to your users as they are rolled out. This keeps me focused on supporting the project, rather than needing to dedicate hours on maintaining one component.
While over a decade has passed since that initial question was asked, the answer for me remains the same for every single project. With the evolution of TinyMCE as a product, its feature set, aesthetics, extensibility, community, and update history have grown with it, creating a mature and reliable product that excels at its core goal: to deliver a best-in-class content authoring experience. And as a developer, I love how it can be configured, extended, and shaped to fit any application environment where authors need to write HTML code (without actually knowing anything about writing code themselves). With the commencement of my next project just around the corner, I already know that TinyMCE will be the WYSIWYG editor used. No question asked.