When and why to migrate from one WYSIWYG editor to another

Posted under Frontend, Software development On By Ryan Lanigan

In our experience there are two reasons to migrate from one WYSIWYG editor (or any large library) to another:

  • The business needs have changed and the current choice does not support those needs
  • The management of the library changed and resulted in support degradation

Seeq uses many libraries for various purposes, and one of the above (or both) have driven us to move from one library to another multiple times. Our initial choice for a WYSIWYG editor was Froala V2, which served our purposes very well. Over time though, it fell victim to both of the described issues, which necessitated us to migrate to our new editor, CKEditor 5. There’s a good bit of history in why we picked one over the other, and how we ended up going with CKEditor in the end.

Why Froala in the first place?

Several years ago, Seeq expanded its functionality by adding a WYSIWYG editor to supplement the analytical work that users were doing with Seeq. We didn’t want to have to create our own, and instead wanted a speedy, reactive, and affordable editor from which to start. It also needed a robust support system as we wanted to trust that we could upgrade Froala without much issue, and also talk to a team of people to help work through whatever bugs we encountered. To that end, our engineers investigated a variety of options and found that Froala V2 ended up winning out in each of the above issues. We integrated Froala into our application with ultimately few issues, and even created Organizer, a new Seeq product that used Froala to create and layout reports.

Our editing functionality, though not as robust as Word, was widely considered pleasant to use, and we were able to push through a scheduled updating system for generating new visualizations for the aforementioned reports, all through Froala.


During the work for the scheduled update system, two distinct issues became known:

  • Froala had recently been purchased, and Froala V3, while having a similar but improved feature set, was notably more difficult to upgrade when compared to previous versions.
  • Froala’s lack of true layout and interactive widgets (read: React components) was stopping us from moving forward with future plans for Organizer.

Pushing us forward over the next several months was an onslaught of issues we discovered in Froala V3 that were not present in previous versions. Below is just a subset of the overall issues:

  • Cannot paste in images and upload them to the server
    • The release that added this was noted to have an “ALL NEW Enhanced Upload Image Feature”
  • Breaking its own copy/paste code requiring us to customize a broken (but mostly stable) release to patch their own bugs. When trying to use a later release that fixed said bugs, we found new bugs, so we reverted to our stable release
  • Breaking the packaging code so commonly used features would instead attempt to use other features (e.g. inserting an image would try to instead replace an image that didn’t exist, which would result in nothing getting inserted).

Strangely, upgrading to newer Froala pointfixes fixed some issues and broke already existing features. We no longer trusted the QA process for Froala to catch issues for us, which was pretty darn spooky.

Though seemingly minor in comparison, the issue of not being able to insert custom widgets combined with our growing unease with using Froala pushed us forward in looking to migrate for a new editor.

Picking a new WYSIWYG editor

If you recall from earlier, we only had a few requirements for a WYSIWYG editor: generally fast and reliable, a robust support team, and affordable (though what affordable is does change after several years of growth). Now tack on custom widgets and custom layout options, and a need to reevaluate became apparent.

Froala is thankfully not the only editor on the market. Below is a short list of the editor/editor frameworks we evaluated and would highly recommend anyone explore as alternatives. Though each of these had their benefits, there was a significant downside with each one that made us skip out on it.

  • Quill: Ideally, though we don’t mind fixing the occasional bug in open source software, given our history with Froala, we wanted something we could talk to a dedicated support team to fix, and Quill being completely open worried us.
  • TinyMCE: We got a demo from them and they weren’t able to dive into the specifics of a lot of our more technical questions, so we kept exploring other options.
  • ProseMirror: A fantastic framework buuuut with the wee downside would have required us to build an entire editor and that extra startup time of 3-6 months to build said editor worried us.
  • Slate: A very bleeding edge editor, all reviews were great, but it had broken backwards compatibility multiple times. We didn’t want to bet everything on something still unstable.

We ultimately went with a different editor: CKEditor 5, which answered every single one of our woes! It:

  • supports custom React components
  • supports a variety of layouts
  • has active support that we can interact with
  • can support multi-user collaboration out of the box
  • and so much more!

I’ll detail some of the ways we’ve been using CKEditor in a later post, but in short, it’s great! It has its quirks, but we’ve upgraded two times since integrating it and nothing’s broken, so that’s a win in my book.

Looking back

Could we have seen the issues with Froala when we picked it years ago? I don’t think so. Any library can fail to meet your needs when your needs change, but I think Froala’s QA failures are an anomaly in this space. It’s not worth speculating on what the future of what a trusted library is. What matters is that shortly after your business and technical needs are no longer met, you focus on how to fix it. We spent a lot of time fixing bugs in Froala, and when we realized our investment was no longer paying out dividends, we researched, planned, and implemented a new editor.

As a closing note, I really hope Froala gets to a place where I feel confident in it again. Its user experience is quite good, and I feel like our experience with it may have been an anomaly, as I’ve heard little else but positive things about it during my research.

Notify of
Inline Feedbacks
View all comments