Remove .htaccess from project?

[roblarsen]

This is a discussion that started after #1526 was closed.

The basic argument is that the .htaccess file:

• Is confusing for newbies (as well as some more advanced users)
• It can cause trouble when the the server configuration is uploaded unchanged to certain hosting environments (related issue on server configs repo)

A third point is that IIS and nginx are both gaining on Apache with IIS nipping at its heels.
#1526 suggested renaming it to solve these issues. That was closed, but the issues are still worth evaluating in a different context.

[koistya]

👍 And maybe add into README.md a direct link to the IIS, Apache configuration docs.

[QWp6t]

👍 delete .htaccess
👍 add note to README.md

[stevenosloan]

probably bias as a primarily nginx user, but removing .htaccess and linking to the h5bp/server-configs project sounds like a great solution to me.

[xeniun]

No to delete anything! Why? We want H5BP for dummies?

[patrickkettner]

@xeniun the idea is that this isn't the best place for an .htaccess file. The server-configs is a better one. It has nothing to do with skill or intelligence.

[xeniun]

So, it's the same for normalize.css or icons or jquery? I like a version with the basic and functional configuration. I think we have to write help documentations and people must to read it before just play. So everyone can modify anything they like or not like.

[patrickkettner]

So, it's the same for normalize.css or icons or jquery?

not at all. Those are front end assets. htaccess is a backend, serverside asset.

Basic and functional server side configurations are available in the server config repo.

[roblarsen]

So, it's the same for normalize.css or icons or jquery?

Not at all. If you're looking at H5BP as an HMTL/CSS/JavaScript foundation, then obviously the main JavaScript and CSS components are central to the project.

[battaglr]

+1

[daniel-kehorne]

1 vote for not deleting.

[jeffreybarke]

While I personally appreciate the convenience of having a boilerplate .htaccess in the HTML5 Boilerplate, conceptually I don't think it belongs here and should be removed.

After it's removed, the root README should be updated with the links from the h5bp/server-configs README.

[JoshuaJones]

While I personally appreciate the convenience of having a boilerplate .htaccess in the HTML5 Boilerplate, conceptually I don't think it belongs here and should be removed.

After it's removed, the root README should be updated with the links from the h5bp/server-configs README.

👍

I've run into multiple cases of using h5bp for different CMS/framework themes where the .htaccess isn't really needed. Moving into the server-configs seems to make the most sense.

[xnf]

Downvote for removing. Its always easier to remove something when it is not needed rather than adding when needed. Especially with links to official Apache docs which are not the most easy thing to read.

[phoebejaffe]

I'd also say don't remove .htaccess . It can be useful as a teaching tool for people unfamiliar with the existence of .htaccess, prompting them to read up on it.

[GlassGruber]

-1 I really think that people can decide on their own if it is necessary to their project or not, while for less expert people on server side it is extremely useful as a starting point.

[derekjohnson]

I would prefer if it was left in. I found it super useful when I starting using HTML5 boilerplate and pored over the code in it before (and way, way more often than) the docs.

Although it's server config there's a lot in there that affects frontend performance. It was my introduction to perf and I view it as in integral part of a well rounded, bases covered professional website.

[QWp6t]

I don't think anyone has given a compelling reason to keep it in this repo.

It would still be available in the server configs repo: https://github.com/h5bp/server-configs-apache

So again, I say get rid of it from this repo. People who want it will still have access to it in its dedicated repo, and we can always put a link to the dedicated repo in this repo's readme..

[alilleybrinker]

The classic line that this project has used is that it is "delete key friendly." While the .htaccess file is not truly a front-end file, as @derekjohnson says, it is a useful introduction to the ideas of server configuration. Ideas that are, if nothing else, pertinent to the interests of front end developers.

There is little harm in keeping the file in the H5BP repo, and greater harm in removing it. It provides a useful educational tool to those who may be unaware of the importance of proper server configuration, and it can be easily removed for people who don't need it. For these reasons, I do not think it should be removed.

[MiguelDebruyne]

I totally agree with @AndrewBrinker. The use of it is far greater than harm of removing it. It's not like it is cluttering up the project with useless stuff

[didacrios]

Another vote for not deleting

I understand that this belongs to the backend, otherwise i think the h5bp must have a basic and safe .htaccess config, wich actually have.

The .htaccess file have a great basic configuration that all frontend developers must care, so im agree with @derekjohnson.

I think that If a frontend developer doesn't feel comfortable with this .htaccess, he/she should have to focus on something else.

[carlos-reynosa]

I always thought it was odd it was in there.

[koistya]

The .htaccess file have a great basic configuration that all frontend developers must care, so im agree with @derekjohnson.

@Mitsurugi that would be true of all front-end developers use web servers that support .htaccess. Most web developers I personally know either use Node.js-based web server or IIS, Nginx.

[roblarsen]

@koistya as I linked to at the top of the issue Apache is still the top web server globally, so it's got that going for it.

That said, IIS and nginx are much closer that they have been in years. So from that perspective it seems to make less sense for this project (which is generally pretty open/global in vision) to default to Apache. I mean, if IIS takes over the top spot would we swap .htaccess out for a web.config?

[koistya]

@koistya as I linked to at the top of the issue Apache is still the top web server globally, so it's got that going for it.

@roblarsen that could be a not so accurate metrics to consider (as opposed to web servers used now by @h5bp audience). I'm curious, how many of you personally know any front-end developers using Apache for new projects?

[roblarsen]

@koistya An informal survey with the Github selection bias in full effect is, never, in a million years, going to be more accurate than Netcraft's survey.

Since it's used as the foundation for so many other things the @h5bpp audience is basically the global web developer community.. The Github H5BP community and the overall H5BP user community are not equivalent in skills, tech stack or interests. There are some things that we we thought were self-evident that ended up being not-so-self-evident in the wild. That's why I like to rely on things like the Netcraft survey or (Builtwith)[http://trends.builtwith.com/Web-Server/Apache] rather than what I think people are doing or are aware of.

And for what it's worth, all my personal development is still on Apache and one of the two consulting projects I'm on right now is on Apache (and the other will use Tomcat), so I'd sink your informal survey right off the bat.

Apache remains super popular. I don't honestly believe that's even up for debate.

[alrra]

Thank you for your feedback! We'll be sticking¹ with the Apache server configs for H5BP v5, and we'll be revisiting the removal for v6.

¹ Reasons include:

• Apache is still the most used server out there, especially with your average Joe's hosting service
  (the docs however, will be updated to promote even more the other server configs)
• even though server configurations are not truly front-end, they make the servers highly improve the front-end part (compression, caching, basic security, ensuring that resources are served with the correct content-type, etc.)
• some of the other server configurations still need work - hopefully we'll get all server configurations (or at least most of them) to a point where they all provide the same basic features