The State of Rich Text Editors

2021 Annual Global Survey Report

In the inaugural year of The State of Rich Text Editors, nearly 500 developers shared their thoughts on how they use rich text editor platforms, their tools, integrations used and what’s most important to them in their daily work.

475 respondents

Security is of utmost importance

UX is the focus of most RTE challenges

Innovative features less important than user and developer-friendliness

Growth in API usage reflects API Economy mega trend and digital transformation

Download the full survey report →

What did they say in 2021?

Who’s who?
Stacks a-plenty
What’s your weapon of choice?
The sticking point
Future trends

How did we get here?

In the pre-world wide web era of the 60s and 70s, documentation was a disaster.

Authors, content creators and the ‘typists’ of the day had little control over how their documents were formatted. Things needed to change, but by who and when?

In 1972, Xerox PARC recruited Butler Lampson and Charles Simonyi, who began developing the first WYSIWYG (What You See Is What You Get) editor. By 1974, the world’s first WYSIWYG document preparation program, Bravo, became operational. Bravo was enabled by the first fully networked personal computer, the Xerox Alto, but was unfortunately never publicly marketed so the WYSIWYG editor remained hidden.

Then in the early 80s, word processing software became the thing.

Although very rudimentary compared to today’s editors, WordStar software and its competitor, WordPerfect, were arguably the first mature WYSIWYG editors widely available. However after (now ex-Xerox) Simonyi joined Microsoft in 1981, Microsoft Word hit the market in 1983 and writing, printing, and publishing skyrocketed.

According to SimpleThread, “The first browser-based WYSIWYG editors became possible because Internet Explorer decided to implement designMode and contentEditable, which gave users a way to edit rich text in the browser. This original implementation of designMode and contentEditable ended up being reverse engineered by developers at Mozilla.”

Once the first website went live in 1991, the heyday of rich text editor innovation began.

In 1995 the first WYSIWYG HTML editor, WebMagic, launched. FrontPage (on Windows) followed in 1996 and Dreamweaver in 1997. The various ‘browser wars’ for dominance then led to numerous RTE innovations, all focused on creating more user-friendly interfaces.

The more recent 2010s years delivered the cloud-native Google Docs software — where previously unimagined collaborative opportunities were added to online rich text editors, as well as cross-browser compatibility.

It’s thanks to the groundwork laid by those early rich text editor pioneers, that WYSIWYG HTML editors are now seamlessly integrated into (and supporting) a myriad of software projects.

WHAT DOES RICH TEXT EDITOR (RTE) MEAN?

The term ‘rich text’ refers to the styling applied to text — over and above plain text. Traditionally bold, italic or underline were the most simple kinds of rich text, followed by other styling techniques such as fonts, sizes and colors.

Most rich text editors are also WYSIWYG editors or What You See Is What You Get — so you can see the rich text as you’re writing it in the editor.

Part 1 of 5

Who’s who?

Developers truly are the centre of our universe

Not just your old forum circa 2000, or the clunky business tool we love to hate — rich text editors (RTE) are a core component of many of the most modern, everyday tools used. That integral role, seems to have also spilled over into who’s using RTEs.

Who responded?

1.1

45%

developers,
full-stack

News flash: Rich text editors are a front-end tool, in a full-stack world! Usually considered a front-end UI component and/or API, it appears that rich text editors are primarily being used by full-stack developers.

Being one of the most surprisingly complex components to create — especially when a single button like ‘Bold’ can have 40+ different calls and interactions — this finding has big implications on a product.

TAKEAWAY

Choose an easy, user-friendly interface that’s suitable for both developers and non-code users:

Lowers ongoing support requests from non-coders
Increases user base opportunities
Maximizes productivity across workflows

On what basis are you employed?

1.2

Not surprisingly, the majority of respondents are employed as full-time developers. However, with more in-house development teams working on editing components, it suggests that many companies now see the value in investing in the creation of a great authoring experience.

RECRUITMENT TIP

