3 ms·

It's primarily a speed-of-light issue. If the server is on the New Jersey and I'm in London, it takes a perceptible amount of time for the signal to travel betw

It's primarily a speed-of-light issue. If the server is on the New Jersey and I'm in London, it takes a perceptible amount of time for the signal to travel between continents. The only way to remove this latency is for the client to take full responsibility for building the UI, instead of playing a complicated game of ping pong across the Earth. While I don't particularly like React, that's what they're aiming for.

dham 11y ago
The funny thing is, a lot of websites I visit that use client side frameworks don't make optimistic/eager updates to the UI. You click a button, it hits the server does the update, then updates the button state. Therefore they're waiting for the roundtrip to the server before making the update anyway. Just because something is possible doesn't mean people are actually using it. To make some optimistic updates you have to duplicate logic on client and server. It just gets really hairy especially when you're using auto increment id's in your database. That's just one of the problems. The complications it creates isn't even worth it. I'd rather just put a server in London. A lot less hassle then dealing with this over engineered client side bullshit.
- tutuca 11y ago
  Lots of funny things, apparently...
- nilliams 11y ago
  > A lot less hassle then dealing with this over engineered client side bullshit. I like to deal with client-side apps which talk to a simple JSON API. It's a lot less hassle than dealing with this over engineered server side bullshit.
  - dham 11y ago
    JSF with Java EE. That was over engineered. This Redux flux capicator, isomorphic, 4 Terabyte NPM install, 45 Babel plugin, flow, dumb component pure functional, immutable js, virtual dom. Now that's over engineered. I built more complicated stuff with Knockout.js in 2011 then half the stuff I see people building with React(which from what I see is just news sites and forum software)
- TimJYoung 11y ago
  Our product, Elevate Web Builder, creates fat-client web applications, and they are much, much simpler to implement than a hybrid approach because you're only coding to one environment at a time (browser, server). They are also much lighter on bandwidth requirements because most data transfers are simple JSON and not content. You can see this here with a demo that loads the IP address ranges for various countries into a grid: http://www.elevatesoft.com:8081/maxgridtest/maxgridtest.html http://www.elevatesoft.com:8081/maxgridtest/maxgridtest.html (our server is in Chicago - SingleHop is fantastic) Yes, you do make a valid point that things like optimistic database updates can be problematic, if not planned for. However, I would counter that the end result is much more durable and scalable than the alternative. If you build your application to handle distributed, optimistic transactions to a back-end JSON-based API (our dataset API does about 98% of the work for you), you're well on your way to having a distributed application that can be run anywhere and maintains a nice separation of concerns where the front-end or back-end can be swapped out as different needs arise. That, to me, seems to be a much better position to be in than one that requires a mix of both client-side and server-side content generation, which intimately ties the front-end to the back-end (brittle).

dham 11y ago

The funny thing is, a lot of websites I visit that use client side frameworks don't make optimistic/eager updates to the UI. You click a button, it hits the server does the update, then updates the button state. Therefore they're waiting for the roundtrip to the server before making the update anyway. Just because something is possible doesn't mean people are actually using it. To make some optimistic updates you have to duplicate logic on client and server. It just gets really hairy especially when you're using auto increment id's in your database. That's just one of the problems. The complications it creates isn't even worth it. I'd rather just put a server in London. A lot less hassle then dealing with this over engineered client side bullshit.

tutuca 11y ago
Lots of funny things, apparently...
nilliams 11y ago
> A lot less hassle then dealing with this over engineered client side bullshit. I like to deal with client-side apps which talk to a simple JSON API. It's a lot less hassle than dealing with this over engineered server side bullshit.
- dham 11y ago
  JSF with Java EE. That was over engineered. This Redux flux capicator, isomorphic, 4 Terabyte NPM install, 45 Babel plugin, flow, dumb component pure functional, immutable js, virtual dom. Now that's over engineered. I built more complicated stuff with Knockout.js in 2011 then half the stuff I see people building with React(which from what I see is just news sites and forum software)
TimJYoung 11y ago
Our product, Elevate Web Builder, creates fat-client web applications, and they are much, much simpler to implement than a hybrid approach because you're only coding to one environment at a time (browser, server). They are also much lighter on bandwidth requirements because most data transfers are simple JSON and not content. You can see this here with a demo that loads the IP address ranges for various countries into a grid: http://www.elevatesoft.com:8081/maxgridtest/maxgridtest.html http://www.elevatesoft.com:8081/maxgridtest/maxgridtest.html (our server is in Chicago - SingleHop is fantastic) Yes, you do make a valid point that things like optimistic database updates can be problematic, if not planned for. However, I would counter that the end result is much more durable and scalable than the alternative. If you build your application to handle distributed, optimistic transactions to a back-end JSON-based API (our dataset API does about 98% of the work for you), you're well on your way to having a distributed application that can be run anywhere and maintains a nice separation of concerns where the front-end or back-end can be swapped out as different needs arise. That, to me, seems to be a much better position to be in than one that requires a mix of both client-side and server-side content generation, which intimately ties the front-end to the back-end (brittle).