ExpressJS vs React: What are the differences?
ExpressJS and React are both open source tools. React with 132K GitHub stars and 24.5K forks on GitHub appears to be more popular than ExpressJS with 44.6K GitHub stars and 7.48K GitHub forks.
Airbnb, Uber Technologies, and Facebook are some of the popular companies that use React, whereas ExpressJS is used by Twitter, Intuit, and OpenGov. React has a broader approval, being mentioned in 3224 company stacks & 3094 developers stacks; compared to ExpressJS, which is listed in 854 company stacks and 790 developer stacks.
What is ExpressJS?
What is React?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
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
Recently I have been working on an open source stack to help people consolidate their personal health data in a single database so that AI and analytics apps can be run against it to find personalized treatments. We chose to go with a #containerized approach leveraging Docker #containers with a local development environment setup with Docker Compose and nginx for container routing. For the production environment we chose to pull code from GitHub and build/push images using Jenkins and using Kubernetes to deploy to Amazon EC2.
We also implemented a dashboard app to handle user authentication/authorization, as well as a custom SSO server that runs on Heroku which allows experts to easily visit more than one instance without having to login repeatedly. The #Backend was implemented using my favorite #Stack which consists of FeathersJS on top of Node.js and ExpressJS with PostgreSQL as the main database. The #Frontend was implemented using React, Redux.js, Semantic UI React and the FeathersJS client. Though testing was light on this project, we chose to use AVA as well as ESLint to keep the codebase clean and consistent.
I found Heroku to be a great option to get ExpressJS up and running with very little hustle. The free tier is great, but I'd recommend to set up a cronjob to visit your site every few minutes so that the server stays awake. Netlify was the option to host the front-end because doing the server side rendering on #Heroku would have taken a little more time than I'd like to. For the moment pre-rendering the app with prerender-spa-plugin is enough to help with #seo. Puppeteer was my choice over other options because it made it easier to scrape websites made on ASP.NET which is what I needed in this case. And Vue.js is my top choice at the moment because it's really beginner friendly and it has a lot of the features I like about Angular 2 and React. vuex is a must in most of the app I build.
Have been working on a side project that focuses on sharing economy, allowing users to pickup and deliver groceries for others. Have already started working on the frontend for the web dashboard using React and plan to use React Native for the mobile app. But am in a dilemma, whether to build the backend myself for the MVP or use firebase for the backend. I need advise, has anyone use Firebase for such project and what are the pros and cons, what issues will i faced.
Note: My proposed stack for the backend is a Prisma database, GraphQL , Apollo and ExpressJS
Thanks in advance to everyone.
With this structure, we're able to combine the automation efforts of each team member into a centralized repository while also providing new relevant metrics to business owners.
I use React because I think it is the one that embraces the most the functional component design.
New versions of React are on the right track.
Having to work with Vue or Angular is a lot of pain for me, especially because I'm used to the simplicity of React (which comes with the great price of a high learning curve). Also, the use of the Flux Pattern is so much easier with React, being designed as a one way data flow, than with its two foremost competitors.
Cheers to the React Team, and thank you very much !
I use React because it provides a high level of flexibility to architecture the front end app having the posibility or not to incorporate other libraries such as State Management, Routing or Form Validation, among others. Unidirectional flow and component reutilization is another important advantage.
I use LoopBack because it is: * It is truly and Unbelievably Extensible * it is default integrated with OpenAPI (Swagger) Spec Driven REST API * I write lesser codes, because most of the user stories have been covered using the code generation * It's documentation is more compact and well detailed than ExpressJS * It is very easy to learn, hence you can build a basic Rest API App in minutes * It has built in NPM packages required to build my Rest API which saves me time on installation and configuration * The Datasource/Service/Controller concept is just Brilliant (that's mostly all you need to get your app speaking with an External API services) * The support for SOAP and Rest API services is amazing!
Having developed in both Vue.js and React, I agree with your assessment of Vue. It does feel light and easier to understand and therefore learn. Seeing that Vue has some genetic roots with React, I would say start your friend out on Vue. If they need to learn React later, that should give them a good foundation. If you have a Pluralsight subscription, look for my course on Vue.js and feel free to use the demo project as a starting point.
I chose to use Vue.js a few years ago mainly for the easy learning curve. I have no experience with React, so I won't make any comparison here. Regarding available components, I never felt locked in because of Vue when looking for components. It happens that a component I wish to use is not available as a Vue component (and nobody published any Vue wrapper for it), but in such cases I was able to quickly hack a Vue wrapper component. In the end I don't think a decision to choose one framework over another should be made solely because of the number of components available. (And not all components in either framework is maintained, bug free, documented or easy to use)
I picked up an idea to develop and it was no brainer I had to go with React for the frontend. I was faced with challenges when it came to what component framework to use. I had worked extensively with Material-UI but I needed something different that would offer me wider range of well customized components (I became pretty slow at styling). I brought in Evergreen after several sampling and reads online but again, after several prototype development against Evergreen—since I was using TypeScript and I had to import custom Type, it felt exhaustive. After I validated Evergreen with the designs of the idea I was developing, I also noticed I might have to do a lot of styling. I later stumbled on Material Kit, the one specifically made for React . It was promising with beautifully crafted components, most of which fits into the designs pages I had on ground.
A major problem of Material Kit for me is it isn't written in TypeScript and there isn't any plans to support its TypeScript version. I rolled up my sleeve and started converting their components to TypeScript and if you'll ask me, I am still on it.
In summary, I used the Create React App with TypeScript support and I am spending some time converting Material Kit to TypeScript before I start developing against it. All of these components are going to be hosted on Bit.
If you feel I am crazy or I have gotten something wrong, I'll be willing to listen to your opinion. Also, if you want to have a share of whatever TypeScript version of Material Kit I end up coming up with, let me know.
I want to create a video sharing service like Youtube, which users can use to upload and watch videos. I prefer to use Vue.js for front-end. What do you suggest for the back-end? Node.js or Laravel ( PHP ) I need a good performance with high speed, and the most important thing is the ability to handle user's requests if the site's traffic increases. I want to create an algorithm that users who watch others videos earn points (randomly but in clear context) If you have anything else to improve, please let me know. For eg: If you prefer React to Vue.js. Thanks in advance
I'm working as one of the engineering leads in RunaHR. As our platform is a Saas, we thought It'd be good to have an API (We chose Ruby and Rails for this) and a SPA (built with React and Redux ) connected. We started the SPA with Create React App since It's pretty easy to start.
We use Jest as the testing framework and react-testing-library to test React components. In Rails we make tests using RSpec.
Our main database is PostgreSQL, but we also use MongoDB to store some type of data. We started to use Redis for cache and other time sensitive operations.
We have a couple of extra projects: One is an Employee app built with React Native and the other is an internal back office dashboard built with Next.js for the client and Python in the backend side.
Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.
Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.
Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.
Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.
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.
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.
Express.js is the workhorse of the Cloudcraft.co backend. It's not the most exciting part of a stack, but it works, is very well documented, and you can find a plugin for almost everything you could possibly want. We also carefully evaluated Koa.js, but decided not to go down this route: fewer plugins, less documentation & answers online. I'm also not personally convinced by the generators yield syntax at all. ES7 async functions looks like a much better bet, and with Promises and Babel I can have that already today.
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.
I use express.js for nightly.zerotoherojs.com and dojo.zerotoherojs.com web apps.
Express is well-known, lightweight, works out-of-the-box, has great middleware support and has minimal learning curve.
It is the best framework to start developing a general Node.js web app.
I'm fluent in ExpressJS, but over the past two years I have moved to HapiJS. Similar results, but I find Hapi to be more full-featured towards my app, api and service needs. I can operate confidently in both.
PrometheanTV utilizes the ExpressJS web application framework to deploy various web applications and services including the Broadcast Center Tool, our video embed service, and our REST API.