Over the last 24 months or so, TinyMCE has had more underlying restructuring than ever before. We’ve done this in order to take TinyMCE into the modern age of JavaScript, with modern UI/UX thinking and a rich plugin and API infrastructure, ensuring it remains the most popular open source rich text editor and the number one choice for professional software developers.
Between 2003 and 2020, the TinyMCE code has been rewritten quite a few times. In the early years, the code was often completely rewritten, but more recently, changes tend to happen more gradually, in steps. We have embraced a continuous improvement process, to make it easier for our community of developers to migrate to each new version, and move forward with us more easily with both our open source and enterprise offerings.
Our early adoption of unit testing, and the amount of tests we have developed over the years, gives us the confidence to make major changes in the underlying code without disrupting our core users. It is like we are refurbishing an apartment or house with the tenants still in it.
Kicking off the project
A lot of these big changes aren’t immediately visible to the developer audience or our end users. In fact, in some cases, we don’t even want you to notice – that is a good sign that our restructuring hasn’t affected you.
Initial work began in 2016, to move towards functional programming, starting with some underlying libraries that were included in TinyMCE. This increased the size of the project somewhat, but also increased the speed of development and took us on the first step towards modern JavaScript.
Next up, in early 2017, was the separation of the user interface from the core. This was a lot of work – even though it finished around June, it wasn’t merged and released until version 4.7 in September, due to the amount of testing. During this period, we also launched the mobile theme, as we had another team working on that in parallel.
Right after the 4.7 release, we did a minor restructuring, pulling each plugin out into separate parts (UI, Core, API). Some plugins are quite large – separating them makes them a lot easier to work with.
Crunch time
Mid-December 2017, we all stopped work for a week, and focused almost every developer in the company on a single task…
...convert TinyMCE to TypeScript.
This, again, restructured the entire project, touched every file, including all our unit tests, testing platforms, build platforms, release systems, cloud infrastructure, enterprise features etc.
Now, to be fair, quite a lot of work went into preparing for this week – for example, testing what tooling to use, and doing some basic converting of underlying libraries – so we knew we could all work in parallel without significant disruptions.
On the following Monday, we were building TinyMCE and running the unit tests on the converted codebase, thanks to all the devs who crunched through all that code during that week and into the weekend.
Now, what does converting to TypeScript really mean? Well, it doesn’t mean we added type checking to the entire codebase at once. It has more to do with gradually typing TinyMCE over time. But in order to do that, the first step was to get the source building and working with ES6 Webpack instead of our homemade module system.
Since then, our team has gradually typed most of the core. Not so much the plugins, but they are quite minor in comparison to the core libraries and functionality, and we will convert them over time as we continue to make improvements to them.
How it turned out
Now that we have been “on the other side” of this for some time, life sure is great. We have now moved TinyMCE into modern JavaScript using TypeScript, ES6, and functional JavaScript.
The conversion went so well that we decided not to release it as version 4.8, as we knew it shouldn’t really affect anyone (no API changes etc). It was purely a restructuring job. The 4.7.5 release went out successfully on January 22nd 2018!
We are seeing great benefits in the parts that we have added types to. There’s been a significant increase in how fast it is to hunt down bugs and fix them. It’s also been helpful when onboarding developers – it’s quicker to understand and learn the codebase. When adding types to various parts, we also find areas where we can make the code even more rigorous. This has made a huge difference to our confidence in this approach to restructuring TinyMCE over time.
Changing the build process also saved us 17% on the size! We expect to be able to optimize and shave off more from the size as we go.
Why not ReasonML or PureScript or X?
We did quite a lot of research before deciding on TypeScript. One of the major factors, considering the size of the codebase we have, was that we had to make it possible to add types gradually. We also wanted whatever we chose to be mature and have good tooling. It is very hard to beat vscode and TypeScript given these restrictions.
There is no doubt we would prefer to have our codebase in a strongly typed language variant instead of the loosely typed TypeScript way of doing things – that would be a luxury. But TypeScript gets us to 80% of what we need, with substantially less effort, as other options would have forced major rewrites of the entire codebase.
We do continue to look at other AltJS solutions. In fact, we have both ReasonML as well as Purescript code in production use. It is important for us to keep up with the JavaScript movement in this area.
You can read more about the process of choosing TypeScript here:
Benefits of gradual strong typing in JavaScript.
What happened next?
During 2018, we put in a large effort to modernize another big part of TinyMCE – the UI/UX. This took most of 2018 and resulted in us releasing a TinyMCE 5.0 preview in October, followed by a beta in December and a final 5.0 release in February 2019. TinyMCE 5.0 was received well and has had a huge impact in the number of new modern projects adopting TinyMCE as their WYSIWYG platform of choice. During 2019 we also released Tiny Drive, a cloud-based file management solution that seamlessly hooks into TinyMCE.
Why don’t we use React or Vue or X for building the toolbar and UI? Simply because it wouldn’t benefit us – they are not made for it. We can take some concepts around those libraries and implement them, but an editor UI is quite special and needs a proper framework, in our opinion.
What kind of impact did this have on our developer community? Well, you got a modernized UI/UX experience, and an editor that works better with the modern responsive web.
Backward compatibility continues to be our main goal. The new UI API is more strict, but it’s also better documented and easier to understand. Anyone who has tried to use our old API and create a dialog knows it was not optimal.
You should also see better accessibility and keyboard navigation support out of the box from our framework, so if you use the new UI API – building your own plugin, dialog etc. – you will instantly benefit from accessibility and keyboard navigation as well for no effort!
We have also improved skinning, including several skins available for you to use right away. The skin tool is also updated to handle TinyMCE 5 skins.
TinyMCE now
So what is up next? TinyMCE 5.1 is out, and with that, our commitment to mobile is even stronger, with a higher level of responsiveness, accessibility, and related changes to the mobile experience with TinyMCE.
In 2020, you will see us working on a number of new features, but also some major core upgrades, as we are looking into alternative models for TinyMCE in order to support real-time collaboration, track changes, and other cool features.
Here are some recent blog posts talking more about our approach to real-time collaboration:
- Building real-time collaboration applications: OT vs CRDT
- Collaborative editing: real-time collaboration with Slate.js
Get in touch if you have any questions.
During 2020, you will also likely notice a renewed commitment to the open source community and everything around it as we are moving all development to GitHub.
Thank you
To all of you who have supported the TinyMCE project over the years – helping us test, using our cloud, purchasing our enterprise services... – you are helping us make sure the open source project is ever improving and moving forward, producing a product you can count on now and in the future. Our developers continuously refactor 100000 lines of code for everyone’s benefit.
