Alternatives to Angular 2 logo

Alternatives to Angular 2

React, Polymer, Aurelia, Vue.js, and Meteor are the most popular alternatives and competitors to Angular 2.
3.8K
2.9K
+ 1
365

What is Angular 2 and what are its top alternatives?

It is a TypeScript-based open-source web application framework. It is a development platform for building mobile and desktop web applications.
Angular 2 is a tool in the Javascript MVC Frameworks category of a tech stack.
Angular 2 is an open source tool with 63.9K GitHub stars and 17.2K GitHub forks. Here’s a link to Angular 2's open source repository on GitHub

Top Alternatives to Angular 2

Angular 2 alternatives & related posts

related React posts

Vaibhav Taunk
Vaibhav Taunk
Team Lead at Technovert · | 30 upvotes · 1M views

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.

See more
Shared insights
on
Vue.jsVue.jsReactReact

I find using Vue.js to be easier (more concise / less boilerplate) and more intuitive than writing React. However, there are a lot more readily available React components that I can just plug into my projects. I'm debating whether to use Vue.js or React for an upcoming project that I'm going to use to help teach a friend how to build an interactive frontend. Which would you recommend I use?

See more
Polymer logo

Polymer

364
382
154
A new library built on top of Web Components, designed to leverage the evolving web platform on modern...
364
382
+ 1
154

related Polymer posts

Adam Rabinovitch
Adam Rabinovitch
Global Technical Recruiting Lead & Engineering Evangelist at Beamery · | 5 upvotes · 104.8K views

At Beamery we had a large, AngularJS app, built over several years. Our clients were happy, but we were not. We had several problems: Building new features was slow. AngularJS doesn’t scale nicely. Features clash with each other. Isolation doesn’t come as standard, you have to work hard to keep features separate. It takes time to get it right. #Hiring was hard, for all the reasons listed above. The app was slower than it needed to be because AngularJS was never built for speed. We wanted to render half a million contacts, and Angular was fighting us all the way.

As time went by it become harder to find developers who would willingly choose AngularJS over React Angular 2 , Vue.js , Aurelia or Polymer .

So we faced a choice. We could throw it all away and start again, we could upgrade to Angular 5, or the awesome option - we could use micro frontends. We chose the awesome option.

See more
Ido Shamun
Ido Shamun
at The Elegant Monkeys · | 5 upvotes · 79.2K views
Shared insights
on
Vue.jsVue.jsReactReactPolymerPolymer
at

For developing our #frontend applications, we decided to use Vue.js . Being such an easy to learn library, compared to React for example, it made everything so easy. At first we started with Polymer but the existing tooling and small community at the time made us look for alternatives.

See more

related Aurelia posts

Adam Rabinovitch
Adam Rabinovitch
Global Technical Recruiting Lead & Engineering Evangelist at Beamery · | 5 upvotes · 104.8K views

At Beamery we had a large, AngularJS app, built over several years. Our clients were happy, but we were not. We had several problems: Building new features was slow. AngularJS doesn’t scale nicely. Features clash with each other. Isolation doesn’t come as standard, you have to work hard to keep features separate. It takes time to get it right. #Hiring was hard, for all the reasons listed above. The app was slower than it needed to be because AngularJS was never built for speed. We wanted to render half a million contacts, and Angular was fighting us all the way.

As time went by it become harder to find developers who would willingly choose AngularJS over React Angular 2 , Vue.js , Aurelia or Polymer .

So we faced a choice. We could throw it all away and start again, we could upgrade to Angular 5, or the awesome option - we could use micro frontends. We chose the awesome option.

See more

related Vue.js posts

Shared insights
on
Vue.jsVue.jsReactReact

I find using Vue.js to be easier (more concise / less boilerplate) and more intuitive than writing React. However, there are a lot more readily available React components that I can just plug into my projects. I'm debating whether to use Vue.js or React for an upcoming project that I'm going to use to help teach a friend how to build an interactive frontend. Which would you recommend I use?

See more
Johnny Bell
Johnny Bell
Shared insights
on
Vue.jsVue.jsReactReact

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.

See more

related Meteor posts

Shared insights
on
MeteorMeteorNode.jsNode.js
at

Mixmax was originally built using Meteor as a single monolithic app. As more users began to onboard, we started noticing scaling issues, and so we broke out our first microservice: our Compose service, for writing emails and Sequences, was born as a Node.js service. Soon after that, we broke out all recipient searching and storage functionality to another Node.js microservice, our Contacts service. This practice of breaking out microservices in order to help our system more appropriately scale, by being more explicit about each microservice’s responsibilities, continued as we broke out numerous more microservices.

See more