Whilst a lot of developers work closely with rich text editors, not all have in-depth experience building one, so screen for traits like learning ability, problem solving skills, and a good solid knowledge of your tech stack.

53%

full-time

17%

self-employed

freelancer

retired

contractor

part-time

other

How many years experience do you need to use RTEs?

1.3

Despite finding their first home within those websites of yesteryear, rich text editors are now all grown up. They’ve become the silent stalwart — a fundamental component that’s always there to support you — yet is surprisingly complex to build, maintain and update. It’s likely for that reason, that the majority of the survey respondents were senior developers, with 10+ years experience.

It may also reflect the fact that the survey sample leaned towards full-time developers, who are more likely working on complex projects where the RTE is an integrated component of another product — thus requiring senior expertise.

TAKEAWAY

Rich text editor onboarding procedures, and support, must reduce friction and speed set-up:

Ensures a wider base of users are learning the underlying importance and uses of RTEs
Early exposure of young developers to RTEs aids market longevity, loyalty, and usage
RTE skills are carried forward throughout careers

How often do people really develop with their editor?

1.4

It’s taken years to create the hundreds of tools used by websites. Equally, Rich Text Editors have taken decades to create a simple experience that’s used by millions.

We get it, generally most people choose a component, integrate it, ignore a few releases and then finally update to the latest version. However, because RTEs are such core components within a diverse range of applications, it seems developers are frequently working with them, updating them and fine tuning their capabilities.

An extension of the same (now overturned) assumption of intermittent use, is the idea that the more frequently a user works with an RTE, the more entwined it becomes within their systems. In turn, that grows the users’ skills and experience with rich text editors.

With over 80% of respondents self-rating their experience as high, the 2021 survey results clearly debunk the theory of hands-off involvement in an RTE, after it’s integration into a product, project or platform. It seems RTEs really are a developer’s BFF!

TAKEAWAY

Developers must have full access to easily customise and adapt RTE base code:

Able to mould code around their needs (but does the core meet the open source test?)
Flexible code and configurations to suit the specific projects and/or products being built
The ability to pick and choose features that fit the use case

What kind of applications are being built?

1.5

No surprises here. CMS and websites are some of the most popular uses for rich text editors. But there’s also less traditional spaces such as AI and commerce systems, who are also seeing and pursuing the need for rich text editing components.

TAKEAWAY

A rich text editor is intrinsic to a vast array of applications and workflows:

Facilitates scalable growth
Adapts to changing technology
Provides the security needed for your business and/or industry

Part 2 of 5

Stacks a-plenty…

But, what does the tech stack look like?

From pure HTML, to frameworks, whales and why not throw in some ships' wheels — developers are integrating rich text editors into their platforms in various ways. Keeping up with (let alone ahead of) growing consumer, user and developer demands, requires a close understanding of how modern applications are being built. And, with what tools. Given the current growth trajectory of the API Economy, the future of RTEs may well rest on the efficiencies provided by seamless integrations.

What’s your industry?

2.1

Every webpage user experiences
a Rich Text Editor.

The majority of respondents appear to be building SaaS applications (as designated by ‘Computer software’ in the results). With the continued growth of eCommerce in a COVID-19 world, it appears more companies are acknowledging the results gained through great content that augments their online shop offerings.

Watch this space: News/Media/Publishing still remain noticeable, but it remains to be seen how much longer it takes this industry to move to more experiential content that’s conversion-focused.

What kind of development work does your company do?

2.2

With the majority of respondents dwelling within the SaaS space, it’s no surprise the majority are building commercial software. However, websites still remain a key contributor to the rich text editing space.

It’s likely that future surveys may endeavour to better understand the in-house and custom-tailored applications undertaken, as well as gather more detail on what encompasses ‘website’ development work.

TAKEAWAY

Regardless of the kind of application you develop, it’s important to check out the security, stability and maintenance of the editor you select. Does it have:

Enterprise grade support with dedicated SLA’s
Guaranteed uptime
Regular ongoing release and maintenance

Preferred programming languages

2.3

Rich Text Editors are one of the Internet’s primary tools that produce terabytes of content daily.

