3 ms·
The idea behind React is pretty cool, that all DOM transformations happen in the template. But that's all it is. There's no need for a vdom for the most part,
by bigmanwalter 9y ago
The idea behind React is pretty cool, that all DOM transformations happen in the template. But that's all it is.
There's no need for a vdom for the most part, template strings and innerHTML are fast enough on their own.
I just find React to be an overly complicated way to achieve its goals.
var model = { text: '' }
var component = $( '.component' ).on( 'render', function() {
$(this).html( `<div>${ model.text }</div>` )
})
update( 'text', 'Hello world' )
function update( key, val ) {
model[ key ] = val;
component.trigger( 'render' )
}
That's React in 8 lines of jQuery. My framework is just a minor extension to this concept.
- tomasroggero 9y ago> That's React in 8 lines of jQuery No sir, that doesn't include server side rendering or diff rendering either (meaning changing a bit on the top component would re render all markup, not just what has changed) Stop trying to over-simplify. The problem being discussed here is not React vs jQuery. It's what we do and the decisions we make as engineers to provide a good experience based on performance which is OUR side of UX.
- bigmanwalter 9y agoI mean, you can use either the of the morphdom or setdom libraries to do the diffing if you don't want to replace all the HTML, but the concept remains the same. I'm not convinced by arguments such as "when you're a large team it's necessary". Scaling teams has more to do with project structure than what rendering library you use. Likewise, it's much easier to tweak performance when you aren't depending on a monolith like React or Angular.