I am trying to implement a rich text editor based on the HTML5 canvas element. It needs to support basic text formatting features as well as keyboard shortcuts (Ctrl + C, Ctrl + V, etc.).
I am unsure wether I should build the code around jQuery, so I can use its keypress() method. I would prefer to avoid the use of jQuery for better performance, but I learnt that there are several issues when using the browser’s native onkeypress() event (inconsistency across browsers) that are nicely solved in jQuery.
Is it really that complicated to get key capturing working on all browsers with only plain JavaScript? Will I need a lot of workarounds, cross browser testing etc.?
Does anybody have some experience in this area? Would you advise me to stick to jQuery?
Important: The editor will only work on browsers capable of HTML5 canvas. So I dont need to consider IE8 or older, etc.
I’ve only worked a little with onkeypress and event capturing. As I understand it, it’s mostly a matter of detecting if the browser uses event.keyCode or event.which. I have read that some browsers use different codes for some keys, but I am not aware of any comprehensive list of discrepancies.
Why do you think jQuery would give you such a significant decrease in performance that it would justify doing everything in vanilla js?
Capturing keys is a headache. I haven’t used it in jQuery, but in general jQuery makes the headaches in vanilla js go away. Such as cross browser support.
Different key codes? That sounds awful… Does anyone know about a good guide/tutorial on how to build a key capture with all browser quirks?
The editor code will be very performance-critical since every interaction will be rendered on the canvas on “frame-by-frame” basis (writing, selecting text, etc.).There is already an editor like this (carota) and it seems to be having performance issues in some cases (with longer documents, on certain browsers).
This is why I want to avoid any overhead by external libraries such as jQuery.It has a lot of code and features I don’t need.
Unless your target demographic is in a country with exceptionally slow internet and/or exceptionally slow computers and/or ancient browsers, I think you can load a 90k library without seeing any performance degradation.
Granted, using jQuery for just one feature is a bit like using a flamethrower to kill a fly, but if it will make headaches like this obsolete, I (personally) feel it’s a no-brainer.
Yeah, I can definitely see where overusing jQuery could be a problem with something like that. However, using it could help you free up development time in other areas where performance isn’t quite as big of an issue and give you more time to tweak and optimize the pieces where performance is critical. There are plenty of other things similar to the link you sent that perform perfectly fine, which means it’s probably just the developer.
Just because it’s there, doesn’t mean you have to use it. It’s just an add-on to Javascript after all. If you don’t use it, all you’re adding to the page is 1 more tiny 100kb GET request (that you can put off on Google’s CDN).
You could download a nicely formatted version of jQuery and look at the code it uses to do that.
jQuery is written in vanilla JavaScript so you should have no trouble reading the formatted code. It may even be possible to just pull out the part of jQuery you need (although referencing a shared copy of the jQuery library that your visitors already have downloaded will usually be more efficient).