Given the future of rich text editing relies on developers, it’s vital to understand the programming languages they use (and favour). PHP is predominant, followed by JavaScript — and while there’s a cluster of other languages noted, just as significant is a segment of no-code respondents using rich text editors.

RECRUITMENT TIP

Not all languages are the same, nor are all developers. When recruiting developers, it sometimes pays to not solely look for 10+ years’ experience in niche languages. Instead, focus on the ability to problem solve and learn quickly on the fly — because industry changes aren’t slowing down anytime soon.

What front end framework do you use?

2.4

Not unexpectedly, ‘React’ and ‘Bootstrap’ ranked equal first in usage, but what was most interesting is that ‘Regular HTML/CSS/JS’ ranked equally to those two frameworks. Whilst we’re currently in an era of new frameworks emerging, none of them have quite reached the full adoption that some developers might have been expecting.

This could signify the importance of ensuring the provision of APIs for custom work — to support those people who are not using an off-the-shelf framework. It also highlights the need for quality documentation and 24/7 support to answer integration queries from developers.

Part 3 of 5

What’s your weapon of choice?

Editor, uses and stuff being made

With so many different rich text editor options for developers, as well as open source, paid and hybrid available to choose from — not to mention building their own — it’s always interesting to see what people are really using… and what stuff they’re making.

What rich text editor do you use at the moment?

3.1

This is a snapshot of the market popularity of various rich text editors. As a pioneer of the sector, ‘TinyMCE’ (5 followed by 4) are the top placed products, followed by ‘CK Editor’ (4 followed by 5).

TAKEAWAY

Whilst TinyMCE is the leading editor — not all editors are built to deliver a better user and developer experience. When choosing (or building) an editor, ask yourself:

If my editor of choice goes unmaintained by a third-party, will this negatively affect me?
Do I really have the resources to build and/or maintain an editor myself?
If I choose to take one ‘off the shelf’, has it been built to serve a developer and not just an end user?

Where do people use their editor?

3.2

It’s clear from this result that RTEs are predominantly a workplace tool, with few respondents using them for personal projects. Does the world really need another personal cooking blog? Maybe not…

75%

work

18%

personal projects

don’t currently use rich text editors

What rich text editors do you use, or have experience in using?

3.3

The marketplace dominance of TinyMCE 4 and 5 is clearly shown through those surveyed. That said, the broadness of responses reflects a wide variety of RTEs that had been sampled during the process of finding a long-term RTE that satisfied their needs and gained their trust.

What type of editing experience did you recently create?

3.4

Understanding the variety of editing experiences people recently created, shows the breadth of RTE uses. Currently, ‘CMSs’ are the predominant projects that developers have recently worked on, followed by ‘Web apps’.

TAKEAWAY

Not all editors are built to perfectly manage the same use-case. When looking at a rich text editor, it’s worth considering:

Is (or can) the editor be configured to provide the features both now and in the future, to support your end users needs?
Are additional plug-ins or features needed, to complement the editor out-of-the-box?
Can the editor deal with multiple users utilizing the component simultaneously?

Part 4 of 5

The sticking point…

Choices + challenges — are you chasing unicorns?

Despite how hard we may wish, it’s clear there’s no single rich text editor that perfectly solves everything. Consider that as your company scales, grows, and evolves, so too does your product roadmap investiably. So when you’re looking for an editor, don’t chase a unicorn that doesn’t exist. Instead, pick a proven editor that has a trusted reputation and track record of creating consistent, regular, innovative updates to their application.

What’s your preferred deployment option for a rich text editor?

4.1

Deployment options are an important gauge of the overall market and the speed of transformation being undertaken across the digital landscape. Without question, ‘Self-Hosted’ is currently the preferred option, but ‘Cloud’ is close behind. Next year’s 2022 survey results will be interesting… to see how (and if) Cloud growth continues in relation to Self-Hosting.

TAKEAWAY

The Cloud vs. Self-Hosted debate continues to rage. And it will, for some time yet. When considering your options, it’s important to pick the one that’s right for you now, and in the future:

