4 ms·

I'm currently developing a lot of websites. Disabling browser cache ensures that every file is the most resent version (and not cached), as well as to better s

I'm currently developing a lot of websites. Disabling browser cache ensures that every file is the most resent version (and not cached), as well as to better see dependency loading. Even with browser cache enabled, stack overflow loads a considerable number of resources compared to st4k. St4k loads 1 api call to get the S.O. data (JSON - ~1KiB), then loads any needed images. Stack overflow is loading the entire HTML document again (~15KiB), along with a lot of other web resources. Without going into their code, I've got no idea on what is lazy loading. But my point still stands on the speed of page navigation (not first time landing). St4k is faster as each change of page requires less KiBs of information to perform a page render, as well as less content to render: Compressed JSON, vs the entire HTML markup, and Rendering the Changes vs Re-Rendering the entire window/document.

oneeyedpigeon 13y ago
Oh, yes - I certainly agree that St4k is a lot faster than Stack Overflow, but I'm not sure quite whether to attribute that to exactly what's happening on the server (remember that the real SO will have load several orders of magnitude greater), fewer 'requirements' (e.g. no analytics?), more efficient markup, or specifically loading markup via AJAX+JSON rather than the 'normal' web route. I'm surprised there's such (15/1) a difference between the HTML and JSON versions of the same data. Both add their own syntactic cruft, but I wouldn't expect the weight of the markup to be that much greater than the equivalent JSON, unless it's being implemented horribly inefficiently (e.g. very verbose class names, inline styling, DIVitis). I'm suspicious about that 15/1 figure. All in all, though, this is an interesting approach. Nothing radically new, but definitely good to see a solid proof of concept that we can all relate to. I particularly like the way this gets around any api throttling limits since the St4k server isn't doing the communication with SO, it's all happening client->server, much as if one were just browsing SO as normal. Is there a term for this? It's not quite a proxy, since it's not 'in the middle', but more 'off to the side, not interfering directly, merely offering helpful advice' :)
- oneeyedpigeon 13y ago
  OK, having looked at the SO source, it's evidently not very concise. Full of inline script, lots of 'data-' attributes, even - gasp - tables for layout. (I think I was dimly aware of that last point, but had chosen to pretend it wasn't the case. And, yes, I know that HN is no better in that regard) Still, FIFTEEN times weightier ...?

oneeyedpigeon 13y ago

Oh, yes - I certainly agree that St4k is a lot faster than Stack Overflow, but I'm not sure quite whether to attribute that to exactly what's happening on the server (remember that the real SO will have load several orders of magnitude greater), fewer 'requirements' (e.g. no analytics?), more efficient markup, or specifically loading markup via AJAX+JSON rather than the 'normal' web route. I'm surprised there's such (15/1) a difference between the HTML and JSON versions of the same data. Both add their own syntactic cruft, but I wouldn't expect the weight of the markup to be that much greater than the equivalent JSON, unless it's being implemented horribly inefficiently (e.g. very verbose class names, inline styling, DIVitis). I'm suspicious about that 15/1 figure. All in all, though, this is an interesting approach. Nothing radically new, but definitely good to see a solid proof of concept that we can all relate to. I particularly like the way this gets around any api throttling limits since the St4k server isn't doing the communication with SO, it's all happening client->server, much as if one were just browsing SO as normal. Is there a term for this? It's not quite a proxy, since it's not 'in the middle', but more 'off to the side, not interfering directly, merely offering helpful advice' :)

oneeyedpigeon 13y ago
OK, having looked at the SO source, it's evidently not very concise. Full of inline script, lots of 'data-' attributes, even - gasp - tables for layout. (I think I was dimly aware of that last point, but had chosen to pretend it wasn't the case. And, yes, I know that HN is no better in that regard) Still, FIFTEEN times weightier ...?