Kinda curious why you did not go with OpenResty?
Why not go with redbean?
Can the redbean webserver dynamically parse markdown?
Why I chose Lua for this blog
91–100 of 159 posts
Re: Why I chose Lua for this blog
#92Love the author's mentality. While I would almost definitely not pick Lua (I'd probably pick Go), I like how they arrived at their decision. Nicely done.
Re: Why I chose Lua for this blog
#93Earlier quoted context omitted.
My point here is that if someone breaks your blog, they've broken your blog. The blast radius of that should be strictly limited. Obviously don't go rolling your custom CGI scripts on a server that also hosts your personal email - but these days we are spoiled for choice in terms of isolated hosting strategies for a blog. Heroku, Vercel, Cloudflare Workers, Fly.io, GitHub Pages, a $5/month VPS...
But "broken your blog" could mean "shell access to your blog server" -- is there no risk of illegal activities happening on that server that put the owner at risk? Like, I don't know, drug trade or child porn or whatever?
Philosophically: L'État, c'est moi, build your crappy cgi scripts with nginx or apache all from the CLI and all in vim and you will understand.
Practically: Ports 22, 80, and 443 open and directly accessible from 0.0.0.0/0 is extremely manageable.
Re: Why I chose Lua for this blog
#94I miss the days when "implement your own blogging engine" was one of the most popular learning projects for engineers. We should bring that back! Its such a great way to play around with client- and server-side development options in an almost zero-risk environment.
Still a good project when one learns a new programming language.
yep. What makes it good is that it's an easy concept to imagine the use cases, but contains subtle details that covers the breadth and depth to gain the experience you need/want. Getting it wrong is not a death sentence (as long as you quarantine the project to it's own, rather than make it part of your home setup...).
Re: Why I chose Lua for this blog
#95I am not sure why one would have to use an engine for this. A blog consist of mostly repetitive list of posts made from a single identical template. Any 10y old kid could just master it enough to write them in html directly. And pandoc is just installed in seconds from any package manager if one wants to use an even easier different markup language. Heck in age of microblogging and social medias most blogs aren't even seeing a new post every week, barely anyone is on dialup anymore[1] and those who do probably won't load images automatically, one could have all their posts in a year on a single html page and just anchor tags. This is certainly the case from the blog linked here.
A shell function is enough to call pandoc, update any kind of index (date or tag based) and an rss page really. I would hardly call that an engine, it is just an helper to not forget to update indexes and feeds.
[1] loading speed was the main reason blog engines used to split posts in single pages
Re: Why I chose Lua for this blog
#96As a a javascript dev I kinda feel you and agree that the tools are moving faster than most codebases. The thing is though, you don't really have to use that many tools unless you really want to.
You can spin up a node server yourself and use web components and it will run fine probably just as long as the lua code will. It's also way easier today to just use web components and not any framework since LLMs can help you speed up the development.
Re: Why I chose Lua for this blog
#97Earlier quoted context omitted.
Everything web-facing, if it's not a static website delivered by a well-tested web server, happens in a high-risk environment. And doubly so, if, like in this case, stuff like custom cgi libraries are involved. One has to be either very confident in their skills to do that or very, very brave.
Ok. I'll bite. What are the risks? As I see it, if you screw up and someone get root access on your server, it's the worse that may happens and then shut down the whole thing is a click away.
Yes, if they do it for fun.
If they do it for money they will install something else and run it in parallel with the blog of the owner of the server. If they are good they'll be lean with resources and not get noticed for months or years. Example: I don't run ps -ef on my server very often and even if I did there are things that can be hidden from ps. It can get complicated.
Re: Why I chose Lua for this blog
#98Mine’s in Python. I took that route when it was a relatively obscure thing and PHP was gaining ground over CGI in Apache (at the time having a Python web server was downright weird) and stuck with it for a long time. These days it’s a purely static site generator and a bit too funky to release (there’s a variant over on https://github.com/rcarmo/sushy) but I really enjoyed maintaining it while it was a small, batteries included environment.
I considered switching to Lua (actually Fennel) but luarocks can be fiddly to use across platforms (I now run everything on ARM servers) and that pretty much was the end of that. So I’m curious as to how maintainable a Lua back-end is over time.
Re: Why I chose Lua for this blog
#99I am not sure why one would have to use an engine for this. A blog consist of mostly repetitive list of posts made from a single identical template. Any 10y old kid could just master it enough to write them in html directly. And pandoc is just installed in seconds from any package manager if one wants to use an even easier different markup language. Heck in age of microblogging and social medias most blogs aren't eve…
If you want to do inter-page linking and some forms of templating, pandoc can be a complete pain, though.
Re: Why I chose Lua for this blog
#100I miss the days when "implement your own blogging engine" was one of the most popular learning projects for engineers. We should bring that back! Its such a great way to play around with client- and server-side development options in an almost zero-risk environment.
When I was a teenager I wrote my first "CMS" and was very proud. A few months later someone called my parents and asked for me. He said he was a developer and found some issues with security. He gave me a few tipps and suggested me some books and left for good. Never talked to hm again but this was so kind and I learned a lot about secure coding after that.