4 ms·

Myself and most full stack devs in my circle using React used to do html/css/jquery before. Nobody misses the jquery days. As soon as you start fetching data fr

Myself and most full stack devs in my circle using React used to do html/css/jquery before. Nobody misses the jquery days. As soon as you start fetching data from api and refreshing your UI you get into a mess. Let's not forget that most MVC frameworks from the era imply mixing server side rendering with some partial client-side rendering on UI updates. Re-rendering your html from templates client-side, re-binding your elements to its events... it's objectively worse both in runtime performance and development wise.

mosdl 8y ago
React just does the rerendering and re-binding for you - and does it way less efficient than if you hand coded it. What you should be doing is just changing the parts that you know have changed. Letting react do the hard work will always lead to worse performance
- phponpcp 8y ago
  Yeah I dont know about that. If you've ever had to deal with optimizing event delegation and updating the DOM without causing massive repaints you'd change your tune.
- bernawil 8y ago
  Not really, at least in my experience. The re-binding really isn't the same as the jquery way. React reuses the same event handlers, how it's implemented is another story and not really important anyway. The other issue is the fact that in the old way it's implicit that there's a mix of server and client side rendering. Say you have a grid of data that was rendered server-side. Then you update a row, which posts to an api endpoint and you get a reponse that represents your new row. At this point there's only a couple of ways this could be done: 1. you get a json object which you pass to a javascript function which re-renders the row's html and re-binds all interactive elements. 2. You get server rendered html from the server, which then leaves you to call a js function to re-bind all interactive elements. some classic problems with this approach: 1. some rows data may depend on the data of other rows... now you have to sync client and server side state! (huge problem). 2. Remember that initial server-side view? guess what, all interactive elements had to be bound to the javascript handlers initially. Now you need code to initialize the view which is different to the one you use to do the partial updates. 3. Yes, I dind't even mention that we could send server rendered html full of inlined handlers as in "onClick=myClickHandler()". Because this leads to problem #2 right away. I'm not saying React and friends are perfect, but it does solve all of this, at least IMHO.

mosdl 8y ago

React just does the rerendering and re-binding for you - and does it way less efficient than if you hand coded it. What you should be doing is just changing the parts that you know have changed. Letting react do the hard work will always lead to worse performance

phponpcp 8y ago
Yeah I dont know about that. If you've ever had to deal with optimizing event delegation and updating the DOM without causing massive repaints you'd change your tune.
bernawil 8y ago
Not really, at least in my experience. The re-binding really isn't the same as the jquery way. React reuses the same event handlers, how it's implemented is another story and not really important anyway. The other issue is the fact that in the old way it's implicit that there's a mix of server and client side rendering. Say you have a grid of data that was rendered server-side. Then you update a row, which posts to an api endpoint and you get a reponse that represents your new row. At this point there's only a couple of ways this could be done: 1. you get a json object which you pass to a javascript function which re-renders the row's html and re-binds all interactive elements. 2. You get server rendered html from the server, which then leaves you to call a js function to re-bind all interactive elements. some classic problems with this approach: 1. some rows data may depend on the data of other rows... now you have to sync client and server side state! (huge problem). 2. Remember that initial server-side view? guess what, all interactive elements had to be bound to the javascript handlers initially. Now you need code to initialize the view which is different to the one you use to do the partial updates. 3. Yes, I dind't even mention that we could send server rendered html full of inlined handlers as in "onClick=myClickHandler()". Because this leads to problem #2 right away. I'm not saying React and friends are perfect, but it does solve all of this, at least IMHO.