Do you want to ongoingly maintain and update the editor code?
Is security the highest concern for your business, so everything must be Self-Hosted?
Or are you most focused on flexibility, maintainability and scalability?

In the next 2 years, are you planning to change the way you deploy your rich text editor?

4.2

Closely tied to the context of the preceding question, this response gauged people’s readiness for change. Overall, it’s clear that the market isn’t open to making rapid changes to how they deploy software. However, there’s clearly an interest in exploring options — so long as there’s no requirement to commit to a specific direction.

That said, with the continued growth in remote working and evolution of Cloud-based rich text editors, there’s clearly increasing interest in moving towards a digital world, based in the Cloud.

TAKEAWAY

Not all Cloud-based solutions are as mature as others, and very few rich text editors on the market offer such a solution. An editor that supports Cloud-based should:

Be committed to security
Be committed to continued investment in their cloud infrastructure

What drives your choice to use a third-party rich text editor, as opposed to building your own?

4.3

‘Speed of development’ and ‘Ease of implementation’ are the core reasons for buying a third-party rich text editor (and integrating it as a component). After all, according to Open Hub, for just the open source core components of each, it’d take an estimated 71 person years to recreate TinyMCE’s 270,122 lines of code, and 128 person years for CKEditor’s 484,006 lines of code. Yikes!

TAKEAWAY

There’s not many development teams who have multiple years or dozens of developers to invest in building a single component. Frequently, buying components and assembling a tech stack of reusable software is the smartest move — after all, how many rich text editor developers are there in the world?

Buying an RTE (as a component) is easier to deploy
Buying an RTE (as a component) gets products launched faster
Buying an RTE (as a component) minimises development time

What drives your choice to build your own rich text editor RTE as opposed to using a third-party editor?

4.4

Unlike the reasons to buy, there are no clear reasons to allocate development resources to internally building a RTE. Most people responded with ‘Not applicable’ — indicating there are difficulties in making a strong enough business case to take that path.

TAKEAWAY

Generally, it’s investable rich text editors that end up being built in-house. And that’s perfectly OK. However, the strategy sometimes comes up against some ‘get off the ground’ challenges:

A financially solid RTE business case is hard — the leading RTEs spend millions a year building and developing their editors to enterprise grade standardsBuilding an in-house RTE is only viable for teams with dedicated skill, experience and time
Given the avoidance of licensing fees is the second largest driver, open source offers some great solutions

What challenges are you currently experiencing with your rich text editing solution?

4.5

Three of the top five challenges focus on the user — ‘User experience’, ‘Reliability’ and ‘Support for mobile application’ — making it clear that developers desire more focus on that area. ‘Keeping it up to date’ was the third most important reason, indicating the need for easier ways to implement updates, with no need for developer intervention.

Part 5 of 5

Future trends

Features + innovations are best kept simple

In a world where ‘shiny new objects’ attract our attention, the winning rich text editor formula is surprisingly clear. No innovations, no fancy features, just keep it simple and deliver a great, secure user experience.

What are the most important features?

Security was ranked most highly — as ‘Extremely important’ by developers. The second big trend was that new, cool, and fancy features aren’t a top priority. AI, real-time collaboration and drag-and-drop layouts all fell to the bottom of developers’ wish lists.

Another aspect that’s of relative importance is developer friendly features. That includes getting started quicker, being able to edit the HTML code and customizing the editor.

Number of responses. Click tabs to change results view

Download the full survey report →

Looking to create interactive content that looks stunning and performs?

Both TinyMCE and Setka are tools from the same developer-trusted editing toolbox,
that’s used for content creation projects.

Get in touch

TinyMCE is a WYSIWYG authoring tool — used for creating trusted, text-based content

Setka is a no-code design tool — used for creating interactive, performance-oriented content

Empower your team’s end-to-end content marketing, workflows
and productivity by designing and publishing digital content that
attracts, engages and converts.

THIS REPORT WAS MADE IN SETKA