3 ms·

I'm having a hard time comprehending this mindset. According to this article we should accept: - Heavy sites that take a long time to load initially. - Are s

I'm having a hard time comprehending this mindset. According to this article we should accept: - Heavy sites that take a long time to load initially. - Are sluggish and unresponsive when not on this year's flagship phone. - Will probably break if the user leaves a tab open for too long. Because: - There's an opportunity to shave a fraction of a second off of your page load times if you want to utilize predictive analytics or extensive preloading to ensure the content request is already loaded in cache. The modern web is just layers upon layers of hacks and it's ugly and slow. I would recommend to anyone who disagrees to install the NoScript Add-on and run with it for 6 months. I did so and here's some things I've observed... When I enabled NoScript: - Most sites do not work without some Javascript that's been used to address Page reflow. They have a global display:none attribute that's removed after the entire page has loaded. All this discussion about page load times or responsiveness is BS when sites are hiding their site from you until it completely loads to avoid reflow. - Most sites rely heavily on Javascript to do basic formatting that's trivial in CSS. - Most sites use Webfonts loaded via Javascript When I disabled NoScript: - My Phone went from 60% battery at the end of the day to <20%. - The Web is slow again. - User hostile behavior like pop overs, auto-play video, and other garbage.

rich_harris 6y ago
> According to this article we should accept Well, I wrote the article, so I can say with some authority that you've badly misinterpreted it! Somehow I manage to build sites with exceptional performance that are snappier than the equivalent JS-free sites, using the techniques I talk about (and https://svelte.dev https://svelte.dev). Yes, there are a lot of bad sites out there that abuse JavaScript. No, that doesn't invalidate the article's thesis; it supports it.
- cptskippy 6y ago
  > Well, I wrote the article, so I can say with some authority that you've badly misinterpreted it! Perhaps but point from Tom MacWright's article is that we're over complicating simple things (e.g blogs) with complicated and heavy libraries and frameworks. Then when we encounter performance issues we attempt to mitigate them by layering on additional crap or spending significant time optimizing the crap out of needless complexity. Your suggestion that full page loads are unnecessarily slow and cumbersome and that we can use predictive analytics, preloading and a slew of other techniques to get a faster response to a page load is the equivalent of building a Rube Goldberg machine to turn the page of a book "that much faster". Sure your techniques address one metric (i.e. response time) but they introduce all manner of other problems that then need to then be solved. For what? > Somehow I manage to build sites with exceptional performance that are snappier than the equivalent JS-free sites. Somehow you manage demonstrate that you completely misunderstood what Tom MacWright was saying. Back to my page turning analogy, I have no doubt someone could build a machine to turn the pages of a book "better" than I can. Does that mean everyone should have this miraculous page turning machine? At the end of the day my local pizzeria doesn't need a multi-megabyte SPA application utilizing client side ML and predictive analytics for me to get the phone number so I can call in an order, but that's the modern web.

rich_harris 6y ago

> According to this article we should accept Well, I wrote the article, so I can say with some authority that you've badly misinterpreted it! Somehow I manage to build sites with exceptional performance that are snappier than the equivalent JS-free sites, using the techniques I talk about (and https://svelte.dev https://svelte.dev). Yes, there are a lot of bad sites out there that abuse JavaScript. No, that doesn't invalidate the article's thesis; it supports it.

cptskippy 6y ago
> Well, I wrote the article, so I can say with some authority that you've badly misinterpreted it! Perhaps but point from Tom MacWright's article is that we're over complicating simple things (e.g blogs) with complicated and heavy libraries and frameworks. Then when we encounter performance issues we attempt to mitigate them by layering on additional crap or spending significant time optimizing the crap out of needless complexity. Your suggestion that full page loads are unnecessarily slow and cumbersome and that we can use predictive analytics, preloading and a slew of other techniques to get a faster response to a page load is the equivalent of building a Rube Goldberg machine to turn the page of a book "that much faster". Sure your techniques address one metric (i.e. response time) but they introduce all manner of other problems that then need to then be solved. For what? > Somehow I manage to build sites with exceptional performance that are snappier than the equivalent JS-free sites. Somehow you manage demonstrate that you completely misunderstood what Tom MacWright was saying. Back to my page turning analogy, I have no doubt someone could build a machine to turn the pages of a book "better" than I can. Does that mean everyone should have this miraculous page turning machine? At the end of the day my local pizzeria doesn't need a multi-megabyte SPA application utilizing client side ML and predictive analytics for me to get the phone number so I can call in an order, but that's the modern web.