550 days of WYSIWYG

These days we’re wrapping around the version 2.0 of our rich text editor and we’ll bring it in your projects on August 1. On August 1 there are 550 days since we published our first version and we believe that the new version is the perfect way to celebrate this day. We’re thankful to everyone who supported us all this time and helped us to create a top editor. We learned a lot from both your positive and negative feedback and we can’t wait to get your next email.

In 550 days of developing our WYSIWYG html editor we’ve discovered all the pitfalls of creating such a product and how hard it is to make it cross browser, cross platform and specially responsive on small screens. With these in mind, we developed the new version 2.0 and we’re really excited of how it comes along. In the WYSIWYG world usually every new feature comes with a new challenge, but I want to share with you 5 of the biggest challenges that I believe every developer will face building a web rich text editor.

1. Keep it small and fast

It’s worthless to mention how important it is to create an website that loads fast. At Froala, we’re always looking to make our products more powerful but smaller at the same time. WYSIWYG editors have many features and if you keep adding features inevitably your library size will grow. However, the features each websites need differ a lot and many times developers end up including much more code than they would actually need. Our new core comes under 50KB gzipped and additional features can be added by including only those plugins that you need.

2. execCommand is bad

If you don’t care about the output you will get, then execCommand probably won't hurt you. But if you’re aiming to create a WYSIWYG editor that produces a clean output and that doesn’t break your website's SEO you should try a different approach. Browsers are competing with each other and each of them wants to attract as many users as possible and as long as there isn't a standard for execCommand, they won’t do it right.

3. Handle selection

In WYSIWYG editors, the selection is one of the core things. It is very important to be able to save, restore and modify the selection. Unfortunately, as I said before, browsers do what they want. Although Mozilla presents the selection API in detail, nothing will work as you expect on Chrome, Safari, Opera or IE. There is Rangy which does a great job, but at over 50K minified it is just too large.

4. Mobile WYSIWYG

Rich text editors started on the web, but these days users use their smartphones and tablets a lot and they want to have the same web editing experience right at their fingers, on their hands. Mobile editing is not only difficult because of the small screen size, but also because each device adds in its own selection elements which are not consistent at all. Moreover, the way touch and selection events work also vary from device to device and even from browser to browser on the Android platform.

5. Keep Testing

We all know how important it is to test the software you write and how great automated tests are. When you build a WYSIWYG editor you’re spending more time writing tests and testing than you’re writing code. To make you an idea, we have almost 100 tests just for a simple enter action. Besides that, there are specific actions, such as pasting and typing that cannot be replicated with automatic tests and you need a list with manual tests which are very time consuming.

And if I mentioned testing, this is exactly what we’re doing now. We’re testing every single feature of the version 2.0 on all devices and we’re going through the entire list of fixed bugs from version 1.0 just to ensure that we don’t miss anything. The new version comes with a lot of new features that you asked for and features that we considered to be a "nice to have" and that most users will find useful.

We’re also curios to get even more feature ideas from you. So, if you have any specific feature or plugin for the editor in mind, please feel free to share it in a comment below.