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

Alpha1

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:
Kier said:
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.
Click to expand...
@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.
 
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.
 
briansol said:
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.
Click to expand...
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.
 
@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 ?
 
InfernoDev said:
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
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top Bottom