Re:Standards First Web Framework
by devalexwells on Friday January 17, 2025 @08:01AM
(#42737075)
Couple other notes:
You appeal to simplicity a lot, which is great! Contemporary frontend is way too complex. But a lot of what you're saying comes off as too black and white and rejects some of the learnings of the past decade.
Some examples:
- Inlining CSS is usually faster, but there are caveats to this. [1]
- You say, "the fastest page load is one that requires just a single request". This makes it sound like we should be avoiding the platform (the browser). Browsers can efficiently parallelize multiple requests. We shouldn't have the 200+ requests that many sites make, absolutely. But a rejection of requests entirely is not a goal. If you have a few interactive components that rarely change, having a few chunks that also rarely change means better caching too.
Point being there's no substitute to engineering and experimenting with what actually makes your site perform best for your users.
You appeal to simplicity a lot, which is great! Contemporary frontend is way too complex. But a lot of what you're saying comes off as too black and white and rejects some of the learnings of the past decade.
Some examples:
- Inlining CSS is usually faster, but there are caveats to this. [1]
- You say, "the fastest page load is one that requires just a single request". This makes it sound like we should be avoiding the platform (the browser). Browsers can efficiently parallelize multiple requests. We shouldn't have the 200+ requests that many sites make, absolutely. But a rejection of requests entirely is not a goal. If you have a few interactive components that rarely change, having a few chunks that also rarely change means better caching too.
Point being there's no substitute to engineering and experimenting with what actually makes your site perform best for your users.
[1] https://www.slideshare.net/slideshow/performance-now-24-perf...
* related video to above slides: https://www.youtube.com/watch?v=j5E_U_hu7g0