don't know if it's already said but if you are using nginx, there's a plugin for minification and builtin support for compressing html pages or static assets. therefore, nobody needs a third-party dependency for building the docs.

On Friday, 16 January 2015 at 22:32:07 UTC, Steven Schveighoffer wrote:
> On 1/16/15 5:23 PM, Andrei Alexandrescu wrote:
>> On 1/16/15 1:44 PM, Steven Schveighoffer wrote:
>>> On an embedded product we have with a dead-simple web server, there is
>>> terrible network performance. Adding gzip support saved way more than
>>> minification ever could. But the best performance improvement was to add
>>> caching support to the server. Both the browser and the server have to
>>> cooperate there.
>>
>> Pretty cool. The problem I'm having right now is the following pattern:
>>
>> 1. I have a mini-idea that takes me minutes to implement and turns the
>> ratchet in the right direction.
>
> At the cost of adding dependencies for builds, and requiring builds be done with Internet access. I don't think it's out of line to ask that if we are going to add extra build requirements, we should make sure it's really making decent progress.
>

Why do we need an external services?

    cat style.css |
        tr '\n' ' ' |
        sed 's/\/\*[^*]*\*\///g' |
        sed 's/\s\+/ /g' |
        sed 's/ \?\([(){},;]\) \?/\1/g

Strictly speaking, this is overzealous (e.g. it also operates inside strings), and I didn't even test it, but it will probably work for almost all cases. The current main CSS file of dlang.org (style.css) shrinks from 14757 to 11720 bytes, a reduction of ~21%.

But even writing a compressor in D should be trivial, as you'd only need a lexer.

>> 2. I post it here in the hope that others will build upon or come with
>> better ideas.
>>
>> 3. I get feedback here that essentially demonstrates me that if I spent
>> some hours or days on a small research project on a better idea, it
>> would yield better results.
>
> I think you misunderstand. We are not saying "do a research project", it takes seconds to gzip 2 files (the minified and not minified) and see the size difference. If it's super-significant, let's go for it! If you send me the minified file, I can test it for you.
>
> There doesn't need to be any research, but all the suggestions that have been provided have NOT required extra tools or dependencies. That is a significant difference.
>
> -Steve

On Friday, 16 January 2015 at 22:02:27 UTC, Kiith-Sa wrote:
> Also, -1 for CSS minification, if I'll ever want to make any CSS contibutions I'll start by looking at the CSS in the browser.

You'd use the DOM inspectors in this case, no? They don't care about the formatting of the CSS file.

Another cheap addition, down to 11577 bytes:

    cat style.css |
        tr '\n' ' ' |
        sed 's/\/\*[^*]*\*\///g' |
        sed 's/\s\+/ /g' |
        sed 's/ \?\([(){},;]\) \?/\1/g |
        sed 's/;}/}/g'

On 1/17/15 4:58 AM, Mengu wrote:
> don't know if it's already said but if you are using nginx,

We use Apache as far as I know.

> there's a
> plugin for minification and builtin support for compressing html pages
> or static assets. therefore, nobody needs a third-party dependency for
> building the docs.

Opt-in is fine. Please review and pull: https://github.com/D-Programming-Language/dlang.org/pull/770


Andrei

On 1/17/15 8:44 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Friday, 16 January 2015 at 22:32:07 UTC, Steven Schveighoffer wrote:
>> On 1/16/15 5:23 PM, Andrei Alexandrescu wrote:
>>> On 1/16/15 1:44 PM, Steven Schveighoffer wrote:
>>>> On an embedded product we have with a dead-simple web server, there is
>>>> terrible network performance. Adding gzip support saved way more than
>>>> minification ever could. But the best performance improvement was to
>>>> add
>>>> caching support to the server. Both the browser and the server have to
>>>> cooperate there.
>>>
>>> Pretty cool. The problem I'm having right now is the following pattern:
>>>
>>> 1. I have a mini-idea that takes me minutes to implement and turns the
>>> ratchet in the right direction.
>>
>> At the cost of adding dependencies for builds, and requiring builds be
>> done with Internet access. I don't think it's out of line to ask that
>> if we are going to add extra build requirements, we should make sure
>> it's really making decent progress.
>>
>
> Why do we need an external services?
>
>      cat style.css |
>          tr '\n' ' ' |
>          sed 's/\/\*[^*]*\*\///g' |
>          sed 's/\s\+/ /g' |
>          sed 's/ \?\([(){},;]\) \?/\1/g
>
> Strictly speaking, this is overzealous (e.g. it also operates inside
> strings), and I didn't even test it, but it will probably work for
> almost all cases. The current main CSS file of dlang.org (style.css)
> shrinks from 14757 to 11720 bytes, a reduction of ~21%.
>
> But even writing a compressor in D should be trivial, as you'd only need
> a lexer.

