Oh no, you're part of the problem :(

"Nobody knows how to do anything and shit is inefficient and slow and why does all of this software suck" - customers of things built using frameworks but no understanding of the system being abstracted

Ok so where is the sensible subset of the runtime we're supposed to use? Why have browsers not excised the rest?

Backwards compatibility, which is kinda important on the web. It should be possible to build a website and have it just work a decade later.

I guess openly admitting that you refuse to learn how your platform actually works is an "earnest approach", of a sort, but so is admitting that you routinely leave grocery carts in the parking lot and don't see a problem with it.

Huh? The built-in APIs aren't perfect, but we're talking about something simple as

``` fetch('/my-content').then(async res => { if(res.ok) { document.getElementById('my-element').innerHtml = await res.text(); } }) ```

Something like that. Doesn't get much easier. Gone are the days of browser inconsistencies, at least of you stick to "Baseline Widely available" APIs which is now prominently displayed on MDN.

No-framework web tinkerer here. If I had a nickel for every second of my life I've spent typing document.getElementById, I'd be able to afford new fingers. Should've been renamed to getId() and put in global scope two decades ago, if not three. At least querySelector() is a few characters shorter, but I always feel bad using such an alarmingly overdesigned tool for anything trivial.

If I'm just adding sprinkles of interactivity to a statically-rendered page for something that vanilla is good enough for (i.e. minimal-to-no display logic), I use the expando giving an element an `id` adds to `window`:

    <textarea id="userNotes"></textarea>
    <button type="button" id="copyButton">Copy</button>
    <script>
    copyButton.addEventListener('click', () => {
      navigator.clipboard.writeText(userNotes.value)
      copyButton.innerText = 'Copied'
      setTimeout(() => copyButton.innerText = 'Copy', 1000)
    })
    </script>

You don’t have to call getElementById or querySelector on document. You can narrow the search by starting at a specific node, just most people default into document as it’s already a global.

> You don’t have to call getElementById or querySelector on document.

You do have to call `getElementById` on a document. There can be many documents in a window.

Ah yes correct on getElementById, especially as every id must be unique.

> especially as every id must be unique.

Although a very consistent convention, there are no guardrails put in place to prevent something from setting the same id on two or more elements.

getElementById will return the first element that it finds with the id, but you can't know for sure if it is the only one without additional checks

That's a code smell. If you're creating the element you ought to already know about it. If you're not creating the element you should inventory them all at once as the page (or component) loads.

Why are you writing it so many times? Write an alias in 10 seconds?

function getId(v) {return document.getElementById(v)}

Dev tools allows $ $$, dunno, make a macro?

But if Brendan Eich wanted us to have a shorter name, he would have given us a shorter name!

We must not defy the system!

As I said to Lex Fridman, I was influenced by AWK. Ragrets!

JavaScript has functions:

    const g = (x) => document.getElementById(x);