As I don't know anything about React jet, I am wondering, what are the main benefits of introducing React in Angular's directives and what are down sides?
Basically I am working on some complex software with lot's of renderings in one cycle. Obviously I already excluded ngRepeat, etc. but I am wondering if React can speed up rendering in this case even further?
Is react better only in rendering lot's of element's or is it better in rendering of small amount of them as well?
That's a subject I've studied at work and here are my conclusions about adopting an hybrid solution (AngularJS 1.x and React) :
Pros :
best of both worlds (speed, testability, a lot of convenient things already are implemented in AngularJS — $http, $cookies, whatever)
probably forces to uncouple more and more the code. Since the two worlds can't really share components/services, you'll have to adopt a nice architecture which will lilely makes the two parts easy to plug/unplug. Say you wanna use Angular2 components after all, a lot of uncoupling work will already be done.
Cons :
You'll have to glue stuff together. The glue code can end being more complicated than expected
You'll have to load two frameworks/libs. Although that might not be a problem for SAAS apps, it can very well be for regular websites with a lot of unique visitors.
You'll have to learn another framework (should that be in the "Pros" section ?)
Maintainance bad smell : the less different technologies, the better
An overall more complicated stack
In the end I think that if you don't absolutely need React, try to implement your component in regular JavaScript to avoid excessive $apply cycles. It's cleaner in my opinion.
You can take a look to this link. This video was recorded last year in the ng-conf and explains how you can speed up your angular application rendering certain elements with react.
I think it can help you.
Related
In team Vue.js project I'm curently working, I wrote something like this in view:
component01
component02
...
There is more than 10 componenets. In every component is one section of landing page, nothing fancy, mostly HTML/CSS and some animations, components don't have props and are used only once. Idea is to simplify maintenance of code - instead of editing view page with, for example, 1000 lines of code, we can edit component with 100 lines of code.
And got instructions to merge all components into one view (eg. 1000 or more lines of code). I'm OK with that, but got me thinking and searching for opinions.
Is there best practice for situations like this - use components even if there is no repeating and no props, to simplify code, or hold everything in one view (and long) file. Components can be in separate folders, so big number of components should not be a problem. Or will they?
Components are the building blocks of all modern JavaScript frameworks as they provide a better overall architecture for your application in terms of reusability, testability, maintainability and in the end SOLID and KISS principles.
I would recommend splitting your app in smaller and presentational components and use services for business logic. It does not matter if the application is small, by following these principles it will be able to grow with no or less pain. That is the way Angular encourages you to build applications.
As always in this industry, don't overuse these concepts and apply where appropriate and with common sense ;-)
This is basically the same old, same old x vs y, what is faster?, but I do hope my version is applicable. Also, React and Angular differ like GTK and Qt (or even more), and comparing them is stupid - one is an out-of-the-box can-do-anything framework, while the other is a View framework designed to only do that. If my question still is unanswerable or subjective and should be closed, please write me a comment how to improve it in the future, if possible. Thank you.
This is a question about Angular 2+ vs React in terms of performance. My team shall build one SPA for identical functionality with each framework.
Assume:
development time for both versions should be equal / similar
non-view related functionality (where Angular differs from view-only React) is unimportant to the measurement and development time, updates to the view happen frequently and are the bottleneck
measured is steady-state performance after initial page-load (so all data for the page is within memory)
both applications are built the way the relevant handbook would recommend
client-side rendering only, with mostly dynamic data (so not much server-side rendering or ahead-of-time-compiling)
Javascript VMs are difficult to reason about, but my two questions are exactly about their behavior:
Would there be a clear performance winner after current-gen JIT has done its part (optimizing as far as possible) or would the final performance be equal?
In the year 2027 we will still use webbrowsers (probably Chrome 256 or Firefox 384). Assume both frameworks still exist and kept their core strategy / mechanics the same as today. Browser Javascript VMs / JIT improved further and further, but I keep my current laptop to measure performance. Which framework would probably win in 2027? Or to rephrase the question: which strategy is theoretically more optimal / 'closer to the metal' (or in this case: closer to Javascript execution models)?
PS: I'm pretty sure in 2027 we will not use either, and this question is also not about which framework anyone should prefer, but only theoretical performance. The question about which framework would be 'closer to the metal' came up one night with friends and should not be used by anyone to make a decision. Never make important life decisions drunk or late at night.
My experience but not the final decision
I started with Angular and wanted to see what React could do. React is certainly not bad, but what I immediately noticed was the disorder that can prevail. That depends on the developer, of course, but with Angular and TypeScript everything looks more orderly and structured. Template and code are separated and with React you have the JSX, i.e. HTML in JavaScript which is JavaScript. Reminds me a bit of PHP and I never liked that, because when a project gets extremely big, you really lose track. For one component you could easily have 3-5 files and that is bad in my opinion.
With Angular you can also lose the overview, but you have a uniform structure with a few deviations.
If your application becomes really very very big then it makes sense to use Redux but why people making life complicated. If you just want to check if a user logged in or not for a middle large e-commerce site then services would also do the job.
In my opinion, the user should focus on working. Redux it is fine but we should not add every new tool which comes each week to our project either is reduce cost and time dramatically. But if you add new tools then you should also have people who can handle it later. It doesn't mean if you use every tool that your application is good or you are a good developer automatically. In my opinion, keep everything as simple as possible and use the tools you really need to fulfill your requirements.
And by the way I don't understand why the people still want to use Vaadin, Spring Boot together with Angular in combination. Maybe someone can explain it me?
I have a performance issues with Angular (as many others). I wish to change only the view layer to either reactjs or Mithril. I found examples of React js (for example http://www.bimeanalytics.com/engineering-blog/you-put-your-react-into-my-angular/), but not of Mithril.
Can anyone advice to the pros and cons of using Mithril as an angular view vs Reactjs?
Thank you!
I don't think there's an objective answer here, and as a Mithril user I have my biases, but here is what I think.
In terms of philosophy, Mithril and React are quite similar: you write view functions that describe how your app should look at any given time. In terms of rendering performance, I don't think there's a clear winner. There are links / blog posts that say Mithril is faster than React, and vice versa.
So instead what I think you should focus on is:
1) Which API do you prefer? With React you should use JSX lest you have to reverse engineer their documentation. Mithril also just has one lifecycle hook (the view function), whereas React has several (such as shouldComponentUpdate) -- do you need all those hooks?
2) Community support -- React is the clear winner here, and the fact that there are existing examples of integration with Angular is a win.
3) Compatibility - DOM redrawing / diffing in React is done when data changes, just like Angular, but Mithril's redraw is centered around user interaction (such as clicks, route changes, ajax requests). You can manually redraw, but that's less desirable. I don't know how well Mithril will fit into an Angular setup.
Should you decide to use Mithril, I'd encourage you to use the Google group (https://groups.google.com/forum/#!forum/mithriljs) as a resource, or at least report back on your experience.
Mithril and React have many similarities. I've used both of them and here are some pros and cons.
Mithril
Pros: It's loading times are very fast. This is because it's templates are compiled first and then served to the browser. You can write Mithril views in JavaScript. Small size, good documentation and doesn't force you into a predefined structure.
Cons: Small API can make it unsuitable for larger more complex projects.
ReactJS
Pros: React's one-way data binding means that it's easy to see where and how your UI is updated and where you need to make changes. It also provides server-side rendering, virtual dom support, good debugging tools, easy to write tests, easy to reuse components, flux architecture patterns, and extensive SVG supports etc.
Cons: Heavy on memory compared to Mithril, not a complete solution as it mainly focuses on the view, and need to learn a new syntax etc.
In my view, React is overall preferable. But, if your application doesn't need all these extra stuff that React provides, you should go with Mithril.
I have been using JavaScript and jQuery for quite a while now and want to extend my skill set further, during my search I came across two popular names Angular and Backbone and while reading about them I found one line common in both them which somehow also seems to be their USP i.e.
It is designed for developing single-page web applications
This makes my confused.
What is that I cannot do with JS or jQuery and I would require these?
I have created web application on single page, where users can perform CRUD operations on single page through asynchronous calls so why so much importance of for these others libraries?
And as a middle level web developer who has have good hands on JS is it right path to move to these two or here is something else I should look into before these?
Please help?
Structure.
In an ongoing project that started about 4 years ago we built the front end with jQuery. We were able to do just about everything that we needed creating several single page applications that were quite functional.
As the project progressed and the code base grew we started experiencing some major problems with maintainability of the code. We ended up with hundreds or thousands of lines of JavaScript code per page in a tangle that was almost impossible to navigate. This could have been avoided if we were more careful of course but at the time we focused on making sure the back end architecture was robust.
Many years ago the community learned that code needs structure to be maintainable. We developed MVC patterns, multi-tiered applications etc. But JavaScript was never a big player in the field and we largely ignored it.
Over the last 6 months or so we introduced Angular into the project and started sorting out some of the mess in the project. The results are remarkable. Not only is the code simpler and easier to create, the structure makes it easier to implement tests, easier to maintain and generally a huge improvement over what we had before. We still use jQuery but now we have been burnt by the lack of structure and know a thing or two about the architecture of a JavaScript application. Angular and its like provide you with the tools to architect a good application.
When you are creating larger scale web applications it is wise to check out Backbone, Angular or perhaps Meteor. jQuery supports neat tricks, but it does not help you structure your code in a maintainable way. Larger scale web apps build on jQuery need their own vision on how to separate the code into layers with their own responsibility.
The other frameworks give more support.
I would suggest checking out at least one of the libraries. Perhaps you eventually won't use them, but it will benefit how you work in jQuery.
Well Now a days there has been quite a hype about Angular.js and especially SPAs (Single Page Applications). Well to be honest, I had the same question in my mind about a month ago when my team decided to shift from Jquery to Angular.
Whenever it comes to Jquery, one of the first thing that comes in our mind is the DOM manipulation. While using Jquery we always think of manipulating the DOM. Show/hide elements, animating elements, getting data from tags you name it. But Angular offers something more than that. It offers you an architecture, a way to structure your applications at the front end.
So whenever you go for Angular.js, change the way you think about creating web applications (and believe me its worth it). Most of Angular's structure uses the concept of Dependency Injection which is a neat way to maintain your code.
Backbone is only a library whereas Angular.js is a complete framework to create and manage Single Page Applications
Talking about the fact that Angular.js should be used when we are creating large scalable apps, it is true. In my case the team I work with is full of Jquery Ninjas. We have been creating a great app for the last 3 years and believe me it became difficult for us to maintain and debug thousands of lines of Jquery. This is the main reason we have decided to revamp this app into Angular.
Kindly see some of these Helpful links. You will get a better idea.
http://net.tutsplus.com/tutorials/javascript-ajax/3-reasons-to-choose-angularjs-for-your-next-project/
"Thinking in AngularJS" if I have a jQuery background?
How should a complex single-page JS web application be structured on the client-side? Specifically I'm curious about how to cleanly structure the application in terms of its model objects, UI components, any controllers, and objects handling server persistence.
MVC seemed like a fit at first. But with UI components nested at various depths (each with their own way of acting on/reacting to model data, and each generating events which they themselves may or may not handle directly), it doesn't seem like MVC can be cleanly applied. (But please correct me if that's not the case.)
--
(This question resulted in two suggestions of using ajax, which is obviously needed for anything other than the most trivial one-page app.)
MVC architecture of PureMVC/JS is the most elegant IMO. I learned a lot from it. I also found Scalable JavaScript Application Architecture by Nicholas Zakas helpful in researching client side architecture options.
Two other tips
I've found view, focus, and input management are areas that need special attention in single page web apps
I also found it helpful to abstract away the JS library, leaving door open to change mind on what you use, or mix & match should the need arise.
Nicholas Zakas's presentation as shared by Dean is a very good place to start with. I was also struggling to answer the same question for a while. After doing couple of large scale Javascript products, thought of sharing the learnings as a reference architecture in case someone needs it. Have a look at:
http://boilerplatejs.org/
It addresses common Javascript development concerns such as:
Solution structuring
Creating complex module hierarchy
Self contained UI components
Event based inter module communication
Routing, History, Bookmarking
Unit Testing
Localization
Document Generation
etc.
The way I build apps:
ExtJS framework, single page app, every component defined in a separate JS file, loaded on-demand
Every component contacts its own dedicated web service (sometimes more than one), fetching data into ExtJS stores or special-purpose data structures
The rendering uses standard ExtJS components, so I can bind stores to grids, load forms from records, ...
Just choose a javascript framework, and follow its best practices. My favorites are ExtJS and GWT, but YMMV.
Do NOT roll your own solution for this. The effort required to duplicate what modern javascript frameworks do is too big. It is always faster to adapt something existing than to build it all from scratch.
Question - What makes an application complex ?
Answer - The use of word 'complex' in the question itself. Hence, a common tendency will be to look out for a complex solution right from the beginning.
Question - What does the word complex means ?
Answer - Anything that is unknown or partially understood. Example : The theory of Gravity even today is COMPLEX to me but not to Sir Isaac Newton who discovered it in 1655.
Question - What tools can I use to deal with complexity ?
Answer - Understanding and simplicity.
Question - But I understand my application . Its still complex ?
Answer - Think twice, because understanding and complexity does not co-exist. If you understand a huge huge application, I am sure you will agree that it is nothing but an integration of small and simple units.
Question - Why all of the above philosophical discussion for a question on
Single Page Application (SAP)?
Answer - Because,
-> SPA is not some kind of core technology that is newly invented for which we need to reinvent the wheel for a lot of things that we are doing in application development.
-> Its a concept driven by the need for better performance, availability, scalability and maintainability of web applications.
-> Its a fairly newly identified design pattern, so an understanding of SPA as a design pattern goes long way in making informed decisions about the architecture of a SPA.
-> At the root level no SPA is complex, because after understanding the needs of an application and the SPA pattern, you will realize that you are still creating an application, pretty much the same way you did before with some modifications and re-arrangements in the development approach.
Question - What about the use of Frameworks ?
Answer - Frameworks are boiler plate code / solution for some commonly identified and generic patterns, hence they can take off x% (variable, based on the application) load from application development but then not a lot should be expected out of them specially for heavy and growing applications. Its always a good case to be in complete control of your application structure and flow but most importantly the code for it. There should be no grey or black areas in the application code.
Question - Can you suggest one of the many approaches to SPA architecture ?
Answer - Think of your own framework based on the nature of your application. Categorize application components. Look for an existing framework that is close to your derived framework, if you find it then use it, if you do not find it then I suggest going ahead with your own. Creating framework is quite an effort upfront but produces better results in long run. Some basic components in my SPA framework will be:
Data Source : Models / Collections of Models
Mark Up for presenting data : Templates
Interaction with the application : Events
State capturing and navigation : Routing
Utilities , widgets and plug-ins : libraries
Let me know if this helped in any way and good luck with your SPA architecture !!
The best thing to do is to look at example uses of other frameworks:
TodoMVC showcases many many SPA frameworks.
You can use javascript MVC framework http://javascriptmvc.com/
The web application that I am currently working on uses JQuery and I would not recommend it for any large single page web application. Most frameworks i.e. Dojo, yahoo, google and others use namespaces in their libraries but JQuery does not and this is a significant drawback.
If your web site is intended to be small then JQuery would be ok but if you intended to build a large site then I would recommend looking at all the Javascript frameworks available and deciding which one most meets your needs.
And I would recommend applying the MVC pattern to your javascript/html and probably most of your object model for the javascript could be done as the json that you actually return from the server through ajax and the javascirpt uses the json to render html.
I would recommend reading the book Ajax in action as it covers most of the stuff you will need to know.
I'm using Samm.js in several one page applications with great success
I would go with jQuery MVC
Check out http://bennadel.com/projects/cormvc-jquery-framework.htm Ben is pretty sharp and if you dig around on his blog he has some nice posts about how CorMVC is put together and why.
Alternative: take a look to ItsNat
Think in JavaScript but code the same in Java in server with the same DOM APIs, in server is way easier to manage your application without custom client/bridges because UI and data are together.
Or have a look at https://github.com/flosse/scaleApp
NikaFramework allows you to create single-page application. Also allows you to write HTML, CSS (SASS), JavaScript into separate files and bundle them into only one output file in the end.
I would recommend to explore Yeoman. It allow you to use existing "best practice" for your new project.
For example:
if you decide to use Angular.js, there is a Yeoman generator, that give you a structure for routing, views, services, etc. Also allow you to Test, minify your code, etc.
If you decide to use Backbone, checkout this generator