Would be a nice tools/ thing. Wanna do it/ --- Andrei

On Friday, 16 January 2015 at 17:40:40 UTC, Andrei Alexandrescu wrote:
> I just added https://github.com/D-Programming-Language/dlang.org/pull/770, which generates minified css files. This is because in the near future css files will become heftier (more documentation comments, more detailed styles etc).
>
> The disadvantage is that now one needs to be online to generate documentation. Thoughts?
>
>
> Andrei

I have taken a look at http://dlang.org and assessed some of the improvements to be made. I will probably step on someones toes, sorry, but that is just because I have big feet.

A lot of people have already said this, but minification is the last thing on the list.

My browser needs to parse 299kb to display the page. Javascript alone takes up 210kb of that. 131kb of that is uncompressed. 33kb is jQuery and 33kb is widget.js.

That widget.js thing is probably because of the twitter stream on the right. A seasoned JS programmer can rewrite that stuff in about 6kb, if not less.

jQuery is the enabler of all bad habits; best to remove it quickly, if only because of principles. If you really got addicted to that horse*@&#, try zepto.

But codemirror-compressed.js and run.js are by far the worst contenders and should be addressed as first. You can bring down loading times to half (yes, you read that correctly, you can cut 150kb). Besides, do you really need 100+kb of codemirror JS? What is it even doing? Even if you really need it, why not compress the thing? It takes around 4 lines in apache conf to accomplish this. Give me SSH access and I'll do it in under 2 min.

Caching is the next trick in the list. Remember that ISP's, proxy, etc. may also cache your files, not just browsers.

These are the files that are referenced by http://dlang.org and are not using caching (nor compression!):
dlang.org/
codemirror.css
style.css
print.css
codemirror-compressed.js
run-main-website.js
run.js
search-left.gif
search-button.gif
dlogo.png
gradient-red.jpg
search-bg.gif

Next point on the list is bundling resources. The browser can only load some much stuff async. If you have too much, part of those resource are going to be blocked. Which basically means you have another round-trip + data that you have to wait for.

While there are some other optimizations to be made - like putting that twitter stream js at the bottom of the page - the point is this: If I wanted to optimize this website, minifying style.css would be the last thing on my list.

Besides, minimizing CSS is tantamount to removing comments and whitespace. Like Adam Ruppe said, a regex program in D can accomplish that; no need to use a online service. It probably takes you more time to integrate the online service than to write the D program including the regex.

At the end of the day, watching `mb-downloaded per resource per total` tells you nothing. What only matter is the time it takes for users to enter `http://dlang.org` in the browser, up until the time they get to see something they can click on.

Being among this group of knowledgeable programmers it amazes me this site is still pre 2000. I for one, am required to use Lynx just because my eyes can't stand the design.

OT:

And lets be honest here, why the hell do we even use apache+php and not D+vibe.d? I just rewrote my companies corporate website in under 4 hours. Granted, it is a simple one. But this community should be able to rewrite this site in D in under a week, right?

On 1/17/15 10:01 AM, Sebastiaan Koppe wrote:
> On Friday, 16 January 2015 at 17:40:40 UTC, Andrei Alexandrescu wrote:
>> I just added
>> https://github.com/D-Programming-Language/dlang.org/pull/770, which
>> generates minified css files. This is because in the near future css
>> files will become heftier (more documentation comments, more detailed
>> styles etc).
>>
>> The disadvantage is that now one needs to be online to generate
>> documentation. Thoughts?
>>
>>
>> Andrei
>
> I have taken a look at http://dlang.org and assessed some of the
> improvements to be made. I will probably step on someones toes, sorry,
> but that is just because I have big feet.

Fantastic.

> A lot of people have already said this, but minification is the last
> thing on the list.

Measurements contradict that. Anyhow my point was one line of code reduces all site traffic by 5% - they call that a good day.

> My browser needs to parse 299kb to display the page. Javascript alone
> takes up 210kb of that. 131kb of that is uncompressed. 33kb is jQuery
> and 33kb is widget.js.
>
> That widget.js thing is probably because of the twitter stream on the
> right. A seasoned JS programmer can rewrite that stuff in about 6kb, if
> not less.

Great. You forgot to link to your pull request :o).

> jQuery is the enabler of all bad habits; best to remove it quickly, if
> only because of principles. If you really got addicted to that
> horse*@&#, try zepto.

I'm not an expert or an ideologist in the area. It was added by others who obviously have a different opinion from yours.

