3 ms·

I just have a hard time understanding where all these web apps are coming from, and what the real requirement is. It seems to me that the ratio of problems tha

by chubot 11y ago

I just have a hard time understanding where all these web apps are coming from, and what the real requirement is. It seems to me that the ratio of problems that require web apps to web sites is more like 1:1000 than 1:10. In other words, I wonder why it seems everyone is using React or Angular, rather than just a few people. I mentioned Google maps, docs, and spreadsheets as bona fide apps. They require a completely different approach. They are extraordinarily stateful on the client. What other sites need that? As mentioned, I don't think AirBNB does. How much state does it need on a page? It's basically like a shopping cart, like eBay. You search for properties, and then you book one. (Maybe it is different for listers, I haven't listed). I get that you need more advanced stuff like React and Angular to manage a lot of state on the client. jQuery gets messy in that case. But I am wondering why apps all of the sudden need this much state. If you break up your app into different pages, then you don't need so much state on each page. The state is in the URI. In other words, I see a lot of it as self-inflicted pain... the customer didn't actually want all this stuff. They just want to order a meal online or something. I looked through that whole "Built with React" github page, and I am still trying to understand where the requirements for lots of state are. I don't buy the motivation of keeping everything on one page to save network latency... if you actually profile a lot of web pages nowadays, the rendering time is greater than network time! I'm seeing full seconds reported by Chrome dev tools just to render!!! It doesn't appear that anyone cares about latency, given how slow most web sites and apps are.

enraged_camel 11y ago
It's not about latency, but about overall performance. Rendering on the server is slower than rendering on the client, because the server may have to deal with a thousand requests per minute whereas the client doesn't. So you push the logic to the client and let the browser deal with it until talking to the server is actually necessary (e.g. when the time comes to submit the data). Therefore client-side frameworks become a kind of distributed processing of application logic. Furthermore, you shouldn't take latency for granted. Many users are on choppy mobile connections. Waiting for the server after every action results in a really bad user experience in those scenarios.
- chubot 11y ago
  I'm not really buying it... Rendering on the server seems like a solved problem to me. Web apps scale. Sure, you can save servers by offloading work on the client. But I think your server cost is absolutely dwarfed by developer salaries. I guess it depends on whether you have more front end people or back end people. Good front end people seem to be just as expensive and rare as good backend/C++/Unix/distributed systems people these days. On mobile, most web apps are a disaster. They are certainly a lot worse than light HTML. Never mind waiting for the server on every action -- try getting the app to load in the first place! The Android and Chrome team have numbers on the astronomical rate of user-aborted or otherwise failed page loads on mobile. On mobile, users see the white screen for 5-10 seconds (probably waiting for your 10-50 round trips for your JS, CSS, heavy image assets, and especially third party JS) and then give up.
  - frik 11y ago
    You are so right! I hand tuned web apps (vanilla JS5, no libs/frameworks) and opimized them for mobile, and they are very fast. But most don't care and use bloated JS libraries/frameworks and the end user has to wait several seconds until the 1MB JS file loads over a cell connection or even crash the mobile browser because the site owner thought it is okay to integrate 30 advertisement and analytics third party JS files.

by chubot 11y ago

enraged_camel 11y ago

It's not about latency, but about overall performance. Rendering on the server is slower than rendering on the client, because the server may have to deal with a thousand requests per minute whereas the client doesn't. So you push the logic to the client and let the browser deal with it until talking to the server is actually necessary (e.g. when the time comes to submit the data). Therefore client-side frameworks become a kind of distributed processing of application logic. Furthermore, you shouldn't take latency for granted. Many users are on choppy mobile connections. Waiting for the server after every action results in a really bad user experience in those scenarios.

chubot 11y ago
I'm not really buying it... Rendering on the server seems like a solved problem to me. Web apps scale. Sure, you can save servers by offloading work on the client. But I think your server cost is absolutely dwarfed by developer salaries. I guess it depends on whether you have more front end people or back end people. Good front end people seem to be just as expensive and rare as good backend/C++/Unix/distributed systems people these days. On mobile, most web apps are a disaster. They are certainly a lot worse than light HTML. Never mind waiting for the server on every action -- try getting the app to load in the first place! The Android and Chrome team have numbers on the astronomical rate of user-aborted or otherwise failed page loads on mobile. On mobile, users see the white screen for 5-10 seconds (probably waiting for your 10-50 round trips for your JS, CSS, heavy image assets, and especially third party JS) and then give up.
- frik 11y ago
  You are so right! I hand tuned web apps (vanilla JS5, no libs/frameworks) and opimized them for mobile, and they are very fast. But most don't care and use bloated JS libraries/frameworks and the end user has to wait several seconds until the 1MB JS file loads over a cell connection or even crash the mobile browser because the site owner thought it is okay to integrate 30 advertisement and analytics third party JS files.