171–180 of 191 posts
Earlier quoted context omitted.
> Templates are usually compiled into native javascript code once no they aren't. > (or at least, can and should be) not by default. React doesn't have templates at all ,so case closed.
> no they aren't. says who?
It seems to me they're missing the point. The implementation of ng-repeat is quite complex, and if, for some reason, it doesn't do what you want and you decide to write your own directive you have to deal with mutating the DOM in an efficient manner yourself. React on the other hand allows you to just generate your DOM structure and be fairly confident in it performing well by default.
> This little change ["track by"] invalidates 95% of comparisons between ReactJS and AngularJS.
Please, let's stop using arbitrarily specific numbers with data to back it up.
Earlier quoted context omitted.
The comment makes some sense if you replace "native" with "plain" or "vanilla" JavaScript.
yep. like 99.9% of the code ad networks expect. they want to check DOM state to make sure you are not a sleazy publisher hiding the ads under the content or if you are not being shown in an iframe on some porn site. with react, they will get inconclusive results because their code might run while they are virtualized or god forbid during the render. and you will only get garbage ads because now they consider you a ga…
Earlier quoted context omitted.
This is absolutely a contrived example. $index is the equivalent to `var ctrl = angular.controller`, something that serves very well to communicate basic concepts but that you would never use in a real-world application. If you're dealing with server side data, your model should have a real unique key/id, and that is what you track by.
The amount of stuff in AngularJS that "serves very well to communicate basic concepts but that you would never use in a real-world application" is a huge problem with the framework. It's a perfect storm of a documentation site and blogosphere full of misleading and/or contradictory advice and examples, combined with conceptual and implementation complexity that makes it incredibly hard to just read the source and ded…
Come to think of it, this describes a lot of PHP example code out there too.
Earlier quoted context omitted.
I guess it just comes down to comparing two different things. Yes, you have to do more setup with React because React isn't what Ext is. But if you set up your React to the point that Ext is at, with data binding and error handling and event listening that Ext magics away you get code that is very similar. Almost all of your code is doing what Ext magically does, but in a React application of any size these things ar…
Not to keep harping on this issue because I know we're way off topic, but I'm genuinely curious how the React code can be simplified because this was one of my main pain points using React. Reflux and alt were major improvements over the Facebook flux impl, but they still require the boilerplate I posted above. If you remove that then you have "Flux magic" :) There's no Ext magic in the code I posted. Flux and MVC ar…
myStore.setLoading(true);
myStore.save(...);
React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead. I wasn't truly interested in React until I read this, which does…
> Observables+DOM elements is a leaky abstraction The DOM itself is also a leaky abstraction. Render cycles are so prohibitively slow that we've started maintaining a parallel DOM and implementing diffing algorithms in JavaScript. As brilliant as that may be, it's also crazy that it's come to that. This is a problem that should be solved in the browser. HTML5 should add a simple API to transactionally update the DOM…
Earlier quoted context omitted.
The most interesting thing to me is that React's virtual dom implementation, according to http://vdom-benchmark.github.io/vdom-benchmark/ , is generally the slowest of the bunch. You could pretty much move to using anything else and have a faster vdom implementation and smaller library. Additionally, many out there are so similar to writing React that I don't see how using React is a win over the alternatives. In my…
React might be slower but it is more battle tested against multiple browsers than other vdom implementations, any vdom implementation might have to take performance hits to support older browsers like Internet Explorer 8
Developers have a tendency to get overly excited about speed. Fast database, fast search, fast framework, etc. The truth of the matter is that speed should be evaluated within a spectrum. As long as your application latency is within a spectrum, you should be just fine
React with a flux-like flow is simply easier to reason with... When I've used Angular, I always hit points of frustration or weirdness that simply didn't make sense... the more advanced bits of React are less surprising in my mind. It's a shift in thinking about larger component based applications.
It's also worth noting that Angular was started some time ago in 2009 and likely in development farther back than that... this is before CommonJS or AMD were widespread, and jQuery was a rising star. This is very much reflected in Angular 1.x.
React is a different approach with a slightly more functional mindset (though I'm still not 100% sold on the structure). With a flux-like workflow, it's very easy to reason/structure your events and data.. yes events take some extra declaration, but your workflows become a lot easier.
Earlier quoted context omitted.
Not to keep harping on this issue because I know we're way off topic, but I'm genuinely curious how the React code can be simplified because this was one of my main pain points using React. Reflux and alt were major improvements over the Facebook flux impl, but they still require the boilerplate I posted above. If you remove that then you have "Flux magic" :) There's no Ext magic in the code I posted. Flux and MVC ar…
And the reason you couldn't setup your stores in a similar fashion? myStore.setLoading(true); myStore.save(...); Where the handling is in your action handler for whatever event was raised... This assumes you do your backend data access in the store itself... there are other options.
React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead. I wasn't truly interested in React until I read this, which does…
> pleasant to work with if you're a startup or small shop. if you have to deal with any native code that expects to know something about the dom, now you just forced that code to do expensive and constant polling algos because you completely pulled the dom from under its feet.