I've been using Blot for years (for two websites), and I can't say enough good things about it. Happy to see it featured here!
Blot turns a folder into a website
41–50 of 143 posts
Re: Blot turns a folder into a website
#42S-so does Apache?
Re: Blot turns a folder into a website
#43Earlier quoted context omitted.
Show ?
Just man tree if it's on your system. I used it for temporary jobs, like where I needed to give some students a quick website of a folder of source files. Not much to it. -H baseHREF Turn on HTML output, including HTTP references. Useful for ftp sites. baseHREF gives the base ftp location when using HTML output. That is, the local directory may be `/local/ftp/pub', but it must be referenced as `ftp://hostname.organiz…
Oooooh, sorry, sorry. I was thinking more about the CSS !
But even so I didn't check out `-H`, I thought it was just the help flag and immediately thought the comment was a bit lacking, my bad.
Re: Blot turns a folder into a website
#44Love the simplicity! Looks like this shouldn't need a server, but instead could just be a static site generator. Am I missing something?
How do you want to serve pages without an http[s] server ?
The next innovation I expect to see on HN is a service that, on a set schedule, gathers articles about a set of topics that you follow, prints them out onto paper, and delivers them to you as a bound volume for easy perusal.
This has a number of advantages for privacy (there's no way for the publishers to know how much time you spent reading each story), offline-first availability (dead-tree is the ultimate), and sharing (you can hand someone the entire volume rather than just a link to it, and they get the whole contents, all offline).
It really sounds like it could be the hot new thing, if only some forward-thinking VC would invest in it.
Re: Blot turns a folder into a website
#45We've come full circle
The internet is made of tubes. And tubes are made of circles.
2024 is the year of PHP.
Re: Blot turns a folder into a website
#46Earlier quoted context omitted.
Isn't that literally just a web server?
Only if the web server transparently converts non-HTML sources (Markdown, Word docs, Google docs, LaTeX, image galleries) into HTML on the fly.
Web browsers can render more than just HTML, can't they? Plain text at the very least, many do PDF as well.
That function really seems like it should be in the browser anyway. The server serves, the renderer renders.
Re: Blot turns a folder into a website
#471. Old solution becomes new again
2. Folks clamor that we actually had things right the first time
3. Hype dies down
4. Blog posts complain that the solution "just doesn't scale" and that the complete opposite approach (or some hybrid) is better
5. GOTO 1
Re: Blot turns a folder into a website
#48A similar thing: http://tiiny.host/ I use them and I'm a big fan.
Whoa, “Remove ${HOST}’s banner”. That brings back memories.
Re: Blot turns a folder into a website
#49Earlier quoted context omitted.
Only if the web server transparently converts non-HTML sources (Markdown, Word docs, Google docs, LaTeX, image galleries) into HTML on the fly.
Web browsers can render more than just HTML, can't they? Plain text at the very least, many do PDF as well. That function really seems like it should be in the browser anyway. The server serves, the renderer renders.
if the server side file format has something semantically similar to #include then your lovely simple binary model fails (without browsers having the same)
Re: Blot turns a folder into a website
#50This makes me think of the early/mid-2000s & https://blosxom.sourceforge.net . Blosxom had this delightful concept of file extensions as "flavours." For example, you could have a ".rss" flavour that would present that hierarchy of your site as an RSS feed if you added ".rss" to the URL. Brilliant!
This used to be fairly common. Reddit is another site. A company I worked at.aroind the same time also had .xml, .rss, .atom. .xml would serve up the raw xml our middleware generated, which was normally "rendered" via xsl (what can I say to redeem myself for that?) server side. It was great for both debugging (you could browse the site in "xml mode") and to provide an API.
I still like the url approach - being able to browse until you have the view you need, and then just copy the URL and change format in order to find the right API call can be very nice. The challenge, of course, is that you need to be very cautious about which urls you guarantee will be stable, or you'll be locked into a site structure you might regret.