3 ms·

> 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

> 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.

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.