4 ms·
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,
by 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 agoMaybe you're right, but I'm interested on your opinion about the rest of my answer, such as mobile browser capacities.
- spaceribs 10y agoThere 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.