I've found my SQL knowledge to be lacking, so I made a project that uses SQLite as a backend.
As it is intended for self-hosting I aim to make it easy to set up and maintain. Getting it up & running takes no more than a few commands (bar setting up a proxy such as nginx, which is out of scope).
I've set up a "demo" site at https://forum.agreper.com/ if you want to try out the UI.
I miss the days of good ole forum software (e.g. FluxBB/PunBB) before it was superseded with massive JS bloat/clunky forum software like Discourse, Flarum, etc.
With modern forums, it’s mostly the UX that sucks. PWAs that never recover from errors, endless scrolling, stuff like that. Also
* Falsehoods forum developers believe about network reliability – did you know the network can be down? Then up again?
* Falsehoods forum developers believe about time – did you know that time can jump forward, by huge amounts, because the page was suspended for whatever reason?
Turns out, if you try to do the browser’s job, that’s a lot of work! Just don’t.
Performance is usually good enough for me, even with all the JS and whatnot.
Back in the day, UBB was the most popular forum script but when vBulletin came out with its extremely comprehensive administration panel and constantly improving features, it started to replace UBB very fast. Then appeared free alternatives like phpBB, which probably became the most popular alternative for a long time and also there was a popular alternative written in ASP: Web Wiz Forums.
Curious, what about vBulletin v4 and v5 do you not like?
EDITED: *conversations
Good times. Sad that things have moved on to systems that don't suck quite so much but that's progress for you.
A 'classical' web forum is threaded, contrasting with an unthreaded (bulletin) board - at least that's how the terminology was used in the German webdev scene of the late 90s/early 2000s, possibly due to the prominence of SELFHTML and its forum.
This is not new, it just isn't applied to web based forums as much as I (someone who likes threaded discussions like that) would like. For small discussions it make little difference, for large branching threads it can help greatly when you don't care to follow all the sub-threads. It was not uncommon in Usenet clients back in the day. Of course it needs to be coupled with good UI for collapsing branches and otherwise navigating the tree, and perhaps a chronological view option for issue who prefer that (or a tree-view with posts spaced by arrival order for the best of both of you do it right - I had a reader that did that but can't currently remember it's name).
Until JS came along, reading online forums on a broadband internet connection was a worse user experience than using BBS forum software on a dial up modem.
Every single action, full page reload. And until cloud computing came along, even the best of website forums had servers that took forever to respond.
Somehow a BBS written for a 386 16mhz in 1992 was faster than a forum written in 1999 or even 2005. Oh wait, the 1992 forum was likely written in C, or even assembly! (And it only had 1 user at a time, that helped!)
But the only forum I know of that realised how to properly do it is this old Russian software forum [1] You need a mail client-like interface so that you can see your place in the discussion.
Triple quoting someone and trying to read the actual thread in a flat forum sucked then and sucks now.
[1] Example link http://rsdn.org/?forum/philosophy/8357952
I also commend demindiro on not requiring JS. It is refreshing to see simple yet useful applications.
[1] - https://www.phpbb.com/community/viewtopic.php?t=2106245
Sure something like phpBB is light, but the UX is also barely usable. Give me something like Reddit or Discourse over that any day. Why can't we have the best of both worlds?
Hackernews on the other hand manages to lack both (in some speculations intentionally), with neither usable design nor speed.
Improving either is an uphill battle when decision makers don't value the work, at best, or at worst are committed to resistance. And you don't even get paid.
Can't you do a lot of that with CSS?
I hate forums which indent replies and don’t support collapsing sub-threads.
The proper way of handling replies is to post them under each other and support quoting.
So you get a vast amount of low quality replies above the next high-quality reply.
For low volume it works okay because you can manually collapse but for high volume once it starts paging it breaks down and you just get further into the top level comment without properly being able to escape.
Reddit's model of auto-collapsing so you get a mix of threads and top-level replies is much better for picking out the better responses.
[-] should collapse subthreads. Caveat is that the browser doesn't remember which subthreads were collapsed due to no-JS.
I did not recognize the [-] as it looks like some weird emoji on my mobile browser due to the too small and uncentered background.
Here's my shameless plug: `pip install sqlitedao`: https://github.com/Aperocky/sqlitedao
my experience optimizing SQL has been removing the ORM layer via hand rolling SQL queries.
Most of my peers also seem to agree that ORM is great for knocking a feature out, but you’ll inevitably run into performance concerns at scale and need to write your own optimized queries yourself.
I feel like with SQLite having limited resources, you’d likely want to optimize your queries as best you can without an ORM? Is that not the case?
The fundamental issue with both handrolled SQL and ORM is inefficient queries leading to linearly increasing time consumption. for instance usage of `LIMIT` and accidentally querying on non-indexed fields. But I don't see how this differentiate the 2 as I have seen it happen in both situations professionally.
A good ORM enforces certain behaviors, specifically querying by index and constant time pagination. This guards against accidental querying behaviors.
ORM's never scale and you end up with hand written SQL long term. Unless it is really just a CRUD app then ORM's really work fairly well.
You might take a look at Fossil (fossil-scm.org) which is not a forum, but is an all-in-one source control system, bug tracker, wiki, and web backend, all implemented as an SQLite client written in C. Its blurb says a scripting language might sound more attractive than C superficially, but in Fossil, SQLite does all the heavy lifting that would otherwise have been done with scripts. On my bottomless todo list I want to study its implementation sometime, since I think it would be a good example of "advanced" uses of SQL and SQLite. That is completely independent of Fossil's purpose as a VCS application. I'm ok at basic SQL but not so clueful about sophisticated uses.
One thing to watch out for is that since SQLite is an embedded DB, when you make an SQlite query, the overhead is basically a local subroutine call rather than the network traffic that a client/server DB would incur. That in a way changes the asymptotics of an application: particularly, the "N+1 queries" antipattern of some client/server DB apps is a perfectly ok design strategy for SQLite. I believe Fossil may rely on this in some way.
If I was developing a new forum engine, I'd base it on federated activitypub protocol.
Do you intend to extend it and keep working on it or was it just a one off project?
"Modern practices make for slow apps" is a common trope on HN, but it's important to note that it's not just modern practices that make modern web apps feel slow; modern feature sets are the larger culprit.
This app could be a React SPA and it would still be faster than most forums you've used because it intentionally has a minimal feature set.
Modern forums haven't innovated all that much, you have infinite scrolls, notifications and live updates, that's all that I can think of, off the top of my head. If you go on the main page of a modern forum and a Phpbb one they'll be functionally equivalent for the end user.
And even if they had innovated, you can put as big a feature set as you want on the backend and not send 20Mb of JavaScript along with a single request per post and your page will load instantly.
And that's not even going into all the websites which are entirely featureless, I regularly see SAAS landing pages that take over a minute to fully load, that's just to display text and images.
Maybe the stack is capable of being fast and light theoretically but it never is in practice.
I actually shortened it, expanded it to add bot detection and published the update also under 1KB: https://gist.github.com/Xeoncross/1503594
Such abuse PHP could handle back then.
Thanks for sharing it :)
I'm pretty okay with that, my only complaint is that when you vote a comment or story it creates an invisible image with a voting URL, which may be loaded much later so the click may not register from time to time.
I ask because I believe this is the hardest part of a forum software; The one thing that make or break a community is whether there is timely and fair moderation so contents are fresh and relevant.
I will definitely focus on having good moderation features as I also believe it is essential for a healthy forum.
You are using flask. How is the performance? I moved away from flask to FastAPI but another one of my goal has been to create a program that can run on cheapest VMs availalble in the market, which means very low ram. I am currently trying to rewrite the server into Go and use something that can consume jinja2 templates in it.
I'm renting a VPS in New York which costs ~€20 a month (€15 for VPS with 1 dedi 3900X core, 4GB RAM and 80GB NVMe, €3 for DDoS protection and €1.5 for up to 7 daily backups), which in hindsight is overkill.
I do intend to add pagination but I'm not sure what a clean implementation would look like.
- A weak CAPTCHA that will be replaced with something stronger (probably image-based)
- Disabling registrations
const input = document.querySelector('body > main > form > table > tbody > tr:nth-child(3) > td:nth-child(2) > input');
const challenge = document.querySelector('body > main > form > table > tbody > tr:nth-child(3) > td:nth-child(1)').innerText.split('=')[0];
input.value = eval(challenge);I'm absolutely loving the fact that the HN zeitgeist has come around to embracing these no-js solutions focusing on function over form.
Every once in awhile I come across little sparks in the forum space, but they all fizzle out for one simple reason: building a forum software isn't as easy as you think it is.
For us, it took three developers a year apiece of full-time work to reach rough feature parity with our competitors, and we're still trying to innovate nearly a decade in (and add in the constant need for reducing technical debt, etc.)
For now I will say what I always say when I see new competitors in the forum space — give me a run for my money. Keep me on my toes! I appreciate the challenge, and it gives me that extra incentive to make our software the best it can be.
It definitely feels like we're going full circle with the Web and back to its earlier, decentralized, stripped-down past.
And specifically, looks great - clearly outlined, threaded, indented, flow of conversation.