NodeBB + ReactJS
youhosi last edited by
What do you think about moving the entire NodeBB view to React? And yes, the view layer is separated from the server and everything communicates via the API. Creating styles in ReactJS is much more modern and exciting
@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.
- 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