I wanted to do some messing around with sharing data between HTML files, and the only effective way to do that is by using search parameters which isn't exactly always ideal.
You can't store cookies in file://. (You can, but it doesn't work on any forks of Chromium, the most common/popular kind of browsers, without setting a flag from the terminal.)
You can't even use localStorage either.
Why not? Because it only works on a per-domain basis and Chrome treats each file as its own domain. 😩
Not only is there this downside of not being able to share data across pages, you can't even read local files relative to the folder the HTML file is in, you need a server for that.
I'm so fucking frustrated that a lot of the more useful/complex features of JS require a "server" of some kind. It makes no damn sense.
Top comments (23)
Simplify your day by just running
npx serveat the root of your projectNPX is a commandline tool available from npm@5.2.* , i.e from npm version 5.2.* and above. It allows to execute commands from the npm global registry without having to install them.
NPX will allow you to serve your project but it will need to install the package:
serveif it in not already installed and store it in the cache.How does it serve ðe page?
What does ðat do? Just make it available þeough
localhostor someþing?Yes you are right. Through
localhost. And you can then interact with your web pageWhat does that do and how do I use it?
And what is
npx?I just typically use python http server
python3 -m http.serverIt will server the directory contents on localhost:8000
While this is a simple solution that can work for me.
Not everyone has Python installed nor wants to invest the time.
I guess it's my fault for saying I was doing testing ("I wanted to do some messing around").
But I was thinking for HTML files that could then be redistributed and run on other people's machines.
You could use Cloudflare Workers to host your files for free. As with many other Web APIs, service workers are tied to a domain. When a user visits your page, your worker is installed in the browser and and acts as a kind of proxy. Future requests are then served directly from cache enabling offline access.
Huh. Neat.
Via the internet.
But once you download the files, I don't want it to be a requirement you have internet after that point.
Imagine I'm making a game, if your internet suddenly goes out you can't (keep) play(ing) my game.
But if you downloaded the files before the outage and have them ready to go: you can.
So you should change your title. This has nothing to do with JavaScript.
Because you can obviously run JavaScript with node, deno, bun without any server.
You are talking about Browsers. And i have news for you... Browsers where meant to access the web.
You can use other technologies than Browsers to render HTML, use storage...there is electron, tauri, etc to not use a server with a domain name.
It does. It literally makes reference to
document.cookieand other JS mechanics.Yes, but this is most convenient.
I don't wanna just randomly go into some language, work with some janky markup parser, then have to compile the program for different systems when I could delegate that to the browser.
I would also like HTML and JS functionality so it's more convenient (and makes more sense to me) to do this in the browser.
I already stated why I can't use
localStorage, unless there's something else you're referring to I don't know about.Let me rephrase this. I don't mean to be rude. No harm ahead.
First, Javascript is not tied to web browser technology. Like i said, Javascript can be used outside of browsers :
Now regarding
document.cookie. It's specifially tied to web. It's not a browser technology, It's a web technology tied to HTTP protocol .Cookies are fondamentally tied to remote servers. It's not your browser fault if is preventing you from using it on a file. it makes no sense to have cookies on files (imagine, this would mean having tied cookies for each file you browse on the web). No cookies are tied to a remote domain. It's their definition.
Now regarding localstorage. It's the same reason, localStorage by design are tied to a domain, not a file. Again, tying it to a file would make it useless for the web.
Now regarding doing cool things on browser without a server to share something between pages... i have your back.
Go here, this is called WebRTC. One cool thing with this. You don't need a web server. You can make two HTML files communicate with javascript.
Now have fun.
I didn't think you intended to originally.
Can WebRTC hold data even when the browser is closed?
That's part of the functionality I was after when trying to see if I could use cookies or
localStorage.Unfortunately, no. There is no storage you can use on a browser without attaching it to a domain and then to a server.
The only thing you can do, is having a local html file that interact with a third party service that will store it for you, like aws dynamoDB. But if you really want your page to not need internet access, i'm affraid you can't.
Thanks for your help.
But as a subrant, that's stupid.
There should be like
directoryStorage, which is likelocalStoragefor the CWD of the HTML file.I just þought:
Could I do some Stop'N'Swap shit to store data? Basically open a new tab, sync local-storages, close first tab to simulate data transfer?
Or is ðat no good?
Well the thing is that I just want to use this for some local pages to redistribute, not everyone is going to know (or want to learn) how to set up a local server just to run some stupid files a dipshit child made.
Þanks for ðe suggestion, I'll check it out.
What is the "Why" anyway?
What do you mean, exactly?
I guess this idea would work.
The only reason I opt for local
.htmlfiles is because you don't need an internet connection to access them.