Author's Note: It's my very first article on Dev.to, so apologies in advance if I seem a bit outside the norm.
As a relative beginner in javascript, I don't always know what's what. But what I do know is that my first real learning JS project was a text editor that made extensive use of execCommand(). But inevitably, everything that isn't 100% great dies out. And with that understanding, it wasn't a complete shock that execCommand()'s API was being deprecated, and everyone was being told to move to the Selection and Range API's.
Fully 90% (and probably more) of the web's WYSIWYG and text editors use execCommand(). I wasn't able to find a single WYSIWYG project on GitHub that didn't make use of the execCommand() API at some point in the code, except for those using Markdown (and even then, some part of the API was included in all but one of the cases). This isn't to say there isn't some great project I'm missing; it's merely pointing out the vast majority of the text-editing web runs on execCommand()'s API, sometimes without even realizing it.
One of the things I've noticed from those few who don't run with execCommand() in their code is that there's a decided lack of "undo" at work. Meaning, that there isn't a "detect if it's already there and undo the application of that particular command" feature. There's no command history. There's no equal functionality. And it's not that I think someone should come up with it in anything under two years. Rather, I think it would be an amazing gesture to come up with a replacement set of API's which didn't have so many random parts on it.
According to MDN's entry about document.execCommand() there are lots of other APIs to replace it. But from the code perspective, it makes things more complicated, because we actually have to think about the code, and implement the things in our own unique ways. But there's no good answer out there as to a "best practices" kind of thing, so what we're looking at seems (from this end of time, at least) to be a time of uncertainty, where WYSIWYG editors are going to need vast amounts of overhaul and larger JS codebases to address what should have been simpler.
And that's the point of this article: simplicity.
If we're going to overcome something, we need it simpler than it is. We need to ensure that there's something akin to a "best practices" for WYSIWYG editors, so that they aren't unwieldy, insecure messes. The last thing we need is another amoeba, trying to be all things to all coders.
But, being a beginner, I'm just one voice, and not a very loud one. My aim is to get us newbies to drive for simplicity (which is easier to secure, in most cases), to get us moving forward, and to actually, I don't know, listen to people who have ideas that work, instead of trying to say why they won't before they're even tested.
Because, ultimately, it's the results that demonstrate why something works or not. And it needs to be simple enough to not cause older machines to bend under the weight of new code.
Just ask execCommand().
Top comments (0)