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
So we've recently picked up React in our company as the front-end technology to build our huge business web application. By saying recently, I mean we don't have any previous experience with React (we have a huge background of AngularJS), and by saying huge application, I mean it's really huge and very dynamic with lots and lots of different pieces and functionality.
Because we will have a lot of huge components that all play a very important role and have complex logic inside them, and because we want them to be easily pluggable and reusable, we want them to be as isolated as possible from the outside world and other parts of our application, because otherwise because of their size and complex functionality it would be pretty much impossible to develop and maintain them. That's the reason why we have decided NOT to use Redux, at least in the beginning, while we are developing just the separate components themselves, because it compromises component isolation and makes the whole application data flow logic impossible to understand when there are so many complex components. Although I believe our choice could be wrong, because as I've already mentioned, we have no experience with React.
As I've already mentioned, the application is very dynamic. By that I mean that components are actually rendered by data. We use various configuration provider classes that interacts with our API endpoints to get the pieces of our application's configuration, like configurations of navigation, pages, various forms, lists, etc., and then try to render components that are read from that configuration.
The problem is, after a couple of weeks struggling to get the momentum with React and discover the right patterns and common solutions to our problems, we've been talking in our crew, that maybe React is not the right technology for us, as it's a UI library, not event a framework, and it doesn't help us a lot, but just adds its rendering rules that we have to break at times to achieve the dynamics and component independence we want.
Considering the component isolation and data flow management, I personally have heard that there is a language for front-end development Elm that has pretty robust data flow architecture where each component has its own model that is separate from others, but I don't know whether it's worth a try, as it may fall behind our big requirements pretty soon too.
The reason I'm writing this question here is that I hope to get an insight from people that have a solid background on working with huge front-end applications. I'd like to know whether it's possible to develop such an application with React, whether React is suitable for such complexity and dynamics, whether we really need Redux or something else, what path, practices, ideologies should we follow. If you understood my question correctly, it's more the architecture side that we are struggling with, than the technological. Maybe we are just walking the path that leads to more and more struggle and complexity but not towards production.
There is absolutely no question that React/Redux can (and is widely) used to develop the kind of applications that you describe. Nothing in your description makes what you are building so unique that it excludes React as a platform for building it. We are actively working with a large enterprise customer who is building their entire front end - with 100 + SPA (Single page applications) in React. This is a team of over 100 developers over a 2-3 year project.
The way we structured this has been crucial -
First, you want to choose a UI component library. A few examples below :
MaterialUI - https://github.com/callemall/material-ui
React Strap - https://github.com/reactstrap/reactstrap
React Bootstrap -https://github.com/react-bootstrap/react-bootstrap
Khan Academy React Components https://github.com/Khan/react-components
https://github.com/elementalui/elemental
We basically took one of these and built a component library off of them, because our components are very custom styled.
Second, we created a modular architecture, where each module (SPA) is an npm package with a main container component and redux store.
Finally, we have a central server package, where each of the modules is registered. The server package is responsible for authentication, authorization, logging, routing, etc.
The essence of this answer is not to advise on how to structure a large React application, but to let you know that React can be (and is being) used to develop applications similar to what you are describing.
I'm at the similar situation right now. I have a background in large desktop applications (ERP, LOB - WinForms, WPF) - 1000+ modules, very dynamic (more than 70% of the UI was generated by input data/configuration), adding new functionality was just about extending some configuration (without touching source code).
I'm deeply investigating current web technologies and I'm more and more convinced that React is not a good fit for that. React really shines in small/middle size applications where you (and other team members) develop every page/component 'manually' (not dynamically generated) and you want to have one global state. But it doesn't help you with building large scale application out of the box - it is only UI library (so no support for modules, routing, forms, binding, http requests, static typing (typescript), etc.) and to my surprise, there is no support for style shadowing/encapsulation (you have to integrate, for example, CSS Modules, by your own). And at the end, you have to constantly bother with libraries versioning (to make them always work together is truly time and energy consuming).
I have a great experience with Angular 2/4+ and I think, for now, it is the best technology for that kind of the applications (if you know WPF, it is very similar). It is a full framework, which is prepared to the scaling out of the box. You can split your app into independent modules (specifying which components will be visible to the outside world), every component has public api (statically typed, inputs/outputs) and encapsulated css styles (there is no interference between others).
For the global state (logged in user, global configuration, etc.), you can still use library ngrx/store (which implements Redux pattern and comes with extra nice things, like 'effects' and integrates really well into Angular ecosystem).
I tried to do in Angular really crazy stuff (dynamically generating the whole application from backend configuration) and everything worked perfectly, as expected.
You nailed the issue in your question- react is a view library, not an application framework. The real question is whether React+Redux(or other state management system) is appropriate for a large LOB app.
I will share some insights from our team’s experience in this realm. Large LOB apps have been developed using the MVC/MVP/MVVM design patterns for decades. These are tried and true patterns that ship software. Couple that with dependency injection and you have a modularized, testable, maintainable application. AngularJS (2.0+) is founded on these principles and leverages them deeply. For this reason we use AngularJS for all of our enterprise line of business apps.
React on the other hand is a lightweight, spritely view render that is awesome for smaller applications and client facing pieces (for example taking a dynamic survey or a simple dashboard). We often turn to React and VueJS here because the full AngularJS stack is way overkill and too heavy.
Getting started writing more complex apps in React can really be a struggle, I know exactly how it feels!
As you say, React is a UI lib and not an event framework. That's why you typically need a library to handle events, for example Redux. You clearly state that you decided not to use Redux (you even used capital letters for not :) ). I would take a step back if I were you and reconsider that decision. You say the reason for not using Redux is that your cannot keep your components easily pluggable and reusable when using Redux. I would argue that is not true. Redux is totally decoupled from your React components. Redux only handles receiving events, and managing state. From the React components point of view, it just receives data in props and sends events by calling regular functions. It's possible to still unit-tests, reuse, etc.
I would suggest you take another look at Redux with this in consideration. Happy to help if you have more questions!
React , Redux will make things easier because When it comes to
complex applications you can create Well structured data object. then you can manage the Complete UI through React and its
Materials ... There are some reasons Why this is right choice
State Management ,
Tree Structure data handling,
Reduce the code,
You will be knowing where the changes made (Actions, Reducers)
Your Component will only taking care of UI things
The things that you have to do is Structuring your data
Completely understand your feelings when you start with React and Redux. We were in the same situation when we started with React in our company. At first React has different approach than other frameworks. Yes of course it's not framework, it's just library. You have to start thinking in React way and that is: React components just render state (It's like you render scene on your graphic card at first you have to prepare scene then you are able render), all what component can do is dispatch actions, or better call just action creators.
You need some smart way how to store state in that point I will suggest use Redux.
We also use TypeScript with combination React, Redux. you have to write more code than pure JS but static type control is priceless when you work on large project.
Separating components logic is native approach of react ... you have to separate logic write "Dummy components" and then reuse this with connect. Or passing values as props.
We are using Thunk middleware as action creators it's good because connected component will call just method and logic is in action creators. You have access there to whole state of app then you can fetch something and base on result you can dispatch different actions.
What I like on react/ redux is how to implement async calls etc. First design component to map all states
1) like I have no data
2) data loading
3) loading done
4) loading error
For that you need only one semaphore in you state and a few checks in render method. Then one action creator that will load data and base on progress dispatch action that describing progress.
What is also cool that in react/redux app you have single data flow it's good when new dev jump into project.
For UI we are using Material UI, yes this framework has some problems but nothing what you will not able to deal with.
We are using also Router for navigating in app.
In the beginning I will avoid server side rendering because it will much easier for you start just with client side rendering and with initial state.
When we start for us was useful this template where everything works in one project JavaScriptServices
Then off course great Abramov tutorials.
For design components very useful Storybook
We can write why use or not React for long time ... but What I can say ... for us it was good choice, with some pain in begging but now we have good payback.
We started a large scale business application using Reactjs as frontend technology.
We have over 30 people in the team and we have over 15 modules in our product.
My approach is to the project is developing a common react project that handles only the Authentication, authorization and routing of the application and all other components developed as separate npm react libraries.
To develop the libraries I used https://www.npmjs.com/package/create-react-hook
This library generates the template with an example app which can use to test our library.
Following is the structure of the project
--Library 1 ( Developed using create-react-hook )
--Library 2 ( Developed using create-react-hook )
...
--Library n
--Common Container App (Developed using create react app and have used all above libraries using npm install)
The main advantage of this approach is developers can focus only on their npm packages and they can develop and test relevant component(s) separately.
The deployment also becomes very easy because we can just update npm package of tested version and rebuild the container app and do the deployment without affecting any other part of the application.
We are using this for several months and running the project with a large team without any issue. I think this may be helpful to anyone else too.
So this is just to share my experience working on an enterprise react application that is in production for years in several banks. yes, you heard me right. Now you can imagine how huge the application will be if it's related to fintech (I know it's not always the case). we have huge modules (70+) with a complex logic that pretty much handles a lot of the work that a bank needs. Modules are both isolated and re-useable. I am going to give an example of only one module so you can imagine the size of each module.
Card Production Module
Bulk Card Generation
Bulk Card Export
Bulk Card Request
Card Operations
Card Operations Approvals
Card Printing
New Card Requests
Pin Generation
Pin Printing
This application is a product, not a project and as a product it is configurable. Even the UI is configurable. I have been working on this application as a full-stack developer. Since it's pretty old the state management library that we are using is flux. With state management, the development speed is a little slow but the tradeoffs are better with us not being worried about state management. By far the application has been able to handle huge changes and things which seemed unachievable. Stability has also been a key element throughout this period.
On the back-end, we have Restful services build using Dot Net which supports both MSSQL Server or Oracle depending on the client's needs/feasibility.
After countless react.js projects, I summarized a domain oriented and practical architecture in my blog post.
It is the absolute best practice that I applied many times, enjoy:
http://denislutz.com/domain-architecture-for-react
I need to design a huge client side application by following MVC architecture.
As of I know angular is best for developing a SPA by in mvc architecture.
I'm not familiar with ReactJS, when i'm going through ReactJS i came to know that ReactJS is best creating user interfaces and building reusable components.
link https://facebook.github.io/react/docs/why-react.html says React as the V in MVC.
From that my question is:
is it possible to use both angularJS (framework) & reactJS(library) in same SPA.
is it possible to create Views using ReactJS and other part of my application in angularjs (M & C part in MVC).
You are correct, React in itself as a smaller scope than Angular, it is not a so-called "framework" but it's a library used to render views, or components inside a view. You will have to assemble many other libraries around React to get a full SPA application, however the good news is that skilled developers already picked them for you and pulled out very useful boiler plates that should get you started much much faster than if you were to do all the work by yourself.
Take a look at those:
Find your perfect React starter project
react-boilerplate
react-redux-starter-kit
I based my latest app on the 3rd one and I love it, but it's personal ...
Now your questions:
Yes you can use both, take a look at ngReact, let's you run React components in an Angular app. If you start from scratch however and don't have legacy code or libs written in one of the two technologies, my recommendation would be to either use one or the other. This kind of hybrid solution would let you slowly migrate an Angular app to React by rewritting one by one your components without breaking the whole app at once.
That's pretty much what I said in 1/ this can be done but if I were to write the app from scratch I would pick either Angular or React depending on time constraints, existing code base and willingness to learn a new framework. My recommendation: take a few days to experience various boilerplates and pick the one that you feel the most comfortable with...
The owner of the DurandalJS project is now working at Google on AngularJS Next (v2?) in addition to keeping the current version of DurandalJS maintained. The two frameworks are converging.
http://blog.angularjs.org/2014/04/angular-and-durandal-converge.html
For a new mini-SPA project, which framework would be the best choice specifically with regard to the upgrade path?
I note that Rob Eisenberg has listed a number of tips to help existing DurandalJS users get ready for the next version, so it appears there will be an upgrade path available, but I'm wondering if the upgrade from AngularJS to the next generation framework would be simpler.
http://eisenbergeffect.bluespire.com/preparing-for-durandal-nextgen/
To be clear - I'm more concerned in making the right choice for the future (large SPA, split into multiple mini-SPAs) than for my current needs.
I'm not sure which one would be the best choice for now ... actually I'd say none of them is future save enough. Angular 2.0 is going to be definitely different from 1.0 and of course also from Durandal.
Nevertheless the framework itself maybe not that important. I think you should focus on separating code in reusable components. Whether it is a Angular Service/Factory/Provider or a clean Require Module in Durandal it actually doesn't matter. Getting it into the "NEW" Framework should be just a matter of adding the proper wrappers. As for 2-way-binding use the oberserver plugin to maintain clean POJOs.
The most important change from my perspective in NG2 will be the support of Lifecycle events, so even using those in Durandal now will be somehow supported in NG2. As for composition there for sure will be a way to simulate that easily in NG2 as well.
For current work the only two things important for the decision of the currently used Framework in my opinion are the use of RequireJS and Framework simplicity. Sure you can add it to Angular as well, there are several guides on that, but Durandal was built from ground up with RequireJS in mind. Especially in bigger projects this can save you a lot of headache from missing or wrong dependencies. As of the second argument -> porting Durandal to Angular is not that of a big deal because it's written in an easy and understandable way. Vice-versa may be a totally different story. Getting your custom Directives implemented as a combination of templating and ko-bindings can get pretty hard :)
So as a closing statement, if it's going to be a small project, but with the need for continuous support as well as update to NG2 in future, I'd go with Durandal. Besides RequireJS everything is exchangeable and adaptable. In the case of Angular I'm not sure how drastically the new DI system will change the way of development so that would be a show-stopper for me.
Btw. here is the design-document for NG2. So as you see there kinda everything that is important is gonna change:
Router
Persistance
Directives
Modularization (maybe we finally see RequireJS :) )
Does it make sense having a solution that uses both Freemarker and AngularJS?
I tried to convince everyone on my team of switching to Angular, and a more experienced developer than me pointed out that he prefers server-side rendering, which is both arguable and valid. But then he told me that if I still want to use Angular just use it with Freemarker instead of replacing it.
I'm a junior programmer, as far as I can understand they are designed to the same purpose.
It depends on the needs.
For example, if you want to break your page into individual re-usable components that you can tie based on some logic on the server side, then using freemarker or velocity for building these components makes sense.
The freemarker or velocity templates might in-turn use angularJS components that would be rendered on the browser and evaluated on the client side.
The server side templating would give you the ability to design re-usable angular components.
Now, some may try to use the Object component in HTML5 for doing the same thing, but this is not recommended as using Object expects a fully formed HTML element with its own <html> opening and closing tag.
Not something that is intended for a small reusable component.
As an example consider having your page header and footer in its own html template file that you would like to tie in for all the pages in your application.
As I google for Freemarker i realize it is just a templating engine. AngularJS is not a templating engine. Templating engine is just part within this framework. So both of them cannot be compared.
AngularJS is a full fledged framework for creating Single Page Applications (SPA). So if you want just templating capabilities on client side, i suggest you better look for some other light weight libraries.
If you want to use AngularJS you need to decide
Whether you can structure your app as a SPA
Does the site needs to be SEO optimized. Which has limited support in Angular or as a matter of fact in any client side framework.
Ready to use the AngularJS templating engine because it is awesome with its support for oneway\two way active bindings. If you don't use it templating engine you are loosing a lot.
No it clearly does not make sense as they serve very different purposes. All I can think of is that you either misunderstood the more experienced developer or he really has not understood the business case (WHY something is worth using) of using either technology. In my experience as a j2ee developer, I find that many server side developers (experienced or not) may not be too educated on the many new advances recently made in client side development. With Angular you are not limited to SPA. You need an insight into the overall architecture of your current project to determine if its a good fit. There are ways around the SEO issues or you can purchase an SEO solution. But clearly not a best choice if SEO is essential.
Unless it is a team decision and there are clear problems Angular solves for you, I would not suggest getting stuck alone with a new technology that only you know. Keep it as a hobby and when you really understand the best practices and benefits you can then try being an evangelist.