3 ms·
98% of the difficulty in implementing a rich text editor is already present in every browser, its hard to call it wheel reinvention at that point. Drawing a car
by _wmd 9y ago
98% of the difficulty in implementing a rich text editor is already present in every browser, its hard to call it wheel reinvention at that point. Drawing a caret and responding to key presses by mutating the dom is about the only thing left
- simias 9y agoIMO actually displaying text is not the big challenge in a text editor. The tricky part is the user interface, text transformation (sed, query-and-replace, pipe through external programs...), text parsing (for syntax highlighting and code folding for instance) and invoking external applications, for instance to compile code or post-process your document. Web browsers are not particularly good at any of these things since they're not needed to purely "browse" the web. If you want performance while handling big files you also need to optimize the way you stream data from the disk, something browsers are terrible at. Is there any web-technology-based editor that handles big files decently? Last time I've seen a benchmark it was pretty abysmal. Not that Emacs is great at it (it was pretty bad for a long time actually, especially pre-64bit computers) but it still was orders of magnitude faster than Atom for instance: https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
- _wmd 9y agoAccurately rendering text in an WYSIWYG HTML editor has equivalent difficulty to implementing the engine used in the web browser that will eventually be used to render that HTML, otherwise it can never truly be WYSIWYG