Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have worked in Angular js and find it to be developer friendly and ease of use is awesome. I found out it performs extremely good with SPA(Single page application) architecture and if controller scope variables are not misused.
I however don't know why most of eCommerce companies complaining angular being not performing equivalent to reactjs. I think in lot of use cases might not event found the visible performance difference, with development effort being less.
Angular followed MVC ideology, while React is developed with MVVM design. I don't consider myself a very good programmer in either of them, anyways I have started learning reactjs, so I want to know should I go for react js for my own project or not, one clear advantage is isomorphic rendering.
I tried to make this a comment but ran out of space :)
As with anything, it is as fast as the developer can make it :) A good AngularJS developer can make an app that is faster than a bad developer creating a React app.
Having said that, React will be faster out of the box with a LARGE amount of elements on screen. AngularJS will require some knowledge to make it fast with lots of on screen elements. But I fully expect for most people they won't ever see any performance drop with most apps. E.g. if you want to make a fairly complex application with a couple of hundred dynamic objects on screen you shouldn't see many performance problems.
If you do choose AngularJS [my preferred framework] I would suggest following the latest component guidelines as it will help you build a performant application.
As an indicator I am working on an asset tracking AngularJS app. We can track around 2000 elements on screen a map at once with lots of additional information and this works pretty fast. It took a lot of work to get there though. It also works great on mobile too :)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I've been coding React for the last couple of months now. I thought, initially, just going through the React official docs would be sufficient. But I've had to learn some other tools in order to really make my apps useful/easier to developer. For example, tools like Redux and react-router. How come these tools don't already come with React officially? What's the true purpose of React vs other JS frameworks?
ReactJs is not a framework ,it's a JavaScript library and it's not a language ,it's build upon JavaScript . It's a way to solve your common problems and complex tasks easy to do.
Angularjs/Angular is a fully fledged framework - it gives you built-in solutions for promises ($q), ajax calls ($http), routing and intra-component communication via services amongst others.
Reactjs on the other hand is much less opinionated. It provides a mechanism to layout and structure view code and practically nothing else (from the list above). So it's much lighter weight and you are much freer to use other libraries/packages where you feel it is necessary.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I would like to understand how to conduct an independent evaluation of available popular JS front-end frameworks (React/Redux, Vue, Angular and others) for use in a new app we are trying to build ground up.
Many references online end up with conclusions and rates one framework over another. However, I find it difficult to relate with. Say, one report says learning curve for Vue is simpler than JSX for React. I don't find that argument very meaningful since it depends on one's exposure and idea of modularizing a UI component.
So, this SO question is raised to get receive a mixed bag of evaluation suggestions/strategies/schemes to conduct an independent inquiry into these available and popular frameworks.
What themes and approaches can I consider to evaluate popularly available front-end frameworks ?
Please advise.
This answer is given by jeremy-d and copy paste his answer because i
love react and i found react more interesting to work. It's be 1 year
in react and the react community is also very active.
https://stackoverflow.com/users/856942/jeremy-d
Advantages of using React:
easy to know how a component is rendered, you just look at the render function.
JSX makes it easy to read the code of your components. It is also really easy to see the layout, or how components are plugged/combined with each other.
you can render React on the server-side.
it is easy to test, and you can also integrate some tools like jest.
it ensures readability and makes maintainability easier.
you can use React with any framework (Backbone.js, Angular.js) as it is only a view layer.
What is not so good about React?
it is only a view layer, you have still to plug your code for Ajax requests, events and so on. Some people get surprised by that.
the library itself is pretty large.
the learning curve can be steep.
If react-native is really how it was described, react is going to become even bigger.
Performance wise, it is really good as it relies on a virtual-dom to know what is really changing in your UI and will re-render only what has really changed. It does have trouble with very large, slightly changing, lists of children (2000 <li> test), but can be optimized simply.
If you are not sure, just think about the big projects using React:
instagram, hipchat, facebook chat and so on.
Some resources:
React for the stupid people
Rebuilding Hipchat with React
Why React?
And probably one of my favorite blog post Why React is awesome?
The community behind a framework is one of the most important factors for me. I want to be able to find answers on Stack Overflow for my questions, and I want to be able to find libraries and packages I can use that are actively maintained.
I like React most of all because it is easy to integrate into some other backend framework e.g. Rails.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
If you're not creating a single page website or generating components on a page that get live updates is there any reason to use a JavaScript framework like angular, react etc?
No, there is not.
But there are things like modules, cross-browser DOM manipulation utilities, routing, 2 way data binding etc. which don't come out-of-the-box with JavaScript but are provided by these frameworks which really helps quicken the development process.
You probably shouldn’t use a JavaScript Framework. Instead, you should write modular, vanilla JavaScript. You also probably shouldn’t be considering a JavaScript MVC framework, especially if it’s going to be architected in the same way as a server rendered application (going to use site/application interchangeably). With a high performing site, you’ll likely squeak just as much perf out of a server rendered app as you would a “single page” app. Between sending less down the line to your users (reducing bandwidth and time to load), keeping their cache size small (making it more likely they’ll have something in cache next time), and reducing the memory footprint of your JavaScript (increasing perceived and on-page performance), you’re likely better off rendering on server.
If you absolutely must use a JavaScript framework (development skills across the team aren’t high enough to write vanilla JavaScript and there’s not time/money/interest in training the team and improving their skills, there is a real, not perceived, business need to support very old and outdated browsers, etc…) for server rendered applications, you should probably use jQuery. Yes, there’s Zepto and any number of other things you can use in place, but you should probably use jQuery.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
There are a lot of "buts" in approaches to web development. Recently I've read an article
why not to use Twitter bootstrap. One of the reasons were that it doesn’t follow best practices. Well I don't want to discuss about TB. What I wanna know is how is it with Modernizr - it looks like that has a lot of advantages, but what about dissadvantages? Is that also redeemed by using bad programming practises on web (like these mentioned in twitter bootstrap)?
By good practices I mean ideas which are connected with Html5 and CSS => this is not opinion based question - I'm basicly asking if Modernizr is in contrary with these ideas.
Modernizr itself tries to follow best practices as best as possible, however there are a few things that it does that aren't necessarily "best practice"
it basically requires being loading in the <head>. Since one of the main uses of Modernizr is the css classes that are added, you actually want it to block the rendering of the page until after it has ran. If you load it in the bottom of the page (which is the "best practice" for javascript, generally) and rely on the classes it provides, you would see a flicker between the non-support and support versions of your styles as it runs.
It can be heavy. There are ongoing discussions on the github issue tracker about how we can improve the execution time of the library, as well as new preposed updates to the lib that would group tests to increase speed
Not only that, but it can be used poorly. One of the most common issues is that people deploy their public website with the debug build of Modernizr - the one that includes ALL of the tests. This means running very large amount of javascript that never impacts your site.
Other than that, modernizr tries very hard to help define best practices, let alone just follow them. If you ever find there is any issue what so ever, I would really encourage you to open up an issue on the github repo to help us move the internet forward.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I recently discovered Typescript. Coming from an OOP C# background, I find Javascript very difficult to work with and am naturally thrilled about Typescript.
I'm currently using Backbone.Marionette.js in my application to manage future complexity (future because it's still the early stage and not yet that complex).
Now I understand there is still room for Backbone.js to play an important role in my application even if I'm using Typescript, but the more I learn Typescript (and begin to love it), the more I start thinking that its objective in managing complexity in enterprise application overlaps too much with what Marionette tries to accomplish. I understand they do it in two completely different ways but coming from C# I of course prefer the OOP approach instead of yet another JS plugin.
Are my considerations to phase out Marionette out of my application justified or is there less overlap than I think? Keep in mind, I'm new to all 3 Backbone, TypeScript, and Marionette and this is the first application I've used them in, which makes it difficult for me to assess this question.
"TypeScript vs Marionette" is the wrong perspective. That would be like "C# vs WinForms", and asking "Should I stop using WinForms when I switch from C# to VB.NET?" This question doesn't make any sense because it is trying to compare a language to a framework.
There are some things that TypeScript will prevent you from doing with Marionette or any other JavaScript framework that takes advantage of JavaScript being dynamic. But that doesn't mean TypeScript replaces Marionette or any other framework. It only limits the usefulness of the framework due to restrictions that TypeScript places on you.
My answer would be based on the following considerations.
Firstly, what parts of Marionette are you using? If it is just the module loading then you don't need it. If you are using a lot of the templating and eventing it may be useful still. If you aren't sure yet what parts you might use, don't use it until you have a compelling reason to use it.
Secondly, how much can you write before you need to make decision? For example, if you start coding today, how long can you defer the decision. The longer you wait, the more information you'll have to help you make the right choice. If you write plain TypeScript, you can wait until you actually need to bring in a framework or toolkit and then choose the one that solves your real problem.
So really, my answer is start without it and wait until you have a problem to solve before choosing how you solve it.