Good day! I have a question. It is planned to develop a large web project, which will be scaled in the future. I would like to know what is better to choose EmberJS or React? There is experience with EmberJs, but I would like to hear the opinion of experts who have experience with both frameworks. I've heard that react is lighter, but at the same time, you need to include a lot of libraries to add functionality like ember js. Tell me, please. It would be great to see some benchmarks in various conditions. Thanks guys!
I started with React and later moved to Ember. The truth of the matter is that the core problems teams face when developing frontend / single-page-apps are about the same regardless of what tool you're using. Those problems are going to include learning the business, learning the history, struggling with how to not over-use the framework, and instead using "the platform" (using MDN more than framework docs, etc). Generally, it takes way more time to learn a business / existing product than it does to learn a framework.
For some benefits of ember's whole ecosystem, which React does not have:
Ember has a more cohesive ecosystem which makes upgrades much more straight forward.
Ember's goal in frontend is to reduce the meanial differences between apps so that you can focus on features. This includes stuff like state management, routing, etc. For comparison, there are features in Next.JS that landed in the last month or so that Ember has had since the beginning.
Ember's discord is an invaluable tool of helpful people. A bit US-work-week centric at times, but it is the go-to place to get more synchronous help outside of your own team. Link here: https://discord.gg/emberjs (which is found on the community page: https://emberjs.com/community/) -- React also has a discord, but I found it way less welcoming due to the sheer volume of people moving through there.
Conventions is key to any framework in the single-page-app approaching SDK space. Conventions are optional guidance that are happy-path defaults that, once memorized, bring productivity ahead of where it would be without the conventions
Ember is mostly "Just JS". React has this same claim, and maybe that was true back when they were using classes for things, but with everything needing hooks now, and the over-use of useEffect, Folks end up writing more React than they write JS. With Ember, you still write more JS than the framework. Ember has tried very hard to allow you to stick to MDN for for anything but reactivity and routing. State management is even allow "normal JS" (with some conventions due to limitations of JS, itself)
I've heard that react is lighter, but at the same time, you need to include a lot of libraries to add functionality like ember js.
This is true, however, It stops mattering very quickly. Ember is only 100KB (min+gzip) -- React (at a minimum, I think is ~40kb (min+gzip), with no libraries (react + react-dom)), and the size of your underlying framework begins to not matter in comparison to the rest of your app's code very quickly.
Unless you're targeting low-connectivity areas and trying to also get your site to load in < 0.1s, the framework choice w/r/t size also doesn't matter. (I'd say this of Angular, too!).
Fwiw, and maybe this is a bit of a disclaimer, I feel like React is a modern day jQuery (usage in the vernacular is nearly the same as jQuery). Nearly everyone is using it because nearly everyone knows it. It doesn't matter if the tool is good or not, it's everywhere, yet holds no opinions about anything and relies on the broader community tot learn how to use it. You can't build products out of just React.
And kind of more cynical, React is an avenue to very cheap labor for employers to hire straight out of bootcamps.
As an aside, one thing I've noticed about frameworks, is that most of the "cool stuff" (that you'd want to use day to day) isn't documented in the framework docs. It's knowledge derived from knowledge of both the framework, and what the web can do on its own.
For example:
handling form submissions without a ton of wireup: https://twitter.com/nullvoxpopuli/status/1502682732178124805
dynamic imports / await importing a component: https://twitter.com/nullvoxpopuli/status/1507715367581462531
testing with MSW:
https://twitter.com/nullvoxpopuli/status/1525509103317041152
https://twitter.com/nullvoxpopuli/status/1525508184353406978
Filtering local data: https://twitter.com/nullvoxpopuli/status/1496512125237440515
Integrating Tailwind: https://twitter.com/nullvoxpopuli/status/1481993894430658568 (the lazy way)
Thinking about template syntax: https://twitter.com/nullvoxpopuli/status/1474037335583080449
Related
Recently I was going through React and Angular Comparison online (latest versions) & found both are good fit for Web Application UI.
While I was also wondering, there must be some differences which must be focused while deciding between two of them.
Lets suppose, I have one Java based web application with Spring MVC framework , Hibernate & JSF/JSP. Assuming this application is doing massive backend operations & displaying data on UI.
If in todays date, if I want to rebuild this type of application with latest Technology then how I should go for decision making out of React /Angular/other UI framework. For backend may be I will prefer to use Spring Boot which is advanced version of Spring MVC, but its really difficult to make choice on UI side.
Few points which I came across after googling are-
React is best when real time data update is required frequently.
React requires lot of Java script skills so it takes time develop web apps.
Now a days React is most preferred JS library which has more flexibility & big MNC's are also migrating from Angular to React.
While Angular has speedy development & also trying to improve on lacking points per release like Bundle Size, Performance etc.
Angular is preferred when web application is stable and not much enhancement are required.
Do we have some guidelines on when to use React / Angular?
Most of the time, both frameworks do the trick. Chose the framework that matches your team. If you like opinionated frameworks - i.e. frameworks that guide you - chose Angular. If you need a lot of freedom or if you don't like TypScript, chose React.
Small Angular applications have a surprisingly large memory footprint. So I'd prefer React for small things like Wordpress plugins. However, if you're writing a large application, memory and AFAIK even performance are in the same league.
Angular assumes it's owning the entire HTML page. So it's a bit difficult to embed Angular in an existing page, or to write microfrontends with Angular. But that's possible, too: just convert your Angular app into a webcomponent.
In any case, both frameworks are mature and have a huge community. The market share of React is larger, but if you're looking at the absolute download figures, both frameworks are popular and even growing. So #James is right, it's largely opinion based.
You gave some clues by mentioning the old application. If your team has a strong Java background, they'll probably prefer Angular. Modern React encourages to abandon object-oriented programming in favor of functional programming. That's pretty cool, but if you're a long-term JSF programmer (like 10+ years), you're already busy learning HTML, CSS, and TypeScript. Maybe it's a bit much to add a new programming paradigm to the stack of stuff to learn. But again - every team is different. Let your team decide!
I'm a project manager of a market place and I'm trying to find solution for my concerns. For two years a ago we decided to develop market place.
In front layer we decide to use angularjs and our team professional implement front layer using AngularJS. We add dependency injection for first time to angularjs 1.3 and solve google analytic crawling in SPA website.
But when google announce On July 1, 2018 AngularJS entered a 3 year Long Term Support period. As a project manager I have a big concern because We living in 2019 and after two years whats happen for our website ?
But my biggest question is how optimistic how long can we use Angularjs?
how much migration is necessary for this framework and
Is it possible that the sites written with Angularjs are not able to work after 2021?
Google announced:
All AngularJS applications that work now, will continue to work in the future. All published versions of AngularJS, on npm, bower, CDNs, etc will continue to be available.
For more information, see
Angular Blog - Stable AngularJS and Long Term Support
AngularJS Version Support Status
It’s out of date now, and new projects should absolutely not be built using it. This isn’t to say it was ever a particularly great choice. AngularJS came out of nowhere and became popular by default, rather than because it had particularly great design. It has a difficulty curve better suited to a great roller coaster than a decent framework, and a bunch of weird architectural and terminology choices. What the hell is a $scope, anyway? And what is a directive? What does transclusion actually mean? Meaningless terms that AngularJS has created. AngularJS does some things that are fundamentally wrong, such as creating invalid attributes on HTML markup. Even Google doesn’t use Angular for their own apps, like Gmail, and there’s a reason for that.
In fairness, AngularJS was always a poor choice. Its idiosyncratic code means that unlike other frameworks, it’s not good at implementing an agnostic, javascript solution. AngularJS code looks unfamiliar to anyone not super experienced with the weird intricacies of AngularJS itself.
Thankfully, this decision is well made for you – AngularJS is now quite thoroughly dead, and only legacy projects will continue to be using it. We should be grateful for what AngularJS has given us, and respect the position it held, but we should be just as pleased that it’s gone.1
The change is only about "support" and it means, no more bug fixes and no more improvements. Other than that, everything will be the same. Although, you should consider some disaster scenarios after LTS.
I saw some posts about running AngularJS and Angular side by side and I think it can be a good solution for your problem. Since you have enough time to migrate, your team can develop new features on Angular and you can also maintain your current AngularJS. Eventually you can get rid of AngularJS depending on your project size and development capacity.
Please check these scenarios.
Running AngularJS 1.6 in Angular 5 (side by side)
Running Angular and AngularJS frameworks side by side
For Angularjs support, you can find the previous discussion on this portal: angularjs 1.x support lifecycle and end-of-life
And the question regarding migration, in my personal opinion migration is a better option as the latest Angular version provides Boost in performance, Mobile-driven approach, code Maintainability & optimization, and most importantly Reduced development time and costs with better support.
And if asked about the migration approach, I would suggest a complete re-write that can be the most cost-effective strategy. If you’re a manager, put your team through Angular training (live, online, videos, books). Allocate time and budget for getting your developers up to speed with Angular as the learning curve is steep and prior experience with AngularJS is not overly helpful. Then your developers will write the new version of the app as per best practices recommended for Angular/TypeScript projects.
And finally, it’ll definitely pay off in the end. And, secondly, the newer versions of Angular won’t let you systems become outdated or irrelevant.
There is a team called XLTS.dev who are providing extended support for AngularJS beyond December 2021.
We have used Angular JS extensively in our company for enterprise projects, mobile applications and continue to use it. Google's decision to stop development of AngularJS and put it on a EOL will definitely make developers to panic. But 3 years to migrate away from it is a long time and you can plan accordingly.
If your plan is to migrate to Angular, then you can follow their official guide to upgrade using ngUpgrade. You can find numerous articles online that explain how they upgraded existing AngularJS apps to Angular.
If your plan is to consider migrating to a totally new framework, then this will involve some work. You should take a look Web Components spec. Your existing directives/components can be re-written, with less effort, as web components (shadow DOM) or custom components (without shadow DOM). There are libraries that help you write these generic components - supported on most browsers today - Stencil JS, lit element and a few others.
The advantage of using Stencil JS is that it provides tools to compile your web components to target different frameworks (Angular, React, Vue, Ember).
The latter solution seems feasible as it allows you to migrate directives one by one over a period of time, without having to re-write the whole application in one go. In the future you can also re-use your components in the framework of your choice.
As for your question about will it continue to work after 2021 - yes it will continue to work. The problems you might face might not really be of technical nature, but related to hiring resources to work on it or maintain it.
I am AngularJS developer and I do continue to use this framework for some of my projects. I am aware that in not too distant future this library will be completely outdated (as some of you can say it's the case now), however:
AngularJS ecosystem gives you still lots of choice/support (as framework is very mature)
my main libraries as ag-grid, highChart or others, help to build great apps out of the box with little time
I still do enjoy to work with this framework for it's simplicity and flexibility
If you should build brand new app I would recommend React or Vue (or other framework) especially if you do not have significant experience with Angularjs. However if Angularjs is not new for you, you need to go fast - just use your experience and go for Angular.
Taking into account what you wrote:
My main concern is after 3 years of support. Whether after the 3 year end of support, Angularjs sites can continue to work without problems
Angularjs apps won't just stop to work like that, from one day to another.
As your project requires long-term maintenance, needs to be built from scratch and will take lots of effort - Angularjs ecosystem is then probably not the best choice for you (I do insist "for you").
I've spent the past few days looking at VueJs 2 with Vuex and i really like it.
Having only had a brief introduction to React, I've found vue js 2 has been easier to pick up.
React seems to be growing in popularity, but I can't see the benefits of React over Vue 2.
Both are component based frameworks with routing and state management tools.
So can someone explain which are the main differences between those frameworks?
This is an opinionated and subjective question. And it often starts holy-wars than really answering anything and thus it is not really suitable for StackOverflow. However, I will try to answer this in an objective manner as possible. (Note: I am purely comparing Vue with React and deliberately avoiding Vuex vs Redux)
Why Vue.js?
It is designed to be an approachable framework. It is suitable for beginners and advanced users alike. When you are starting with Vue.js, it is as simple as adding a script tag to your page. For the advanced developer, the possibilities are endless. You can start with any sophisticated build tools - TypeScript, Babel, Webpack, etc.
Vue.js is developed much after Angular and React. It has learned from both and managed to pick many best things from them into Vue. For a beginner, Angular's idea of components, services, dependency injection, bootstrapping application, etc can feel overwhelming. Same is applicable to React; JSX can feel odd (Even after years, I still find it weird.). Now, Vue.js is a cross-path. You can use angular like templates or you have the freedom to choose React like JSX.
Vue.js reactivity is very well abstracted. With Angular (digest cycle in v1 and zones in v2) or React, it is bit different. It takes time to learn these concepts.
There are tons of other reasons why Vue.js should be your choice. Sometime back, I had written an article explaining why Vue.js:
https://blog.webf.zone/vue-js-answering-the-why-after-15-months-62db797f75cc
Why React?
React is a pioneering library (It is not a framework) just like Angular. It introduced the ideas of uni-directional architecture, virtual-dom, components (stateful and stateless), etc.
React Native is another reason why you may want to consider React. It allows you to take the same code that you wrote for Web and build native mobile applications. Now solutions do exist in the Vue.js world. But definitely not as mature as React Native.
Functional programming: No way React is a library based on functional programming. But doing React right way means you need to use immutability, explicit state management and all these allied concepts stemming from functional world.
Redux: Redux is the darling of React world. It has unlocked wonderful architectural patterns for front-end world like time-travel debugging, explicit side-effects, functional components, etc.
Innovation: React has some crazy ideas like Relay, Next.js (Vue.js has Nuxt.js). I also heard about some Drap-n-drop editor for React; first class TypeScript and Flow support (You just cannot get TypeScript + Vue.js + JSX working together even in 2018).
Why not React?
Using only React is not enough. Very soon, you will end up with using Redux, Redux middleware, Immutable.js, etc. Doing all of that at once can be intimidating.
Redux. It is wonderful but it is verbose.
Most important: Using React without any sophisticated build system is cumbersome. To do anything serious, you will need Babel, Webpack, etc.
Again, which one is better?
There is no better solution. I will choose Vue.js if I need to accommodate a vast array of developers (beginners-advanced). I will choose React if my team is versed with all the extra overload that comes with React and team loves everything JavaScript approach to web development (Even CSS is JS).
Finally, there is one another angle to it. Programming in React needs discipline and hence, there is a good chance that you will find it easier to bring homogeneity to your codebase. With Vue.js, there is often more than one solution to a problem. That makes it good and bad at the same time.
You will not go wrong with either of them.
Building app with react with flux, I'm wondering developing an app with react is really efficient.
With flux all states are maintained by domain. All state of components have to manuplate in flux. I need to normalize data structure to consume in react components. This is verbose.
And more components are listed we have to consider rerender optimization. This is time consumer stuff.
Of course reusing react components is nice but configuring, designing, planning are also complex.
I need some advice of using react.
It is very overwhelming at first as there are so many decisions to be made. Just do a google search for "JavaScript fatigue" and you will realize you are not alone.
Fortunately, there are lots of great resources out there (both free and paid) to learn about all of this stuff. I personally used Cory House's two React courses on Pluralsight to get up to speed and found this route very helpful.
Still, project setup can be very time consuming with flux or redux, and you have to consider whether your application is complicated enough to warrant their use. React itself is extremely flexible and can be used in a simple application on it's own, or even in conjunction with other frameworks or tools like backbone.
There are plenty of things out there to help ease some of the pain of setting boilerplate for a react project.
https://github.com/coryhouse/react-flux-starter-kit
https://github.com/coryhouse/react-slingshot
Both of those are good resources (there are many more out there as well) and serve as good starting places.
Lastly, Facebook just the other day released an official tool that allows developers to start writing react apps without having to worry about any configuration. There are still some limitations to the tool, but it seems very promising and looks like a great place to start for beginners.
https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html
I'm working on a project which has the luxury of using ECMA 6 on the latest browsers for a product that will be shipped in 1.5 years. So we thought why not use Web Components now that Angular 2 isn't available (which is going to be ECMA 6). And while we are at it, can we replace Angular altogether without having to go back to stone age?
How to replace Angular?
There's this site called youmightnotneedjquery.com which is basically about how modern browsers actually have most of the stuff that jQuery was traditionally used for. I'm interested to see something like that for Angular.
We mainly use four Angular features. What are my options for replacing them?
Angular Directives --> Web Components
Angular Modules --> ECMA 6 Modules (not exactly the same thing)
Angular Routes --> ???
Angular 2-way databinding --> ???
PS. We don't want to replace Angular with something similar like Backbone or Ember. We want to replace it with standard web technologies but if we have to use small tools to fill the gap, we'll consider it.
I've been researching in the past 3 weeks and turns out many people are thinking about an alternative after Angular took a drastic change path. Fortunately the upcomming W3C Web Components standard actually has all we need and it works right now with polyfills from the Polymer project. So to answer the question:
Angular Directives --> Web Components use the polyfill until all browsers support it.
Angular Modules --> ECMA 6 Modules part of the problem is solved with HTML imports. But you can also use Traceur until the browsers support it.
Angular Routes --> There's a component for that™ use <app-router>.
Angular 2-way databinding --> Polymer adds a "magic" layer on top of the plain standard web components. This includes many features including data-binding.
+Plus More
If you're wondering about the build process for concatenating files in order to reduce the number of HTTP requests, take a look at Addy Osmani's post about Vulcanize. Spoiler: you may not need it with the upcoming HTTP 2 optimizations.
Many Angular projects use Twitter Bootstrap for the layout. Polymer can do that plus it plays nicely with Google's Paper elements (totally optional but superbly awesome).
If you want to make yourself familiar with web components in general, here is a bunch of nice articles: http://webcomponents.org/articles/
And here is a wealth of web components: http://customelements.io/ I don't know if it's going to be a new NPM, but the list components is pretty impressive and growing.
It's relatively complicated to expose an API for an Angular component. People have come up with all sorts of methods from link function to emitting events. In Web Components, however, it's really easy to make your component interact with the world outside and indeed the API and events you expose aren't much different from standard HTML tags like <audio>.
Just like Angular, you can use Polymer with Dart as well.
Conclusion
Overall, I don't see any reason to use Angular except if:
You have a huge source code investment in angular and don't want to port everything to standard web. (Angular 2.0 will deprecate your code anyway, so you're stuck with Angular 1.*)
Your team is too lazy to learn a new technology (in that case web might not be the right platform for this attitude anyway).
Angular was good for what it was doing and had its own Hype cycle. Web components solve many of the issues Angular was trying to address. Probably Angular had a role as a proof of concept for the Web components. But now it's time to move on. Web is reinventing itself everyday and it's inevitable to moves someone's cheese.
I'm not saying that Polymer is the ultimate answer to everything. At best it's another Angular which will render useless in a couple of years, but now it's a good time to learn and use it. The W3C standards don't die easily though, and Polymer tends to be much closer to them.
There's an element for that™ is the new There's an app for that™
TLDR: seriously consider writing an almost Angular 2.0-compatable Angular 1.3 app before rolling your own framework
It seems as if you've identified that Angular does a lot of things the right way and that's why you're attempting to replicate it, so basically you're going to roll your own by combining a hodgepodge of libraries. Unless you have an enormous investment of Engineering hours, the framework you build will likely be:
Lightly documented
A cross-browser maintenance nightmare and (worst of all)
Difficult for new hires to learn
If there wasn't a framework out there that did what you want to do already, I think rolling your own makes sense, but by trying to recreate Angular you're:
Taking on a lot of Engineering work that has already been done by a dedicated team, that could have been spent on building product
Made it MUCH more difficult to onboard new employees because you have to:
Find candidates that are willing to use a home-grown framework instead of growing their skills at an open source framework they could use elsewhere
Train these employees to use your framework (and good luck unless your documentation is mature)
I know your question asks how to replace Angular, but I've seen too many companies go the route of rolling their own and paying for it down the road. Again, if your budget includes a ton of core resources to build out (and document, and maintain) the framework and you don't think there is any chance corners will get cut when push comes to shove later if timelines get tight, then rolling your own might make sense. However, I think you should seriously consider reading up on how to write Angular 1.3 apps so that they're easy to port to Angular 2.0 and go the Angular route. Just look at the size of the community you're missing out on:
http://www.airpair.com/js/javascript-framework-comparison