I don’t blame this guy at all, really.
i just want to put text and images on a page without having to assemble and operate a whole Toolchain. when did we give up on the idea that computers should make things easier? when did everyone decide that “1987 greentext unix machine” was the pinnacle of computing? i don’t know, but i refuse to accept it.
I don’t quite understand what he’s looking for.
He wants the ease of use of a service (like say https://bearblog.dev/ or https://micro.blog/ ) but wants it to be free, self-hosted with a single click install and fully maintenance free?
frankly, i was surprised to see this—i don’t know if you’ll find folks on this same wavelength here. what’s stopping you from creating your own website without the use of AI?
the cafe is all about expressing yourself with personal websites and using coding/webweaving as a means to express yourself, give you a space online to be yourself, and own a stake of real estate on the web. if you’re just spitting out websites via chatGPT, what are you expressing? how is an amalgamation of themes from around the web and average of website styles allowing you to learn how to manipulate code and website-building to make something truly yours?
we have a lot of resources for you to be able to learn how to code and create your own website. it’s really not that hard if you make it fun! so many folks here were brand new to coding when they join us. would you like to learn how to do it?
I didn’t get that impression — it doesn’t seem like he needs it to be free, he just wants a WYSIWYG interface for something that doesn’t make heavy, JavaScript-laden pages. Kinda sounds like a job for Publii…?
@Lars-Christian and @eladnarra, I thought Cathode Ray Dude was pretty explicit about what he wanted when he wrote:
it’s pathetic that what we could do with frontpage in 1998 is no longer possible with any available tooling
He’s talking about Microsoft Frontpage, which made it easy for a lot of people to build websites without having to know HTML. It didn’t necessarily generate “good” HTML, but the people using it didn’t care.
There was also Netscape Composer, which people still use in 2004, though mainly as a lark. Composer still lives on in Seamonkey, which people also still use.
I’m definitely not on the same wavelength here. It wouldn’t be my website if I generated it with ChatGPT and the like.
here’s some php or python you can use instead of wordpress to make a site that works like blogger
The author wants WordPress but it cannot be WordPress. 
node.js however is a fragile china doll with infinite dependencies, and i have never gotten it working in any environment without a lengthy struggle
We all gave up and used containers.
no, i do not want to run a VPS. my first website was on shared hosting in 2003, and you can’t tell me that 21 years later we have slid so far backwards that i now need to feed and care for apache myself just in order to have any presence on the web at all
Plenty of people are still using cPanel.
CGI still works, it has always worked, and it has always been the ideal way to make a website.
It is true that hardly anybody is still making software where the installation instructions begin with opening your FTP client and copying the code into your CGI-BIN.
I found this in the Comments about Ghost as an Alternative to WordPress on AlternativeTo.
Needs NodeJS, which means more powerful hosting or VPS that cost more than ordinary hosting. There is also less plugins and support. It is just a basic blog platform. Faster? Yeah. More secure? Yeah. Membership included? Yeah. But you have to pay more than on wordpress. And good luck with looking for an enthusiastic developers working for a smile. Wordpress is still the best platform. For a blogging i would choose anything but ghost.
I think this commenter is on the same wavelength as the writer of the post here. “Ordinary hosting” implies a lot of assumptions and expectations that are unmet by anything other than shared hosting with a LAMP stack. SSG developers (and there are a lot of them) don’t share these assumptions and expectations.
Same deal with this user on the hugo forum.
The only problem was, google didn’t know a lot about “hugo CGI-BIN”. I took a deeper look at the hugo documentation and found nothing about CGI-BIN. That confused me. That’s why I am asking how to do that.
They talk past each other in that thread because of divergent expectations and assumptions.
Quite the rant. Agree on a few things, disagree with most of the rest. Fun read though!
I agreed with the over riding feeling of this even if all the technical details went straight over my head.
I don’t have any technical background worth mentioning, and the jump from hand written fully manual HTML to any kind of site manager/generator is huge and mega frustrating.
They all seem to be built with the expectation that you’re a programmer or at least a computer science student and know their languages and structure already.
Using Hugo has let me automate a bunch of the stuff that was tedious when my site was written by hand but it’s also made everything way more complicated than it needs to be and trying to figure out how it works from the docs and forums is like trying to read a book in another language via the dictionary.
If there was a tool like frontpage still maintained and available I would jump to it in a heartbeat. I just want to write and have my little space, I do not give a shit about the technical details.
The modern equivalent to Frontpage I guess is something like webflow but it’s just so stupidly expensive that it’s not even worth mentioning imo.
I generally agree, especially when you want to start going image- and video-heavy (important for if you’re an artist or animator, for instance).
Some of this is slightly undermined by the fact that SSGs like Jekyll do have live reload, so it doesn’t take “six steps” to see what you’re doing, but I definitely agree that SSGs have too steep of a learning curve to get basic things done, especially when your needs scale beyond a few distinct pages (such as in my case).
The worst part about having to use tedious tools with a steep learning curve is the moment you’ve spent all that effort to discover that that tool is particularly opinionated and conflicts with the way you want your site set up, and then you’re fighting the software to get what you want, rather than minimizing the friction. For instance, it gets me that countless CMSes allow for any arbitrary amount of pages and then only one “collection” for blog posts. Really? What if I want more than one collection? It can’t be that hard to imagine a use case for multiple collections, as I sure make heavy use of them.
Thinking about this a little more, I thought to look at some early installation instructions from some early blogging software. (2005)
The instructions are very in-depth.
Observations:
- The instructions assume very little about the reader’s existing knowledge. It explains what a web server is, what an FTP client is, and so on.
- A section on “selecting a web host” explains the requirements in terms that are easy to understand, and explains why not all of the required Perl modules can be included.
- A link to a list of hosting partners who meet the requirements is provided.
- Users are asked to find perl on their system and manually edit the shebang in 12 files if it isn’t the default
#!/usr/bin/perl -w - Users can “[choose] between static page generation or dynamic pages […]” so it can act as a CMS and SSG. So modern!
- General instructions for unzipping files and operating and using an FTP client to copy are provided.
There are probably hundreds of SSGs available and I expect few or none of them provide quite this level of detailed documentation oriented toward a general audience. Many (most?) are going to assume you already know how to use npm.
Computer People who say “just use a static site generator. all you have to do is SSH into your server (you DO carry the same laptop with you everywhere, right?) and type up everything in markdown, then run a command to generate your site, then go load the site in a browser and drill down to the page you just created in order to find out what it looks like, then repeat that every single time you make a change
this is funnily detached from the modern web development to the absurd degree. at least half of this is addressed by good enough CI [i let github do the job with actions] and the tooling like vite that makes iterating on the site quite effortless, hot reloading and all. not to mention that anything not involving pushing a website can be done locally. it feels like they are inventing the problems the community using the “method 2” has already solved quite a while ago.
yeah, that is true, frankly. to me the kind of SSG that is worth its salt is one that doesn’t actively get in the way of actually writing things for it and doesn’t introduce some esoteric templating system that feels like performing a surgery on HTML with a spoon. 11ty came close to that vision for me, but it’s Astro that truly sealed the deal: it’s a modern framework that uses js toolchains pretty much everyone in the webdev world expects, but it doesn’t feel particularly contrived, so far it’s been a breeze to upgrade should upgrades be needed, and its .astro template language basically feels like html with jsx sprinkled in [that basically means “you can use computed values in your html like you do string literals in js”]. it’s kind of diverging in values from the op, but it more than satisfies my idea of an SSG being “tooling that supercharges my html”. i do yearn for something to plug into it that abstracts away the whole posting thing, though, preferably none of that cloud subscription nonsense.
I still don’t understand the appeal of SSGs when you can run a file based cms and the performance is basically identical once you have a cache in front. And you can run those on almost any cheap shared hosting. I really don’t get it.
the SSGs and file-based CMS are not mutually exclusive exactly - SSG largely solves the whole problem of raw HTML being kind of a PITA to modularize and rework, letting one split the various parts that comprise a webpage into templates that pages can reuse when needed, so you only need to edit a part that’s being reused in one place and have it apply everywhere that uses the template.
there absolutely are ways to pipe content from a CMS to various SSGs, and some SSGs even offer ways to diverge slightly from the static part in order to make fetching of content from a CMS more dynamic/on-demand. Astro is absolutely one of those, and the version 5 now accommodates loading things from CMS even more with the new content layer API.
The part I don’t understand is what you’re gaining with the whole build step that’s usually involved in an SSG. Like I can understand that in some situations an SSG might be a nifty tool but for blogs? Or personal sites? I really don’t get it. You get basically no benefits compared to alternative setups and you probably have a more complex publishing process.
I see so many developers setting up personal sites in insane ways and I’m always baffled by it. At some point I’m wondering if it’s just because they can.
for me, it’s simple: my personal website is for entertaining my personal brain worms.
i highly disagree with the publishing process part, though. publishing is, in fact, easier with this setup, as you can just plop a markdown file with necessary front matter and have it all neatly filled into your crafted templates, and when you want to make them look different, you just edit the template while keeping all the crucial post metadata intact. it’s specifically optimized for publishing, it’s more that the development part itself is a bit more challenging, figuring out how to slot things in the right places.
for example, this is what my typical status entry looks like. i write the text, plop it into a folder with statuses, push it to git, and then CI does the job of displaying it on the front page. here’s the same status in my archive for reference on how it looks live.
Ok. Now do that on your phone while you’re somewhere that is not your desk. This is the part i don’t get about SSG. You’re chained to the rest of your tooling because without it you can’t update your site. And the point of a blog is to being able to update it easily.
EDIT: an entry on my site, at the backend level, looks basically identical to yours. I have a simple txt file, on a folder, with markdown in it. The difference is that I can just go here and hit save.
