4 ms·

I know it's just a demo and I'm sure it scales very well, but I can't help but think that's a lot of code for a such simple UI. The intercoolerjs equivalent is

I know it's just a demo and I'm sure it scales very well, but I can't help but think that's a lot of code for a such simple UI. The intercoolerjs equivalent is pretty simple: http://intercoolerjs.org/examples/activesearch.html http://intercoolerjs.org/examples/activesearch.html Don't misunderstand me, there are a lot of places where react is appropriate and intercooler isn't, but for something like this...

firasd 10y ago
The intercooler.js example seems to be iterating over the results, building up a string of <tr> items, and then appending the string to the DOM? Yeah, React is for stuff where you never want to do that... it's for when you write your table rendering stuff once, and then just change/update the data. React also holds the entire UI state as data, things like: what information is typed in the text box, when to clear the text box, whether the checkbox is checked. The intercooler.js example seems to have a technique for showing a processing indicator based on an ID, so their approach to this kinda thing seems to be more 'implicit'. React doesn't have any UI-level abstractions like that, so you do have to implement things like that yourself. (Edit: I looked at the intercooler homepage and it's a specialized AJAX library, which explains what's going on in their example.)
- carsongross 10y ago
  Right, totally understand, but, functionally, these are pretty much the same UX (and a pretty common one). My point is that this is quite a bit of code for the same UI and, unless there is a compelling reason to have a client side model (which, of course, introduces the complexities of syncing w/ a server side model/data store) then you end up with a lot of complexity for very little benefit.
  - firasd 10y ago
    Yeah, fair point. I would say, besides interacting with server-side updates, the other use case for something like React is when you have a bunch of event listeners and find they're getting out of control (onclick function triggering something else which has a condition to check the class attribute of something else etc.)
BigJono 10y ago
This is one thing I find a little bit frustrating with the tutorials of various JS tools. They fail to accurately describe a problem that they solve. Usually you just get a quick paragraph going on about what you can do with the tool, then a quick example of something you could have easily done without the tool, then straight into the full API documentation. And after I've read all that I'm still saying "Ok, that's kind of cool. But why would I add another dependency to my project when I can code your example up in clean, vanilla JS (or more often in these days, plain old React)". I'd love to start seeing tutorial documentation address this more. Having a basic example is great, but it shouldn't be the only example. You should follow it up with a more complex example that really captures the reason you built the tool in the first place.
- bromuro 10y ago
  > This is one thing I find a little bit frustrating with the tutorials of various JS tools. They fail to accurately describe a problem that they solve. Yes, this is valid for anything. It's harder to understand the solution if we haven't met the problem. For example, I realized the need of React after my template-based app was becoming a huge mess.

firasd 10y ago

The intercooler.js example seems to be iterating over the results, building up a string of <tr> items, and then appending the string to the DOM? Yeah, React is for stuff where you never want to do that... it's for when you write your table rendering stuff once, and then just change/update the data. React also holds the entire UI state as data, things like: what information is typed in the text box, when to clear the text box, whether the checkbox is checked. The intercooler.js example seems to have a technique for showing a processing indicator based on an ID, so their approach to this kinda thing seems to be more 'implicit'. React doesn't have any UI-level abstractions like that, so you do have to implement things like that yourself. (Edit: I looked at the intercooler homepage and it's a specialized AJAX library, which explains what's going on in their example.)

carsongross 10y ago
Right, totally understand, but, functionally, these are pretty much the same UX (and a pretty common one). My point is that this is quite a bit of code for the same UI and, unless there is a compelling reason to have a client side model (which, of course, introduces the complexities of syncing w/ a server side model/data store) then you end up with a lot of complexity for very little benefit.
- firasd 10y ago
  Yeah, fair point. I would say, besides interacting with server-side updates, the other use case for something like React is when you have a bunch of event listeners and find they're getting out of control (onclick function triggering something else which has a condition to check the class attribute of something else etc.)

BigJono 10y ago

This is one thing I find a little bit frustrating with the tutorials of various JS tools. They fail to accurately describe a problem that they solve. Usually you just get a quick paragraph going on about what you can do with the tool, then a quick example of something you could have easily done without the tool, then straight into the full API documentation. And after I've read all that I'm still saying "Ok, that's kind of cool. But why would I add another dependency to my project when I can code your example up in clean, vanilla JS (or more often in these days, plain old React)". I'd love to start seeing tutorial documentation address this more. Having a basic example is great, but it shouldn't be the only example. You should follow it up with a more complex example that really captures the reason you built the tool in the first place.

bromuro 10y ago
> This is one thing I find a little bit frustrating with the tutorials of various JS tools. They fail to accurately describe a problem that they solve. Yes, this is valid for anything. It's harder to understand the solution if we haven't met the problem. For example, I realized the need of React after my template-based app was becoming a huge mess.