7 ms·

Maybe I am not getting it, but to me react.js seems like a bad way of wrapping your view html in javascript. What can you do easier using react.js (and backbon

by diziet 13y ago

Maybe I am not getting it, but to me react.js seems like a bad way of wrapping your view html in javascript. What can you do easier using react.js (and backbone) that you can't already do using knockout and plain html or whatever markup you prefer? To me, there is a reason to abstract javascript and similar logic outside the plain html -- however the workflow of including script sources inside html that in turn include html that gets rendered is backwards.

lomnakkus 13y ago
Knockout is pretty good, but the big deal about React vs. Knockout is components and the reusability you (can) get from componentizing your view code/html. This is something that you might not notice (and it might not even be relevant) if you just need to drizzle a little Knockout throughout your app/site for a little interactivity, but the lack of abstraction really starts to hurt once you go beyond simple interaction. EDIT: Oh, I should also mention the Virtual DOM, but that's not really that relevant unless you're experiencing performance problems. It might also be very handy for server-side rendering, but I don't have actual experience with that, so YMMV.
- mandeepj 13y ago
  I think angularjs is better than knockout if u r looking for full blown mvc app in Js as it supports DI and testability. On the downside, angularjs have lot of configuration
  - paultannenbaum 13y ago
    Angular is a framework, knockout and react are data binding libraries. You can get dependency injection and testing with both, its just something you have to set up yourself.
- baddox 13y ago
  It seems to me that Knockout's custom bindings provide the same reusability as React. The only difference I see is that React recommends their JSX preprocessor to allow HTML right in the JS, whereas Knockout custom bindings require building elements using the JS DOM API or hooking up some preprocessor manually.
  - lomnakkus 13y ago
    Custom bindings which generate DOM get you some of the way, but not quite the whole way. One of the disadvantages with custom bindings is that they are rather tightly bound to how the view model looks. If your binding expects something which isn't directly in your view model (at the right level) and perhaps requires a little transformation of your view model, you sometimes end up adding "synthetic" computed observables just to transform from your real view model to the view model that the custom binding expects. This is not really encapsulated very well. (I hope that makes sense, it's kind of hard for me to explain.) In React it's just simple JS which you write exactly where you need it, namely where you instantiate your component -- it doesn't even have to escape the scope (vs. KO where it "pollutes" the view model in the "owning" component so to speak). EDIT: A little addendum: It's been a while since I've used KO in any serious way, but another issue is that of embedding arbitrary components inside another. One thing is generating DOM from whole cloth, but if I have a component which just takes other components as input then the KO model breaks down.
    - baddox 13y ago
      I think I'm in the opposite situation. I've used Knockout recently, but haven't used React (I've only read their documentation). I can't think of an example of what you're talking about when you say that custom bindings are bound to how the view model looks, and that sometimes "synthetic" computed observances are needed.
catshirt 13y ago
the reason your html is modeled at the javascript level is because of the DOM efficiencies it provides. but they've provided JSX on top which means you can essentially write "plain html" as with any other application. i really prefer having my template and it's logic in the same language. one option is React without JSX, another is clojurescript. the short answer to your question is that Backbone and Knockout (afaik) don't do diffs to update your DOM.
- RussianCow 13y ago
  That's not particularly relevant because Knockout doesn't need to do diffs--it uses the observable pattern, so in most cases it knows what changes have been made the moment they are made.
