Should XenForo switch to Node.js or similar for a modern live responding interface?

Alpha1

Well-known member
Forum users are also social media users and are therefore used to live interaction of the interface. i.e. you see whats going on now and the page will live refresh when there is anything new happening. Not offering such features means offering a stale outdated experience compared to social media. PHP is not up to the task and requires huge resources. @Kier explained this here:
Just a note about this add-on - while the functionality is excellent, the requirement note about needing a dedicated server is absolutely right due to the nature of PHP itself.

The comments here about there being a memory hole are correct in their observation of huge amounts of memory being consumed, but it's not due to a bug, it's due to the fundamental way PHP operates, in that it expects to consume huge amounts of resources for a very brief moment, then release those resources ready for the next request. Websockets expect to start up the application then hold it in a suspended state waiting for an event trigger to allow it to release its payload - which is fine for a very light app running on node.js or similar, but it's not really the expected use case for PHP with Apache/Nginx.

So, by all means enjoy the great features from this add-on, and well done to @DimmmCom for putting it together, but do bear in mind that for a busy site, this is going to require epic amounts of resources through no fault of the author.
@Kier 's comment here leads to my question:
Is PHP unfit for purpose considering the end users expectations of a modern live responding interface?

In Next.js, building a fast, mobile-perfect, "app-like" experience is the default standard. Its fast and offers flexibility.
NodeBB uses Node.js and big boards on NodeBB forum software are quite fast compared to PHP.

Should the XenForo team consider to switch to Node.js/Next.js stack (React) or similar to modernize the software interface? Or are there significant downsides of doing so?

I'd love to read opinions on this.
 
Biggest downside with Node-based stacks is you then eliminate a lot of affordable hosting options (most shared web hosts don't allow you to run Node.js).

LAMP stacks may not be the most bleeding edge or fastest, but they are the most widely-supported, and can be pretty easy to maintain too relatively speaking.
 
If i were to do it from scratch today, backend would be python/fast-api approach with a front end running react/next/vue/etc/etc of the day.

That said, state is hard, and makes search engine optimization harder.

When's the last time you saw a facebook thread rank in a search? never...


php can do the api backend. In fact, xf has it built in already and everything could have an api function equivalent. you could easily render a custom addon to return response json instead of render the template.

hosting shouldn't cost more based on stack choice. it should come empty and cost the same.
if your host costs more to install free open source software, you're on the wrong host.
 
You don't need node.js to do this.
It's completely possible to continue using PHP.

PHP is faster than javascript when you use something like swoole to enable async behavior.
You can do async behavior with PHP without swoole, but it's more difficult.
 
hosting shouldn't cost more based on stack choice. it should come empty and cost the same.
if your host costs more to install free open source software, you're on the wrong host.
It shouldn't, but it does. For a variety of reasons, but in regards to shared hosting, security, server load, and overhead for maintenance are big ones.

Not saying PHP is better at those 3, but we've got easy, established methods for managing them on shared hosting infrastructure that already exists.

I'm sure at some point it'll change - my personal site web hosts allow for Node apps on shared hosting, for example - but a lot of major ones still don't last I knew.
 
A pure PHP backend can be retained by using a WebSocket API.
I tried all the real-time add-ons for XenForo, and the most lightweight and stable WebSocket backends are
  • Soketi
  • Centrifugo
 
Threaded replies looks ugly.
You only gotta look at vBulletin, proboards, and many others that have it.
But if @Kier says he wants them then i guess it will be ok if he knows that language to set it up correctly.
Coding means programming languages are being used.
 
@Alpha1 said: "the page will live refresh when there is anything new happening"

Live Threads exists, this seems to be an option as well, in a forum I frequent via Websockets Recent posts appear at the end of the thread every X seconds so you don't have to refresh. It works fairly well. a manual [Refresh] button at the end of the thread might be just as good.

TipTap seems like it might support collaborative real time multiuser page editing (Similar to Google Docs) which is something I want. Pretty sure you would need Websockets for that.

Real time threads, chat, what's new, seem like uses ... any others ?
 
I would also think the hosting would be an issue especially for a larger site but would think a supabase and firebase stack would be on the cheaper side
 
I would also think the hosting would be an issue especially for a larger site but would think a supabase and firebase stack would be on the cheaper side

Substantially more expensive than running localhosted mysql and also, you got added network latency ahead of every database call, so now your application is going to run slower.

Even in a best case situation where you're on AWS and you have a remote mysql database in the same datacenter, you'll see 2-3ms of added lag.. since SQL calls are rarely paralellizable/async-able.. the more database calls, the more latency.
I've seen this add up to a 25-33% performance loss in a few applications.

With a remote database not in the datacenter, the per-call latency ( supabase, etc ) will be substantially higher.

And maintaining a localhosted database is not hard whatsoever.. just run regular OS updates and that's all that's necessary. It's the easiest part of maintaining a LAMP stack and you will easily achieve higher uptime than any remote hosted provider.
 
Back
Top Bottom