Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

As much Stack Overflow as possible in 4096 bytes

danlec.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: As much Stack Overflow as possible in 4096 bytes

#71

Post by oneeyedpigeon »

cobookman wrote: post #69
oneeyedpigeon wrote: post #67

Earlier quoted context omitted.

Almost all that really tells us is that you have browser cache disabled (resources such as jquery wouldn't be re-requested on StackOverflow is you didn't). As a matter of interest, why are you disabling browser cache? Doesn't that waste a needless amount of bandwidth? Is it for some kind of security reason?

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…

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' :)

Re: As much Stack Overflow as possible in 4096 bytes

#72

Post by oneeyedpigeon »

oneeyedpigeon wrote: post #71
cobookman wrote: post #69

Earlier quoted context omitted.

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…

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…

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

Re: As much Stack Overflow as possible in 4096 bytes

#73

Post by Retric »

bane wrote: post #68
userbinator wrote: post #65

Earlier quoted context omitted.

> I wish extreme performance goals and requirements would become a new trend. Not just performance, but efficiency - both speed and size. Sadly it seems that most of the time this point is brought up, it gets dismissed as "premature optimisation". Instead we're taught in CS to pile abstraction upon abstraction even when they're not really needed, to create overly complex systems just to perform simple tasks, to not c…

> Instead we're taught in CS to pile abstraction upon abstraction even when they're not really needed, to create overly complex systems just to perform simple tasks, to not care much about efficiency "because hardware is always getting better". I've never agreed with that sort of thinking. Right, exactly. It's obvious too that software has scaled faster than hardware in the sense that to do an equivalent task like sa…

My desktop cold boots in well under 30 seconds which is fater than say Apple Lisa which took over 1min to boot and showed a blank screen for a good 30 seconds. You can find videos on YouTube of various boot sequences. Worst case I can recall was a windows 95 machine which took 15 min to boot.

Re: As much Stack Overflow as possible in 4096 bytes

#74

Post by bane »

Retric wrote: post #73
bane wrote: post #68

Earlier quoted context omitted.

> Instead we're taught in CS to pile abstraction upon abstraction even when they're not really needed, to create overly complex systems just to perform simple tasks, to not care much about efficiency "because hardware is always getting better". I've never agreed with that sort of thinking. Right, exactly. It's obvious too that software has scaled faster than hardware in the sense that to do an equivalent task like sa…

My desktop cold boots in well under 30 seconds which is fater than say Apple Lisa which took over 1min to boot and showed a blank screen for a good 30 seconds. You can find videos on YouTube of various boot sequences. Worst case I can recall was a windows 95 machine which took 15 min to boot.

I think my new desktop does about the same thanks to the magic of SSDs. But a minute ain't bad for a boot. I remember some old servers I used to work on that would take 30 or 40 minutes to boot, most of which was spent waiting while the SCSI controllers did some kind of check out.

Before I replaced my old desktop, I think my boot times were something on the order of 10 minutes.

(and I don't count Windows claiming you can start to work while it loads a bunch of stuff in the background making the system unusably slow as counting).

https://www.youtube.com/watch?v=YQuODFwfZYw

http://www.therestartpage.com/

Re: As much Stack Overflow as possible in 4096 bytes

#75

Post by scott_karana »

mberning wrote: post #6

Very impressive. I wish extreme performance goals and requirements would become a new trend. I think we have come to accept a certain level of sluggishness in web apps. I hate it. I wrote a tire search app a few years back and made it work extremely fast given the task at hand. But I did not go to the level that this guy did. http://tiredb.com

You're not kidding! The site is amazingly fast.

Re: As much Stack Overflow as possible in 4096 bytes

#76

Post by userbinator »

bane wrote: post #68
userbinator wrote: post #65

Earlier quoted context omitted.

> I wish extreme performance goals and requirements would become a new trend. Not just performance, but efficiency - both speed and size. Sadly it seems that most of the time this point is brought up, it gets dismissed as "premature optimisation". Instead we're taught in CS to pile abstraction upon abstraction even when they're not really needed, to create overly complex systems just to perform simple tasks, to not c…

> Instead we're taught in CS to pile abstraction upon abstraction even when they're not really needed, to create overly complex systems just to perform simple tasks, to not care much about efficiency "because hardware is always getting better". I've never agreed with that sort of thinking. Right, exactly. It's obvious too that software has scaled faster than hardware in the sense that to do an equivalent task like sa…

> All of this is really to make the programmers more efficient, because programmer time is expensive (and getting stuff out the door quicker is important), but the amount of lost time (and money) on the user's end, waiting for these monstrosities of abstraction to compute something must far far exceed those costs.

I believe that the amount of time spent optimising software should be proportional to how long it will be used for, and how many users it has/will have. It makes little sense to spend an hour to take 10 minutes off the execution time of a quick-and-dirty script that will only be run once or twice. It makes a lot of sense to spend an hour, or even a day or week, to take 1 second off the execution time of software with hundreds of thousands or millions of users that constantly use it. At some point the overhead of optimisation is less than the time (or memory?) saved by everyone, so the "programmer time is expensive" line of thinking is really a form of selfishness; interesting that free/open-source software hasn't evolved differently, since it operates under a different set of assumptions.

Post reply on HN