5 ms·

I'm impressed at how the author of this website managed to take plain text content and literally make it slower to load than a 1080p 60FPS video. You really hav

I'm impressed at how the author of this website managed to take plain text content and literally make it slower to load than a 1080p 60FPS video. You really have to try to do something like that, bravo. I normally try to avoid commenting on stuff like this, but that's pretty much all I can say considering it took me actual minutes to load (from Japan). In lieu of the article's content, I'll spare readers the trouble and provide something better (and faster to load!): -Read lots of code There you go, you're well on your way to becoming a code-reading master!

riffraff 10y ago
the sad thing is The Wiki (this is the original one) used to be a simple text thingy, with instant load. I have no idea what happened, but I presume the new version just doesn't handle the HN effect well enough.
- shakna 10y ago
  > doesn't handle the HN effect well enough. Not at all. c2 now uses Federated Wiki, which for engineering reasons (I think), loads the entire wiki tree as a key part of the json that serves as the content for every page.
- jeremiep 10y ago
  Looks like new maintainers took control and decided the old codebase wasn't to their liking. Thing is, these changes come with loads of tradeoffs the newcomers usually are completely oblivious to and the new product is of lesser quality than the original, but they feel good about themselves now :)
rejschaap 10y ago
The irony is that they also host an article about Over Engineering: http://wiki.c2.com/?OverEngineering http://wiki.c2.com/?OverEngineering I didn't wait for it to finish loading and actually read it though.
- bschwindHN 10y ago
  Well I finally loaded it. It's a piece about how the support code (argument parsing, error handling) around the code that "actually does anything" has more lines than the "actually does anything" code.
  - taneq 10y ago
    Wow, you mean just like I spend more time reading specs, quoting, researching, schmoozing with clients etc. than "actually doing work"?
    - jeremiep 10y ago
      He didn't mean the tasks around programming, he meant the bits of code around the main problem domain in your codebase.
hrnki 10y ago
Italy here, I wish I had never clicked on the first link..
taneq 10y ago
I must admit, this was my first thought too. "Oh look, c2 wiki is back up! Huh, a loading spinner, it must be doing something fancy... oh look, it looks EXACTLY THE SAME AS BEFORE." The general content seems on track, if obvious ('find the high level logic', 'draw flowcharts if it's complicated', 'grep for whatever you're looking for') but some comments are out of date ("print the code because there's more code space on your desk" no longer applies, I literally have more square centimeters of monitor than of desk space and that monitor area can scroll!) and some are flat-out wrong ("software doesn't always have an entry point"? Really?)
alistproducer2 10y ago
I keep JavaScript if on mobile and around 95% of sites still work. This one not so much. If your site is just text please dispense with all the JavaScript.
jasode 10y ago
>how the author of this website managed to take plain text content and literally make it slower to load I didn't comprehensively debug the whole page but in a cursory 2 minute trace in Chrome Dev Tools, I found javascript that makes an XHR request for a 265k text file[1] with 36000 lines. The javascript code then parses the names (which takes ~300ms) and then seemingly does nothing with the information. It doesn't show up anywhere on any subsequent DOM rewrites. The actual visible content that people read is only 10k. For mobile users, you punish them twice by (1) subtracting 265k from their data plan and then (2) wasting battery power on cpu to parse it for no reason. That one example of useless bloat is probably multiplied dozens of times elsewhere in the lifecycle of the webpage. [1] don't click on this if you're on mobile phone: http://wiki.c2.com/names.txt http://wiki.c2.com/names.txt
- dom0 10y ago
  It doesn't seem to be the JS, though. The request that takes a whoppin' 33 seconds - server-side - for me is http://c2.com/wiki/remodel/pages/TipsForReadingCode http://c2.com/wiki/remodel/pages/TipsForReadingCode
- twiss 10y ago
  It seems like a list of all the pages on the wiki, presumably to turn mentions of those pages in the text into links automatically. Still, it seems better to do this on the server, if possible.
mercurysmessage 10y ago
It was taking me a long time as well (Canada), so I just quit. I thought it was noscript but I allowed the page.

riffraff 10y ago

the sad thing is The Wiki (this is the original one) used to be a simple text thingy, with instant load. I have no idea what happened, but I presume the new version just doesn't handle the HN effect well enough.

shakna 10y ago
> doesn't handle the HN effect well enough. Not at all. c2 now uses Federated Wiki, which for engineering reasons (I think), loads the entire wiki tree as a key part of the json that serves as the content for every page.
jeremiep 10y ago
Looks like new maintainers took control and decided the old codebase wasn't to their liking. Thing is, these changes come with loads of tradeoffs the newcomers usually are completely oblivious to and the new product is of lesser quality than the original, but they feel good about themselves now :)

rejschaap 10y ago

The irony is that they also host an article about Over Engineering: http://wiki.c2.com/?OverEngineering http://wiki.c2.com/?OverEngineering I didn't wait for it to finish loading and actually read it though.

bschwindHN 10y ago
Well I finally loaded it. It's a piece about how the support code (argument parsing, error handling) around the code that "actually does anything" has more lines than the "actually does anything" code.
- taneq 10y ago
  Wow, you mean just like I spend more time reading specs, quoting, researching, schmoozing with clients etc. than "actually doing work"?
  - jeremiep 10y ago
    He didn't mean the tasks around programming, he meant the bits of code around the main problem domain in your codebase.

hrnki 10y ago

Italy here, I wish I had never clicked on the first link..

taneq 10y ago

I must admit, this was my first thought too. "Oh look, c2 wiki is back up! Huh, a loading spinner, it must be doing something fancy... oh look, it looks EXACTLY THE SAME AS BEFORE." The general content seems on track, if obvious ('find the high level logic', 'draw flowcharts if it's complicated', 'grep for whatever you're looking for') but some comments are out of date ("print the code because there's more code space on your desk" no longer applies, I literally have more square centimeters of monitor than of desk space and that monitor area can scroll!) and some are flat-out wrong ("software doesn't always have an entry point"? Really?)

alistproducer2 10y ago

I keep JavaScript if on mobile and around 95% of sites still work. This one not so much. If your site is just text please dispense with all the JavaScript.

jasode 10y ago

>how the author of this website managed to take plain text content and literally make it slower to load I didn't comprehensively debug the whole page but in a cursory 2 minute trace in Chrome Dev Tools, I found javascript that makes an XHR request for a 265k text file[1] with 36000 lines. The javascript code then parses the names (which takes ~300ms) and then seemingly does nothing with the information. It doesn't show up anywhere on any subsequent DOM rewrites. The actual visible content that people read is only 10k. For mobile users, you punish them twice by (1) subtracting 265k from their data plan and then (2) wasting battery power on cpu to parse it for no reason. That one example of useless bloat is probably multiplied dozens of times elsewhere in the lifecycle of the webpage. [1] don't click on this if you're on mobile phone: http://wiki.c2.com/names.txt http://wiki.c2.com/names.txt

dom0 10y ago
It doesn't seem to be the JS, though. The request that takes a whoppin' 33 seconds - server-side - for me is http://c2.com/wiki/remodel/pages/TipsForReadingCode http://c2.com/wiki/remodel/pages/TipsForReadingCode
twiss 10y ago
It seems like a list of all the pages on the wiki, presumably to turn mentions of those pages in the text into links automatically. Still, it seems better to do this on the server, if possible.

mercurysmessage 10y ago

It was taking me a long time as well (Canada), so I just quit. I thought it was noscript but I allowed the page.