4 ms·

HTML/Javascript would like a word

flossly 1mo ago
we need a way to access locally running web apps without doing an ugly http://localhost:8022 and having to remember that. I'd say http://localapps should give an overview of all web apps running locally, with links to them. Those links should follow a naming scheme where the hostname ends with `.local` or smth. So: http://claudecode.local http://claudecode.local
- antonvs 1mo ago
  > I'd say http://localapps should give an overview of all web apps running locally, with links to them. Malware will thank you.
- fc417fc802 1mo ago
  Won't that be cluttered by various random processes listening via 0/0? Perhaps we need a standardized service that web apps can register with.
- mr_olive 1mo ago
  Hah, I was dealing with this problem today. My approach: Add entries for my localhost apps to `/etc/hosts`, and set up nginx as a reverse proxy. Now when I go to `http://myapp.local http://myapp.local` in the browser, `/etc/hosts` tells it to go to `localhost:80`. The http server sitting there knows which port to send the request to. I also made a systemd service that starts nginx automatically. Now I have meaningful URLs for local apps, and I don't have to remember which one is listening on which port.
- singpolyma3 1mo ago
  Bring back installable PWA on desktop
- iskra 1mo ago
  Rather than typing http://localhost:8022, name each app and put them behind one local proxy: 1. In /etc/hosts (or dnsmasq): 127.0.0.1 ourapp.test 2. Caddy in front: ourapp.test { reverse_proxy localhost:8022 } Caddy auto-provisions local certs, so you get https://ourapp.test https://ourapp.test, no ugly ports and no "not secure" prompt. For the overview idea: a tiny local dashboard that scans common dev ports (3000, 5173, 8080...) and lists each running app by name is a ~100-line utility. This is exactly the kind of small tool I build, happy to make a quick version for you.
  - flossly 1mo ago
    Cool! I'd say we need a big linux distro to buy into it, so that it provides it's config-panel and package manager UI in this format.
NBJack 1mo ago
Definitely not weightless. So much bloat has been dedicated to various frameworks for it, and modern browsers are notorious for how much RAM they require. I'm particularly reminded of this each time I try to visit websites on one of my older Raspberry Pis. You are just pushing much of that complexity and overhead to the client. That same Pi won't even blink at a local TUI.
Brian_K_White 1mo ago
[flagged]

we need a way to access locally running web apps without doing an ugly http://localhost:8022 and having to remember that. I'd say http://localapps should give an overview of all web apps running locally, with links to them. Those links should follow a naming scheme where the hostname ends with `.local` or smth. So: http://claudecode.local http://claudecode.local

antonvs 1mo ago
> I'd say http://localapps should give an overview of all web apps running locally, with links to them. Malware will thank you.
fc417fc802 1mo ago
Won't that be cluttered by various random processes listening via 0/0? Perhaps we need a standardized service that web apps can register with.
mr_olive 1mo ago
Hah, I was dealing with this problem today. My approach: Add entries for my localhost apps to `/etc/hosts`, and set up nginx as a reverse proxy. Now when I go to `http://myapp.local http://myapp.local` in the browser, `/etc/hosts` tells it to go to `localhost:80`. The http server sitting there knows which port to send the request to. I also made a systemd service that starts nginx automatically. Now I have meaningful URLs for local apps, and I don't have to remember which one is listening on which port.
singpolyma3 1mo ago
Bring back installable PWA on desktop
iskra 1mo ago
Rather than typing http://localhost:8022, name each app and put them behind one local proxy: 1. In /etc/hosts (or dnsmasq): 127.0.0.1 ourapp.test 2. Caddy in front: ourapp.test { reverse_proxy localhost:8022 } Caddy auto-provisions local certs, so you get https://ourapp.test https://ourapp.test, no ugly ports and no "not secure" prompt. For the overview idea: a tiny local dashboard that scans common dev ports (3000, 5173, 8080...) and lists each running app by name is a ~100-line utility. This is exactly the kind of small tool I build, happy to make a quick version for you.
- flossly 1mo ago
  Cool! I'd say we need a big linux distro to buy into it, so that it provides it's config-panel and package manager UI in this format.

NBJack 1mo ago

Definitely not weightless. So much bloat has been dedicated to various frameworks for it, and modern browsers are notorious for how much RAM they require. I'm particularly reminded of this each time I try to visit websites on one of my older Raspberry Pis. You are just pushing much of that complexity and overhead to the client. That same Pi won't even blink at a local TUI.

Brian_K_White 1mo ago

[flagged]