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
