Node.js vs React: What are the differences?
Node.js and React are both open source tools. It seems that React with 132K GitHub stars and 24.5K forks on GitHub has more adoption than Node.js with 35.5K GitHub stars and 7.78K GitHub forks.
According to the StackShare community, Node.js has a broader approval, being mentioned in 4104 company stacks & 4042 developers stacks; compared to React, which is listed in 3224 company stacks and 3094 developer stacks.
I'm trying to build a demo app to show an image, and it's metadata (EXIF data or read relevant image data from XML/DB). I need to display the image and data side-by-side. As a novice web developer, I am trying to understand what tools to pick, so it's easy to develop, maintain, and at the same time, it performs well for a huge volume of images display (something like picture/file gallery). We also want to offer one-click on one file/picture that needs to be shown in a split view. Please advise and let me know if my problem statement is unclear.
Thank you. SSK
You need to decide if this is a demo app or an app which you'll want to scale and maintain. For a quick demo, I would spin up a Node.js server with server rendered frontend using Handlebars template. This way, the whole project can be maintained in one repository without much moving parts.
If you are extracting data from image itself and not from a database, you wouldn't even need Node.js. Just a React app will do. Data extraction from image can be done on client side.
I will be programming my project in the coming months. I would need advice on the technology I will use.
I focus mainly on mobile apps, so it's clear there that it will be a native app written in Kotlin.
I will also need a backend (database, API). In the database, I will need to store words and their translations along with users and some statistics to start with.
I don't know which database to choose, whether NoSQL or SQL. Maybe NoSQL would suffice for some words and key-value data.
With that backend, I have a dilemma as to which framework to use. Basically, it will be such a new for me, I just played with Flask a little bit, but It doesn't matter. Basically, everything runs on JS except the Android app. So is it advantageous to choose Node.js on the backend? I have no experience with this, is it an advantage when everything runs in almost one language? I also thought about Flask / Django, but I also quite like Node.js since it's in JS. But I'm open to all the possibilities of .NET, Spring .... What would be your choice?
I'll write everything myself, it's a project for school, but I want to move it to a higher level and release it. If it doesn't work out, at least I'll learn something. Thank you for the answers.
Let's start with the database. First, in my experience, there are few applications where choosing a document database (NoSQL) over a relational database (SQL) is advantageous. While document databases are conceptually very straight forward, I find the tradeoffs down the road are simply not worth it (I wont get into all the details here, but please do some research on the downsides of NoSQL databases). If your data storage needs were exceedingly simple, I might reach for something from the Google Firebase suite, Realtime Database or Cloud Firestore; but I find even simple storage needs tend to expand and grow over time as your application matures. Postgresql is an excellent choice, and an absolute powerhouse for a ton of applications. With the somewhat recent additions of hstore, json, and jsonb datatypes, the advantages of reaching for a pure document datastore melt away.
For the Chrome extension, I would probably favour going for something a bit more lightweight than React or Angular. I'm a huge fan of React, but it comes with a somewhat hefty download, so if it were me, I might reach for Vue instead on that one. React is better for bigger, more complex single-page applications, whereas Vue is probably a better fit for simpler applications which require a smaller set of components.
But, let me change my tune a little bit. You mentioned that this is a school project. In light of that fact I suggest you gravitate towards languages and frameworks that will help grow your career. Making smart choices based on the requirements of the task at hand is always prudent, but in this case I think it may be more valuable to gain some experience with some of the current "industry standard" stacks. Ask yourself what you can build a career on, and dabble in some of those areas until you find something that clicks for you. So, here are my revised answers, with options for each category ranked in order of preference
- Database: PostgreSQL, MySQL
- Backend: Node/Express, Rails, Django, Spring
- Frontend: React, Angular, Vue
Hi Karin, I really liked your take on this whole school thing, I'm amazed you want to put such a huge effort in it.
And please appreciate your project is a lot to take and it can also be a lot to do: the risk is going beyond the assignment for the sake of exploring technologies, architecture styles, desing patterns, and so on, just for the sake of it (don't take me wrong, I've done it all my life).
So my first advice, as quite an experienced software developer, is always go back to some fundamental principles before starting anything, before thinking to anything, and perhaps the most important principle of all is KISS: Keep It Simple and Short (search it up, there are a few versions of what those letters represent :) ). In your case, since it's a school assignment, simplicity is even more important because it makes things clear which makes learning so much more effective.
When dealing with complex tasks like this, another fundamental element is focus: where should you keep your attention when designing and then developing a software product?
In this specific case, I lack what the original assignment was requesting, but I'm quite sure the point (or one of the points) was to make you think and then act on something that didn't require months to be developed, it was to make you learn how to accomplish a task without getting lost in details or in a project too big to be finished in a finite time.
I may be wrong, but I'll keep this in mind when writing the below lines.
FIrst, the architecture of the software product looks like a classic three tiered one: frontend, backend, database. Keep in mind another fundamental principle here: the separation of concerns, which leads to different decoupled architectural elements. Also, just for clarity, the frontend(s) will talk only with the backend, while the backend will talk with the database: this will help you isolate the database from the frontend, ideally enabling you to change database technology if needed.
Second, you explained you want to go web and mobile for the frontend tier: this inevitably will lead you to the conclusions you pointed out correctly, having to choose a number of platforms and languages to basically create the same application, but the fragmentation of different knowledge and procedures can make your life quite complicated and probably miserable.
On the database tier, remember NoSQL databases can be quite powerful, but in your case try something very simple (redis can do), or just go with MongoDB as it makes easy to start and evolve your data structures. If you're more the structured type and you want to go RDBMS, try postgresql, it's easy to start (it has also NoSQL features) but so much more powerful and you could learn real SQL on it (stay away from the omnipresent MySQL, it's kind of odd sometimes).
I hope the above didn't sound too much of a lecture, and I also really hope you learn the most important lesson of all: always keep in mind the big picture!
I'm researching what Technology Stack I should use to build my product (something like food delivery App) for Web, iOS, and Android Apps. Please advise which technologies you would recommend from a Scalability, Reliability, Cost, and Efficiency standpoint for a start-up. Here are the technologies I came up with, feel free to suggest any new technology even it's not in the list below.
For Mobile Apps -
- native languages like Swift for IOS and Java/Kotlin for Android
- or cross-platform languages like React Native for both IOS and Android Apps
For UI -
For Back-End or APIs -
For Database -
- Cloud Firestore
My Recommendations: Front End: Flutter because of developer tooling and powerful declarative widget system Back End: Node.js or Go because Node.js has a large ecosystem and Go has a good built in http setup Database: Cloud Firestore because of ease of use, NoSQL, and the ability to set data from the client
Considering that your objectives are Scalability, Reliability, Cost, and Efficiency, I recommend the following:
- Backend - Node.js/Express/MongoDB
- Frontend - React
- Mobile - React Native
Flutter is a new sparc out there, because it's Dart engine can run server-side, client side (as web app) and natively - it cross compiles to all major platforms from single codebase...
I'm currently working with React and I would recommend you because it will help you develop both web app and similar to React is Reactive Native which will work mobile devices. And with these frameworks, I will choose Node.js in the backend. In DB, I have experiences with MySql and MongoDB. I think you should go with MongoDB, it will help out with its cloud service also. Happy Coding!😀🤩
We thought about creating a web application for a long time, but came to the conclusion that it is better to create an adaptive site with PWA technology. This will save your budget and speed up updates (you won't need to update 3 versions of apps for different platforms, just the site). In addition, research on the preferences of smartphone users suggests that users are not very willing to install new offers for reasons of personal data security. Sites that work through the browser are more trusted.
It was easier to find people who've worked on React than Vue. Angular did not have this problem, but seemed way too bloated compared to React. Angular also brings in restrictions working within their MVC framework. React on the other hand only handles the view/rendering part and rest of the control is left to the developers. React has a very active community, support and has lots of ready-to-use plugins/libraries available.
It is a very versatile library that provides great development speed. Although, with a bad organization, maintaining projects can be a disaster. With a good architecture, this does not happen.
Angular is obviously powerful and robust. I do not rule it out for any future application, in fact with the arrival of micro frontends and cross-functional teams I think it could be useful. However, if I have to build a stack from scratch again, I'm left with react.
We actually initially wrote a lot of networking code in Kotlin but the complexities involved prompted us to try and compile NodeJS for Android and port over all the networking logic to Node and communicate with node over the Java Native Interface.
This turned out to be a great decision considering our battery usage fell by 40% and rate of development increased by a factor of 2.
Sign up to add or upvote prosMake informed product decisions
Sign up to add or upvote consMake informed product decisions
What is Node.js?
What is React?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Red Hat, Inc.
I have benchmarked Node.js and other popular frameworks using a real life application example. You can find the results here: https://firstname.lastname@example.org/web-rest-api-benchmark-on-a-real-life-application-ebb743a5d7a3
Before two weeks ago or so, it used to be Backbone views and models, and everything was on our main store app, and our mobile web app, but actually, we just switched our mobile web app to using ReactJS for the interface. So it’s using Backbone models but ReactJS front-end components. Really, it was borne out of the frustration with how the Backbone model-view bindings worked, and it wasn’t especially performant for large views, and we had to do lots of tricks to make it performant. But swapping that out with React views meant that it could be both simpler and faster without having to spend a lot of time on that.
One other interesting thing about that is, since React actually works okay with the Backbone models and the Backbone router and stuff like that, we didn’t have to rewrite the mobile web application and update it to ReactJS. Rewrites are almost always a bad idea. We were able to upgrade pieces of it at a time, move on to React, and now the entire thing is using React and just has the Backbone router and models and stuff like that that we already had, so it's a lot faster.
We decided to move the provisioning process to an API-driven process, and had to decide among a few implementation languages:
- Go, the server-side language from Google
We built prototypes in both languages, and decided on NodeJS:
- NodeJS is asynchronous-by-default, which suited the problem domain. Provisioning is more like “start the job, let me know when you’re done” than a traditional C-style program that’s CPU-bound and needs low-level efficiency.
- NodeJS acts as an HTTP-based service, so exposing the API was trivial
Getting into the headspace and internalizing the assumptions of a tool helps pick the right one. NodeJS assumes services will be non-blocking/event-driven and HTTP-accessible, which snapped into our scenario perfectly. The new NodeJS architecture resulted in a staggering 95% reduction in processing time: requests went from 7.5 seconds to under a second.
At the beginning of last year, Netflix UI engineers embarked on several ambitious projects to dramatically transform the user experience on our desktop and mobile platforms. Given a UI redesign of a scale similar to that undergone by TVs and game consoles, it was essential for us to re-evaluate our existing UI technology stack and to determine whether to explore new solutions. Do we have the right building blocks to create best-in-class single-page web applications? And what specific problems are we looking to solve? Much of our existing front-end infrastructure consists of hand-rolled components optimized for the current website and iOS application. Our decision to adopt React was influenced by a number of factors, most notably: 1) startup speed, 2) runtime performance, and 3) modularity.
React has exceeded our requirements and enabled us to build a tremendous foundation on which to innovate the Netflix experience.
The server side of Trello is built in Node.js. We knew we wanted instant propagation of updates, which meant that we needed to be able to hold a lot of open connections, so an event-driven, non-blocking server seemed like a good choice. Node also turned out to be an amazing prototyping tool for a single-page app. The prototype version of the Trello server was really just a library of functions that operated on arrays of Models in the memory of a single Node.js process, and the client simply invoked those functions through a very thin wrapper over a WebSocket. This was a very fast way for us to get started trying things out with Trello and making sure that the design was headed in the right direction. We used the prototype version to manage the development of Trello and other internal projects at Fog Creek.
All backend code is done in node.js
We have a SOA for our systems. It isn't quite Microservices jsut yet, but it does provide domain encapsulation for our systems allowing the leaderboards to fail without affecting the login or education content.
We've written a few internal modules including a very simple api framework.
I don't know how well this will scale if/when I have hundreds of people connected simultaneously, but I suspect that when that time comes, it may be just a matter of increasing the hardware.
Used node.js server as backend. Interacts with MongoDB using MongoSkin package which is a wrapper for the MongoDB node.js driver. It uses express for routing and cors package for enabling cors and eyes package for enhancing readability of logs. Also I use nodemon which takes away the effort to restart the server after making changes.
Web-frontend programming prior to React: like banging rocks together. With React: Like wearing fusion powered underwear. Gives you a nice warm feeling. Using React for Cloudcraft.co allowed us to create a beautiful UI in record time (1 month start to launch), with virtually no bugs popping up during development. The functional approach to just rendering your component given a state just makes so much sense, with React figuring out the delta between your current and desired representation. It's the future kids!
React is choice number 1 when it comes to JS development at Kurzor. We choose React because it solves many issues with web applications in a elegant way. Writing an app in components is useful for coordination and isolation of concerns. React forces you to abandon state and use vertical passing through props instead. And having as many Pure Components as possible helps to write cleaner code.
With React we usually use: Redux, React Router, React Toolbox, Styled Components.
This is the best component framework and API available today for building modern web sites and apps. I really enjoy how minimal it is, and powerful at the same time. It removes opinionated development and replaces it with logic and data philosophies, which has in turn fostered a robust and lively code and support community.