Skip to main content
Topic: If I was building a new forum software today... (Read 73 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

If I was building a new forum software today...

I've thought about what it would look like if I were to build a new forum application many times over the years. Every time I think I learn something new and add or remove some ideas from my previous thoughts. I have no intention of creating something new, but if I were this is what I think it would look like...

Built in Javascript Typescript
It's not that I think Javascript is a great language because I don't. I think the lack of types makes it hard. Typescript adds something there, but it's not true type safety. You only get so far with it.

What I like about JS/TS is that I can write isomorphic code, any frontend developer can read most of the backend stuff, and there's a package to do everything. The last part might not be a good thing, but for someone looking to bootstrap something quickly, they can just pick one and be on their way.

I'd use React + Redux and all of the great things that go with that. There would be server-side rendering. I'd require JS for any interactions but since the site is server-side rendered, a user wouldn't need it to display public content.

I could do so much with caching and an ORM since the Node process would build when it starts and wouldn't have PHP's awesome (and sometimes horrible) "know nothing" startup.

Mostly static
Most pages would be static with only user-specific content (login state for instance) and actions (post, reply, moderation, etc) having to be generated. The entire public-facing site can be static with those pieces loaded dynamically. That means it could all be pushed to a CDN.

If you make a change to the theme, it would flush that cache and start recompiling all pages. A separate process would build them or when a user visits a page that wasn't already built. You might even be able to host a whole forum on Github.

Any posts that aren't accessible to all would be served after authentication and authorization, but they would be injected onto a page and would be cached.

Microservices
It is hell to setup, but once you do, you can run a massive forum using AWS Lambda functions and not have to worry about scaling it up/down. So long as your code is written as many microservices. I'd probably tie it all together with a message queue. A user wants to see the post they made after they made it, so I'd probably cache that locally until the MQ caught up with actually posting it.

GraphQL
Much of the site would work using GraphQL. With all of those microservices, you want to have a layer that will grab the information without returning too much. This is extremely important for low-bandwidth devices.

WebSockets
On a busy site, I always feel like I'm missing something because I have to keep refreshing the page. I feel like a WS would help me with notifications. Also, I could run all of the GraphQL queries through it. I could also use this to track where I left off in a conversation.

More like Slack with rich text than email
I want a site that feels like a lot of little conversations going on. I'd probably have a bar on the left with conversation I'm participating in. When someone replies, it would show a number of the replies since the last time I saw it.

I want to be able to compose messages like an Office document though. I used to hate the WYSIWYG editors. Now I value my keystrokes and want to save myself from having to type out the characters. I want the Word or Google Docs editor. I want my posts to have the structure that HTML has provided.

PWA
Progressive Web Apps are the new hot thing and for good reason. I think forums fit perfectly with them: long conversations that may be read and responded to on mobile at varying times. I'd love to be able to start reading a topic on the train, then reply to it while without an internet connection, but have it upload when I do. I think a shortcut for my favorite forum on my mobile home screen would help me read it much more often.

Material Design
I am only using it as an example, but I want to highlight a lot of the UX research that companies like Google, Microsoft, and Facebook have done.

So much more
There's so much more I'd do, but it's late. Maybe I'll write more later.
I am currently doing freelance work. If you need coding help, forum help, or server maintenance, shoot me a PM and let me know.

Re: If I was building a new forum software today...

Reply #1
Quote
I used to hate the WYSIWYG editors.
I still hate pretty much all of them except for Lynx and LibreOffice Writer. Word used to be okay back in the '90s when it still did styles properly. Where by properly I mean it didn't do things like creating new styles more or less at random.

But this isn't really WYSIWYG/WYSIWYM vs source. "Intellisense" and any half-decent HTML/XML editor take away most of keystrokes. And here on Elk a shortcut like Ctrl + i doesn't care. In WYSIWYG mode it makes text italic; in manual mode it sticks the BB code around it. There are better and worse editors for any mode.

I do think BB code is to a large extent extremely stupid. Properly sanitized HTML is much better for all of the basic stuff. It's redundant.

I'd use CommonMark (with an optional WYSIWYM GUI).

Quote
Progressive Web Apps are the new hot thing and for good reason.
New? We all played around with that stuff well over a decade ago, except then they were called things like widgets. ;) Which finally culminated in this standard by ~2011: https://www.w3.org/TR/widgets/

Of course things are better with Service Workers but that's all "PWA" means anyway. Web manifest (like a widget manifest, but directly for the page), push notifications (hate, death stare), service workers (neat), responsive web design (ancient although for some reason only mainstream post-iPhone), etc.

Quote
I am only using it as an example, but I want to highlight a lot of the UX research that companies like Google, Microsoft, and Facebook have done.
Facebook A/B tests what keeps people on their page the longest (i.e., what makes them the most addicted). I propose that their main interest is a showcasing of stuff I want to avoid. Also I can barely manage to find anything on Facebook. I spent over 10 minutes trying to find a post from one or two years ago recently. It's worse than useless: it's actively hostile.

Microsoft is infinitely more interesting, but somehow they still ended up with a Windows 10 where you can't tell an active window from an inactive window.

Google actually feels like they improved by leaps and bounds since ~2010 in UX, although I've stopped using their (former?) main product, the search, because it's just plain terrible these days. The UX doesn't matter if it doesn't work. Google Scholar and Google Books have much worse UX but they work.

Not trying to argue too much; just sharing my thoughts. ;)

Re: If I was building a new forum software today...

Reply #2
@Frenzie widget != PWAs. PWAs are much more than just frontend injected "blocks". Offline support is necessary for it to be called a PWA. It's actually the first thing in the PWA checklist.
I am currently doing freelance work. If you need coding help, forum help, or server maintenance, shoot me a PM and let me know.

 

Re: If I was building a new forum software today...

Reply #3
@Frenzie widget != PWAs. PWAs are much more than just frontend injected "blocks". Offline support is necessary for it to be called a PWA. It's actually the first thing in the PWA checklist.
I don't understand what you're trying to say given that I already explicitly mentioned Service Workers as a means of facilitating this stuff much more efficiently. The only meaningful distinction between a widget and an installable webpage is that widgets require separate bundling, which is a very nice thing to get rid of. Most of the pieces for that were in place by 2010, except for Service Workers. The suggestion that there's something about widgets that prevents them from working offline and syncing up seems rather odd to say the least. Just look at these widget docs from '06:

Quote
Developer tips
  •     Do not reinvent the wheel: Use the libraries provided by Opera
  •     Limit the size of your widgets
  •     Keep your widgets simple
  •     Write efficient code
  •     Widgets should not stop working when the user is offline
Particularly note the last item on the list.

This is when widgets were just chromeless things; we didn't yet have application widgets more similar to Electron like a couple of years later. (A few years later still Mozilla introduced their Desktop Apps. I preferred XULRunner or whatever it was called.)

You might mutter some protest about semi-proprietary open technologies, but that's called Chrome. :P But it's certainly true that since 2017 all of this is less problematic than ever. But it's not so much hot and new as ffs I had all of this in 2010 and then they took it away from me. :D