> But codemirror-compressed.js and run.js are by far the worst contenders
> and should be addressed as first. You can bring down loading times to
> half (yes, you read that correctly, you can cut 150kb). Besides, do you
> really need 100+kb of codemirror JS? What is it even doing? Even if you
> really need it, why not compress the thing? It takes around 4 lines in
> apache conf to accomplish this. Give me SSH access and I'll do it in
> under 2 min.

I'm working with our webmaster to create accounts for a few folks. For now you may want to send me what needs to be done and I'll take it with him. N.B. I vaguely recall I've tried that once but it was not possible for obscure reasons.

> Caching is the next trick in the list. Remember that ISP's, proxy, etc.
> may also cache your files, not just browsers.
>
> These are the files that are referenced by http://dlang.org and are not
> using caching (nor compression!):
> dlang.org/
> codemirror.css
> style.css
> print.css
> codemirror-compressed.js
> run-main-website.js
> run.js
> search-left.gif
> search-button.gif
> dlogo.png
> gradient-red.jpg
> search-bg.gif

Where should these be cached? I don't understand.

> Next point on the list is bundling resources. The browser can only load
> some much stuff async. If you have too much, part of those resource are
> going to be blocked. Which basically means you have another round-trip +
> data that you have to wait for.

Yah, we do a bunch of that stuff on facebook.com. It's significant work. Wanna have at it?

> While there are some other optimizations to be made - like putting that
> twitter stream js at the bottom of the page - the point is this: If I
> wanted to optimize this website, minifying style.css would be the last
> thing on my list.

Yah, the problem is everything on your list is hypothetical and not done, whereas css minimization is actual and done. Big difference. Very big difference.

> Besides, minimizing CSS is tantamount to removing comments and
> whitespace. Like Adam Ruppe said, a regex program in D can accomplish
> that; no need to use a online service. It probably takes you more time
> to integrate the online service than to write the D program including
> the regex.

Then do it.

> At the end of the day, watching `mb-downloaded per resource per total`
> tells you nothing. What only matter is the time it takes for users to
> enter `http://dlang.org` in the browser, up until the time they get to
> see something they can click on.

Agreed.

> Being among this group of knowledgeable programmers it amazes me this
> site is still pre 2000. I for one, am required to use Lynx just because
> my eyes can't stand the design.

Then improve it.

> OT:
>
> And lets be honest here, why the hell do we even use apache+php and not
> D+vibe.d? I just rewrote my companies corporate website in under 4
> hours. Granted, it is a simple one. But this community should be able to
> rewrite this site in D in under a week, right?

I wish.


Andrei

On Saturday, 17 January 2015 at 18:23:45 UTC, Andrei Alexandrescu wrote:
> On 1/17/15 10:01 AM, Sebastiaan Koppe wrote:
>>
>> A seasoned JS programmer can rewrite that stuff in about 6kb, if not less.
>
> Great. You forgot to link to your pull request :o).
Wait, one step back. I was still in assessment mode. I haven't committed to doing anything.

>> jQuery is the enabler of all bad habits; best to remove it quickly, if
>> only because of principles. If you really got addicted to that
>> horse*@&#, try zepto.
>
> I'm not an expert or an ideologist in the area. It was added by others who obviously have a different opinion from yours.
Well, then they should use http://zeptojs.com/

>> why not compress the thing? It takes around 4 lines in
>> apache conf to accomplish this. Give me SSH access and I'll do it in under 2 min.
>
> I'm working with our webmaster to create accounts for a few folks. For now you may want to send me what needs to be done and I'll take it with him. N.B. I vaguely recall I've tried that once but it was not possible for obscure reasons.
I do not know the obscure reasons, but it should be as simple as:

nano /etc/apache2/mods-enabled/deflate.conf

<IfModule mod_deflate.c>
          # these are known to be safe with MSIE 6
          AddOutputFilterByType DEFLATE text/html text/plain text/xml

          # everything else may cause problems with MSIE 6
          AddOutputFilterByType DEFLATE text/css
          AddOutputFilterByType DEFLATE application/x-javascript application/javacript application/ecmascript
          AddOutputFilterByType DEFLATE application/rss+xml
          AddOutputFilterByType DEFLATE application/json
</IfModule>

I know I am imposing on somebodies else's work here, but compressing resources should really be done.

>> Caching is the next trick in the list. Remember that ISP's, proxy, etc.
>> may also cache your files, not just browsers.
>>
> Where should these be cached? I don't understand.
In the browser. So that on a reload of the page, the browser, instead of making HTTP calls, uses it's cache.

