Hacker News Reader

Comment by modeless | Hacker News Reader

HTML becomes pretty delightful for prototyping when you embrace this. You can open up an empy file and start typing tags with zero boilerplate. Drop in a script tag and forget about getElementById(); every id attribute already defines a JavaScript variable name directly, so go to town. Today the specs guarantee consistent behavior so this doesn't introduce compatiblity issues like it did in the bad old days of IE6. You can make surprisingly powerful stuff in a single file application with no fluff.

I just wish browsers weren't so anal about making you load things from http://localhost instead of file:// directly. Someone ought to look into fixing the security issues of file:// URLs so browsers can relax about that.

View on HN

Welcome, kids, to how all web development was done 25-30 years ago. You typed up html, threw in some scripts (once JavaScript became a thing) and off you went. No CMS, no frameworks. I know a guy who wrote a fully functional client-side banking back office app in IE4 JS by posting into different frames and observing the DOM returned by the server. In 1999. Worked a treat on network speeds and workstation capabilities you literally can’t imagine today.

Things do not have to be complicated. That abstraction layer you are adding sure is elegant, but is it also necessary? Does it add more value than it consumes not just at the time of coding but throughout the entire lifecycle of the system? People have piled abstraction on top of hardware from day one, but one has to ask, if and when did we get past the point of diminishing returns? Kubernetes was supposed to be the thing that makes managing vms simple. Now there are things supposedly making managing Kubernetes simple. Maybe, just maybe, this computer-stuff is inherently complicated and we’re just adding to it by hoping all of it can eventually be made “simple”? Just look at the messages around vibe coding…

yeh, the good old (tm) days :-))

Today you first need AI to figure ot what is the JS-framework-of-the-week and then you need AI to generate all the boiler plate code and then you use AI to debug all the stuff you created :-)

Love the single file html tool paradigm! See https://simonwillison.net/2025/Dec/10/html-tools/

Opus and I have made a couple of really cool internal tools for work. It's really great.

A workaround for the file:// security deny is to use a JavaScript file for data (initialized array) rather than something more natural like JSON.

Apparently JavaScript got grandfathered in as ok for direct access!

once i had to import some xml and just put it in a hidden div since html allows any tag names XD

Wow, I had never heard of that ID -> variable feature

Yeah it was hard to believe when I first learned about it, but it's true. I think I first found out when I forgot to put in a getElementById call and my code still worked.

Also window.document.forms gets you direct access to all forms, "name" automatically attach an attribute to the parents and "this" rebind to the current element on inline event handler.

The DOM API may have been very messy at creation, but it is also very handy and powerful, especially for binding to a live programming visual environment with instant remote update capabilities.

Speaking of forms: form.elements.username is my preferred way of accessing form fields. You can also use a field .form prop to access its connected form. This is fundamental when the field exists outside <form> ;)

You mean there is bidirectional binding between form.elements.username and the UI value? Why did we need React! HTML should have IFs and FOR loops…

It's been there since the beginning but it has several exceptions, like it's not available in strict mode and modules. Ask your ChatGPT if implied globals are right for you.

More specifically it becomes a property of window, which is the global object.

So <div id="hello"> becomes accessible as window["hello"], which means you can just directly write hello.innerText = "Hi!".

Since this may conflicts with any of the hundreds of other properties on window, it's generally not something that should be used.

Historically it wasn't too uncommon to see it, but since it doesn't work well with typescript, it's very rare now.

You can make it work with typescript by declaring it as an HTMLElement without defining it.

I liked learning this so much that I created a VSCode Extension to enable goto clicking and autocomplete and errors for single page html files and type hover so I can properly use it when i am prototyping.

https://marketplace.visualstudio.com/items?itemName=carsho.h...

> Someone ought to look into fixing the security issues of file:// URLs

If you mean full sandboxing of applications with a usable capability system, then yeah, someone ought to do that. But I wouldn't hold my breath, there's a reason why nobody did yet.

Yes i love quickly creating tools in a single file, if the tool gets really complex I'll switch to a sveltekit Static site. I have a default css file I use for all of them to make it even quicker and not look so much like AI slop.

I think every dev should have a tools.TheirDomain.zzz where they put different tools they create. You can make so many static tools and I feel like everyone creates these from time to time when they are prototyping things. There's so many free options for static hosting and you can write bash deploy scripts so quickly with AI, so its literally just ./deploy.sh to deploy. (I also recommend writing some reusable logic for saving to local storage/indexedDB so its even nicer.)

Mine for example is https://tools.carsho.dev (100% offline/static tools, no monetization)

What are the security issues of file:// URLs?

  fetch("file:///C:/Users/You/Documents/secrets.txt")

"Chrome wants to access 'secrets.txt'. Allow | Deny"

  $ python -m http.server

Imagine a very plausible situation. You have 1 HTML file at the top that wants to access hundreds of files in a subfolder. There is no way you can show Allow | Deny for every one of them. On the other hand, it's also possible for someone to take that file and put it in a folder like Documents or Downloads, so blanket allowing it access to siblings would allow access to all those files.

This could easily be solved by some simple contract like "webgame.html can only access files in a webpage/ subdirectory," but the powers that be deemed such thing not worth the trouble.

As long as same-origin is enforced this is probably OK? I'm going to steal my own secrets?

Congratulations, you won $1000000! In order to continue, please download and open this HTML file.

Reply on news.ycombinator.com