antris 13y ago
> To me, there is a reason to abstract javascript and similar logic outside the plain html -- however the workflow of including script sources inside html that in turn include html that gets rendered is backwards Yes, coming from a traditional JavaScript MVC background it's hard to let go of this idea, when it's been touted everywhere for years. But the fact is, there's no fundamental reason why we need to put these technologies into separate containers. I recommend this talk by Pete Hunt: https://www.youtube.com/watch?v=x7cQ3mrcKaY https://www.youtube.com/watch?v=x7cQ3mrcKaY edit. oops, linked the wrong talk
ludwigvan 13y ago
The big idea is the render function in React describes your UI at any point in time. Not initially only, at any point in time. The biggest complexity in frontend development is that there is too much state. Most people, when doing frontend dev blame JavaScript for the difficulty. JavaScript is a problem, but it is not the problem. The problem is the management of state. Compare this to server side development. It is much more robust. Why is that? Because there is too little state, what you render has a little lifetime. Request comes, response generated, there you go. What's the problem with frontend? The app there has a much higher life. You get the page, interact with this, many interactions later, you accumulate state, but you are still dealing with the same "response". Hence the difficulty of building UI's. So, what's the solution to this? One: you need to manage your state properly. Two: through this state, you need to be able to define your UI at any point in time. Assume you solved these problems, but naively, that is, once state changes, you re-render the whole response. This would be much less bug prone. But now you have a performance problem: Changing state will not necessarily change all the UI response. Hence the genius of React's virtual DOM, which acts an intermediary, diffs the different responses over time, and redraw only what's necessary to redraw, not the whole UI response.
- baddox 13y ago
  Knockout templates also represent your UI at any point in time. The only significant difference as far as I can tell is that React feels strongly that pure JavaScript (with an optional preprocessor that lets you type HTML in your JS) is a better way to organize UI code than templates with bindings. With Knockout custom bindings, this difference becomes much smaller.
  - peterhunt 13y ago
    I had to cut the Knockout-specific slides, but I do cover this topic in depth here: https://www.youtube.com/watch?v=h3KksH8gfcQ https://www.youtube.com/watch?v=h3KksH8gfcQ tl;dr it's about expressiveness
    - ufo 13y ago
      I found the presentation really interesting.If I had to give a slightly larger TLDR the two main points I got from it were 1) In a virtual DOM system your view code is a black box, while in an observable-based system you need a way to specify all the data bindings. This means that virtual DOM systems can use usual Javascript abstractions (functions, varuiables, etc) where observable systems often need custom DSLs (for templating, data-binding, etc). Additionally, data binding can be tricky to get right when it gets more complicated, for example, if you have a sorted list of items it needs a way to know that should be rerendered when the inner properties change. 2) Performance: in a observable-based system, the memory and CPU costs are related to the size of the model while in a virtual DOM system the costs are related to the size of the view. This can be a performance gain for the virtual DOM if you have a big model but use windowing to display only part of it. Also, the O(n) cost on the size of the view is usually not a problem since views tend to be small enough that that fits inside one repaint frame.
noname123 13y ago
I think you're pulling more concerns about integration with existing JS MVC frameworks (e.g., Backbone/Ember/Angular) than just reacting. The Reactor pattern came more out of the back-end world where suppose you have a data stream that you have to filter and do more processing to create more data stream (e.g., person A,B post cat gifs on Wall on client -> pushed to respective the Facebook Wall stream for person A, B -> piped to Facebook Feed for person C who is subscribed to [A,B] -> combined with Facebook real-time ad-stream for demographics group X that person C belongs to -> pushes the ad-infested social media crap down to the user C on client), Now normally all of these would be traditionally done via a HTTP RESTful Ajax pull request from the client-side and the back-end service would query the database or some kind of caching service (Redis/Memcache) and perform some application logic to combine the data and send it down to the client-side. Reactor pattern tries to do away with the service layer and instead have the JS clients as first class citizen subscribers in a publish-subscribe model and pushes the streams of data down to the client. So you can think of some really exciting use-cases, like Pornhub/Youtube/Spotify processing streams of everyone who is watching a video at any given moment; then showing everyone the chain of top "branching-off" of video's that everyone is watching and have the people who have this shared "experience" chat and lead the group to the next recommended video and so forth for a much more collaborative and real-time media consumption/"discovery" experience.
spyder 13y ago
Knockout too pollutes the HTML with it's own "language" in the "data-bind" attribute (for example: data-bind='value: itemToAdd, valueUpdate: "afterkeydown"') True separation would be if there will be the HTML file and then there will be a separate definition for the data bindings using selectors, because then you don't have to touch the HTML when you change bindings. React cannot do that but the other useful feature i was looking for is that it can render the views on the server-side (node.js) too.
- diziet 13y ago
  Sure, though I'd argue that knockut's data-bind attribute makes sense to fit inside HTML as it makes any sort of debugging a lot more straightforward (with the exception of handling context and what hierarchy your specific model is in at this very moment).