>> Next point on the list is bundling resources. The browser can only load
>> some much stuff async. If you have too much, part of those resource are
>> going to be blocked. Which basically means you have another round-trip +
>> data that you have to wait for.
>
> Yah, we do a bunch of that stuff on facebook.com. It's significant work. Wanna have at it?
Yes. Please. But the compression thing takes precedence.

>> While there are some other optimizations to be made - like putting that
>> twitter stream js at the bottom of the page - the point is this: If I
>> wanted to optimize this website, minifying style.css would be the last
>> thing on my list.
>
> Yah, the problem is everything on your list is hypothetical and not done, whereas css minimization is actual and done. Big difference. Very big difference.
True. If you can get a 4% difference by minimizing CSS, just do it. I am just saying you can do a lot better.

Plus, I think with all the expertise around here, most of us who do web development, did this at one stage or the other.
>
>> Besides, minimizing CSS is tantamount to removing comments and
>> whitespace. Like Adam Ruppe said, a regex program in D can accomplish
>> that; no need to use a online service. It probably takes you more time
>> to integrate the online service than to write the D program including
>> the regex.
>
> Then do it.
regex to select comments: /(\/\*[^(*\/)]+\*\/)/g
regex to select whitespace: /(\s+)/g

and then delete those.

I know css minimizers do more, but if comments and whitespace is your issue, this does the trick.
>
>> Being among this group of knowledgeable programmers it amazes me this
>> site is still pre 2000. I for one, am required to use Lynx just because
>> my eyes can't stand the design.
>
> Then improve it.
Design is a *very* touchy issue. It is basically a matter of choice. Without a definite choice made, I won't waste my time improving it.

The choice is very simple:

keep it like it is,
do what everybody else is doing

On 1/17/15 12:00 PM, Sebastiaan Koppe wrote:
> On Saturday, 17 January 2015 at 18:23:45 UTC, Andrei Alexandrescu wrote:
>> On 1/17/15 10:01 AM, Sebastiaan Koppe wrote:
>> I'm not an expert or an ideologist in the area. It was added by others
>> who obviously have a different opinion from yours.
> Well, then they should use http://zeptojs.com/

Of course. :o)

>>> why not compress the thing? It takes around 4 lines in
>>> apache conf to accomplish this. Give me SSH access and I'll do it in
>>> under 2 min.
>>
>> I'm working with our webmaster to create accounts for a few folks. For
>> now you may want to send me what needs to be done and I'll take it
>> with him. N.B. I vaguely recall I've tried that once but it was not
>> possible for obscure reasons.
> I do not know the obscure reasons, but it should be as simple as:
>
> nano /etc/apache2/mods-enabled/deflate.conf
>
> <IfModule mod_deflate.c>
>            # these are known to be safe with MSIE 6
>            AddOutputFilterByType DEFLATE text/html text/plain text/xml
>
>            # everything else may cause problems with MSIE 6
>            AddOutputFilterByType DEFLATE text/css
>            AddOutputFilterByType DEFLATE application/x-javascript
> application/javacript application/ecmascript
>            AddOutputFilterByType DEFLATE application/rss+xml
>            AddOutputFilterByType DEFLATE application/json
> </IfModule>
>
> I know I am imposing on somebodies else's work here, but compressing
> resources should really be done.

Forwarded to our webmaster, thanks.

>>> Caching is the next trick in the list. Remember that ISP's, proxy, etc.
>>> may also cache your files, not just browsers.
>>>
>> Where should these be cached? I don't understand.
> In the browser. So that on a reload of the page, the browser, instead of
> making HTTP calls, uses it's cache.

How do we improve that on our side?

>>> Next point on the list is bundling resources. The browser can only load
>>> some much stuff async. If you have too much, part of those resource are
>>> going to be blocked. Which basically means you have another round-trip +
>>> data that you have to wait for.
>>
>> Yah, we do a bunch of that stuff on facebook.com. It's significant
>> work. Wanna have at it?
> Yes. Please. But the compression thing takes precedence.

Awesome. Don't forget you said this.

> regex to select comments: /(\/\*[^(*\/)]+\*\/)/g
> regex to select whitespace: /(\s+)/g
>
> and then delete those.

Tested PR or by the end of the day this will slide into obsolescence.

> Design is a *very* touchy issue. It is basically a matter of choice.
> Without a definite choice made, I won't waste my time improving it.

It's clear that once in a while we need to change the design just because it's old. Also, there are a few VERY obvious design improvements that need be done and would be accepted in a heartbeat, but NOBODY is doing them.

I'm not an expert in design but I can tell within a second whether I like one. Yet no PR is coming for improving the design.

> The choice is very simple:
>
> keep it like it is,
> do what everybody else is doing

False choice.


Andrei