The State of Browser Based Text Editors
Posted by Write.app on 04/02/2013
In a previous post I mentioned rewriting a lot of Write.app's codebase. I could start with authentication or routing or any other current feature but what I chose to do first was rewrite our editor. The state on web-based text editors is abysmal. It has gotten a lot better in recent years but there's still much to be desired. I want to talk about what I'm looking for in a text editor and what we should expect from browser-based text editors if anyone ever hopes to make one that can ever hope to compete with native text editors. WYSIWIG editors don't count by the way. The kind of editor I'm talking about needs to not only take input well but save it in a format that doesn't turn the output into total garbage (looking your way Wordpress and TinyMCE).
Things I expect of my editor
I write a ton of code. I basically want to take Sublime Text 2 and put it in my browser and run it from any computer, phone, or tablet. This may be a tall order so instead of expecting every function a coder needs, I'll focus on the few must-haves especially for Markdown.
Multiple themes/color scheme options
Sometimes I want my editor to be light with big monospaced text. Sometimes I want a nice serif font. Sometimes I want to use Solarized Dark as my theme. I should be able to switch themes quickly and easily just like I can in my native editor.
I want my Markdown to be highlighted. Mou, my favorite Markdown editor for Mac does this very well and has some beautiful themes too. Check out this gem:
It's very well done! This is what I want in a browser based editor. I also want it to be live. Highlighting after the fact is a well-solved problem but live syntax highlighting is hard and few have ventured into that territory. Codemirror and Ace do a good job and they might be good starting points for what I need.
Saving without a page reload
This one is a new peeve of mine. The action of the save button in Write.app does not do what it should do, I know. When I first Wrote the code that handles the editor I was too afraid to implement AJAX saving or auto-saving for a lot of reasons. Security and added complexity were the main ones. Looking back I think this was a mistake. Now I believe you should be able to hit the save button and have a little message pop up for a few seconds letting you know your work was saved just like Gmail does with a sent email. The next version of the editor will have this. I don't believe auto-saving is the right thing to do right now, however. It's one thing to save your progress without having to wait for a page to reload but it's quite another to have the editor automatically saving your document for you. What if you just deleted a paragraph that you want to go back to? Control + Z should work most of the time but because we're working within the constraints of the browser, I don't think it's the right time for this yet. Auto-saving also means that you assume that any time a new note is started is should be saved permanently. This isn't always the case. Sometimes I begin writing something then close the browser tab without saving because I just didn't want to. I want users to explicitly save their work. A happy medium may be temporarily saving an unfinished note and alerting the user about it on their next login to give them the option to restore it if it was a mistake.
Match my brackets
Writing in Markdown means using a lot of brackets. When I write Markdown in the browser I get all thrown off. I'm used to my various editors matching my brackets for me. In the browser I have to do it myself. I need my browser-based editor to match my brackets. And while we're at it I need it to indent my tabs. Don't move me to the next form element. Just indent, please. And if we're doing all that then we better be highlighting syntax as we go along here.
I want to fullscreen my browser and have just a big blank canvas ready for my text input in front of me. I don't want to see a bunch of toggles or buttons. I want all sorts of options and toggles for naming, options to make a note public, themes, etc. but I want it all hidden at the same time. How can I balance this power with a clean UI? Right now the solution is the bottom bar you see when you're writing a note in Write.app. It sits down there at all times no matter what mode you put the editor in. Some have said it's hard to tell there's anything down there especially on big monitors. My question is what can I do to make it better. Somehow, everything I've mentioned needs to be accessible, obvious, but still out of the way. This is quite a challenge and one I'm going to look into very carefully.
There are some standard text editor functions that should be translated into a web based text editor. Working within the limitations of technology on the server side and client and side and balancing that with making sure users can handle all the cool new toys you throw at them is tough. What I'm asking for here may be a tall order but it isn't impossible. I've already begun to design the new editor and I'm currently working on all the technology that'll make it possible to rival native text editors. I'm thinking it could even become an open source project in case others want to use it in their own applications.
I'll write more when I have more to show. For now I'll leave you with a list of the features Write.app's new editor absolutely must have to make me happy:
- Save on the fly (no page reloading, that's so 90's)
- Distraction-free view (focus on the writing, get the buttons out of the way)
- Live syntax highlighting
- Bracket completion
- Real tab indents
- Export to .txt, .md, .html, or .pdf
- Themes, color schemes, and other display options (font, font size, etc. but not too many)
- Must be a plain text editor (no formatting in the editor like TinyMCE, pure Markdown only but provide perfectly formatted output)
- Save text as UTF-8 always always always