Show HN: Wd-40, a static webserver with automatic hot-reloads (github.com)
It works by injecting a websocket script which listens for file changes. The filechanges are detected using the go fsnotify package, which in turn uses the different OS's equivalent to inotify.
I basically got bored with alt-tabbing and refresing when developing 'vanilla-js'. The hot-reload in the modern frameworks are very nice, so figured I'd recreate it.
85 comments
[ 2.5 ms ] story [ 145 ms ] threadThe fact that they make spray lubricants and you have a website re-loader will likely not make any difference to them.
Such as if you have ignition wires soaked with water and shorted, it will get you going again.
And even when used as that most people I'd guess don't shake the can, a long shake, as required.
It does to the US government... trademarks are industry-specific. It is absolutely legal for people to use the exact same trademark for different classes of business.
Of course they could still probably sue you into oblivion anyways, even if they're wrong.
I've tried many simple servers for experimenting with simple static websites (HTML, CSS, JS). I'm currently settled on LiveReload[1] and BrowserSync[2]. LiveReload attaches to other tooling and is more straightforward, while Brower-Sync when looking across a few multiple browsers (out of habit). I'm not particularly fond of tooling that attaches to an IDE, but I like more of the ones that I can pipe with arguments. But then again, I do straightforward stuff these days.
LiveReload should also be easily attachable to a simple `python -m SimpleHTTPServer 8000`.
1. https://github.com/livereload
2. https://browsersync.io
It is, especially it's rust-repellent properties. The only 'plug-and-play' static webserver I found was, well... https://github.com/static-web-server/static-web-server/ which is written in Rust (I didn't look around super hard). But, being a gopher, and since it lacked live reload, I wrote my own.
[0] https://www.reddit.com/r/rust/comments/27jvdt/internet_archa...
> <graydon> > A little. Also big metallic things. And rusts and smuts, fungi. And it's a > <graydon> > nice substring of "robust".
> <graydon> IOW I don't have a really good explanation. it seemed like a good name. (also a substring of "trust", "frustrating", "rustic" and ... "thrust"?)
> <graydon> but then everyone thinks it's a pun on "chrome" so maybe we should stick with that
And given that now all the lore around it is about oxidation, I guess that's what stuck?
These old IRC dumps make me nostalgic instantaneously. There was a time not that long ago when we were still mostly fine with plain text for complex communications.
Like on this very website? :)
> I think I named it after fungi. rusts are amazing creatures.
Sure, there’s room for doubt, but not that much room.
Maybe you think it's not a _good_ lubricant? But a lot of its use is to extract stuck things which requires a thin lubricant
Neither does KY and yet here we are.
While WD40 wasn't designed as a lubricant it does function as one.
People using heavy equipment often grease their machines daily but no one claims grease isn't a lubricant.
I have to put bar oil in my chain saw every time I use it, and often have to refill it during the day. Is that not a lubricant?
But a bike chain is a thing that you want lubricated for a long time, and not have to think about lube every time you want to use it (well.. in a normal, bike-driving way). Is it still lubed? Did it rain the last time you drove a bike? When was the last time you lubed it? Some other lubricant would last much longer and lubricate much better, and with a bike chain, lasting many months is good thing.
That's why we have and use different kind of lubricants for different things, and WD40 is not a "good choice" for most of the stuff some people use it for (like bike chains... or anal).
As I said: a chainsaw is constantly adding lubricant to the bar. Meanwhile the swing I built for my son had white lithium sprayed on it and still doesn't make a sound, after full exposure to 3 monsoonal wet seasons.
I'll see myself out.
The word you are looking for is “penetrating oil”. The problem with a too broad definition of “lubricant” is that I wouldn’t use Coca Cola to lube my engine or KY Jelly to lube my bike chain. WD-40 is a shitty lubricant for metal-on-metal moving parts, so it’s helpful in that context to say that it isn’t a lubricant.
Also, it is written Wd-40 not WD-40..
As long as it stays a dev http server, it should be fine.
1. For the mirroring, are you using something like rsync (with modifications for the web socket script injection) underneath? Also, will the mirroring reflect destructive changes (like rsync's --delete flag), like if a directory or file is deleted in the original content directory?
2. Could you avoid mirroring the content directory, and just directly serve the original content directory, by just simply on-the-fly injecting the relevant script tag in text/html files? (Or, only mirroring those text/html files, and serving the remaining files from the original content directory.)
2. This was my initial idea as well: to simply inject the ws-load script tag on the fly. But it would require basically writing a static file server from scratch, which I didn't feel like doing (I have a blog to write, not static file servers!). Currently the solution is based on the go standard library fileserver handler [2] which makes the solution simple and effective. So i decided on the mirrored approach with the idea that the result for the end user should be the same, apart for the temporary directory where the mirrored files lives. I haven't yet detected any speed-issues in the mirroring process or the file-watch process, which I think is the only downside (please correct me if I'm wrong).
[1]: https://pkg.go.dev/github.com/fsnotify/fsnotify#hdr-Watching...
[2]: https://github.com/baalimago/wd-41/blob/main/cmd/serve/serve...
Stop inventing new static web servers. Contribute patches to an existing project if you feel so inclined but this has been a solved problem for decades by very intelligent people who understand how the Internet works. We've gone full circle from bloated behemoths like Netscape, to serving from kernel mode (http.sys, Tux Web Server, etc.) and back again.
Take pdf viewers for example. I hated all of them until I found Zarthura. I’m glad someone took the time to make that.
It is pretty clever, not sure how much need I have for it, but it's an interesting idea.
You joke, but the only thermo mug that I've been able to find that fits into my car is an off-brand one my mother-in-law picked up from a bargain bin in Lidl. None of my five mugs or bottles fit.
That only shows your ignorance. By that logic, transportation has been a solved problem for millennia. We were moving from A to B for quite some time.
When your wife tells you "Hey, look what I cooked for dinner"? Do you tell her "I have seen this dish 30 years ago, why don't you develop new recipes instead?"
Find something better to do than belittling others side projects that they shared for fun.
It's a single file go executable. Supports CORS too. I use it via direnv & nix-shell.
is this the best the web have to offer in terms of standards to keep one tab with fresh content? i recall some push standard discussions
https://gohugo.io/getting-started/usage/#livereload
Also curious about this: "The delta-streamer.js script then checks if the current window origin is the updated file. If so, it reloads the page."
Does that mean it doesn't auto-refresh if dependencies (scripts, stylesheets, etc) are updated? Maybe there's room for improvement here though I'm not sure how I would approach it. Maybe just an option to skip the check would do the job.
It does refresh on all other file changes. I first thought about trying to figure out what js/css was used on which page but that turned too complicated. So now it refreshes on all js/css files [1].
[1]: https://github.com/baalimago/wd-41/blob/main/internal/wsinje...
https://news.ycombinator.com/item?id=41284189
How many times do you feel the need to repeatedly hype this?