6 ms·

Nice tutorial, I just disagree on two small points. First, there are very sound arguments for not using CSS preprocessors [1]. Second, for a website that you

by nmc 13y ago

Nice tutorial, I just disagree on two small points. First, there are very sound arguments for not using CSS preprocessors [1]. Second, for a website that you own, using ".htaccess" is discouraged for performances reasons. The Apache 2.4 docs [2] say: "You should avoid using .htaccess files completely if you have access to httpd main server config file. Using .htaccess files slows down your Apache http server. Any directive that you can include in a .htaccess file is better set in a Directory block, as it will have the same effect with better performance." [1] http://blog.millermedeiros.com/the-problem-with-css-pre-processors/ http://blog.millermedeiros.com/the-problem-with-css-pre-proc... [2] http://httpd.apache.org/docs/2.4/howto/htaccess.html http://httpd.apache.org/docs/2.4/howto/htaccess.html

laumars 13y ago
> Second, for a website that you own, using ".htaccess" is discouraged for performances reasons. Agreed, and not just for performance reasons but security as well. While a correct set up wouldn't allow write access to the docs root nor developers to copy up hidden files, sometimes a sysadmin drops the ball. So disabling the use of .htaccess files prevents an attacker from changing your Apache configuration without gaining root access (and if that happens, then it's already game over).
pyalot2 13y ago
The benefit of having some (any) facility to be able to write non vendor prefix/semantic infested CSS and to have nesting take care of an otherwise entirely unmaintainable flat CSS selector soup so far outweights any drawback that whatever argument you'll contrieve to construct against CSS preprocessors is essentially null, nill and invalid.
petewailes 13y ago
I can't agree with the first. Most of the arguments from the quoted post are the result of bad practice with preprocessing, not preprocessing itself. For example, the "Dumb code duplication is dumb" example is just someone writing things badly. It should have been written as: .error-default, .error-special { @include error; } .error-special { background-color: #fcc; } Similar arguments can be made for most of the other points. The nesting part for example seems to imply that you'd write in LESS/SASS etc, then maintain the post-processed CSS - whereas obviously you'd be maintaining the pre-processed files. Not convinced, personally. Disclosure: I actively develop a CSS framework built explicitly around the functionality of preprocessors.
- nmc 13y ago
  "not preprocessing itself [...] just someone writing things badly" I agree with that, but I think that is precisely the point of the quoted post: CSS preprocessors, not unlike compile-to-JS languages, try to make you write less, at the cost of pushing you to write badly. Of course, with a full mastery of LESS, you will not make those mistakes. But you will probably make them a lot while learning to become such a master.
onion2k 13y ago
The reasons not to use preprocessors set out in that article are generally arguments against using one without understanding what it's actually doing. A little knowledge is a dangerous thing - poorly written SASS code can build a nightmare forest of styles that get out of hand quickly, slow the client down, and cascade in strange and wonderful ways - but that isn't a reason not to use it. It's a reason to learn it.
prottmann 13y ago
How many Billions of visitors you need, until a local .htaccess slows down your Website significant ?
- laumars 13y ago
  It's not just dependant on traffic, other factors include: o How deep the page request is (as Apache cascades it's checks down the directory structure, so /article/year/month/day/page.html could look for a .htaccess file in 4 different locations before even reaching /.htaccess. o The IOPS of your storage (super fast SSD, slower NFS server, SAN? etc) o And whether your host OS has done any file caching (dependant on if a file exists and if it's been modified outside of the OS, in the case of network mounted file systems) So the only way to know precisely would be to benchmark (a basic load test should suffice). However if you're running a blog on a VPS and you occasionally have articles hit HN and other aggregators, then disabling .htaccess (amongst other free tweaks) could be enough to prevent your site getting DDoS'ed offline if/when you hit the front page.
- dave1010uk 13y ago
  Very rough benchmarks running "ab" against a random page on localhost: with AllowOverride 215rps without AllowOverride 245rps It makes a difference, but there's not enough data to conclude much.
  - m3mnoch 13y ago
    so, what you're saying here is that if you skip the ease and convenience of .htaccess files, you can get better performance? as in, if you get slasdotted (ha! i'm old!) your site will stay up either way as long as you're getting less than 215 rps. and it goes down either way if you're getting more than 245 rps. that's a pretty tiny window in the grand scheme of things. yeah... i'd rather my personal site be easier to maintain. and, as to the security of it -- if you have access to the httpd.conf file, i GUARANTEE you've got bigger holes in your own hodge-podge, whole-system security than something like an .htaccess file on which you'd have to work really hard and explicitly make insecure. just sayin'.
iamchrisle 13y ago
The .htaccess file is important for SEO. For the context of the blog (seogadget.com), it's worth noting that SEO is more important than performance. The .htaccess is used to 301 redirect www.bennet.org to bennet.org. Important for SEO so that Google only indexes one domain instead of the domain and the subdomain. Only indexing one domain gives it a better chance of ranking higher. Also.. do you really think the traffic and 453k of bandwidth is really going to put any strain on performance?
- vonmoltke 13y ago
  The .htaccess file is not required for anything. Anything that can be put into .htaccess can be put into httpd.conf or one of the virtual host confs.
  - chime 13y ago
    Agreed. However, in a shared hosting environment (which most personal sites are in), you can't edit the .conf files.
    - bstamour 13y ago
      Which goes right back to the original piece of advice: if you have access to the main apache config, put your changes there for performance reasons. Otherwise use .htaccess.
  - oneeyedpigeon 13y ago
    > Anything that can be put into .htaccess can be put into httpd.conf or one of the virtual host confs. Also, important to note, "and not vice versa" (i.e. httpd.conf much more powerful)
