I'm not viewing the website on mobile, and nor did the people I shared it with, but we all were surprised at the slowness. Of course, as you mention, the quality of the content is enough to cover over the performance issues, but it most certainly detracts from the website.

Fine, that wasn't the spirit of the original comment I replied to though, which was needlessly negative and lacked any awareness of context.

I'm a developer and I just read this whole site on mobile to see if there's anything I don't know. Initial load was clunky, fonts have initially not been showing up but after that it works pretty well on mobile.

Yep wasn't suggesting it wouldn't work fine on mobile, just addressing the 'perf' criticism which to me, isn't really relevant to most devs when they would tend to use that resource on their dev machines.

I nearly closed it when it it loaded this bad and I saw the fonts missing. But scrolled a bit and fonts showed up. So 'perf' criticism is valid because it's so bad on this site that it affected usability for me.

But you didn't close it? So you're not even one negative datapoint. I don't think any rational dev would close a useful developer resource based on perf reasons.

Again, I'm merely replying to the initial comment which was needlessly negative and frankly a tiring trope on HN (rudely criticising something unimportant about the site regardless of its intended use).

Honestly, your going on about it is worse. Sometimes a negative comment just comes out badly. It happens. And even then, taken in good faith, at least it's somewhat constructive. This whole sub-thread of you arguing against people doing exactly that, is off-topic good for nothing ballast. That is a tiring and persistent HN-trope I can really do without.

Just answered each comment as it came, trying to defend a good submission against nonsensical snark.

If you don't like sub-threads I suggest you get an HN-reader than can collapse comments.

Developers don't use mobile? Or tablets? Or...performance?

http://imgur.com/a/GiGBY

That's not what I said.

It's not your exact words, but I don't think it's an unfair characterization, if the excuse is simply that they'll be reading it on a desktop machine anyway.

I took that image from a non-laptop desktop machine, by the way.

> It's not your exact words, but I don't think it's an unfair characterization

You ignored the half of the sentence following the 'or'. To me, that's unfair.

> if the excuse is [...]

It's not an excuse, it's context.

The performance is a low priority compared to the content, when the site is a developer resource.

And for me it speaks to credibility.

As another random anecdote from another random developer, I find the site's content far outshines any purported credibility loss - which just seems like a very silly argument to make.

Perf is not important for a dev resource. If a dev had spent a ton of time optimising that they'd have wasted their time. Why does wasting their time make them more credible?

I disagree.

In many places, perf is still important, and one of the reasons, I believe, that GNU offers its manuals in various formats: [0]

I know of a few devs that work for web, but due to their nations economics, work:

* On a smartphone

* Via a satellite connection

Despite being in a first world country, I've had to do both at various times whilst working from remote areas.

The GNU manuals have a huge wealth of information, but they load fast by following simple-first policies.

caniuse.com is a SPA, but they load damn fast.

I'm not saying that this page is insanely slow, but that it is slow at all is still a surprise.

And not every dev in the world gets to have broadband.

[0] http://www.gnu.org/software/libc/manual/

> The GNU manuals have a huge wealth of information, but they load fast by following simple-first policies.

Do all GNU projects keep there documentation i one big file? I wanted to contribute some recently but got lost in a complex help file.

Most GNU manuals I've seen come as:

* HTML - entirely on one web page.

* HTML - one web page per node.

* HTML compressed (gzipped tar file) - with one web page per node.

* Info document (gzipped tar file).

* ASCII text compressed (gzipped).

* TeX dvi file (gzipped).

* PDF file.

* Texinfo source (gzipped tar file).

If the one big file (great for grepping) was too confusing, you probably want to opt for HTML, with one file per node. For example, the Sockets/Local Namespace page for glibc: [0]

[0] http://www.gnu.org/software/libc/manual/html_node/Local-Name...

Edit:

And it appears the help files are seperate inside the source code as well. [1]

[1] https://sourceware.org/git/?p=glibc.git;a=tree;f=manual;h=71...

> And it appears the help files are seperate inside the source code as well.

Thanks. It appears that this wasn't the case for make.

Ow. Make's manual is a 10,000 line texi file.

That really sucks.