3 ms·

HN pages are small, the HTML is generated on the server, and they render nearly progressively. That is, the renderer doesn't need to block waiting for many CSS,

HN pages are small, the HTML is generated on the server, and they render nearly progressively. That is, the renderer doesn't need to block waiting for many CSS, JavaScript, or font files to download. Most development practices considered "modern" prevent progressive rendering. Common tools like Bootstrap or Jquery, as normally used, cause page rendering to block until large libraries are downloaded, despite the fact that only a tiny portion of bootstrap or Jquery are actually used by the page. The largest reason of all is that most developers dismiss such concerns as old school worries and like to harp on and on about how tools like Angular enforce wonderful software engineering practices, ignoring that most such frameworks, as commonly used, bloat pages and cause incredible rendering delays. The difficulty with improving performance is that most "modern" pages have numerous render-blocks. The page doesn't get fast until you fix all of them. This is the reason most wise suggestions to speed up a page make little difference when tested individually.

edanm 11y ago
"The largest reason of all is that most developers dismiss such concerns as old school worries and like to harp on and on about how tools like Angular enforce wonderful software engineering practices, ignoring that most such frameworks, as commonly used, bloat pages and cause incredible rendering delays." Alternatively, you could say that many people look at the tradeoffs and decide they're comfortable with trading off a certain amount of speed for the user, in order to increase development speed. Whether these people are right or wrong really depends on the context.
- paulsutter 11y ago
  Users sitting on gigabit links close to the server make the tradeoffs, and people on a high latency end of a 3G link, or an airport wifi with a weak signal and 50% packet loss need to live with those tradeoffs.
  - edanm 11y ago
    Sometimes, yes, in which case the tradeoff might not make sense. But sometimes it does - e.g. I think in most cases, something existing but being slow is better than something not existing in the first place, which might be the case if the costs of making it go up.

edanm 11y ago

"The largest reason of all is that most developers dismiss such concerns as old school worries and like to harp on and on about how tools like Angular enforce wonderful software engineering practices, ignoring that most such frameworks, as commonly used, bloat pages and cause incredible rendering delays." Alternatively, you could say that many people look at the tradeoffs and decide they're comfortable with trading off a certain amount of speed for the user, in order to increase development speed. Whether these people are right or wrong really depends on the context.

paulsutter 11y ago
Users sitting on gigabit links close to the server make the tradeoffs, and people on a high latency end of a 3G link, or an airport wifi with a weak signal and 50% packet loss need to live with those tradeoffs.
- edanm 11y ago
  Sometimes, yes, in which case the tradeoff might not make sense. But sometimes it does - e.g. I think in most cases, something existing but being slow is better than something not existing in the first place, which might be the case if the costs of making it go up.