4 ms·

The good part about React is that given a `messages` data structure and a `render` function, it implements `addMessage`/`addMessageBefore`/`updateMessage`/`remo

The good part about React is that given a `messages` data structure and a `render` function, it implements `addMessage`/`addMessageBefore`/`updateMessage`/`removeMessage` on its own. Writing once and not multiple variants of the same is good. Another good thing is that that there are a lot of components someone already published, that are ready to use (immediately, or after a few small fixes/PRs). The bad part is that React has a lot of code on its own, and somewhat strongly suggest use of even more. It's orders of magnitude more than that your `{add,update,remove}Message` snippet has. While React tries its best to hide all that complexity, it's still there. Designing, writing, reading, debugging and rewriting (if necessary) those few functions is all trivial (but somewhat routine) - not so much with React.

platz 10y ago
all the add/remove list stuff can be implemented by a simple templating library (handlebars/mustache) which doesnt mess up the whole client side architecture
- drdaeman 10y ago
  Oh, no, I'm sure that's incorrect. Templating libraries can't update documents, they can only overwrite them completely. This either loses state (entered-but-unsaved text, cursor positions, <detail> collapse status, etc.), or requires a lot of watchers and extra state information. Those DOM updates is the whole point of React. There are other libraries that work in a similar fashion, but React has more traction thus reusable components and recipes available...
  - platz 10y ago
    no, the point of the template engine is not to push all the logic into the templates. as you say you still handle the state yourself. the template render just skips the messy output building step, which for many cases is all you need
    - drdaeman 10y ago
      Ah, I think I see. React is a templating library. Nothing more, nothing less. It takes a state ("props"), a template ("component") and renders the DOM tree. That's all it does. (Non-templating uses like react-router are kind of hacks, rather than intended use. YMMV, of course.) However, it's more complex than previous-generation templating libraries (that had emitted strings, rather than operating on DOM trees), because DOM trees are stateful. This is why React is so huge, when compared to, say, Mustache. (And, of course, it's really easy to mess things up by putting application logic right in the component class. And, I'd say, sometimes it's really tempting to do so. Mustache/Handlebars doesn't have this only because they're specifically designed to disallow such things.)
      - platz 10y ago
        no disagreement on what react is. yes, I understand react can be used just to template (no one uses it this way). yes, react is powerful. yes, react provides a good mechanism for handling state and events. what i am saying though is that for some apps, you can get by with simpler templating and avoid the conplexity/power react gives you, handling state and events yourself manually. does it sound crazy? if you know it will work for your particular use case, i dont think its crazy, and you avoid a bundle of complexity that react gives you, in essesnce you own the complexity now
        drdaeman 10y ago
        > react can be used just to template (no one uses it this way) I don't know about the others but I do. Got bad experience when I've shoved logic where it didn't belong, don't repeat the same mistake again. As the templating "got data, want a form, a table and a chart" engine it's good - exactly in a sense that I can write one template instead of multiple partials (add+update+remove). The complexity hidden underneath doesn't strike my fancy, but... it works, and saves coding time - especially because a lot of components are already written by someone else and is available on npm. Still, it's really really easy to shoot yourself in the leg. And I found a fair share of tutorials and examples teaching those sort of things. > react provides a good mechanism for handling state and events No, it doesn't have those. Unless you count react-router/Redux/Mobx/whatever as React-the-umbrella-naming. Well, there is some basic internal state management (via constructor + `setState` + `componentWillReceiveProps`) but that's about it, and IMHO it best very used conservatively, for approximately the same reasons why having logic in, say, Jinja2 templates isn't the best idea in Python world. Or maybe I just don't know how to cook stateful components properly, but last time I made a stateful component I ended up rewriting it some weeks later, extracting the state away, because it became a problem. There is no event handling at all - except for the "props are changing, this is going to update" event, of course. All React has is `onClick`-like attributes and handlers bound to those are best left as some dispatch calls to the outside, with no logic inside the React component code whatsoever.

platz 10y ago

all the add/remove list stuff can be implemented by a simple templating library (handlebars/mustache) which doesnt mess up the whole client side architecture

drdaeman 10y ago
Oh, no, I'm sure that's incorrect. Templating libraries can't update documents, they can only overwrite them completely. This either loses state (entered-but-unsaved text, cursor positions, <detail> collapse status, etc.), or requires a lot of watchers and extra state information. Those DOM updates is the whole point of React. There are other libraries that work in a similar fashion, but React has more traction thus reusable components and recipes available...
- platz 10y ago
  no, the point of the template engine is not to push all the logic into the templates. as you say you still handle the state yourself. the template render just skips the messy output building step, which for many cases is all you need
  - drdaeman 10y ago
    Ah, I think I see. React is a templating library. Nothing more, nothing less. It takes a state ("props"), a template ("component") and renders the DOM tree. That's all it does. (Non-templating uses like react-router are kind of hacks, rather than intended use. YMMV, of course.) However, it's more complex than previous-generation templating libraries (that had emitted strings, rather than operating on DOM trees), because DOM trees are stateful. This is why React is so huge, when compared to, say, Mustache. (And, of course, it's really easy to mess things up by putting application logic right in the component class. And, I'd say, sometimes it's really tempting to do so. Mustache/Handlebars doesn't have this only because they're specifically designed to disallow such things.)
    - platz 10y ago
      no disagreement on what react is. yes, I understand react can be used just to template (no one uses it this way). yes, react is powerful. yes, react provides a good mechanism for handling state and events. what i am saying though is that for some apps, you can get by with simpler templating and avoid the conplexity/power react gives you, handling state and events yourself manually. does it sound crazy? if you know it will work for your particular use case, i dont think its crazy, and you avoid a bundle of complexity that react gives you, in essesnce you own the complexity now
      - drdaeman 10y ago
        > react can be used just to template (no one uses it this way) I don't know about the others but I do. Got bad experience when I've shoved logic where it didn't belong, don't repeat the same mistake again. As the templating "got data, want a form, a table and a chart" engine it's good - exactly in a sense that I can write one template instead of multiple partials (add+update+remove). The complexity hidden underneath doesn't strike my fancy, but... it works, and saves coding time - especially because a lot of components are already written by someone else and is available on npm. Still, it's really really easy to shoot yourself in the leg. And I found a fair share of tutorials and examples teaching those sort of things. > react provides a good mechanism for handling state and events No, it doesn't have those. Unless you count react-router/Redux/Mobx/whatever as React-the-umbrella-naming. Well, there is some basic internal state management (via constructor + `setState` + `componentWillReceiveProps`) but that's about it, and IMHO it best very used conservatively, for approximately the same reasons why having logic in, say, Jinja2 templates isn't the best idea in Python world. Or maybe I just don't know how to cook stateful components properly, but last time I made a stateful component I ended up rewriting it some weeks later, extracting the state away, because it became a problem. There is no event handling at all - except for the "props are changing, this is going to update" event, of course. All React has is `onClick`-like attributes and handlers bound to those are best left as some dispatch calls to the outside, with no logic inside the React component code whatsoever.