4 ms·
> 5 different JavaScript frameworks This is not the problem. You can easily use i.e. React and some related libs on mobile without slowing down the experience
by greenspot 10y ago
> 5 different JavaScript frameworks
This is not the problem. You can easily use i.e. React and some related libs on mobile without slowing down the experience at all. Everything will be fast and responsive, loading times and the mobile site itself (if done right). The problem Google tries to address (and this is a real problem) are the cascaded ad networks on webpages which load hundreds of JS libs once a page is loaded. This is a huge problem and yes, it needs to be solved. Just go to any news site and open Chrome Inspector's Networking tab, then you'll be shocked about the millions of resources still being loaded. AMP is solving this by putting Google as the gatekeeper in front of all this networks. I am ok with this, those ad networks created the problem and I am fine if they now need to deal with Google's monopoly but I am not fine with being restricted in using JS in general because you can do it right, even on mobile.
- makmanalp 10y agoWould this theoretically be solved by some HTTP 2 stuff?
- tiffanyh 10y ago>> "This is not the problem. You can easily use i.e. React and some related libs on mobile without slowing down the experience at all." Hasn't Facebook proven this to be incorrect. Facebook mobile app was originally just HTML5 & JavaScript. The experience was so slow, they ditched it and instead built a native iOS & Android app. [1] [1] https://techcrunch.com/2012/12/13/facebook-android-faster/ https://techcrunch.com/2012/12/13/facebook-android-faster/
- manmal 10y agoTwo more reasons why this comparison is not on point: - On iOS, the FB App had to make do with a really slow JS engine at the time. IIRC Safari's JS performance was x5 compared to JS performance in apps' web views? This has more to do with how iOS treats apps, rather than how fast web pages in Safari are or were. - The FB apps were okayish at the time, given that they were web based. If you manage to get your web app to that level, your site is ok. Now add to that the performance gains and browser optimizations of the last 4 years and you get a system that flies. Native apps are still faster and respond quicker to touch, but you cannot hold that against JS web apps.
- flukus 10y agoNo, fastlite and a dozen other facebook apps have proven this incorrect. The official facebook app is slower, more bloated and battery draining than the mobile version ever was.
- objclxt 10y agoThat article is four years old. Facebook's app architecture has changed significantly since then, as has the speed at which JS can execute.
- matthewmacleod 10y agoThat article's no longer relevant, and in any case the existence of a bad implementation does not mean that a good implementation is not possible.
- iainmerrick 10y agoThat seems irrelevant here -- Facebook is a web app that needs you to log in, and displays user-specific info in a very dynamic way. It's not the kind of thing that could ever be cached, whether by Amp or any other generic CDN.
- mtberatwork 10y ago> This is not the problem. It's certainly a large part of the problem. All this unnecessary offloading of processing to the client has gotten way out of hand. Why does a simple Wordpress blog (or any blog for that matter) that is essentially serving read-only pages need React in the first place? I have yet to see a blog that needs to be designed as an SPA.
- tboyd47 10y agoNot sure why you're being downvoted. You're right. I'm not a fan of React and ilk myself, but they aren't the problem. Ad delivery technology is the problem, and Google itself is a huge part of that since they own so much of the ad industry.