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.<p>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 :)<p>Thanks to the author for putting this together.
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.<p>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?<p>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.<p>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.<p>In the end I migrated to Svelte, and I’m much happier as a result.
`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.
Seems like a helpful list of things to know, I haven't gone through it all but looks good so far.<p>Clicked on the first one and I noticed something.<p>They write this:<p><pre><code> const setFavicon = () => {
const favicon = document.querySelector('link[rel="icon"]');
favicon.href = (window.matchMedia('(prefers-color-scheme: dark)').matches)
? 'dark-mode-favicon.png'
: 'light-mode-favicon.png';
};
setFavicon();
</code></pre>
And then this:<p>> We can use this function to update the user's color scheme preference whenever they make a change.<p><pre><code> window
.matchMedia('(prefers-color-scheme: dark)')
.addEventListener('change', setFavicon);
</code></pre>
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:<p><pre><code> const setFavicon = (event) => {
const favicon = document.querySelector('link[rel="icon"]');
favicon.href = event.matches ? 'dark-mode-favicon.png' : 'light-mode-favicon.png';
</code></pre>
This would be my preferred way of doing it because it supports users who are visiting with JS disabled.<p><pre><code> <link href="light-mode-favicon.png" rel="icon" media="(prefers-color-scheme: light)">
<link href="dark-mode-favicon.png" rel="icon" media="(prefers-color-scheme: dark)">
</code></pre>
<a href="https://phuoc.ng/collection/html-dom/change-the-favicon-dynamically-based-on-user-color-scheme-preference/" rel="nofollow noreferrer">https://phuoc.ng/collection/html-dom/change-the-favicon-dyna...</a>
The technique for "Make a textarea auto-expand" is obsoleted by a new CSS property("form-sizing"):<p><a href="https://chriscoyier.net/2023/09/29/css-solves-auto-expanding-textareas-probably-eventually/" rel="nofollow noreferrer">https://chriscoyier.net/2023/09/29/css-solves-auto-expanding...</a><p>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.<p>A better approach is to use a mirror hidden element:<p><a href="https://css-tricks.com/the-cleanest-trick-for-autogrowing-textareas/" rel="nofollow noreferrer">https://css-tricks.com/the-cleanest-trick-for-autogrowing-te...</a>
A number of these are using older, awkward APIs, when there's nicer native versions now.<p>For example, "replace an element" is<p><pre><code> ele.parentNode.replaceChild(newEle, ele);
</code></pre>
but unless you're targeting Chrome < 54, FF < 49, or Safari < 10, you can just do<p><pre><code> ele.replaceWith(newEle)
</code></pre>
`replaceWith` also lets you replace a node with _multiple_ nodes, or with text.<p>Similarly, "loop over a nodelist" wants you to use array spread and then forEach, instead of just<p><pre><code> for (let ele of nodelist) ...</code></pre>
Nice. Bookmarked. Another good one in a similar vein is <a href="https://youmightnotneedjquery.com/" rel="nofollow noreferrer">https://youmightnotneedjquery.com/</a><p>I don't do web stuff often, but when I do I am <i>completely</i> 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.<p>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.<p>Front-end devs: are you ok?
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.<p><i>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.</i><p>A contrived example of something that's a pain to do with raw DOM:<p><pre><code> 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>`
);
}
</code></pre>
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.<p>1. <a href="https://developer.mozilla.org/en-US/docs/Web/API/Element/insertAdjacentHTML" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/API/Element/ins...</a>
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.<p>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).<p>I kept it as simple as possible:<p><pre><code> - 16 cheap relays for the 24V AC electric valves
- 1 beefy relay for the pump
- 1 Pi Pico W for controlling the relays
</code></pre>
Here's a picture of the "low-tech" build: <a href="https://files.alinpanaitiu.com/lowtech-irigation.jpeg" rel="nofollow noreferrer">https://files.alinpanaitiu.com/lowtech-irigation.jpeg</a><p>The Pico W would have a <i>code.py</i> with all the relay and schedule logic, and an <i>index.html</i> 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.<p><i>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.</i><p>The web page looks like this: <a href="https://shots.panaitiu.com/lHMGplFn" rel="nofollow noreferrer">https://shots.panaitiu.com/lHMGplFn</a><p>That's all there is to it, really. That <i>simple</i> 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.<p>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 <i>repeat schedule</i> feature. Oh boy, so much code to parse and change, so many slider.value calculations to redo... yep, never doing this again
These days, I get by with just two dependencies. One is dqs.js:<p><a href="https://github.com/no-gravity/dqs.js">https://github.com/no-gravity/dqs.js</a><p>Which turns document.querySelector('.some .thing') into dqs('.some .thing').<p>The other one is Handlebars:<p><a href="https://github.com/handlebars-lang/handlebars.js/">https://github.com/handlebars-lang/handlebars.js/</a><p>Which I use for all my frontend templating needs.
Great resource! I've defaulted to just use vanilla js and petite-vue, it's 15 kilobytes and gives a good base.<p>The problem is the build requirements you run into quickly if you want to use plugins these days with vanilla js.<p>Elegance was being able to load actual modules from a CDN. Why did we need these anti-web build steps on top of JS?<p>I feel like there was a sweet spot of complexity around Vue 1 or say 2014.<p>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.<p>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.
If I were making a cookbook on HTML/JS I would probably leave out this:<p><a href="https://phuoc.ng/collection/html-dom/sanitize-html-strings/#eliminating-the-script-tags" rel="nofollow noreferrer">https://phuoc.ng/collection/html-dom/sanitize-html-strings/#...</a>
FYI: Understanding some very basic DOM manipulation is important even if you are working with very modern tools.<p>Case in point: I'm working on a shipping Blazor WASM application, and I've had to drop into the DOM twice:<p>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.<p>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.)
For syntactic DOM manipulation sugar I use Cash[0]<p>[0] <a href="https://kenwheeler.github.io/cash/" rel="nofollow noreferrer">https://kenwheeler.github.io/cash/</a>
I appreciate the benefit of not having dependencies but not a fan of this rabid vanilla fixation.<p>Of course you can do anything with Vanilla that you can do with e.g. jquery. Otherwise jquery obviously couldn't do it.<p>The problem is that the vanilla DOM API sucks. document.getElementById sucks vs $, document.querySelector sucks vs $. setTimeout and setInterval suck. addEventHandler really sucks.
<a href="https://phuoc.ng/collection/html-dom/resize-an-iframe-to-fit-its-content/" rel="nofollow noreferrer">https://phuoc.ng/collection/html-dom/resize-an-iframe-to-fit...</a><p>There should be a way to do this with CSS and maybe some magic headers. It's super annoying that it has be done via JS.
what is the value in manually processing knowledge bases like this (besides perhaps in an artisan fashion) if your knowledge interface such as chatgpt already knows it and surfaces it at will?