4 ms·

I feel like this is a situation where developers are looking back to an internet that doesn't exist anymore. In 2002, there were 665 million internet users, now

I feel like this is a situation where developers are looking back to an internet that doesn't exist anymore. In 2002, there were 665 million internet users, now there are 3.4 billion and growing [http://www.internetlivestats.com/internet-users/ http://www.internetlivestats.com/internet-users/]. If we were still stuck with terrible standards implementations and lack of processing power, I would side with the "Lets do everything on the server again!" argument, but we're not. For most use cases only privileged information has the requirement of server processing, and if thats not a requirement, why not take advantage of the device requesting the service? Set aside the 5 second delay user experience annoyance, and realize that as a business there is no way to scale your services profitably without offloading as much work as possible to the web client.

pmlnr 10y ago
> In 2002, there were 665 million internet users, now there are 3.4 billion and growing A significant part of that 3.4 billion are on mobile, which is even deeper prone to the overused JS problem. > terrible standards implementations Ah, you mean IE6. In it's prime time, it was a brilliant browser, standards or not; it was a necessary evil to forcefully move things ahead. It has XHR, webfonts, a gazillion things none of the browsers had yet. It indeed stuck around for too long, but this was not the case in it's initial state. > lack of processing power https://hackernoon.com/10-things-i-learned-making-the-fastest-site-in-the-world-18a0e1cdf4a7#4509 https://hackernoon.com/10-things-i-learned-making-the-fastes... -> Read the paragraph "#2 Do mobile first. Like, really do it." We do lack processing power on mobile, so for that 2-3billion people, who are using mobile _only_ or mobile first, we need economical solutions. > why not take advantage of the device requesting the service? Because you can't assume the device is powerful enough to do so. Why do you think https://mbasic.facebook.com https://mbasic.facebook.com still exists? > Set aside the 5 second delay user experience annoyance You go against one of the initial hard rules of the web with that. I wonder if is the importance of speed had changed, but judging by the grouchy voices all around, it did not. People only keep using the services because they deliberately made it hard to leave or because they learned tactics from Microsoft and are constantly eliminating competitors. > and realize that as a business there is no way to scale your services profitably without offloading as much work as possible to the web client. Now, this is complete nonsense; there is no money you save there. How is generating all those React apps, shuffling all that data is better then generating HTML? :) Of course, there are exceptions, there are always exceptions, but most of the things would not need mammoth sized invisible JSONs to be parsed in the browser while the pre-rendered HTML could be served and manipulated only when needed.
- spaceribs 10y ago
  I think your misunderstanding surrounds the amount of processing required to render HTML on the server, if you believe that rendering JSON is just as expensive, I'm open to the discussion but I don't agree. Usually these applications are compiled once, and delivered by CDN. That's a huge savings. Also I'm not saying the speed of Google Maps in your browser is acceptable, but with tools like Webpack Chunking, you can optimize even the initial load to nothing. This is a software architecture problem, not a javascript problem.
  - pmlnr 10y ago
    Maybe you're right, but I'm interested on your opinion about the rest of my answer, such as mobile browser capacities.
    - spaceribs 10y ago
      There is no way you'd want to leak even more information about the machine such as RAM and CPU power, I feel like it's already dangerously easy to de-anonymize users across websites simply using what's provided in headers and described in the "navigator" global. So with that in mind, I believe that Google Maps is purposefully not optimized for most mobile clients. It's designed as a fallback if you don't install the app (which they are deeply incentivized to peddle). I also think other web applications that get to the point of ~5 seconds of loadtime need to rethink their compiling strategy (if at all possible). I mentioned webpack before, but spreading out the work of large payloads is a well documented issue with many different solutions. If it's the CPUs fault, you should be using Web Workers. My original point stands though, processing on the client is free, scalable and an effective solution even considering the harm it could inflict on UX, and those harms can be mitigated.