- sspiff 13y ago
  .htaccess is read only by the webserver, never by the crawler or client. So how you implement your redirect (through .htaccess or central apache config files) will not affect how an outsider sees your website. I'm pretty sure Google is smart enough to understand DNS CNAME records, too.
normloman 13y ago
He said hand coding. Not hand hosting. He's on a shared host, so good luck changing the main server config.

by nmc 13y ago

laumars 13y ago

> Second, for a website that you own, using ".htaccess" is discouraged for performances reasons. Agreed, and not just for performance reasons but security as well. While a correct set up wouldn't allow write access to the docs root nor developers to copy up hidden files, sometimes a sysadmin drops the ball. So disabling the use of .htaccess files prevents an attacker from changing your Apache configuration without gaining root access (and if that happens, then it's already game over).

pyalot2 13y ago

The benefit of having some (any) facility to be able to write non vendor prefix/semantic infested CSS and to have nesting take care of an otherwise entirely unmaintainable flat CSS selector soup so far outweights any drawback that whatever argument you'll contrieve to construct against CSS preprocessors is essentially null, nill and invalid.

petewailes 13y ago

I can't agree with the first. Most of the arguments from the quoted post are the result of bad practice with preprocessing, not preprocessing itself. For example, the "Dumb code duplication is dumb" example is just someone writing things badly. It should have been written as: .error-default, .error-special { @include error; } .error-special { background-color: #fcc; } Similar arguments can be made for most of the other points. The nesting part for example seems to imply that you'd write in LESS/SASS etc, then maintain the post-processed CSS - whereas obviously you'd be maintaining the pre-processed files. Not convinced, personally. Disclosure: I actively develop a CSS framework built explicitly around the functionality of preprocessors.

nmc 13y ago
"not preprocessing itself [...] just someone writing things badly" I agree with that, but I think that is precisely the point of the quoted post: CSS preprocessors, not unlike compile-to-JS languages, try to make you write less, at the cost of pushing you to write badly. Of course, with a full mastery of LESS, you will not make those mistakes. But you will probably make them a lot while learning to become such a master.

onion2k 13y ago

The reasons not to use preprocessors set out in that article are generally arguments against using one without understanding what it's actually doing. A little knowledge is a dangerous thing - poorly written SASS code can build a nightmare forest of styles that get out of hand quickly, slow the client down, and cascade in strange and wonderful ways - but that isn't a reason not to use it. It's a reason to learn it.

prottmann 13y ago

How many Billions of visitors you need, until a local .htaccess slows down your Website significant ?

laumars 13y ago
It's not just dependant on traffic, other factors include: o How deep the page request is (as Apache cascades it's checks down the directory structure, so /article/year/month/day/page.html could look for a .htaccess file in 4 different locations before even reaching /.htaccess. o The IOPS of your storage (super fast SSD, slower NFS server, SAN? etc) o And whether your host OS has done any file caching (dependant on if a file exists and if it's been modified outside of the OS, in the case of network mounted file systems) So the only way to know precisely would be to benchmark (a basic load test should suffice). However if you're running a blog on a VPS and you occasionally have articles hit HN and other aggregators, then disabling .htaccess (amongst other free tweaks) could be enough to prevent your site getting DDoS'ed offline if/when you hit the front page.
dave1010uk 13y ago
Very rough benchmarks running "ab" against a random page on localhost: with AllowOverride 215rps without AllowOverride 245rps It makes a difference, but there's not enough data to conclude much.
- m3mnoch 13y ago
  so, what you're saying here is that if you skip the ease and convenience of .htaccess files, you can get better performance? as in, if you get slasdotted (ha! i'm old!) your site will stay up either way as long as you're getting less than 215 rps. and it goes down either way if you're getting more than 245 rps. that's a pretty tiny window in the grand scheme of things. yeah... i'd rather my personal site be easier to maintain. and, as to the security of it -- if you have access to the httpd.conf file, i GUARANTEE you've got bigger holes in your own hodge-podge, whole-system security than something like an .htaccess file on which you'd have to work really hard and explicitly make insecure. just sayin'.

iamchrisle 13y ago

The .htaccess file is important for SEO. For the context of the blog (seogadget.com), it's worth noting that SEO is more important than performance. The .htaccess is used to 301 redirect www.bennet.org to bennet.org. Important for SEO so that Google only indexes one domain instead of the domain and the subdomain. Only indexing one domain gives it a better chance of ranking higher. Also.. do you really think the traffic and 453k of bandwidth is really going to put any strain on performance?

vonmoltke 13y ago
The .htaccess file is not required for anything. Anything that can be put into .htaccess can be put into httpd.conf or one of the virtual host confs.
- chime 13y ago
  Agreed. However, in a shared hosting environment (which most personal sites are in), you can't edit the .conf files.
  - bstamour 13y ago
    Which goes right back to the original piece of advice: if you have access to the main apache config, put your changes there for performance reasons. Otherwise use .htaccess.
- oneeyedpigeon 13y ago
  > Anything that can be put into .htaccess can be put into httpd.conf or one of the virtual host confs. Also, important to note, "and not vice versa" (i.e. httpd.conf much more powerful)
sspiff 13y ago
.htaccess is read only by the webserver, never by the crawler or client. So how you implement your redirect (through .htaccess or central apache config files) will not affect how an outsider sees your website. I'm pretty sure Google is smart enough to understand DNS CNAME records, too.

normloman 13y ago

He said hand coding. Not hand hosting. He's on a shared host, so good luck changing the main server config.