NodeBB + ReactJS
-
@youhosi Everything is available as an API endpoint already, e.g https://community.nodebb.org/api/topic/14371/nodebb-reactjs and then you have the write api to write to db. So it shouldn't be hard creating a client in React.
Any specifics why you think it would be better to go with react?
-
To give you a little bit of history...
@youhosi -- no, we explicitly made the decision to not use a framework for our frontend because we as developers were trained in an era when client-side frameworks did not exist.
However, in hindsight this decision ended up being quite advantageous for the following reasons:
-
Speed at the expense of convenience
- You will always find that framework-less websites and web apps are much faster than ones using frameworks. My belief is that this is the case because frameworks need to broadly apply to as many use cases as possible, and this necessitates a significant amount of excess code that slows down the application.
- NodeBB prioritises speed. You can see it in our time-to-first-paint and page transition speeds. The fact that we're a heavy (relatively, anyway) javascript app is already enough of a handicap. We have no intention of slowing things down further with additional client-side code to support a framework
- We use BenchpressJS for our front-end templates, which is highly optimized and efficient, against at the expense of more esoteric logic. However, we find this is a good balance of speed vs. convenience. Thanks to @PitaJ and @psychobunny for putting in the legwork to create our templating system!
- We also use jQuery to ease client-side development.
-
There will always be developers who can code in a framework-less style, and we do not see this going away any time soon.
-
Frameworks come and go, but our code will always be more-or-less up to date and supported.
- For example, could you imagine if we wrote our app in Angular 1 (which was all the rage at the time)? We also considered using MooTools instead of jQuery, which is pretty much defunct now. Every time a dependent framework goes, the developers leave for greener pastures (see point 2), and you'll be stuck with a codebase that needs rewriting.
All of the above points are open for debate (and I do encourage it here), but this is our thinking as of this moment
-
-
I am now wondering why frontend like React is even needed. Usually React is well-known to works well with node.js backend and allow us to experience smooth web performance because React doesn't re-render whole page newly like refresh since it only modifies virtual dom. But since Node.js itself seems like being able to modify virtual dom without completely re-rendering whole page like old forum softwares do (xenforo, phpbb and so on). I haven't seen nodebb re-render whole page per each page (url) change request, rather it re-render only the parts needed.
-
@noob111 the main benefit of React is not really performance. The benefit of React and other frameworks is that it separates your UI into individual composable components and allowed you to easily define them in a declarative fashion. Those features of that kind of framework allow for much easier development.
-
@julian this post is the reason I didn't use nodebb when I was evaluating frameworks last year, and I've linked other people to it.
This is a bad design decision with graybeard logic. DX is always the main pain point and driver of third party contributions, not premature optimization.
React, for example, has eaten the world and birthed many alternatives with similar ergonomics, smaller footprints and faster renders. Meanwhile nodebb is using... jQuery and BenchpressJS? Oof.
Lastly, I was also "trained in an era when client-side frameworks did not exist"; it is not a flex to refuse to grow with the times. This is like saying you were raised in a barn so don't know how to shower. These architectural decisions have surely been a deterrent for adoption for many others.
-
Thanks for commenting!
@Henryk said in NodeBB + ReactJS:
React, for example, has eaten the world and birthed many alternatives with similar ergonomics, smaller footprints and faster renders.
I'm going to have to ask for citations there.
Saying react is small footprint or faster than handwritten js and benchpress is ... a laudable claim. I'd love to see it backed up.
-
@Henryk said in NodeBB + ReactJS:
it is not a flex to refuse to grow with the times. This is like saying you were raised in a barn so don't know how to shower.
Never said this was a positive thing. Just stating facts. It provides context as to why I believe what I say, even if erroneously.
All of my justifications could even be the case because they were applied ex post facto
-
@Henryk said in NodeBB + ReactJS:
React, for example, has eaten the world and birthed many alternatives with similar ergonomics, smaller footprints and faster renders. Meanwhile nodebb is using... jQuery and BenchpressJS? Oof.
I mean, NodeBB is slowly moving away from jQuery, but the issue is the plugin ecosystem - removing jQuery would be a very breaking change, much, much bigger than the move from less to scss (since most plugins would still at least work even with their css broken, and most of the time the transition didn't actually require rewriting anything unless one was using more advanced features). I suspect it'll end up moving to something like cash at some point.
And I suspect you're confusing Benchpress with some other templating engine, since (which has both positive and negative aspects) it's basically used only by NodeBB and tailored towards it. It's a tiny and from what I've seen fairly well optimized templating engine - I suspect it'd be faster than react for templates just because it's significantly less complex.
I honestly imagine that if NodeBB was written, or fully rewritten, now it'd be using some framework, likely React/Preact. But the issue is that when you have a long-lived codebase with existing ecosystem the benefits need to be much larger than for the initial choice. Because even with diminishing returns on smaller improvements, the required amount of work makes it hard for a rewrite to beat them, much more so if the changes will require more changes by third party developers too. And you still have to ask yourself if working on DX and performance is worth the opportunity cost, or maybe it's "good enough" and you should focus your efforts elsewhere.
It's annoying, and if I had the time and will to develop forum software from scratch my tech stack would look different than NodeBB, but as with many things it's only easy on the surface and I still prefer the way NodeBB is built to php of Flarum (also - they're an example of an early framework bet that didn't work out ecosystem-wise, since mithril ended with a far smaller community than React and has gone through a few periods when it had years between new releases) or the weirdly dockerized Ruby on Rails w/ ember.js that Discourse uses.
I may not be a big fan of jQuery, but at least even when writing for core I have the choice of just not using it and going with modern JS instead. -
T the skyfoxx referenced this topic on
-
@crazycells I have the desire, but I need a lot of time to make it a separate plugin, now everything is strongly tied to the theme. Alas no free time right now
but someday I think I'll do it
-
Are nodebb + nextjs compatible?
When developing nodebb custom plugin or custom theme, is there a way to make nextjs compatible?
reactjs is client side rendering, and nextjs is SSR, so when considering seo, it must be developed with SSR.
These days, many of the web developers being hired use nextjs as a basis for development, so we are also developing web using nextjs.Of course, I know how to use bootstrap + jquery tpl express. But these days, people who are beginners in web development are more familiar with nextjs.
-
@루루 said in NodeBB + ReactJS:
Are nodebb + nextjs compatible?
Is anything Nextjs compatible? lol
Unless Nextjs has changed in the last 3 months, it is super complicated to work with. Even then you have to use it on Vercel to have any hope of it working, as using Nextjs on another host is even more problematic.I'm waiting for someone to tell me my past experiences are no longer valid?
On the wider-point of de-couplement, then yes, modularity is a good principle to aim for. Im not a CSS fan so a year ago I did try making a pure js front end using nodebb API as a backend!
Unfortunately that project went by the wayside as it was a lot of work! -
@eeeee Did you fail while trying to deploy nodebb on vercel?
=> You used only the backend function of nodebb, but is there a reason why it failed in the end?
I tried to do that (nodebb backend + nextjs 13). So, I would appreciate it if you could tell me why it failed.https://vercel.com/guides/using-express-with-vercel
I understand that deploying a general nodejs application such as express in a vercel environment is not easy. Functions that require allocating IO for a certain period of time, such as [websocket, database connection], require special processing suitable for serverless functions.
Since edge function-serverless functions have all of these characteristics, I know that it is not easy for developers to develop them.
I'm also using strapi, but I couldn't distribute it on vercel.The site I am currently running is made with nextjs 13, and is distributed using [google cloud run for the API server and aws amplify for nextjs].
Nextjs Logic is not being developed to handle complex server logic such as API logic.We are still considering exactly what to do with nodebb, but we plan to use nodebb hosting or self-hosting using google cloud run.
How to Deploy an Express.js Application to Vercel
Learn how to use Express.js in a Serverless environment.
(vercel.com)
-
I think you answered my point, by agreeing there are issues.
I didn't even attempt to deploy nodebb, I had problems with much smaller projects!
Nextjs routing was going through a change of design at the time, so perhaps that is less confusing now, but there were multiple other headaches. I would get build errors and issues with package management.
any plan to make a "kanban board" plugin? 
