3 ms·

I'm definitely interested in playing with React. My Angular experience was pretty painful. If I can summarize your point: Data-binding can simplify complex pag

by ssmoot 12y ago

I'm definitely interested in playing with React. My Angular experience was pretty painful. If I can summarize your point: Data-binding can simplify complex pages. That can be true. I do think most page interactions for most websites don't come close to approaching that level of complexity however. And even then, a helper-function that takes one message and performs multiple assignments can be simpler to write, simpler to understand and simpler to maintain. You still have to explicitly bind the data after all. If you only need to make one update, such as a message post in a chat application, then you're probably not saving a lot from a pure character count perspective. You're also throwing in a framework requirement, a need to maintain it, spreading your data-binding across the page, adding abstractions, etc. I'm not sure what you mean by not waiting for a response from the server before updating the app, though I suspect it implies even more complexity (local storage, synchronization, out-of-band management of failures, etc). From a maintenance stand-point: $(".content").html(response) has had a very long shelf-life. Where you can probably put a 2-year expiration date on any project targeting most of the handful of popular JavaScript MVC frameworks. Trying to predict which one is going to go the distance, not replace major components in that time, and provide a smooth, relatively painless upgrade path is probably futile I'd guess.

RussianCow 12y ago
> You're also throwing in a framework requirement, a need to maintain it, spreading your data-binding across the page, adding abstractions, etc. Well now you're getting into the framework-or-not debate, which I don't really care to argue. (There are valid arguments on both sides, and it's really a judgement call you have to make for each specific application, but it seems like that's been beaten to death here on HN.) I was specifically replying to your point about having the server generate all HTML changes, which I think is generally a bad idea. > If you only need to make one update, such as a message post in a chat application, then you're probably not saving a lot from a pure character count perspective. Either way, the "character count" of the data being sent over the wire shouldn't be an issue, and if it is, that's an edge case and not the general rule. Saving a few bytes on each response is not why JSON is used for data exchange. > I'm not sure what you mean by not waiting for a response from the server before updating the app, though I suspect it implies even more complexity (local storage, synchronization, out-of-band management of failures, etc). That's not what I meant at all. If the server is your templating engine, then you can't update the UI until you get a response from the server. So that means, if I click to read the message in my chat application, the UI doesn't acknowledge that it's been read until I get a response from the server, which can be more than a full second in a high-latency environment. In something like React, I can instantly update the UI before the request even finishes. Having said that, you make web apps seem trivial to develop. In practice (at least in my experience), many (most?) web apps are complex. I've been bitten too many times by projects that seemed "too simple" for a framework. If the web apps you're building really are that simple, then I think your solution is great, but I think most of today's rich web apps aren't simple CRUD applications anymore. > From a maintenance stand-point: $(".content").html(response) has had a very long shelf-life. It's also a pain in the ass to maintain. You have to imperatively define changes to your UI based on different events, which makes refactoring difficult and often leads to spaghetti code. There's also the fact that you'd have to keep UI state on the server as well (if this menu is open, change this thing, else change this other thing), which opens a whole new can of worms. > If I can summarize your point: Data-binding can simplify complex pages. React actually doesn't do data binding. The reason React is awesome is because it isolates different parts of your app and allows you to define the UI almost declaratively. Rather than keeping track of the current state of your application at all times, changes in state cause React to just (conceptually) re-render components. So your components essentially become pure functions that take state and render a UI. And for event handling and dispatch, check out [Flux](http://facebook.github.io/react/blog/2014/05/06/flux.html http://facebook.github.io/react/blog/2014/05/06/flux.html) if you haven't already. Even if you don't use React specifically, I think the architecture (treating components like pure functions Let me know if I'm misunderstanding the architecture you're proposing, because architecture is something I've thought about a lot and am genuinely interested to see how others are structuring their web apps.

by ssmoot 12y ago

RussianCow 12y ago

> You're also throwing in a framework requirement, a need to maintain it, spreading your data-binding across the page, adding abstractions, etc. Well now you're getting into the framework-or-not debate, which I don't really care to argue. (There are valid arguments on both sides, and it's really a judgement call you have to make for each specific application, but it seems like that's been beaten to death here on HN.) I was specifically replying to your point about having the server generate all HTML changes, which I think is generally a bad idea. > If you only need to make one update, such as a message post in a chat application, then you're probably not saving a lot from a pure character count perspective. Either way, the "character count" of the data being sent over the wire shouldn't be an issue, and if it is, that's an edge case and not the general rule. Saving a few bytes on each response is not why JSON is used for data exchange. > I'm not sure what you mean by not waiting for a response from the server before updating the app, though I suspect it implies even more complexity (local storage, synchronization, out-of-band management of failures, etc). That's not what I meant at all. If the server is your templating engine, then you can't update the UI until you get a response from the server. So that means, if I click to read the message in my chat application, the UI doesn't acknowledge that it's been read until I get a response from the server, which can be more than a full second in a high-latency environment. In something like React, I can instantly update the UI before the request even finishes. Having said that, you make web apps seem trivial to develop. In practice (at least in my experience), many (most?) web apps are complex. I've been bitten too many times by projects that seemed "too simple" for a framework. If the web apps you're building really are that simple, then I think your solution is great, but I think most of today's rich web apps aren't simple CRUD applications anymore. > From a maintenance stand-point: $(".content").html(response) has had a very long shelf-life. It's also a pain in the ass to maintain. You have to imperatively define changes to your UI based on different events, which makes refactoring difficult and often leads to spaghetti code. There's also the fact that you'd have to keep UI state on the server as well (if this menu is open, change this thing, else change this other thing), which opens a whole new can of worms. > If I can summarize your point: Data-binding can simplify complex pages. React actually doesn't do data binding. The reason React is awesome is because it isolates different parts of your app and allows you to define the UI almost declaratively. Rather than keeping track of the current state of your application at all times, changes in state cause React to just (conceptually) re-render components. So your components essentially become pure functions that take state and render a UI. And for event handling and dispatch, check out [Flux](http://facebook.github.io/react/blog/2014/05/06/flux.html http://facebook.github.io/react/blog/2014/05/06/flux.html) if you haven't already. Even if you don't use React specifically, I think the architecture (treating components like pure functions Let me know if I'm misunderstanding the architecture you're proposing, because architecture is something I've thought about a lot and am genuinely interested to see how others are structuring their web apps.