What is AngularJS and what are its top alternatives?
Top Alternatives to AngularJS
- JavaScript
JavaScript is most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic,and supports object-oriented, imperative, and functional programming styles. ...
- Angular
It is a TypeScript-based open-source web application framework. It is a development platform for building mobile and desktop web applications. ...
- React
Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. ...
- Node.js
Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. ...
- jQuery
jQuery is a cross-platform JavaScript library designed to simplify the client-side scripting of HTML. ...
- PHP
Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world. ...
- Angular CLI
A command-line interface tool that you use to initialize, develop, scaffold, and maintain Angular applications. You can use the tool directly in a command shell, or indirectly through an interactive UI such as Angular Console. ...
- Vue.js
It is a library for building interactive web interfaces. It provides data-reactive components with a simple and flexible API. ...
AngularJS alternatives & related posts
JavaScript
- Can be used on frontend/backend1.7K
- It's everywhere1.5K
- Lots of great frameworks1.2K
- Fast896
- Light weight745
- Flexible425
- You can't get a device today that doesn't run js392
- Non-blocking i/o286
- Ubiquitousness236
- Expressive191
- Extended functionality to web pages55
- Relatively easy language49
- Executed on the client side46
- Relatively fast to the end user30
- Pure Javascript25
- Functional programming21
- Async15
- Full-stack13
- Its everywhere12
- Setup is easy12
- JavaScript is the New PHP11
- Because I love functions11
- Like it or not, JS is part of the web standard10
- Easy9
- Future Language of The Web9
- Expansive community9
- Can be used in backend, frontend and DB9
- Can be used both as frontend and backend as well8
- Everyone use it8
- Most Popular Language in the World8
- Easy to hire developers8
- No need to use PHP8
- For the good parts8
- Photoshop has 3 JS runtimes built in7
- Evolution of C7
- Popularized Class-Less Architecture & Lambdas7
- Agile, packages simple to use7
- Supports lambdas and closures7
- Love-hate relationship7
- Powerful7
- Nice6
- Hard not to use6
- Versitile6
- Client side JS uses the visitors CPU to save Server Res6
- It let's me use Babel & Typescript6
- Easy to make something6
- Its fun and fast6
- Can be used on frontend/backend/Mobile/create PRO Ui6
- 1.6K Can be used on frontend/backend6
- It's fun6
- Function expressions are useful for callbacks5
- What to add5
- Client processing5
- Everywhere5
- Scope manipulation5
- Stockholm Syndrome5
- Promise relationship5
- Clojurescript5
- Because it is so simple and lightweight4
- Only Programming language on browser4
- Hard to learn1
- Test1
- Test21
- Easy to learn1
- Not the best1
- Easy to understand1
- Subskill #41
- Hard 彤0
- A constant moving target, too much churn22
- Horribly inconsistent20
- Javascript is the New PHP15
- No ability to monitor memory utilitization9
- Shows Zero output in case of ANY error8
- Thinks strange results are better than errors7
- Can be ugly6
- No GitHub3
- Slow2
related JavaScript posts
Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.
But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.
But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.
Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.
How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
- It's a powerful framework108
- Straight-forward architecture53
- TypeScript48
- Great UI and Business Logic separation45
- Powerful, maintainable, fast40
- Amazing CLI39
- Great mvc33
- Powerfull Dependency Injection28
- Easy to build19
- Opinionated, batteries-included approach15
- All in one Framework15
- Schematics11
- Solid Standard Setup.10
- Structured8
- Performance7
- Complex5
- Only for single page applications4
- Builders3
- RxJS2
- Ng upgrade2
- React1
- Overcomplicated9
- Large overhead in file size and initialization time9
- Ugly code2
- CLI not open to other test and linting tools2
related Angular posts
When Redash was created 5 years ago we chose AngularJS as our frontend framework, but as AngularJS was replaced by Angular 2 we had to make a new choice. We decided that we won't migrate to Angular, but to either React or Vue.js. Eventually we decided to migrate to React for the following reasons:
- Many in our community are already using React internally and will be able to contribute.
- Using react2angular we can do the migration gradually over time instead of having to invest in a big rewrite while halting feature development.
So far the gradual strategy pays off and in the last 3 major releases we already shipped React code in the Angular.js application.
From my experience of the early startup world, a majority of companies these days use Node.js. Python and Go are the next biggest languages, but significantly smaller than Node.
However, if you're having trouble with the front end aspect of Django, using Node probably won't make that easier for you. You'll have a lot more options between front end frameworks (React, Vue.js, Angular 2) , but they'll definitely take more time to learn than Django's templating system.
Think about whether you want to focus on front end or back end for now, and make a decision from there.
- Components823
- Virtual dom670
- Performance577
- Simplicity505
- Composable442
- Data flow185
- Declarative166
- Isn't an mvc framework127
- Reactive updates118
- Explicit app state114
- JSX48
- Learn once, write everywhere28
- Easy to Use22
- Uni-directional data flow21
- Works great with Flux Architecture17
- Great perfomance11
- Javascript10
- Built by Facebook9
- TypeScript support8
- Speed6
- Feels like the 90s5
- Excellent Documentation5
- Props5
- Functional5
- Easy as Lego5
- Closer to standard JavaScript and HTML than others5
- Cross-platform5
- Server Side Rendering5
- Easy to start5
- Hooks5
- Awesome5
- Scalable5
- Super easy4
- Fancy third party tools4
- Server side views4
- Allows creating single page applications4
- Scales super well4
- Sdfsdfsdf4
- Strong Community4
- Start simple4
- SSR3
- Great migration pathway for older systems3
- Simple3
- Has functional components3
- Rich ecosystem3
- Every decision architecture wise makes sense3
- Has arrow functions3
- Very gentle learning curve3
- Beautiful and Neat Component Management3
- Just the View of MVC3
- Simple, easy to reason about and makes you productive3
- Fast evolving3
- Permissively-licensed2
- HTML-like2
- Image upload2
- Split your UI into components with one true state2
- Sharable2
- Fragments2
- Recharts2
- React hooks1
- Requires discipline to keep architecture organized40
- No predefined way to structure your app29
- Need to be familiar with lots of third party packages28
- JSX13
- Not enterprise friendly10
- One-way binding only6
- State consistency with backend neglected3
- Bad Documentation3
- Error boundary is needed2
- Paradigms change too fast2
related React posts
I am starting to become a full-stack developer, by choosing and learning .NET Core for API Development, Angular CLI / React for UI Development, MongoDB for database, as it a NoSQL DB and Flutter / React Native for Mobile App Development. Using Postman, Markdown and Visual Studio Code for development.
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.
Node.js
- Npm1.4K
- Javascript1.3K
- Great libraries1.1K
- High-performance1K
- Open source805
- Great for apis486
- Asynchronous477
- Great community423
- Great for realtime apps390
- Great for command line utilities296
- Websockets84
- Node Modules83
- Uber Simple69
- Great modularity59
- Allows us to reuse code in the frontend58
- Easy to start42
- Great for Data Streaming35
- Realtime32
- Awesome28
- Non blocking IO25
- Can be used as a proxy18
- High performance, open source, scalable17
- Non-blocking and modular16
- Easy and Fun15
- Easy and powerful14
- Future of BackEnd13
- Same lang as AngularJS13
- Fullstack12
- Fast11
- Scalability10
- Cross platform10
- Simple9
- Mean Stack8
- Great for webapps7
- Easy concurrency7
- Typescript6
- Fast, simple code and async6
- React6
- Friendly6
- Control everything5
- Its amazingly fast and scalable5
- Easy to use and fast and goes well with JSONdb's5
- Scalable5
- Great speed5
- Fast development5
- It's fast4
- Easy to use4
- Isomorphic coolness4
- Great community3
- Not Python3
- Sooper easy for the Backend connectivity3
- TypeScript Support3
- Blazing fast3
- Performant and fast prototyping3
- Easy to learn3
- Easy3
- Scales, fast, simple, great community, npm, express3
- One language, end-to-end3
- Less boilerplate code3
- Npm i ape-updating2
- Event Driven2
- Lovely2
- Creat for apis1
- Node0
- Bound to a single CPU46
- New framework every day45
- Lots of terrible examples on the internet40
- Asynchronous programming is the worst33
- Callback24
- Javascript19
- Dependency based on GitHub11
- Dependency hell11
- Low computational power10
- Can block whole server easily7
- Callback functions may not fire on expected sequence7
- Very very Slow7
- Breaking updates4
- Unstable4
- No standard approach3
- Unneeded over complication3
- Can't read server session1
- Bad transitive dependency management1
related Node.js posts
When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?
So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.
React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.
Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.
How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
- Cross-browser1.3K
- Dom manipulation957
- Power809
- Open source660
- Plugins610
- Easy459
- Popular395
- Feature-rich350
- Html5281
- Light weight227
- Simple93
- Great community84
- CSS3 Compliant79
- Mobile friendly69
- Fast67
- Intuitive43
- Swiss Army knife for webdev42
- Huge Community35
- Easy to learn11
- Clean code4
- Because of Ajax request :)3
- Just awesome2
- Used everywhere2
- Powerful2
- Nice2
- Widely Used1
- Improves productivity1
- Open Source, Simple, Easy Setup1
- It Just Works1
- Industry acceptance1
- Allows great manipulation of HTML and CSS1
- Javascript1
- Easy Setup1
- Large size6
- Sometimes inconsistent API5
- Encourages DOM as primary data source5
- Live events is overly complex feature2
related jQuery posts
The client-side stack of Shopify Admin has been a long journey. It started with HTML templates, jQuery and Prototype. We moved to Batman.js, our in-house Single-Page-Application framework (SPA), in 2013. Then, we re-evaluated our approach and moved back to statically rendered HTML and vanilla JavaScript. As the front-end ecosystem matured, we felt that it was time to rethink our approach again. Last year, we started working on moving Shopify Admin to React and TypeScript.
Many things have changed since the days of jQuery and Batman. JavaScript execution is much faster. We can easily render our apps on the server to do less work on the client, and the resources and tooling for developers are substantially better with React than we ever had with Batman.
#FrameworksFullStack #Languages
I'm planning to create a web application and also a mobile application to provide a very good shopping experience to the end customers. Shortly, my application will be aggregate the product details from difference sources and giving a clear picture to the user that when and where to buy that product with best in Quality and cost.
I have planned to develop this in many milestones for adding N number of features and I have picked my first part to complete the core part (aggregate the product details from different sources).
As per my work experience and knowledge, I have chosen the followings stacks to this mission.
UI: I would like to develop this application using React, React Router and React Native since I'm a little bit familiar on this and also most importantly these will help on developing both web and mobile apps. In addition, I'm gonna use the stacks JavaScript, jQuery, jQuery UI, jQuery Mobile, Bootstrap wherever required.
Service: I have planned to use Java as the main business layer language as I have 7+ years of experience on this I believe I can do better work using Java than other languages. In addition, I'm thinking to use the stacks Node.js.
Database and ORM: I'm gonna pick MySQL as DB and Hibernate as ORM since I have a piece of good knowledge and also work experience on this combination.
Search Engine: I need to deal with a large amount of product data and it's in-detailed info to provide enough details to end user at the same time I need to focus on the performance area too. so I have decided to use Solr as a search engine for product search and suggestions. In addition, I'm thinking to replace Solr by Elasticsearch once explored/reviewed enough about Elasticsearch.
Host: As of now, my plan to complete the application with decent features first and deploy it in a free hosting environment like Docker and Heroku and then once it is stable then I have planned to use the AWS products Amazon S3, EC2, Amazon RDS and Amazon Route 53. I'm not sure about Microsoft Azure that what is the specialty in it than Heroku and Amazon EC2 Container Service. Anyhow, I will do explore these once again and pick the best suite one for my requirement once I reached this level.
Build and Repositories: I have decided to choose Apache Maven and Git as these are my favorites and also so popular on respectively build and repositories.
Additional Utilities :) - I would like to choose Codacy for code review as their Startup plan will be very helpful to this application. I'm already experienced with Google CheckStyle and SonarQube even I'm looking something on Codacy.
Happy Coding! Suggestions are welcome! :)
Thanks, Ganesa
PHP
- Large community951
- Open source818
- Easy deployment765
- Great frameworks487
- The best glue on the web386
- Continual improvements235
- Good old web184
- Web foundation145
- Community packages135
- Tool support125
- Used by wordpress35
- Excellent documentation34
- Used by Facebook28
- Because of Symfony23
- Dynamic Language21
- Easy to learn16
- Cheap hosting16
- Awesome Language and easy to implement14
- Fast development14
- Very powerful web language14
- Composer13
- Because of Laravel12
- Flexibility, syntax, extensibility11
- Easiest deployment8
- Fastestest Time to Version 1.0 Deployments7
- Worst popularity quality ratio7
- Fast7
- Short development lead times7
- Readable Code7
- Faster then ever6
- Most of the web uses it6
- Simple, flexible yet Scalable5
- Open source and large community5
- Cheap to own4
- Easy to learn, a big community, lot of frameworks4
- Is like one zip of air4
- Large community, easy setup, easy deployment, framework4
- Has the best ecommerce(Magento,Prestashop,Opencart,etc)4
- Easy to use and learn4
- I have no choice :(4
- Open source and great framework4
- Great developer experience3
- Fault tolerance2
- Great flexibility. From fast prototyping to large apps2
- Interpreted at the run time2
- FFI2
- Safe the planet2
- Hard not to use2
- Used by STOMT2
- Walk away2
- Secure1
- Simplesaml1
- Bando1
- Secure0
- So easy to learn, good practices are hard to find22
- Inconsistent API16
- Fragmented community8
- Not secure6
- No routing system3
- Hard to debug3
- Old2
related PHP posts
When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?
So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.
React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.
Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.
Our whole Node.js backend stack consists of the following tools:
- Lerna as a tool for multi package and multi repository management
- npm as package manager
- NestJS as Node.js framework
- TypeScript as programming language
- ExpressJS as web server
- Swagger UI for visualizing and interacting with the API’s resources
- Postman as a tool for API development
- TypeORM as object relational mapping layer
- JSON Web Token for access token management
The main reason we have chosen Node.js over PHP is related to the following artifacts:
- Made for the web and widely in use: Node.js is a software platform for developing server-side network services. Well-known projects that rely on Node.js include the blogging software Ghost, the project management tool Trello and the operating system WebOS. Node.js requires the JavaScript runtime environment V8, which was specially developed by Google for the popular Chrome browser. This guarantees a very resource-saving architecture, which qualifies Node.js especially for the operation of a web server. Ryan Dahl, the developer of Node.js, released the first stable version on May 27, 2009. He developed Node.js out of dissatisfaction with the possibilities that JavaScript offered at the time. The basic functionality of Node.js has been mapped with JavaScript since the first version, which can be expanded with a large number of different modules. The current package managers (npm or Yarn) for Node.js know more than 1,000,000 of these modules.
- Fast server-side solutions: Node.js adopts the JavaScript "event-loop" to create non-blocking I/O applications that conveniently serve simultaneous events. With the standard available asynchronous processing within JavaScript/TypeScript, highly scalable, server-side solutions can be realized. The efficient use of the CPU and the RAM is maximized and more simultaneous requests can be processed than with conventional multi-thread servers.
- A language along the entire stack: Widely used frameworks such as React or AngularJS or Vue.js, which we prefer, are written in JavaScript/TypeScript. If Node.js is now used on the server side, you can use all the advantages of a uniform script language throughout the entire application development. The same language in the back- and frontend simplifies the maintenance of the application and also the coordination within the development team.
- Flexibility: Node.js sets very few strict dependencies, rules and guidelines and thus grants a high degree of flexibility in application development. There are no strict conventions so that the appropriate architecture, design structures, modules and features can be freely selected for the development.
related Angular CLI posts
I am starting to become a full-stack developer, by choosing and learning .NET Core for API Development, Angular CLI / React for UI Development, MongoDB for database, as it a NoSQL DB and Flutter / React Native for Mobile App Development. Using Postman, Markdown and Visual Studio Code for development.
Picked Angular 2 as framework since Angular CLI made it easy to get started on a self-contained frontend web project with TypeScript for easier development -- thanks to intellisense extensions for Visual Studio Code, hassle-free browser compatibility with the built-in Babel transpiler and packaging with the built-in Webpack configuration.
- Simple and easy to start with293
- Good documentation228
- Components196
- Simple the best131
- Simplified AngularJS100
- Reactive93
- Intuitive APIs76
- Javascript56
- Changed my front end coding life52
- Configuration is smooth48
- Easy to learn37
- So much fun to use35
- Progressive25
- Virtual dom22
- Faster than bulldogs on hot tarmac16
- Component is template, javascript and style in one12
- It's magic12
- Light Weight10
- Perfomance10
- Best of Both Worlds9
- Elegant design8
- Application structure8
- Intuitive and easy to use8
- Without misleading licenses8
- Good command line interface6
- Small learning curve6
- Single file components5
- Logicless templates5
- Easy to integrate to HTML by inline-templates5
- Like Angular only quicker to get started with5
- High performance4
- Component based3
- Vuex3
- Bridge from Web Development to JS Development3
- Customer Render ending eg to HTML3
- Lots of documentation2
- Concise error messages2
- Supports several template languages2
- One-way data flow2
- Intuitive2
- GUI1
- Less Common Place9
- YXMLvsHTML Markup5
- Don't support fragments3
- Only support programatically multiple root nodes3
related Vue.js posts
Our whole Node.js backend stack consists of the following tools:
- Lerna as a tool for multi package and multi repository management
- npm as package manager
- NestJS as Node.js framework
- TypeScript as programming language
- ExpressJS as web server
- Swagger UI for visualizing and interacting with the API’s resources
- Postman as a tool for API development
- TypeORM as object relational mapping layer
- JSON Web Token for access token management
The main reason we have chosen Node.js over PHP is related to the following artifacts:
- Made for the web and widely in use: Node.js is a software platform for developing server-side network services. Well-known projects that rely on Node.js include the blogging software Ghost, the project management tool Trello and the operating system WebOS. Node.js requires the JavaScript runtime environment V8, which was specially developed by Google for the popular Chrome browser. This guarantees a very resource-saving architecture, which qualifies Node.js especially for the operation of a web server. Ryan Dahl, the developer of Node.js, released the first stable version on May 27, 2009. He developed Node.js out of dissatisfaction with the possibilities that JavaScript offered at the time. The basic functionality of Node.js has been mapped with JavaScript since the first version, which can be expanded with a large number of different modules. The current package managers (npm or Yarn) for Node.js know more than 1,000,000 of these modules.
- Fast server-side solutions: Node.js adopts the JavaScript "event-loop" to create non-blocking I/O applications that conveniently serve simultaneous events. With the standard available asynchronous processing within JavaScript/TypeScript, highly scalable, server-side solutions can be realized. The efficient use of the CPU and the RAM is maximized and more simultaneous requests can be processed than with conventional multi-thread servers.
- A language along the entire stack: Widely used frameworks such as React or AngularJS or Vue.js, which we prefer, are written in JavaScript/TypeScript. If Node.js is now used on the server side, you can use all the advantages of a uniform script language throughout the entire application development. The same language in the back- and frontend simplifies the maintenance of the application and also the coordination within the development team.
- Flexibility: Node.js sets very few strict dependencies, rules and guidelines and thus grants a high degree of flexibility in application development. There are no strict conventions so that the appropriate architecture, design structures, modules and features can be freely selected for the development.
I've used both Vue.js and React and I would stick with React. I know that Vue.js seems easier to write and its much faster to pick up however as you mentioned above React has way more ready made components you can just plugin, and the community for React is very big.
It might be a bit more of a steep learning curve for your friend to learn React over Vue.js but I think in the long run its the better option.