Show HN: Minimal, no-JS web forum software(github.com)
github.com
Show HN: Minimal, no-JS web forum software
https://github.com/Demindiro/agreper
160 comments
It's always nice to hear about someone writing a cool program just because they felt like doing so. Every time I think about writing a forum server, I find I return to the thought that Usenet was better, and that if I wanted a web forum, I'd consider putting a web front end on an NNTP server. That would among other things let people keep using NNTP clients (I like gnus.el) if they don't want to use a browser. There are a bunch of NNTP web clients already, but afaict they all needlessly suck.
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.
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.
Every now and then I'm reminded of what could have been when someone submitted a patch to Dreamwidth (probably easily ported to Livejournal) that provided a bi-directional NNTP gateway that allowed posting. The Dreamwidth devs quite reasonably ended up regretfully rejecting it because there was no-one in the dev community who could maintain it, but sometimes when I'm reading through a community that generates 5000 messages a day I'm reminded that I could have had real kill files and proper tracking of new messages. Even close to 30 years later I haven't found anything as efficient for forums & such as a good newsreader was for netnews.
The D Language forum is a web forum/NNTP client/mail archive/irc bot/rss feed. You don't have to make an account to post. A friend of mine pointed out many years ago that it was basically the peak form of multi-protocol communications. If someone could implement convenient encryption it would be magic.
The most productive workplace forum I have used was based on NNTP. So much better than "improvements" like Slack and Discourse. But then I considered it was really just a shared email. Would email with shared folders not achieve the same?
> and that if I wanted a web forum, I'd consider putting a web front end on an NNTP server.
If I was developing a new forum engine, I'd base it on federated activitypub protocol.
If I was developing a new forum engine, I'd base it on federated activitypub protocol.
I commend you for hand rolling it all and not using JS.
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.
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.
I actually believe vBulletin 3 is where it’s at!
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.
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.
Although it is undeniable how good vBulletin was, UBB (original Ultimate Bulletin Board written in Perl, not the newer UBB.threads) will always have a special place in my heart. I always loved its esthetics, maybe because of the memories of nice communities using UBB I was part of. I even wrote an ASP forum script that mimicked its style.
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.
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.
> I actually believe vBulletin 3 is where it’s at!
Curious, what about vBulletin v4 and v5 do you not like?
Curious, what about vBulletin v4 and v5 do you not like?
Developers of vB 3 left the company and started new forum software named XenForo. They were then sued by Internet Brands (vB owners) for IP theft - IB claimed XenForo was next vBulletin. In court hearings we’ve learned that IB plan for vBulletin development was to fire all but lead dev, and have this lead dev only delegate and review work to outsourced devs in Asia. We’ve also heard that „only developers care about quality of code” and trying to keep code good is „waste of time”.
And then vB 4 landed and turned out to be insanely poor launch - forum index was plugin based, but it was very easy to end with index page that did 700 mysql queries, which took forever to execute without relying on full page cache like varnish.
Today its supposedly much better, but Internet Brands uses internal version of vBulletin 3 (3.8) to run their sites instead of v4 or v5.
And then vB 4 landed and turned out to be insanely poor launch - forum index was plugin based, but it was very easy to end with index page that did 700 mysql queries, which took forever to execute without relying on full page cache like varnish.
Today its supposedly much better, but Internet Brands uses internal version of vBulletin 3 (3.8) to run their sites instead of v4 or v5.
I wondered why vbulletin v4+ seemed like such a radical shift. vB 3.x was a true platform. There was a rich ecosystem of plugins (including many paid) and many sites were heavily customized. Every vB 4+ site looks exactly the same to me IMHO. This also explains why all of the paid plugins moved to XenForo. Interesting...
It’s just the feeling! :-)
vBulletin 4 was also okay in the end, but I always thought vBulletin 5 was trying to be too many things at once. It’s just too modern! I understand, of course, that the online community landscape has changed since back then and vBulletin has to adapt to remain competitive.
vBulletin 4 was also okay in the end, but I always thought vBulletin 5 was trying to be too many things at once. It’s just too modern! I understand, of course, that the online community landscape has changed since back then and vBulletin has to adapt to remain competitive.
Why do people hate endless scrolling so much?
Because it’s like swimming across a large lake finding yourself exhausted in the middle with little alternative to swimming back.
Now on my phone it’s relatively easy to jump to the top of the page. It’s also almost done impossible to jump to the bottom.
On a desktop I can at least mash the END key or play silly reindeer games with the scrollbar thumb.
On mobile it’s very hard to Leap or Surge or Jump.
If I’m madly fanning the page with my thumb or, worse, my fingers because I’m tired with my thumb, I pretty much just give up at that point.
I also like having non-endless scrolling because I can use the scroll bar as a gauge of how much is left of the article.
Being constantly fed is just a bad experience.
Now on my phone it’s relatively easy to jump to the top of the page. It’s also almost done impossible to jump to the bottom.
On a desktop I can at least mash the END key or play silly reindeer games with the scrollbar thumb.
On mobile it’s very hard to Leap or Surge or Jump.
If I’m madly fanning the page with my thumb or, worse, my fingers because I’m tired with my thumb, I pretty much just give up at that point.
I also like having non-endless scrolling because I can use the scroll bar as a gauge of how much is left of the article.
Being constantly fed is just a bad experience.
Terrible user experience. If it infinitely scrolls I can be sure some gesture on the phone will lose my spot and it will take ages to find where I was. Also they rarely play nice with the back button. There is usually a better way to present data.
For reading, do you prefer books or ancient scrolls?
For reading, do you prefer books or ancient scrolls?
Apollo (reddit client on iOS) solves this by having the same gesture undo itself -- tap at the top to scroll to the top of the reddit post, tap again to return to where you were.
I'm not saying your complaint is invalid, just that there are ways of mitigating the issue. And that said, I can't imagine how reddit threads would work if paginated.
I'm not saying your complaint is invalid, just that there are ways of mitigating the issue. And that said, I can't imagine how reddit threads would work if paginated.
> I can't imagine how reddit threads would work if paginated.
Presumably similarly to HackerNews threads, which are paginated.
Presumably similarly to HackerNews threads, which are paginated.
Yes. Pagination can be bad if the URL indexes by 1-10, 11-20 etc. But I think HN paginates using the post ID, so that the links are permanent (?) which is a better way to do it. Basically the novel idea here is to treat the browser like a REST client.
This also means you need a predictable, deterministic algorithm, like "ORDER BY DATE DESC", but Reddit does have order by popularity, so that will not be idempotent. But now being super picky as order by popularity is pretty useful. Although I think date should be the default. And order by [what cambridge analytica-likes know about me] should be off.
This also means you need a predictable, deterministic algorithm, like "ORDER BY DATE DESC", but Reddit does have order by popularity, so that will not be idempotent. But now being super picky as order by popularity is pretty useful. Although I think date should be the default. And order by [what cambridge analytica-likes know about me] should be off.
HN also lets you elide branches with a click, so you're not trapped in a section you're not interested in. It's so nice opening a 400 response thread, getting 10 messages into the top comment, and clicking the hide button and watching 200 messages vanish.
Do you have a way to fold a branch once you're, as you say, 10 messages in? Or do you need to scroll back up to the parent to fold it? That's what I'm seeing and it's sub-optimal.
HackerNews threads aren't paginated, at least not for me. I just checked a post with 500 comments on it, and they all displayed in one long list.
HackerNews posts are paginated. And there isn't any interface for navigating the pages. Which is fine for HN's minimalist approach and tech-oriented audience. But it hardly seems optimal for a general audience.
HackerNews posts are paginated. And there isn't any interface for navigating the pages. Which is fine for HN's minimalist approach and tech-oriented audience. But it hardly seems optimal for a general audience.
> And that said, I can't imagine how reddit threads would work if paginated.
It's not that hard. I saw good example of paginated threads at livejournal.com: it paginates root comments and collapses large subthreads. https://ammo1.livejournal.com/1348094.html?view=comments#com...
It's not that hard. I saw good example of paginated threads at livejournal.com: it paginates root comments and collapses large subthreads. https://ammo1.livejournal.com/1348094.html?view=comments#com...
Yeah but how many people will discover that functionality themselves vs how much effort will you expend trying to educate the rest of your users? Pagination wins because there's nothing to learn, it's obvious where you are and how to get somewhere else.
Sounds reasonable. I am complaining about infinite scroll on the web. But inside a native app it might be better since there is more precise control of that experience. Assuming the app creator has done a good job.
The app creator has done a very good job. And is responsive if there is an issue.
Well, first, it's not reliable. If the network goes down and it doesn't have some form of recovery, you gotta start from scratch. Second, it's not bookmarkable (except for the odd case), so you can't send specific pages to anyone, you often can't start navigating in it one day and continue on other, or in another device. Third, you lose navigation and exploration features, like navigating to the first page and seeing the oldest stuff, or going into the middle.
But the biggest reason people hate as a matter principle is because it is in 99% of cases done without any UX research and without any care from developers, and that's in the best case. The worst case is to cause doomscrolling, which is nefarious in its own.
It is disrespectful to users. If you don't want people seeing old content just fucking delete it.
But the biggest reason people hate as a matter principle is because it is in 99% of cases done without any UX research and without any care from developers, and that's in the best case. The worst case is to cause doomscrolling, which is nefarious in its own.
It is disrespectful to users. If you don't want people seeing old content just fucking delete it.
Someone posted this on HN last month and I think it summarizes very well what people dislike the most about infinite scrolling: https://news.ycombinator.com/item?id=32789617
Impossible to jump pages, know how much there is, often breaks native scrolling in awkward ways without recourse.
It often breaks the builtin Browser-Search.
Which is often followed by attempts to replace browser native Find in Page with a custom implementation that doesn't work as well.
And you love it, so much? It's probably the stupidest thing ever invented as far as UX goes.
It is possible the gp post just feels neutral about it. There are a whole range of emotions between love and hate.
I do feel neutral/indifferent about it. I was just wondering why I see so much negative sentiment towards it.
I feel vaguely-neutral/negative toward it. It plays somewhat annoyingly with things like bookmarking (mitigated slightly by the fact that infinite scrolls are usually generated content anyway so bookmarking them is probably meaningless) and are trying to tempt the user into endless scrolling (but I guess it is our responsibility to resist the temptation there).
It makes it impossible to get to the footer.
And impossible to link to anything behind the scroll interaction.
[deleted]
Ohh I miss the good old days of forums in general. I find all this new software, where conversions* are "threaded" stupidly hard to read. Even worse, when the software is trying to recommend to you, what to read. Back in the day you had a thread, every post to that thread was chronologically added to that thread and in case you wanted to reply to someone, you quoted them... sigh
EDITED: *conversations
EDITED: *conversations
I actually love threaded discussions… On HN and Old Reddit. But anything is better than whatever XDA uses, and almost everything is better than discourse.
> Old Reddit
Important distinction.
New Reddit also fell prey to bad development practices and is without exaggeration unusable for me. It often "crashes" and the whole page goes dark-grey on my browser, and this has been happening for at least a year. After reloading I can't see all messages without navigating away, and middle click messes with the scrolling. At this point I will assume they either don't care or are fucking with me.
Important distinction.
New Reddit also fell prey to bad development practices and is without exaggeration unusable for me. It often "crashes" and the whole page goes dark-grey on my browser, and this has been happening for at least a year. After reloading I can't see all messages without navigating away, and middle click messes with the scrolling. At this point I will assume they either don't care or are fucking with me.
I also prefer reading threaded discussions, but are you aware of a good way of keeping track of new messages? That’s my main issue with threaded discussions, for example here on HN.
The way Usenet clients and traditional email clients work is that unread messages are marked as such (usually by use of bold typeface), and you have keyboard shortcuts to navigate from one message to the next, or to jump to the next unread message.
For example, the Tab key jumps to the next unread message, Space/Backspace scroll up/down within a message, and the Up/Down arrow keys jump to the previous/next message (regardless if unread or not). A message is marked as read automatically when you navigate to it (it gains focus). There’s also a keyboard shortcut to mark a read message as unread again if you w.
The keyboard navigation means that only one message has focus any point in time. You have a threaded view of all messages, where the unread ones are highlighted (e.g. by bold typeface). Then you can decide which ones to navigate to. Usually you just use Tab and Space to jump/scroll through the unread messages. It’s incredibly efficient to use.
For example, the Tab key jumps to the next unread message, Space/Backspace scroll up/down within a message, and the Up/Down arrow keys jump to the previous/next message (regardless if unread or not). A message is marked as read automatically when you navigate to it (it gains focus). There’s also a keyboard shortcut to mark a read message as unread again if you w.
The keyboard navigation means that only one message has focus any point in time. You have a threaded view of all messages, where the unread ones are highlighted (e.g. by bold typeface). Then you can decide which ones to navigate to. Usually you just use Tab and Space to jump/scroll through the unread messages. It’s incredibly efficient to use.
I am the developer of HACK, an iOS, android, MacOS client app which provides push notifications for HN when someone replies to your comment or post.
I too miss the good old days where the information you wanted was buried somewhere in a 100 page phpBB thread and you had to manually search through it 1 page at a time, with each one-line comment taking up half the page with avatars and signatures.
Good times. Sad that things have moved on to systems that don't suck quite so much but that's progress for you.
Good times. Sad that things have moved on to systems that don't suck quite so much but that's progress for you.
Ohh I miss the good old days of forums in general. I find all this new software, where conversions are "threaded" stupidly hard to read.
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.
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.
> find all this new software, where conversions are "threaded" stupidly hard to read.
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).
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).
I find HN's approach very easy to read and follow. But then, each submission does not keep getting commented on indefinitely. Could get unwieldy then.
it works if you want to read a thread exactly once and then never come back to it. if it's an ongoing discussion that you want to visit even just two times, you'll just end up reading all the same comments again and struggle to find anything new
I miss the good old days of BBSes, the late 90s were a serious step back in forum usability.
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!)
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!)
My favorite kind of web forum engine is the one which keeps discussions threaded, but displays them in a flat list of messages ordered by time, but with quick navigation to parent and responses.
Threaded conversations are really good because you can have branching discussions that don't interfere with each other.
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
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
vBulletin 3.x/4.x and IPB 2.x/3.x had threaded view as an option alongside flat.
Forum software of old actually gave users the power to choose the interface they want. We've really gone backwards with software interfaces.
Also, themes. These days all we get are "Dark Mode" and "Light Mode". Boring.
Forum software of old actually gave users the power to choose the interface they want. We've really gone backwards with software interfaces.
Also, themes. These days all we get are "Dark Mode" and "Light Mode". Boring.
Check out the D language forums. Easily the best forum software I've seen.
It looks like a regular flat forum with a thread display just bolted on top of the page where clicking a post in the thread just dumps you in the middle of a flat discussion
What are they using?
Thank you. I just found it now on my own on desktop via their "About this forum" footer link, wasn't obvious to me when I quickly glanced at it on mobile earlier.
For what it's worth, phpBB still sortof supports having javascript disabled [1] but it is nowhere near as lightweight as the example here created by demindiro.
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
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
I loved PunBB. 18 years ago at my first IT job I actually stole PunBBs design to make the control panel for our web hosting company. Nobody knew because even then punbb was kinda esoteric.
I do still wonder why the fast and responsive software can't invest a little bit into design in order to not look like complete shit.
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.
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.
There is a considerable cultural overlap between "people who think no-JS, fast and responsive software is cool" and "people who think the design of Reddit or Discourse is really awful". (Man, especially Reddit, I swear the day they retire old.reddit.com will be the day I stop using it). They probably are investing a little bit into design, just not the one you like.
FOSS tends to treat aesthetics like developers complain executives treat software quality: This doesn't help me. Why does it matter? Why should I care? I see no difference.
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.
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.
Yep often they don't see aesthetics/usability as a feature, and sometimes even have a grudge against it.
For example, Blender pre-v2.8, many many flamewars belittling people who wanted something usable, akin to calling them shallow/superficial Untermensch who "don't understand" Blender's supposedly genius but strange design choices at that time.
I suppose that's why most aren't capable of making a product and are relegated to being an employee or unpaid open source employee.
For example, Blender pre-v2.8, many many flamewars belittling people who wanted something usable, akin to calling them shallow/superficial Untermensch who "don't understand" Blender's supposedly genius but strange design choices at that time.
I suppose that's why most aren't capable of making a product and are relegated to being an employee or unpaid open source employee.
I also miss the days of good ole server-side rendered applications. I'm not sure the author's history or work experience, but, if I built something like this, I'd likely find it extremely cathartic compared to most tech stacks nowadays. :-)
For that era, FluxBB/PunBB weren't even that great. I think phpBB/vBulletin took the cake (as was evident by the number of forums run by the said software), and of course, IPB was also nice but came with a steep price by comparison.
PHPBB
The point of no-js is mainly to avoid client-side tracking, right?
Can't you do a lot of that with CSS?
Can't you do a lot of that with CSS?
That reminded me of the 1KB forum: https://nerdparadise.com/programming/phpforum
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.
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.
I haven't seen representatives from Discourse, Flarum, Vanilla, or the like chime in yet, but as the founder of NodeBB, I want to say this is just awesome!
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.
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.
This is great. I want to see more of the web to be like this. Simple, direct, light, and functional. I've came to learn on this thread alone that other projects such as teddit and nitter exist, which capture this same spirit. I'd like to know if other projects for popular sites exist as well. Someone should make an aggregation of sites and open source libraries like https://github.com/Demindiro/agreper that exist.
bearblog & prose.sh came to mind (minimal blog system). For chat, we got https://github.com/altilunium/darkhallv3
It feels very retro - back to the earlier days of the web circa what Craigslist still looks like. Are you doing this just for development experience / fun or to make it something bigger? I still find no-JS back-end forums such as PHPBB and similar to still be useful. People are still running vBulletin. These systems are all very robust and handle moderation and many other forum-related must haves. Are you looking to build those as well?
It definitely feels like we're going full circle with the Web and back to its earlier, decentralized, stripped-down past.
It definitely feels like we're going full circle with the Web and back to its earlier, decentralized, stripped-down past.
Teddit works like a charm with disabled javascript, it supports css based thread collapsing, and cookie based information for logged out users as well (you can store which subreddits you follow).
Love it! I built one using go (https://git.sr.ht/~m15o/vpub) and it powers https://forum.status.cafe/
Thanks for sharing it :)
Thanks for sharing it :)
It's not caching the stylesheet. If you plan on updating it a lot you should still enable caching and e.g. increment a url parameter every time you change it (like style.css?v=3).
Is it still being maintained? Do you accept PR's?
I tried to register on the forum to ask, but my user has not been activated.
I love it. And it's telling of modern practices that it's one of the fastest forum I've used in the past few years, you click and the page instantly appears!
Do you intend to extend it and keep working on it or was it just a one off project?
Do you intend to extend it and keep working on it or was it just a one off project?
> And it's telling of modern practices that it's one of the fastest forum I've used in the past few years, you click and the page instantly appears!
"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 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.
I don't buy that for a second to be honest.
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.
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.
> Modern forums haven't innovated all that much...
I'm not comparing modern forums to older forums, I'm comparing both types of forum to OP's minimal forum.
> 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.
You have to distinguish between initial page loads and subsequent interactions. Forums are not typically one-page-and-done websites: you spend a lot of time navigating around the different views.
For this use case, phpBB forums were and are very slow.
I tested out the phpBB demo [0] and compared it with the Discourse demo [1]. The Discourse demo has a slow initial load, but it's quite snappy after you've downloaded the 6.23mb (not 20mb!) of JS and CSS. The phpBB demo seems faster on the initial page load, but it gets pretty painful to navigate as you click around into different sub-forums.
The reason why the OP's no-JS forum can outperform both phpBB and Discourse is primarily that it doesn't do very much work on each user action, not that its stack is inherently superior. The biggest bottleneck in a forum will be the speed of each request-response cycle, not whether the requests return JSON or HTML.
[0] http://www.try-phpbb.com/33x/index.php
[1] https://try.discourse.org/
I'm not comparing modern forums to older forums, I'm comparing both types of forum to OP's minimal forum.
> 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.
You have to distinguish between initial page loads and subsequent interactions. Forums are not typically one-page-and-done websites: you spend a lot of time navigating around the different views.
For this use case, phpBB forums were and are very slow.
I tested out the phpBB demo [0] and compared it with the Discourse demo [1]. The Discourse demo has a slow initial load, but it's quite snappy after you've downloaded the 6.23mb (not 20mb!) of JS and CSS. The phpBB demo seems faster on the initial page load, but it gets pretty painful to navigate as you click around into different sub-forums.
The reason why the OP's no-JS forum can outperform both phpBB and Discourse is primarily that it doesn't do very much work on each user action, not that its stack is inherently superior. The biggest bottleneck in a forum will be the speed of each request-response cycle, not whether the requests return JSON or HTML.
[0] http://www.try-phpbb.com/33x/index.php
[1] https://try.discourse.org/
> it's quite snappy after you've downloaded the 6.23mb (not 20mb!) of JS and CSS
The pbpBB page you linked downloads 330 KB. Or you can disable JavaScript (and the page still works), and it only downloads 156 KB.
Discourse sucks.
The pbpBB page you linked downloads 330 KB. Or you can disable JavaScript (and the page still works), and it only downloads 156 KB.
Discourse sucks.
Feature set is absolutely design practice.
I will keep working on it. There is a lot more interest than I anticipated.
I dislike forums which indent successive replies.
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.
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.
That's just, like, your opinion man. I prefer HN's indented approach to a typical forum listing where it's just a firehose with quotes. But the best approach is to allow the view to be switched as desired.
HN's model is bad for high volume. Sometimes on HN you only get one top level reply on the whole page because once it puts the top top-level reply it then puts all the replies to that above the next top-level reply.
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.
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.
I made a reddit-like comment system for HN if you are curious: https://www.hackernewz.com/item/33153152 (link to your comment: https://www.hackernewz.com/item/33153152?commentId=33155112)
It seems you only show top 3 levels by default, then allow manual toggle to show/hide nested replies?
Also for long list of replies, you also only show first few.
This design may helps "smaller comments" to surface when the conversation is relatively "mature".
Also for long list of replies, you also only show first few.
This design may helps "smaller comments" to surface when the conversation is relatively "mature".
The problem with letting users choose the view is that the chosen view affects how they write. If I can see it's obvious in my tree view who I'm responding to, I won't point it out, and then someone who uses the firehose view won't be able to follow the conversation.
I feel the main problem wouldn't be this (if you handle quotes to show in a tree view then surely you can handle replies in a tree view to show quotes in a firehose).
However, the main issue is that when you can quote multiple comments (when you are in a firehose view) you tend to send a single post for multiple replies; I have no idea how that could be shown in the tree view.
Essentially a firehose is a superset of a tree structure, if your unit is a post.
However, the main issue is that when you can quote multiple comments (when you are in a firehose view) you tend to send a single post for multiple replies; I have no idea how that could be shown in the tree view.
Essentially a firehose is a superset of a tree structure, if your unit is a post.
> then surely you can handle replies in a tree view to show quotes in a firehose
One problem is that when people are manually quoting a post, they can edit that quote down to only include the relevant portion of the post they're replying to, and depending on the forum culture unnecessary full-quoting is actively being discouraged.
Automatically added quotes on the other hand don't have such a luxury, so you'd get a big bunch of full quotes, which wouldn't really be ideal, either.
One problem is that when people are manually quoting a post, they can edit that quote down to only include the relevant portion of the post they're replying to, and depending on the forum culture unnecessary full-quoting is actively being discouraged.
Automatically added quotes on the other hand don't have such a luxury, so you'd get a big bunch of full quotes, which wouldn't really be ideal, either.
There's really two concepts: parent, which is how hierarchy is achieved, and quotes, which are stylized text linking back to an ancestor.
The potential for problems would arise when everyone Replied using a root-level post to the firehose. This could be mitigated with prominent Reply links on every post in the firehose, with the root-level contribution form deemphasized. So you can quote multiple people but you still chose a parent by choosing which Reply link to click.
The potential for problems would arise when everyone Replied using a root-level post to the firehose. This could be mitigated with prominent Reply links on every post in the firehose, with the root-level contribution form deemphasized. So you can quote multiple people but you still chose a parent by choosing which Reply link to click.
> I hate forums which indent replies and don’t support collapsing sub-threads.
[-] should collapse subthreads. Caveat is that the browser doesn't remember which subthreads were collapsed due to no-JS.
[-] should collapse subthreads. Caveat is that the browser doesn't remember which subthreads were collapsed due to no-JS.
Not if each "collapse" link reloads the page and at the same time stores the preference in the backend against your username so that subsequent page loads know what to hide (:
LOL you are so right... so much was lost when we started accepting that page reloads are expensive (T_T)
For 20 years page reloads were expensive.
In 1999 I had a cable modem connection that could pull down 2 megabytes per second and ping up and down the west cost well under 50ms.
But forum servers were slow. Like, really really slow. When Sites like Reddit finally came to, 15 or so years later, with inline replies, they were a breath of fresh air.
Back in 99 Slashdot had massive resources put into making it responsive, lots of servers thrown at it, and it was still laggy and slow compared to Reddit now days.
Everyone arguing about "time to first draw being under 100ms" forgets that just a short time ago, web servers took more than 100ms to respond to a connection.
In 1999 I had a cable modem connection that could pull down 2 megabytes per second and ping up and down the west cost well under 50ms.
But forum servers were slow. Like, really really slow. When Sites like Reddit finally came to, 15 or so years later, with inline replies, they were a breath of fresh air.
Back in 99 Slashdot had massive resources put into making it responsive, lots of servers thrown at it, and it was still laggy and slow compared to Reddit now days.
Everyone arguing about "time to first draw being under 100ms" forgets that just a short time ago, web servers took more than 100ms to respond to a connection.
Yeah you’re not wrong. But I wouldn’t consider that 100ms, or even 500ms, “expensive”.
In 1999 I would have been jealous of your internet connection — I still had a 256kbps ISDN line, and there were fast forums even then (but mostly not). I think it mainly depended on whether the sites rendered HTML on the fly (with like maybe Perl? to render database content) or... just served static HTML.
Page reloads only got expensive when we decided that they would do a bunch of other shit besides that.
In 1999 I would have been jealous of your internet connection — I still had a 256kbps ISDN line, and there were fast forums even then (but mostly not). I think it mainly depended on whether the sites rendered HTML on the fly (with like maybe Perl? to render database content) or... just served static HTML.
Page reloads only got expensive when we decided that they would do a bunch of other shit besides that.
> Yeah you’re not wrong. But I wouldn’t consider that 100ms, or even 500ms, “expensive”.
100ms is noticeable, 500ms is bad.
The old dial up BBSs may have been slow enough that you could watch character appear, but they were responsive! Those characters started printing right after your keypress happened. Of course it helped that it was likely a local phone call.
I imagine HN ever had a 500ms response rate, the engineers behind it would consider it a failure!
(Even reddit is under 500ms for many operations, and it is super heavyweight)
> I think it mainly depended on whether the sites rendered HTML on the fly (with like maybe Perl? to render database content) or... just served static HTML.
Yeah Perl didn't help the 90s web at all. It made stuff possible, but wow, the performance was bad.
Then again web server software design back then was also a long ways away from what we know to do now.
100ms is noticeable, 500ms is bad.
The old dial up BBSs may have been slow enough that you could watch character appear, but they were responsive! Those characters started printing right after your keypress happened. Of course it helped that it was likely a local phone call.
I imagine HN ever had a 500ms response rate, the engineers behind it would consider it a failure!
(Even reddit is under 500ms for many operations, and it is super heavyweight)
> I think it mainly depended on whether the sites rendered HTML on the fly (with like maybe Perl? to render database content) or... just served static HTML.
Yeah Perl didn't help the 90s web at all. It made stuff possible, but wow, the performance was bad.
Then again web server software design back then was also a long ways away from what we know to do now.
> just a short time ago, web servers took more than 100ms to respond to a connection
And yet, once you wait that 100ms or however long it takes for the server to respond, your page is fully loaded and interactive. During the loading process, your browser remains responsive and your CPU is not loaded.
Nowadays, we still wait the same amount of time for the initial load, but now your CPU is at 100% parsing megabytes of shitty Javascript, and once the initial load completes, you're still not guaranteed the page won't slow down/overload your CPU again because some stuff can be asynchronously loaded (supposedly for performance reasons, even though doing it on the backend as part of the initial load would be faster in the vast majority of cases).
And yet, once you wait that 100ms or however long it takes for the server to respond, your page is fully loaded and interactive. During the loading process, your browser remains responsive and your CPU is not loaded.
Nowadays, we still wait the same amount of time for the initial load, but now your CPU is at 100% parsing megabytes of shitty Javascript, and once the initial load completes, you're still not guaranteed the page won't slow down/overload your CPU again because some stuff can be asynchronously loaded (supposedly for performance reasons, even though doing it on the backend as part of the initial load would be faster in the vast majority of cases).
> Nowadays, we still wait the same amount of time for the initial load, but now your CPU is at 100% parsing megabytes of shitty Javascript, and once the initial load completes, you're still not guaranteed the page won't slow down/overload your CPU again because some stuff can be asynchronously loaded (supposedly for performance reasons, even though doing it on the backend as part of the initial load would be faster in the vast majority of cases).
The new reddit site is fast. Yes initial load time is like 2 seconds, but after that, everything else is instant. Click comments, escape out, go back to feed, load comments of a different story, it is quick.
Yes crappy JS abounds everywhere, NYT is an offender recently (they used to be good!), lots of sites suck in this regard, but when modern web dev is done well, it works really well.
Though having read the Reddit engineering blog posts, they throw a ton of resources at ensuring Reddit is fast.
Meanwhile, Ars Technica loads things almost instantly, but for the last year or two (!!) their article pages have leaked memory and CPU, eventually taking up all my CPU and gigs of memory.
Not sure how even. Great load times, responsive site, keep that background tab open and watch the CPU start to melt down.
The new reddit site is fast. Yes initial load time is like 2 seconds, but after that, everything else is instant. Click comments, escape out, go back to feed, load comments of a different story, it is quick.
Yes crappy JS abounds everywhere, NYT is an offender recently (they used to be good!), lots of sites suck in this regard, but when modern web dev is done well, it works really well.
Though having read the Reddit engineering blog posts, they throw a ton of resources at ensuring Reddit is fast.
Meanwhile, Ars Technica loads things almost instantly, but for the last year or two (!!) their article pages have leaked memory and CPU, eventually taking up all my CPU and gigs of memory.
Not sure how even. Great load times, responsive site, keep that background tab open and watch the CPU start to melt down.
> The new reddit site is fast. Yes initial load time is like 2 seconds, but after that, everything else is instant.
Disagree. I just gave it a try on a desktop (!) browser – when switching from the thread list into a particular comment thread, "new" reddit is definitively slower than old.reddit.com, both visually (after the thread page as such displays, it spends another second or two loading the actual comments, whereas on old.reddit.com everything renders instantly), and measured end-to-end (from clicking on the "comments" link to the moment the comments actually appear) as well.
On my underpowered phone, "new" reddit fares even worse, and never mind all that additional "you can only view this in the app"-crap that was thankfully never backported to old.reddit.com.
Disagree. I just gave it a try on a desktop (!) browser – when switching from the thread list into a particular comment thread, "new" reddit is definitively slower than old.reddit.com, both visually (after the thread page as such displays, it spends another second or two loading the actual comments, whereas on old.reddit.com everything renders instantly), and measured end-to-end (from clicking on the "comments" link to the moment the comments actually appear) as well.
On my underpowered phone, "new" reddit fares even worse, and never mind all that additional "you can only view this in the app"-crap that was thankfully never backported to old.reddit.com.
It was a tongue-in-cheek suggestion but page reloads are pretty fast these days with http/2. Maybe there's ways of submitting a form in the background for the same effect, no reload needed! now we're surfing.
Can't you redirect/store the information in the URL and then somehow read the URL data in CSS?
I stand corrected.
I did not recognize the [-] as it looks like some weird emoji on my mobile browser due to the too small and uncentered background.
I did not recognize the [-] as it looks like some weird emoji on my mobile browser due to the too small and uncentered background.
[deleted]
What innovation do you have to make a moderator's job easier?
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 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.
Currently there aren't many moderation features - only banning and removing threads & comments are implemented right now. Registrations can be disabled by the admin.
I will definitely focus on having good moderation features as I also believe it is essential for a healthy forum.
I will definitely focus on having good moderation features as I also believe it is essential for a healthy forum.
Looks great. If you wanted to extend it with JS, HTMX or lightweight functions easily added to Flask, which is imho the right way for CRUD.
And specifically, looks great - clearly outlined, threaded, indented, flow of conversation.
And specifically, looks great - clearly outlined, threaded, indented, flow of conversation.
Out of curiously, does HN use JS heavily? It feels quite lightweight, and it’s sort of a forum
Very sparingly: https://news.ycombinator.com/hn.js
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'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.
And all of it is optional. You can do all operations (readinig, posting, commenting, voting, flagging) with JS disabled, you just get page loads rather than dynamic updates.
Thanks for sharing this. I've been writing my own simple websites for a couple years now and I really like seeing what other people have done. Sometimes I learn better ways to do things, and sometimes I realize what I did was perfectly acceptable.
Please accept my sincere respect. I have been trying to create a blog of sorts with no or clear degradation upon no javascript myself, but I am not much of a UI expert and have failed to make my UI good looking.
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.
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.
Performance is pretty good: CPU usage has so far not been higher than 2.5% and is usually <1% on a single core of a 3900X. Currently 192MiB of RAM is used (162MiB by systemd-journald, 4x 37MiB + 22MiB for the workers according to htop).
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'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.
Looks nice! But as with any 2022 project that publishes user input, please put a section in the README describing counter-abuse and moderation features, even if (especially when!) there is none. Here it seems there is an easily defeated captcha.
It's absolutely beautiful. Within a fraction of a second, I knew what it was and how to use it and how much value it has.
This is a cool project! One small suggestion: the native blue links for the author name, "thread", and "reply" make the content hard to focus on as the UI is quite intrusive. HN solves this quite well with a colour scheme that has the comment content as the most prominent element in a thread.
Love the HN-like design. How do you handle big threads and many nested replies?
Currently not at all. All comments in a thread are loaded.
I do intend to add pagination but I'm not sure what a clean implementation would look like.
I do intend to add pagination but I'm not sure what a clean implementation would look like.
I thought for a minute this was going to link to news.ycombinator.com!
HN is not "no-JS web forum software".
Refreshingly simple. I'm so tired of JS bloat.
[deleted]
IMHO one of the best features a modern web forum sw can provide is browser notifications
May I recommend an ORM for any such project? hand rolling SQL statement aren't going to scale.
Here's my shameless plug: `pip install sqlitedao`: https://github.com/Aperocky/sqlitedao
Here's my shameless plug: `pip install sqlitedao`: https://github.com/Aperocky/sqlitedao
Not trying to bash your ORM as it could have a great translation layer to make optimal queries.
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?
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?
A well thought out ORM would consider for performance, obviously if you're just retrieving a particular string then manual SQL might have a few times speed lead.
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.
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.
My experience is the exact opposite.
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.
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.
On a personal and professional level it has been the opposite case for me.
I get the impression that OP's project is not aiming for scale.
Thanks for this interesting information!
In addition to addressing the needs of your organization, custom software can also help you generate revenue through licensing. Whether your company is in need of a consumer-focused application or a business-to-business solution, i3solutions will help you design and develop the solution that will help your business grow. They will conduct interviews with your team and stakeholders to determine your needs and identify potential opportunities. They will then develop a project roadmap and risk management strategy https://mlsdev.com
Nice! I built one with Flask as well :-)
Oh my god, this looks so sane.
Very fast. Really like it.
is it missing captcha ?
Has a CAPTCHA but it can be solved pretty easily (paste into Dev Tools console)...
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);Very nice work.
very cool forum
Wonderful job!
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.