4 ms·

This seems like a huge step back from declarative UIs, any reason why you would say it’s preferable?

torginus 5y ago
Performance, for one. This method can easily avoid allocating an object for every div (since it turns into a method call, not something that needs to return an object), compared to React's render() method. Another scenario outlined in the article of rendering a row of buttons, each with it's own click handler, that needs to allocate a lambda for each button every render. Alternatively, using map() and filter() also allocates lambdas and temporary arrays. All this can be replaced with a simple for loop like: for (item of items) { if(!item.isClickable) continue; if(button(item.name)){ console.log(item.name) } } Compare this to the React-ish pseudocode: items.filter(item=>item.isClickable).map(item=><button onClick={()=>console.log(item.name)} >{item.name}</button>) Readibility-wise, it's sort of an acquired taste, I'm not saying it looks better than JSX (but it's a hell of a lot readable than React.createElement, so some syntactic sugar might be put on top of it).
- mst 5y ago
  I suspect that the nature of the DOM means that being able to do that in the first place would actually require a virtual DOM w/diffing assuming you're targeting browsers. However that's probably obvious, so: Assuming you're considering greenfield / blue sky thinking here, it's worth noting that v8 has had so much money and engineering hours sunk into it that the react-ish pseudocode probably doesn't make nearly as many allocations as a naive reading of the code might expect. (a good friend of mine was very surprised to discover that v8's JIT is good enough that naive javascript code was basically competitive with FFI-ing out to C++ just because the node FFI layer introduced sufficient overhead that the JIT managed to catch up ... I am not a compiler wonk so please don't take this as a remotely expert pronouncement but "it is, in fact, quite difficult to overestimate v8 these days" seems to be a solid heuristic)
  - torginus 5y ago
    >the react-ish pseudocode probably doesn't make nearly as many allocations as a naive reading of the code might expect. Who knows, if V8 manages it to turn it into a for-loop? I don't, but after a quick googling, as of 2018, it certainly didn't: https://github.com/dg92/Performance-Analysis-JS https://github.com/dg92/Performance-Analysis-JS The problem with JS is that the execution model is so nebulous, that performance advice basically boils down to - trust in Google.
- antihero 5y ago
  Everyone goes on about performance but unless you are doing something extremely complicated or you have fucked stuff up in an extremely bad way, the actual part of React apps which is rendering to vdom and diffing to dom, in my quite long experience with it, is very rarely a problem, and not enough to warrant a stateful imperative approach.

Performance, for one. This method can easily avoid allocating an object for every div (since it turns into a method call, not something that needs to return an object), compared to React's render() method. Another scenario outlined in the article of rendering a row of buttons, each with it's own click handler, that needs to allocate a lambda for each button every render. Alternatively, using map() and filter() also allocates lambdas and temporary arrays. All this can be replaced with a simple for loop like: for (item of items) { if(!item.isClickable) continue; if(button(item.name)){ console.log(item.name) } } Compare this to the React-ish pseudocode: items.filter(item=>item.isClickable).map(item=><button onClick={()=>console.log(item.name)} >{item.name}</button>) Readibility-wise, it's sort of an acquired taste, I'm not saying it looks better than JSX (but it's a hell of a lot readable than React.createElement, so some syntactic sugar might be put on top of it).

mst 5y ago
I suspect that the nature of the DOM means that being able to do that in the first place would actually require a virtual DOM w/diffing assuming you're targeting browsers. However that's probably obvious, so: Assuming you're considering greenfield / blue sky thinking here, it's worth noting that v8 has had so much money and engineering hours sunk into it that the react-ish pseudocode probably doesn't make nearly as many allocations as a naive reading of the code might expect. (a good friend of mine was very surprised to discover that v8's JIT is good enough that naive javascript code was basically competitive with FFI-ing out to C++ just because the node FFI layer introduced sufficient overhead that the JIT managed to catch up ... I am not a compiler wonk so please don't take this as a remotely expert pronouncement but "it is, in fact, quite difficult to overestimate v8 these days" seems to be a solid heuristic)
- torginus 5y ago
  >the react-ish pseudocode probably doesn't make nearly as many allocations as a naive reading of the code might expect. Who knows, if V8 manages it to turn it into a for-loop? I don't, but after a quick googling, as of 2018, it certainly didn't: https://github.com/dg92/Performance-Analysis-JS https://github.com/dg92/Performance-Analysis-JS The problem with JS is that the execution model is so nebulous, that performance advice basically boils down to - trust in Google.
antihero 5y ago
Everyone goes on about performance but unless you are doing something extremely complicated or you have fucked stuff up in an extremely bad way, the actual part of React apps which is rendering to vdom and diffing to dom, in my quite long experience with it, is very rarely a problem, and not enough to warrant a stateful imperative approach.