- Yetanfou 10y ago
  Read the paragraph "#2 Do mobile first. Like, really do it." We do lack processing power on mobile, so for that 2-3billion people, who are using mobile _only_ or mobile first, we need economical solutions. Or use an older, 'underpowered' (by modern standards) machine for development, like I do. A Thinkpad T42p will give you a 1600x1200 screen, one of the best mobile keyboards available, 5-6 hours of autonomy with an extended battery and... the awesome power of a 1.8 GHz Pentium M... well, not so awesome maybe but if it works on that machine it flies on anything more up to date.

pmlnr 10y ago

> In 2002, there were 665 million internet users, now there are 3.4 billion and growing A significant part of that 3.4 billion are on mobile, which is even deeper prone to the overused JS problem. > terrible standards implementations Ah, you mean IE6. In it's prime time, it was a brilliant browser, standards or not; it was a necessary evil to forcefully move things ahead. It has XHR, webfonts, a gazillion things none of the browsers had yet. It indeed stuck around for too long, but this was not the case in it's initial state. > lack of processing power https://hackernoon.com/10-things-i-learned-making-the-fastest-site-in-the-world-18a0e1cdf4a7#4509 https://hackernoon.com/10-things-i-learned-making-the-fastes... -> Read the paragraph "#2 Do mobile first. Like, really do it." We do lack processing power on mobile, so for that 2-3billion people, who are using mobile _only_ or mobile first, we need economical solutions. > why not take advantage of the device requesting the service? Because you can't assume the device is powerful enough to do so. Why do you think https://mbasic.facebook.com https://mbasic.facebook.com still exists? > Set aside the 5 second delay user experience annoyance You go against one of the initial hard rules of the web with that. I wonder if is the importance of speed had changed, but judging by the grouchy voices all around, it did not. People only keep using the services because they deliberately made it hard to leave or because they learned tactics from Microsoft and are constantly eliminating competitors. > and realize that as a business there is no way to scale your services profitably without offloading as much work as possible to the web client. Now, this is complete nonsense; there is no money you save there. How is generating all those React apps, shuffling all that data is better then generating HTML? :) Of course, there are exceptions, there are always exceptions, but most of the things would not need mammoth sized invisible JSONs to be parsed in the browser while the pre-rendered HTML could be served and manipulated only when needed.

spaceribs 10y ago
I think your misunderstanding surrounds the amount of processing required to render HTML on the server, if you believe that rendering JSON is just as expensive, I'm open to the discussion but I don't agree. Usually these applications are compiled once, and delivered by CDN. That's a huge savings. Also I'm not saying the speed of Google Maps in your browser is acceptable, but with tools like Webpack Chunking, you can optimize even the initial load to nothing. This is a software architecture problem, not a javascript problem.
- pmlnr 10y ago
  Maybe you're right, but I'm interested on your opinion about the rest of my answer, such as mobile browser capacities.
  - spaceribs 10y ago
    There is no way you'd want to leak even more information about the machine such as RAM and CPU power, I feel like it's already dangerously easy to de-anonymize users across websites simply using what's provided in headers and described in the "navigator" global. So with that in mind, I believe that Google Maps is purposefully not optimized for most mobile clients. It's designed as a fallback if you don't install the app (which they are deeply incentivized to peddle). I also think other web applications that get to the point of ~5 seconds of loadtime need to rethink their compiling strategy (if at all possible). I mentioned webpack before, but spreading out the work of large payloads is a well documented issue with many different solutions. If it's the CPUs fault, you should be using Web Workers. My original point stands though, processing on the client is free, scalable and an effective solution even considering the harm it could inflict on UX, and those harms can be mitigated.
Yetanfou 10y ago
Read the paragraph "#2 Do mobile first. Like, really do it." We do lack processing power on mobile, so for that 2-3billion people, who are using mobile _only_ or mobile first, we need economical solutions. Or use an older, 'underpowered' (by modern standards) machine for development, like I do. A Thinkpad T42p will give you a 1600x1200 screen, one of the best mobile keyboards available, 5-6 hours of autonomy with an extended battery and... the awesome power of a 1.8 GHz Pentium M... well, not so awesome maybe but if it works on that machine it flies on anything more up to date.