by diziet 13y ago

lomnakkus 13y ago

Knockout is pretty good, but the big deal about React vs. Knockout is components and the reusability you (can) get from componentizing your view code/html. This is something that you might not notice (and it might not even be relevant) if you just need to drizzle a little Knockout throughout your app/site for a little interactivity, but the lack of abstraction really starts to hurt once you go beyond simple interaction. EDIT: Oh, I should also mention the Virtual DOM, but that's not really that relevant unless you're experiencing performance problems. It might also be very handy for server-side rendering, but I don't have actual experience with that, so YMMV.

mandeepj 13y ago
I think angularjs is better than knockout if u r looking for full blown mvc app in Js as it supports DI and testability. On the downside, angularjs have lot of configuration
- paultannenbaum 13y ago
  Angular is a framework, knockout and react are data binding libraries. You can get dependency injection and testing with both, its just something you have to set up yourself.
baddox 13y ago
It seems to me that Knockout's custom bindings provide the same reusability as React. The only difference I see is that React recommends their JSX preprocessor to allow HTML right in the JS, whereas Knockout custom bindings require building elements using the JS DOM API or hooking up some preprocessor manually.
- lomnakkus 13y ago
  Custom bindings which generate DOM get you some of the way, but not quite the whole way. One of the disadvantages with custom bindings is that they are rather tightly bound to how the view model looks. If your binding expects something which isn't directly in your view model (at the right level) and perhaps requires a little transformation of your view model, you sometimes end up adding "synthetic" computed observables just to transform from your real view model to the view model that the custom binding expects. This is not really encapsulated very well. (I hope that makes sense, it's kind of hard for me to explain.) In React it's just simple JS which you write exactly where you need it, namely where you instantiate your component -- it doesn't even have to escape the scope (vs. KO where it "pollutes" the view model in the "owning" component so to speak). EDIT: A little addendum: It's been a while since I've used KO in any serious way, but another issue is that of embedding arbitrary components inside another. One thing is generating DOM from whole cloth, but if I have a component which just takes other components as input then the KO model breaks down.
  - baddox 13y ago
    I think I'm in the opposite situation. I've used Knockout recently, but haven't used React (I've only read their documentation). I can't think of an example of what you're talking about when you say that custom bindings are bound to how the view model looks, and that sometimes "synthetic" computed observances are needed.

catshirt 13y ago

the reason your html is modeled at the javascript level is because of the DOM efficiencies it provides. but they've provided JSX on top which means you can essentially write "plain html" as with any other application. i really prefer having my template and it's logic in the same language. one option is React without JSX, another is clojurescript. the short answer to your question is that Backbone and Knockout (afaik) don't do diffs to update your DOM.

RussianCow 13y ago
That's not particularly relevant because Knockout doesn't need to do diffs--it uses the observable pattern, so in most cases it knows what changes have been made the moment they are made.

antris 13y ago

> To me, there is a reason to abstract javascript and similar logic outside the plain html -- however the workflow of including script sources inside html that in turn include html that gets rendered is backwards Yes, coming from a traditional JavaScript MVC background it's hard to let go of this idea, when it's been touted everywhere for years. But the fact is, there's no fundamental reason why we need to put these technologies into separate containers. I recommend this talk by Pete Hunt: https://www.youtube.com/watch?v=x7cQ3mrcKaY https://www.youtube.com/watch?v=x7cQ3mrcKaY edit. oops, linked the wrong talk

ludwigvan 13y ago