As Mixmax began to scale super quickly, with more and more customers joining the platform, we started to see that the Meteor app was still having a lot of trouble scaling due to how it tried to provide its reactivity layer. To be honest, this led to a brutal summer of playing Galaxy container whack-a-mole as containers would saturate their CPU and become unresponsive. I’ll never forget hacking away at building a new microservice to relieve the load on the system so that we’d stop getting paged every 30-40 minutes. Luckily, we’ve never had to do that again! After stabilizing the system, we had to build out two more microservices to provide the necessary reactivity and authentication layers as we rebuilt our Meteor app from the ground up in Node.js. This also had the added benefit of being able to deploy the entire application in the same AWS VPCs. Thankfully, AWS had also released their ALB product so that we didn’t have to build and maintain our own websocket layer in Amazon EC2. All of our microservices, except for one special Go one, are now in Node with an nginx frontend on each instance, all behind AWS Elastic Load Balancing (ELB) or ALBs running in AWS Elastic Beanstalk.

See more
KnockoutJS logo

KnockoutJS

184
150
2
Knockout makes it easier to create rich, responsive UIs with JavaScript
184
150
+ 1
2
CONS OF KNOCKOUTJS
    No cons available

    related KnockoutJS posts

    related AngularJS posts

    Simon Reymann
    Simon Reymann
    Senior Fullstack Developer at QUANTUSflow Software GmbH · | 23 upvotes · 745.4K views

    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.
    See more
    Simon Reymann
    Simon Reymann
    Senior Fullstack Developer at QUANTUSflow Software GmbH · | 18 upvotes · 240.3K views

    Our whole Vue.js frontend stack (incl. SSR) consists of the following tools:

    • Nuxt.js consisting of Vue CLI, Vue Router, vuex, Webpack and Sass (Bundler for HTML5, CSS 3), Babel (Transpiler for JavaScript),
    • Vue Styleguidist as our style guide and pool of developed Vue.js components
    • Vuetify as Material Component Framework (for fast app development)
    • TypeScript as programming language
    • Apollo / GraphQL (incl. GraphiQL) for data access layer (https://apollo.vuejs.org/)
    • ESLint, TSLint and Prettier for coding style and code analyzes
    • Jest as testing framework
    • Google Fonts and Font Awesome for typography and icon toolkit
    • NativeScript-Vue for mobile development

    The main reason we have chosen Vue.js over React and AngularJS is related to the following artifacts:

    • Empowered HTML. Vue.js has many similar approaches with Angular. This helps to optimize HTML blocks handling with the use of different components.
    • Detailed documentation. Vue.js has very good documentation which can fasten learning curve for developers.
    • Adaptability. It provides a rapid switching period from other frameworks. It has similarities with Angular and React in terms of design and architecture.
    • Awesome integration. Vue.js can be used for both building single-page applications and more difficult web interfaces of apps. Smaller interactive parts can be easily integrated into the existing infrastructure with no negative effect on the entire system.
    • Large scaling. Vue.js can help to develop pretty large reusable templates.
    • Tiny size. Vue.js weights around 20KB keeping its speed and flexibility. It allows reaching much better performance in comparison to other frameworks.
    See more
    Backbone.js logo

    Backbone.js

    5.4K
    1.8K
    676
    Give your JS App some Backbone with Models, Views, Collections, and Events
    5.4K
    1.8K
    + 1
    676

    related Backbone.js posts

    Dan Robinson
    Dan Robinson

    The front end for Heap begun to grow unwieldy. The original jQuery pieces became difficult to maintain and scale, and a decision was made to introduce Backbone.js, Marionette, and TypeScript. Ultimately this ended up being a “detour” in the search for a scalable and maintainable front-end solution. The system did allow for developers to reuse components efficiently, but adding features was a difficult process, and it eventually became a bottleneck in advancing the product.

    Today, the Heap product consists primarily of a customer-facing dashboard powered by React, MobX, and TypeScript on the front end. We wrote our migration to React and MobX in detail last year here.

    #JavascriptUiLibraries #Libraries #JavascriptMvcFrameworks #TemplatingLanguagesExtensions

    See more
    Marcos Iglesias
    Marcos Iglesias
    Sr. Software Engineer at Eventbrite · | 13 upvotes · 127.2K views

    We are in the middle of a change of the stack on the front end. So we used Backbone.js with Marionette. Then we also created our own implementation of a Flux kind of flow. We call it eb-flux. We have worked with Marionette for a long time. Then at some point we start evolving and end up having a kind of Redux.js-style architecture, but with Marionette.

    But then maybe one and a half years ago, we started moving into React and that's why we created the Eventbrite design system. It's a really nice project that probably could be open sourced. It's a library of components for our React components.

    With the help of that library, we are building our new stack with React and sometimes Redux when it's necessary.

    See more