Excellent list and examples. Browsing through a dozen or so of these I'm amazed at the care and detail in the examples. They are not only functional, but provide very solid UI work as well.
As I've shifted away from platforms like React to smaller, minimalist implementations, I often have trouble finding ways for how to do complex patterns in standard JS. It's funny when you look at the code and think... huh, that's actually a lot easier than importing a huge library with way too many props :)
> It's funny when you look at the code and think... huh, that's actually a lot easier than importing a huge library with way too many props
I had this realization after the 3rd or 4th RiotJS major version update. It started getting harder to do it the opinionated way. I realized that every minimalistic JS framework would eventually suffer this fate as totally innocent feature requests gradually accumulate into a monstrous pile of hooks, events and other side-effect bandaids.
I don't even use jQuery anymore. I will use things like ES modules to help organize code, but you don't need to run a goddamn npm command to use any of that technology. All of this is a global browser standard, not something you have to vendor in.
I look at MDN as the Bible these days. If you take a leap of faith, it will carry you almost 100% of the way. The frameworks will cripple you after a certain point. I can't say this would have been true ~5 years ago. Things have shifted rapidly with browser APIs converging on a powerful set of primitives (modules, flexbox, grid, etc) that are now very consistent across platforms.
Nothing in TFA competes with a web client framework, though, since the framework is solving the general questions of how to manage state and then update the UI when state changes.
For example, pretty much all of the TFA examples are code you'd have to write even if you were using React.
So I’m working on this side project. I don’t have a name for it yet but I’ve been describing it as “vim for web designers”. The idea is that you can build a website (or components) in the browser, similar to Webflow, but it’s entirely driven by a command language.
When I began the project, I told myself I wasn’t going to use a framework. After all, I’ve been doing this since 2009, I was working with JS for a long time before I ever touched a framework. And besides, the native DOM APIs have long been good enough. Right?
My god, it was an absolute slog. Marshalling data into and out of the DOM is so tedious and error prone that I began writing my own mini framework to save my own sanity. And then I remembered why I began using frameworks to begin with - because ultimately you’re going to be using a framework of some kind regardless, it’s just whether you want your own custom one or a community-built industry standard.
I do still think native DOM is great, if you’re working with small amounts of interactivity. Most sites that use React probably don’t need it. But if your product has even a little bit of nuance or complexity, I’d go with a framework and avoid the hassle.
In the end I migrated to Svelte, and I’m much happier as a result.
Hyper minimalist projects always end up re-implementing half of jquery or lodash. Much easier to just find a good library that does treeshaking like ramda and use it sparingly.
You are building application - I could estimate from your description alone that you're better off wrapping the DOM interactions.
For websites that need interaction, DOM manipulation is IMO a better move due to it using a more fundamental/universal skill, light or no build process, faster execution, and explicitness.
This is a categorization, with lots of room for grey areas! I bring it up because your use case falls squarely in the category that benefits from a framework.
`value.startsWith('javascript:')` and there you have a vulnerability. There can be arbitrary white-space before the URL, so you'd need to do `value.trim().startsWith('javascript:')` instead. However, I much prefer white listing instead, i.e. only allowing `http:`, `https:` and maybe `mailto:`, `ftp:`, `sftp:` and such. Maybe allow relative URLs starting with `/`. Maybe. Though that would mean to correctly handle all attributes that actually can be URLs. Again, I'd just white list a few tags plus a few of their attributes.
Unless you need to support ancient browsers [1], I'd go the easy way and leave the URL parsing to the browser, e.g. `['http:', 'https:', 'mailto:', 'tel:'].includes(new URL(value, location.origin).protocol)`
Yeah, that article really shouldn't imply that sanitization is "that easy". It does at least mention https://github.com/cure53/DOMPurify at the end but it should LOUDLY argue against attempting to write this particular thing yourself and promote that exclusively in my opinion.
They are running "window.matchMedia('(prefers-color-scheme: dark)')" twice unnecessarily. If you're going to run `setFavicon` as the callback to the event listener, you can get the result from the `event` parameter passed to the callback like this:
Also, doing it in HTML prevents the flash of alternate-themed content. Doing the same with the `theme-color` meta is also a seldom-used but great feature for detail-minded PWA developers.
I don't do web stuff often, but when I do I am completely demoralized by the state of framework-itis there. It's gotten completely out of control. A fresh React project is hundreds of dependencies. The weight of that complexity is astounding to me.
Meanwhile the core cross-platform browser tech shipped by default has never been more capable and the amount of code to do common things ... isn't very much.
I am no fan at all of react or npm, but some frameworks do provide some helpful things that pure DOM APIs do not, so they still have a place I think.
So e.g. application state management and routing are two huge things you'll still need to implement yourself if you just use pure DOM APIs
Depending on the complexity of your app then that might not be such a big deal, but these extras are rapidly worth their weight in gold as soon as you go beyond a basic app. Unless you are using anything that needs NPM in which case you are fucked.
As a front-end dev who actually like the fundamental platform and the capacities it offers, I'm both happy to see so much nice things coming our way (nested CSS, container queries, and a generally nicer JS experience since ES6) and at the same time horrified by the amount of people using components for trivial things like buttons or bold text.
And I do like framework, but so much framework and library's marketing depend on making people believe that CSS and vanilla DOM manipulation is insanely hard (it's not once you know the fundamentals), and that pulling a random package on NPM is not just quick and easy, but also the professional thing to do.
Agreed it’s out of control. But in the past year I’ve transitioned to a platform team so I’m working with devops-ish tooling for the first time. Holy shit…the amount of complexity there gives front-end a run for its money. You’ve got Kubernetes, Helm, Terraform, CircleCI, yadda yadda. The amount of layered terminology in just those technologies alone is absurd.
> Meanwhile the core cross-platform browser tech shipped by default has never been more capable and the amount of code to do common things ... isn't very much.
Have you tried to use this "capable cross-platform tech" to do anything non-trivial? And React isn't the only thing out there.
What really blew my mind was when I found out that many of the DOM functions return live HTMLCollections that are automatically updated. I wonder how often that feature is being actively used in production code (before the framework craze or developing with no framework being somewhat more popular again)
What's old is new again. My first front-end role was building web applications wayyyyy back in 1999. Everything was done with "Vanilla" JS, including fancy stuff like drag and drop in a treeview, click to edit, building what effectively was a single page app, etc. etc. The hardest part was negotiating the differences between Netscape and Internet Explorer.
My new favorite bit of vanilla JavaScript has been around since Chrome 1.0 and IE: Element.insertAdjacentHTML. To say it's useful is an understatement, especially with multi-line Strings using `. I can't believe it's been around so long and I only realized it a year or so ago.
The insertAdjacentHTML(position, text) method of the Element interface parses the specified text as HTML or XML and inserts the resulting nodes into the DOM tree at a specified position.
A contrived example of something that's a pain to do with raw DOM:
let anchors = ['#a', '#b', '#c'];
let el = document.querySelector('ul');
for (let a of anchors) {
el.insertAdjacentHTML(
'beforeend',
`<li><a href="${a}">${a.substr(1)}</a></li>`
);
}
Previously I would have to create the li element, then the a element, add it as a child, set the href attribute, then the text value of the a element, then insert it into the ul element. Or, I'd batch it all up as a big string and insert it using innerHTML. Modifying an existing list was even more painful and verbose.
These are great. It's unfortunate that if there's any minor bugs there's no way to really keep in sync though, for example the security issue mentioned in another comment in these comments. It would be cool if these examples could be wrapped up into some sort of convenient "package" or something like that, such that you could easily know if there are any updates and grab them, as well as just make it easier to grab these functions whenever you need them instead of copy-pasting them...
I am a great fan of vanilla JavaScript so for me it is a great resource. Sadly many js developers nowadays don't really understand what the Dom can do for them. A great resource!
yeaaaaaaah no. Never going this path again for any interactive page.
This summer I built an irrigation system for my father's field, with the idea that the scheduling would be done in relative time (water this zone for 2h) instead of absolute (start watering this zone at 9AM and end at 11AM).
I kept it as simple as possible:
- 16 cheap relays for the 24V AC electric valves
- 1 beefy relay for the pump
- 1 Pi Pico W for controlling the relays
The Pico W would have a code.py with all the relay and schedule logic, and an index.html which would be a simple list of sliders to set how much time each valve should be open. The Pico W would function as a "hotspot" which the phone would connect to, and the "app" would be available at 192.168.4.1.
It can be added to homescreen and it looks just like a native app as far as my father is concerned. It doesn't feel like one though, he can tell.
That's all there is to it, really. That simple single page with a few sliders and buttons took weeks to build and test thoroughly with only vanilla JS. I was obviously constrained by the flash memory, but there are KB-sized helper frameworks nowadays which I wasn't aware of.
It's also really hard to refactor. I initially stored the schedules at minute-resolution, but then had to store it in second-resolution to add a repeat schedule feature. Oh boy, so much code to parse and change, so many slider.value calculations to redo... yep, never doing this again
The magic of react is that it handles the entire View part of MVVC and also provides a nice DSL for writing the View Controller. With a lot of architectural planning you can develop as clean of code without it (cleaner, perhaps), but I agree it's better to just embrace it.
If you want to use the browser as a user interface for an application, use a user interface library. Knowing what you're building is just as important as picking the right tools after you figured that part out: not all web pages (in fact, man web pages) are not, and don't need to be, user interfaces for applications.
Is the code shared anywhere? I'm thinking that it could benefit from some input from others that have done a lot of vanilla JavaScript work. That application should be pretty concise and DRY using <template>.
These days? This is what we were using 10 years ago before React came about! It works fine, but performance can be a problem in large apps as handlebars just naively recreates entire DOM trees rather than diffing.
Great resource! I've defaulted to just use vanilla js and petite-vue, it's 15 kilobytes and gives a good base.
The problem is the build requirements you run into quickly if you want to use plugins these days with vanilla js.
Elegance was being able to load actual modules from a CDN. Why did we need these anti-web build steps on top of JS?
I feel like there was a sweet spot of complexity around Vue 1 or say 2014.
The Vue 2-->3 jump illustrates the welcome but total breakdown of frameworks in my opinion. It constantly gets in your way and moving data on a page with a hierarchy you need some bizarrely complex data flow, so many folders, files, tools, brittle typescript linting, "auto" this and that, constant building and so many rules it's not fun to engineer anymore.
Anyway, i think we are very close to a sweet spot if we just use something like Petite-vue / Alpine on top of JS maybe with a tiny router and get creative with JS around that, or just early versions say Vue if we need anything more complex.
The toolchain complexity problem was already present with Vue 2 (and anyway it was usable as a dependency pulled into a classic web page). It definitely could be better, and it seems to be on the way of being improved.
I feel like a lot of criticism toward Vue 3 is based on feelings and vibes. What exactly are your complaints toward v3?
`value.startsWith('javascript:')` and there you have a vulnerability. There can be arbitrary white-space before the URL, so you'd need to do `value.trim().startsWith('javascript:')` instead. However, I much prefer white listing instead, i.e. only allowing `http:`, `https:` and maybe `mailto:`, `ftp:`, `sftp:` and such. Maybe allow relative URLs starting with `/`. Maybe. Though that would mean to correctly handle all attributes that actually can be URLs. Again, I'd just white list a few tags plus a few of their attributes.
I’m not sure quite why you’re against removing script tags, but honestly that entire article is poor, riddled with disastrously bad advice:
• “Using regular expressions”: it suggests that this approach is acceptable within its limits. It’s not at all. As a simple example, the expression shown is trivially bypassed by "<script>…</script >". This is why, unlike the post claims claims, using regular expressions for cleaning HTML is not a common approach.
• (“Eliminating the script tags”: I want to grumble about using `[...scriptElements].forEach((s) => s.remove())` instead of `for (const s of scriptElements) { s.remove(); }` or even `Array.prototype.forEach.call(scriptElements, (s) => s.remove())`. Creating an array from that HTMLCollection is just unnecessary and a bad habit.)
• “Removing event handlers”: `value.startsWith('javascript:') || value.startsWith('data:text/html')` is inadequate. Tricks like capitalising and adding whitespace (which the browser will subsequently normalise) in order to bypass such poor checks have been common for decades.
• “Retrieving the sanitized HTML”: you are now vulnerable to mXSS attacks, which undo all your effort.
• “Elements and attributes to remove from the DOM tree”: this proposes a blacklist approach and mentions a few examples of things that should be removed. Each example misses adjacent but equally-important things that should be removed. You will not get acceptable filtering if you start from this approach.
• “Simplifying HTML sanitization with external libraries”: this is pitched merely as easier, faster and cheaper, rather than as the only way to have any confidence in the result.
• “Conclusion”: as I hope I’ve shown, “The DOMParser API is one tool you can use to get the job done right.” is not an acceptable position.
Really, the article could be significantly improved by presenting it as what a common developer might think, and then scribbling all over the problematic things with these explanations of why they’re so bad, and ending with the conclusion “so: just use the DOMPurify library; consider nothing else acceptable”. (There have at times been a couple of other libraries of acceptable quality, but as far as I’m concerned, DOMPurify has long been the one that everyone should use. I note also that this article is talking about client-side filtration. I’m not familiar with the state of the art in server-side HTML sanitisation, where you probably don’t have an actual DOM; this is also a reasonable place to wish to do filtering, but the remaining active mXSS vectors might pose a challenge. I’d want to research carefully before doing anything.)
I look forward to the Sanitizer API <https://wicg.github.io/sanitizer-api/> being completed and deployed, so that DOMPurify can become just a fallback library for older browsers.
FYI: Understanding some very basic DOM manipulation is important even if you are working with very modern tools.
Case in point: I'm working on a shipping Blazor WASM application, and I've had to drop into the DOM twice:
1: We're still using Leaflet.js for a map component. This occasionally requires some DOM calls to adapt between Blazor's worldview and Leaflet's worldview.
2: Blazor WASM loads slowly, so we put up a splash animation in HTML. Removing the splash animation at the "right" time requires DOM manipulation. (Because we want to keep the splash animation up while the Blazor side makes additional calls, so we use DOM manipulation to hide the Blazor-based UI until we've loaded everything.)
[+] [-] snide|2 years ago|reply
As I've shifted away from platforms like React to smaller, minimalist implementations, I often have trouble finding ways for how to do complex patterns in standard JS. It's funny when you look at the code and think... huh, that's actually a lot easier than importing a huge library with way too many props :)
Thanks to the author for putting this together.
[+] [-] bob1029|2 years ago|reply
I had this realization after the 3rd or 4th RiotJS major version update. It started getting harder to do it the opinionated way. I realized that every minimalistic JS framework would eventually suffer this fate as totally innocent feature requests gradually accumulate into a monstrous pile of hooks, events and other side-effect bandaids.
I don't even use jQuery anymore. I will use things like ES modules to help organize code, but you don't need to run a goddamn npm command to use any of that technology. All of this is a global browser standard, not something you have to vendor in.
I look at MDN as the Bible these days. If you take a leap of faith, it will carry you almost 100% of the way. The frameworks will cripple you after a certain point. I can't say this would have been true ~5 years ago. Things have shifted rapidly with browser APIs converging on a powerful set of primitives (modules, flexbox, grid, etc) that are now very consistent across platforms.
[+] [-] hombre_fatal|2 years ago|reply
For example, pretty much all of the TFA examples are code you'd have to write even if you were using React.
[+] [-] danielvaughn|2 years ago|reply
When I began the project, I told myself I wasn’t going to use a framework. After all, I’ve been doing this since 2009, I was working with JS for a long time before I ever touched a framework. And besides, the native DOM APIs have long been good enough. Right?
My god, it was an absolute slog. Marshalling data into and out of the DOM is so tedious and error prone that I began writing my own mini framework to save my own sanity. And then I remembered why I began using frameworks to begin with - because ultimately you’re going to be using a framework of some kind regardless, it’s just whether you want your own custom one or a community-built industry standard.
I do still think native DOM is great, if you’re working with small amounts of interactivity. Most sites that use React probably don’t need it. But if your product has even a little bit of nuance or complexity, I’d go with a framework and avoid the hassle.
In the end I migrated to Svelte, and I’m much happier as a result.
[+] [-] dmix|2 years ago|reply
[+] [-] bryancoxwell|2 years ago|reply
[+] [-] the__alchemist|2 years ago|reply
For websites that need interaction, DOM manipulation is IMO a better move due to it using a more fundamental/universal skill, light or no build process, faster execution, and explicitness.
This is a categorization, with lots of room for grey areas! I bring it up because your use case falls squarely in the category that benefits from a framework.
[+] [-] synergy20|2 years ago|reply
[+] [-] panzi|2 years ago|reply
[+] [-] jfhr|2 years ago|reply
[1] https://caniuse.com/url
[+] [-] simonw|2 years ago|reply
Yeah, that article really shouldn't imply that sanitization is "that easy". It does at least mention https://github.com/cure53/DOMPurify at the end but it should LOUDLY argue against attempting to write this particular thing yourself and promote that exclusively in my opinion.
Filed an issue about this here: https://github.com/phuocng/html-dom/issues/281
[+] [-] flanbiscuit|2 years ago|reply
Clicked on the first one and I noticed something.
They write this:
And then this:> We can use this function to update the user's color scheme preference whenever they make a change.
They are running "window.matchMedia('(prefers-color-scheme: dark)')" twice unnecessarily. If you're going to run `setFavicon` as the callback to the event listener, you can get the result from the `event` parameter passed to the callback like this: This would be my preferred way of doing it because it supports users who are visiting with JS disabled. https://phuoc.ng/collection/html-dom/change-the-favicon-dyna...[+] [-] explaininjs|2 years ago|reply
[+] [-] throwaway858|2 years ago|reply
https://chriscoyier.net/2023/09/29/css-solves-auto-expanding...
Even without using this new CSS property, the technique that is used (adjusting the "height" of the element) is not ideal and can be glitchy.
A better approach is to use a mirror hidden element:
https://css-tricks.com/the-cleanest-trick-for-autogrowing-te...
[+] [-] bakkoting|2 years ago|reply
For example, "replace an element" is
but unless you're targeting Chrome < 54, FF < 49, or Safari < 10, you can just do `replaceWith` also lets you replace a node with _multiple_ nodes, or with text.Similarly, "loop over a nodelist" wants you to use array spread and then forEach, instead of just
[+] [-] akira2501|2 years ago|reply
[+] [-] cmrdporcupine|2 years ago|reply
I don't do web stuff often, but when I do I am completely demoralized by the state of framework-itis there. It's gotten completely out of control. A fresh React project is hundreds of dependencies. The weight of that complexity is astounding to me.
Meanwhile the core cross-platform browser tech shipped by default has never been more capable and the amount of code to do common things ... isn't very much.
Front-end devs: are you ok?
[+] [-] mattlondon|2 years ago|reply
So e.g. application state management and routing are two huge things you'll still need to implement yourself if you just use pure DOM APIs
Depending on the complexity of your app then that might not be such a big deal, but these extras are rapidly worth their weight in gold as soon as you go beyond a basic app. Unless you are using anything that needs NPM in which case you are fucked.
[+] [-] mablopoule|2 years ago|reply
As a front-end dev who actually like the fundamental platform and the capacities it offers, I'm both happy to see so much nice things coming our way (nested CSS, container queries, and a generally nicer JS experience since ES6) and at the same time horrified by the amount of people using components for trivial things like buttons or bold text.
And I do like framework, but so much framework and library's marketing depend on making people believe that CSS and vanilla DOM manipulation is insanely hard (it's not once you know the fundamentals), and that pulling a random package on NPM is not just quick and easy, but also the professional thing to do.
[+] [-] danielvaughn|2 years ago|reply
[+] [-] troupo|2 years ago|reply
Have you tried to use this "capable cross-platform tech" to do anything non-trivial? And React isn't the only thing out there.
[+] [-] blablabla123|2 years ago|reply
[+] [-] fatnoah|2 years ago|reply
[+] [-] aatd86|2 years ago|reply
Why does it seem that we don't know how to do these things anymore? ;]
[+] [-] russellbeattie|2 years ago|reply
The insertAdjacentHTML(position, text) method of the Element interface parses the specified text as HTML or XML and inserts the resulting nodes into the DOM tree at a specified position.
A contrived example of something that's a pain to do with raw DOM:
Previously I would have to create the li element, then the a element, add it as a child, set the href attribute, then the text value of the a element, then insert it into the ul element. Or, I'd batch it all up as a big string and insert it using innerHTML. Modifying an existing list was even more painful and verbose.1. https://developer.mozilla.org/en-US/docs/Web/API/Element/ins...
[+] [-] tolmasky|2 years ago|reply
[+] [-] beardyw|2 years ago|reply
[+] [-] alin23|2 years ago|reply
This summer I built an irrigation system for my father's field, with the idea that the scheduling would be done in relative time (water this zone for 2h) instead of absolute (start watering this zone at 9AM and end at 11AM).
I kept it as simple as possible:
Here's a picture of the "low-tech" build: https://files.alinpanaitiu.com/lowtech-irigation.jpegThe Pico W would have a code.py with all the relay and schedule logic, and an index.html which would be a simple list of sliders to set how much time each valve should be open. The Pico W would function as a "hotspot" which the phone would connect to, and the "app" would be available at 192.168.4.1.
It can be added to homescreen and it looks just like a native app as far as my father is concerned. It doesn't feel like one though, he can tell.
The web page looks like this: https://shots.panaitiu.com/lHMGplFn
That's all there is to it, really. That simple single page with a few sliders and buttons took weeks to build and test thoroughly with only vanilla JS. I was obviously constrained by the flash memory, but there are KB-sized helper frameworks nowadays which I wasn't aware of.
It's also really hard to refactor. I initially stored the schedules at minute-resolution, but then had to store it in second-resolution to add a repeat schedule feature. Oh boy, so much code to parse and change, so many slider.value calculations to redo... yep, never doing this again
[+] [-] explaininjs|2 years ago|reply
[+] [-] TheRealPomax|2 years ago|reply
[+] [-] topspin|2 years ago|reply
[+] [-] mg|2 years ago|reply
https://github.com/no-gravity/dqs.js
Which turns document.querySelector('.some .thing') into dqs('.some .thing').
The other one is Handlebars:
https://github.com/handlebars-lang/handlebars.js/
Which I use for all my frontend templating needs.
[+] [-] bambax|2 years ago|reply
[+] [-] nicoburns|2 years ago|reply
[+] [-] dylan604|2 years ago|reply
how much is truly saved by this? these seem like the things of a solo dev vs building something for other people to follow
[+] [-] evbogue|2 years ago|reply
[+] [-] r-spaghetti|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] kossTKR|2 years ago|reply
The problem is the build requirements you run into quickly if you want to use plugins these days with vanilla js.
Elegance was being able to load actual modules from a CDN. Why did we need these anti-web build steps on top of JS?
I feel like there was a sweet spot of complexity around Vue 1 or say 2014.
The Vue 2-->3 jump illustrates the welcome but total breakdown of frameworks in my opinion. It constantly gets in your way and moving data on a page with a hierarchy you need some bizarrely complex data flow, so many folders, files, tools, brittle typescript linting, "auto" this and that, constant building and so many rules it's not fun to engineer anymore.
Anyway, i think we are very close to a sweet spot if we just use something like Petite-vue / Alpine on top of JS maybe with a tiny router and get creative with JS around that, or just early versions say Vue if we need anything more complex.
[+] [-] athanagor2|2 years ago|reply
I feel like a lot of criticism toward Vue 3 is based on feelings and vibes. What exactly are your complaints toward v3?
[+] [-] bobmaxup|2 years ago|reply
https://phuoc.ng/collection/html-dom/sanitize-html-strings/#...
[+] [-] panzi|2 years ago|reply
[+] [-] zeroCalories|2 years ago|reply
[+] [-] chrismorgan|2 years ago|reply
• “Using regular expressions”: it suggests that this approach is acceptable within its limits. It’s not at all. As a simple example, the expression shown is trivially bypassed by "<script>…</script >". This is why, unlike the post claims claims, using regular expressions for cleaning HTML is not a common approach.
• (“Eliminating the script tags”: I want to grumble about using `[...scriptElements].forEach((s) => s.remove())` instead of `for (const s of scriptElements) { s.remove(); }` or even `Array.prototype.forEach.call(scriptElements, (s) => s.remove())`. Creating an array from that HTMLCollection is just unnecessary and a bad habit.)
• “Removing event handlers”: `value.startsWith('javascript:') || value.startsWith('data:text/html')` is inadequate. Tricks like capitalising and adding whitespace (which the browser will subsequently normalise) in order to bypass such poor checks have been common for decades.
• “Retrieving the sanitized HTML”: you are now vulnerable to mXSS attacks, which undo all your effort.
• “Elements and attributes to remove from the DOM tree”: this proposes a blacklist approach and mentions a few examples of things that should be removed. Each example misses adjacent but equally-important things that should be removed. You will not get acceptable filtering if you start from this approach.
• “Simplifying HTML sanitization with external libraries”: this is pitched merely as easier, faster and cheaper, rather than as the only way to have any confidence in the result.
• “Conclusion”: as I hope I’ve shown, “The DOMParser API is one tool you can use to get the job done right.” is not an acceptable position.
Really, the article could be significantly improved by presenting it as what a common developer might think, and then scribbling all over the problematic things with these explanations of why they’re so bad, and ending with the conclusion “so: just use the DOMPurify library; consider nothing else acceptable”. (There have at times been a couple of other libraries of acceptable quality, but as far as I’m concerned, DOMPurify has long been the one that everyone should use. I note also that this article is talking about client-side filtration. I’m not familiar with the state of the art in server-side HTML sanitisation, where you probably don’t have an actual DOM; this is also a reasonable place to wish to do filtering, but the remaining active mXSS vectors might pose a challenge. I’d want to research carefully before doing anything.)
I look forward to the Sanitizer API <https://wicg.github.io/sanitizer-api/> being completed and deployed, so that DOMPurify can become just a fallback library for older browsers.
[+] [-] gwbas1c|2 years ago|reply
Case in point: I'm working on a shipping Blazor WASM application, and I've had to drop into the DOM twice:
1: We're still using Leaflet.js for a map component. This occasionally requires some DOM calls to adapt between Blazor's worldview and Leaflet's worldview.
2: Blazor WASM loads slowly, so we put up a splash animation in HTML. Removing the splash animation at the "right" time requires DOM manipulation. (Because we want to keep the splash animation up while the Blazor side makes additional calls, so we use DOM manipulation to hide the Blazor-based UI until we've loaded everything.)
[+] [-] DerekBickerton|2 years ago|reply
[0] https://kenwheeler.github.io/cash/