The big idea is the render function in React describes your UI at any point in time. Not initially only, at any point in time. The biggest complexity in frontend development is that there is too much state. Most people, when doing frontend dev blame JavaScript for the difficulty. JavaScript is a problem, but it is not the problem. The problem is the management of state. Compare this to server side development. It is much more robust. Why is that? Because there is too little state, what you render has a little lifetime. Request comes, response generated, there you go. What's the problem with frontend? The app there has a much higher life. You get the page, interact with this, many interactions later, you accumulate state, but you are still dealing with the same "response". Hence the difficulty of building UI's. So, what's the solution to this? One: you need to manage your state properly. Two: through this state, you need to be able to define your UI at any point in time. Assume you solved these problems, but naively, that is, once state changes, you re-render the whole response. This would be much less bug prone. But now you have a performance problem: Changing state will not necessarily change all the UI response. Hence the genius of React's virtual DOM, which acts an intermediary, diffs the different responses over time, and redraw only what's necessary to redraw, not the whole UI response.

baddox 13y ago
Knockout templates also represent your UI at any point in time. The only significant difference as far as I can tell is that React feels strongly that pure JavaScript (with an optional preprocessor that lets you type HTML in your JS) is a better way to organize UI code than templates with bindings. With Knockout custom bindings, this difference becomes much smaller.
- peterhunt 13y ago
  I had to cut the Knockout-specific slides, but I do cover this topic in depth here: https://www.youtube.com/watch?v=h3KksH8gfcQ https://www.youtube.com/watch?v=h3KksH8gfcQ tl;dr it's about expressiveness
  - ufo 13y ago
    I found the presentation really interesting.If I had to give a slightly larger TLDR the two main points I got from it were 1) In a virtual DOM system your view code is a black box, while in an observable-based system you need a way to specify all the data bindings. This means that virtual DOM systems can use usual Javascript abstractions (functions, varuiables, etc) where observable systems often need custom DSLs (for templating, data-binding, etc). Additionally, data binding can be tricky to get right when it gets more complicated, for example, if you have a sorted list of items it needs a way to know that should be rerendered when the inner properties change. 2) Performance: in a observable-based system, the memory and CPU costs are related to the size of the model while in a virtual DOM system the costs are related to the size of the view. This can be a performance gain for the virtual DOM if you have a big model but use windowing to display only part of it. Also, the O(n) cost on the size of the view is usually not a problem since views tend to be small enough that that fits inside one repaint frame.

noname123 13y ago

I think you're pulling more concerns about integration with existing JS MVC frameworks (e.g., Backbone/Ember/Angular) than just reacting. The Reactor pattern came more out of the back-end world where suppose you have a data stream that you have to filter and do more processing to create more data stream (e.g., person A,B post cat gifs on Wall on client -> pushed to respective the Facebook Wall stream for person A, B -> piped to Facebook Feed for person C who is subscribed to [A,B] -> combined with Facebook real-time ad-stream for demographics group X that person C belongs to -> pushes the ad-infested social media crap down to the user C on client), Now normally all of these would be traditionally done via a HTTP RESTful Ajax pull request from the client-side and the back-end service would query the database or some kind of caching service (Redis/Memcache) and perform some application logic to combine the data and send it down to the client-side. Reactor pattern tries to do away with the service layer and instead have the JS clients as first class citizen subscribers in a publish-subscribe model and pushes the streams of data down to the client. So you can think of some really exciting use-cases, like Pornhub/Youtube/Spotify processing streams of everyone who is watching a video at any given moment; then showing everyone the chain of top "branching-off" of video's that everyone is watching and have the people who have this shared "experience" chat and lead the group to the next recommended video and so forth for a much more collaborative and real-time media consumption/"discovery" experience.

spyder 13y ago

Knockout too pollutes the HTML with it's own "language" in the "data-bind" attribute (for example: data-bind='value: itemToAdd, valueUpdate: "afterkeydown"') True separation would be if there will be the HTML file and then there will be a separate definition for the data bindings using selectors, because then you don't have to touch the HTML when you change bindings. React cannot do that but the other useful feature i was looking for is that it can render the views on the server-side (node.js) too.

diziet 13y ago
Sure, though I'd argue that knockut's data-bind attribute makes sense to fit inside HTML as it makes any sort of debugging a lot more straightforward (with the exception of handling context and what hierarchy your specific model is in at this very moment).