What Are Your Tips for Best Practice for Web Application Structure

What are your tips for best practice for web application structure?

Should I have one base style sheet for the whole site and one for each individual page for customizations?

Be pragmatic. If you have few enough rules that you can organise them all in one file and retain an oversight of what does what, do that. If you have a significant number of rules that only apply to certain sections or individual pages in your site, by all means break them out into their own sub-stylesheets, but don't feel the need to create a separate stylesheet for every single page even when it only contains two rules. Add a page-specific class or id to <body> so you can pick out single pages from a shared stylesheet should you need to.

The separation of styles into stylesheets is for your benefit as an author, so do what you find easiest to manage. For a complicated site that'll probably be more than one CSS file, but it's not going to be dozens.

Should I have another for print styles?

Generally yes. Whilst you can embed print styles inside another stylesheet using an @media rule, this has traditionally been buggy, so putting the media in the <link> tag is usually easiest. In any case print stylesheets are often so different from their screen counterparts that it just makes sense to keep their rules separate.

I've heard that linking more files takes more time for the browser to retrieve them.

Yes, but this effect is often overstated. HTTP/1.1 reduces the per-request latency by keeping connections between the client and server alive, which is a strong mitigation.

How many is is too many?

Enough that you're extremely unlikely to have that many stylesheets. Scripts can be a problem if you're using the kind of framework that demands one script file per class, but otherwise are generally OK. It's more commonly problematic with lots of small images.

Do you heavily comment your CSS?

Light commenting usually should be enough. CSS's declarative rule style doesn't usually get complicated enough to need the in-depth explanations code can demand. In particular though, document anything counterintuitive like browser-specific hacks.

Alphabetize within elements?

Not unless that makes it easier for you to manage. Usually it wouldn't, you'd try to group similar rules, or rules applying to similar groups of elements.

Do I need a reset?

A full reset? Not if you know what you're doing and can select the particular problematic defaults you want to reset.

Should I include one or two nice libraries (JQuery and Prototype, for example)

Don't include more than one framework unless you absolutely have to.

and then have another included for each page?

If each page has particular custom behaviour you could. But that doesn't usually happen. If you make progressive-enhancement behaviour scripts that bind to eg. class names, you can include the script for each behaviour on each page that uses it, then let it find the elements to bind to automatically.

Directory Structure: How do you organize a site?

Personally, for my Python/WSGI applications:

appfolder
    application.py       - main WSGI entry point and control/configuration script
    data                 - run-time writable application file store
        private          - files not available through the web server
        public           - mounted as a virtual directory on the web server
    logs                 - access, error, application log files
    system               - all the static application code and data
        htdocs           - web server root folder
            file         - static servable files
            img          - static images
            script       - JavaScript
            style        - CSS
        lib              - Python modules used by site
            appmodule    - main application code package
        templates        - HTML page templates
            mail         - mail text templates

It's important for me to keep the ‘data’ in a separate place (with separate permissions) to the application in ‘system’. You need to be able to swap out the ‘system’ folder to upgrade the application, without having to worry that there are uploaded images in htdocs/img you have to worry about keeping.

Java Web Project Structure Best Practice

To continue my previous answer, I have many web projects. In all of them the structure under src is more or less the same. The packages are roughly separated to 3 logical layers.

First is the presentation layer, as you said, for servlets, app listeners, and helpers.

Second, there is a layer for the hibernate model/db access layer. The third layer for business logic. However, sometimes the boundary between these layers is not clear. If you are using hibernate for db access then the model is defined by hibernate classes so I put them in the same area as the dao objects. E.g. com.sample.model holds the hibernate data objects and com.sample.model.dao hold the dao objects.

If using straight jdbc (usually with Spring), then sometimes I find it more convenient to put the data objects closer to the business logic layer rather than with the db access layer.

(The rest of the stuff typically falls under the business layer).

Web project's folders/directories structure - Best practices

Your examples show two popular project structures, organize files by type or by module. I prefer the latter (code separated into modules) and I see it being used a lot for javascript frontend frameworks. It's something the Angular style guide (a good reference for angular best practices) refers to as folders by feature.

I reference the Angular style guide because your examples showed Angular projects, but the concept can be translated to other frameworks. Code is organized by feature so it's easy the find the file you need to edit. As someone pointed out in a comment, this project structure scales well as the app and team grow in size.

Current common practices in web application architecture

I'd also look into code generation/scaffolding/ORM, or ActiveRecord.

What's the best practices for making a Web application to support HTTP/2

You don't need any changes to your apps to deploy HTTP/2: most things will work out of the box.

That said, here are a few tips that apply mostly if you are starting from scratch:

Start developing your application using HTTPS. You don't want to have problems with your URLs when you deploy your application because fetching some resources over http:// (e.g. Google fonts or any other CDN resources) does not work anymore. It takes five minutes with some tools (just google "Five minutes to HTTPS development URLs").
Consider if you want to host some resources that you would normally link to a public CDN in your own server. The main performance reason with HTTP/2 for linking to some assets in a CDN, if you are not hosting your entire site on that CDN, is that those resources may be already in the user's cache. If they are not, opening a new connection takes in average half a second.
Don't set up bundling. Set up instead HTTP/2 Push. And then go and grab your favourite module manager. Give a try also to web components and PolymerJS. They are simply awesome when you are not concerned about bundling and round-trips.

If you are using a server that uses machine learning for configuring HTTP/2 Push automatically (e.g, ShimmerCat), then a third tip is to keep the structure of your web pages predictable.

What is the best practice for Enterprise level application architecture using MVC5?

Since my question has been visited a lot in the last year and there is no solid answer as I am aware of that, I decided to provide a comprehensive answer as much as possible. This answer is based on some actual projects experience and with few expert consultations:

First of all, it is important to note that in software design
process, there is nothing like solid right and wrong. As long as an
approach works for your project and fits well, it is right and if
it doesn’t, it is wrong. There are no rigid principals in software
design. There are "Project needs and specifications". But generally,
it has been accepted using "Design Patterns and Principles" makes
project more robust, reliable and easy to maintain and make
your code loosely coupled and highly cohesive.
The whole story of "Software Design and Architecture" is about how
you could manage your project easily and how you could maintain your
future changes. Think about which approach gives you best answer on
them. That will be the best for you. Don't think too much about
professionalism! Your project grows by time and gets more mature.
So just think about your project!
As a first step and for Enterprise level application architecture,
always try to follow "Separation of Concerns" or "SoC". It means you
should have different tiers for different layers of your project. It
is highly recommended to use different project in your
solution for Data Access Layer, Domain Entities, Business Layer and Presentation Layer. In MVC5 project, it is better to use Class Library Project for Data Access Layer, Domain Entities, Business Layer and a MVC project for Presentation Layer.
Data Access Layer is the project that faces to database and database interactions. You could have all your Entity Framework or similar entities in this project. Having separated layer for database layer means in the case of changing your project data warehouse, the only thing you need to change is changing this project and some minor changes on your Business Layer. All other projects in your solution remain intact. So you could easily move from MS Sql to Oracle or from Entity Framework to NHibernate.
Domain Entities is the project I use to define all my solution
level interfaces, classes, enums and variables. This project keeps
integrity throughout my solution on my classes and my methods. My
all classes in whole solution are inherited from interfaces in this
project. So I have one place to change my classes or global
variables and it means easy to maintain for future in my solution
and easy to understand for newly joined developers to the project.
Business Layer is the place I put my all business logic including
Business Entities and Business Services. The whole idea about
this layer is having one place to keep your all business methods and
interactions. All calculations, object modification and all logic
about data including saving, retrieving, changing and so on should
happen in this section. By having this layer in your project, you
could have different consumers at the same time, for example one
native MVC and one Web API layer. Or you could provide different
feeding based on different business services consumers
specifications. It is highly recommended to avoid putting any
business logic into controller section of MVC layer. Having any
business logic inside controllers means you using your presentation
layer as business logic layer and it violates Separation of Concerns. Then it won’t be easy to change from one presentation layer to other or having different type of consumers for your
solution. It is better to keep controller section in MVC as slim as
possible. The controllers should only have logic and methods
directly related to View Models. For more information about View Models
refer to section 7. One thing to remember, It is better to
have different Business Services classes based on your solution
objects or Business Entities.
Presentation Layer in MVC solution will be an MVC project. But
solution could have other type or more than one Presentation Layers
for different consumers or technology. For example you could have
one MVC layer and one Web API in one solution. Generally Use
Presentation Layer to keep all presentation logic in it.
Presentation logic shouldn’t have anything related to business logic
or data logic. So question is what is Presentation logic?
Presentation logic is logic related to view models. View models
are objects customized for views or pages. In most cases, business
objects are not suitable to use in views. On the other hand,
presentation views usually need some validation logic or
presentation logic, for example display name different than original
object names. In these cases it is better keep presentation logic
separated than business logic to make it easy to change presentation
logic or business logic independently and even easy to switch
presentation layer for different UI design or changing business
logic for having more functionality without fear of any interruption
with presentation logic. In the case of using MVC project as
presentation layer for solution, all view models should be places in
Models section of MVC project and all presentation logic should be
placed in Controllers section of project.
The last thing to say is for every multi-tier solution, you need
frameworks for object to object mapping, for example to convert your
business entity to view model. There are some tools for this
purposes like AutoMapper, BLToolkit, and EmitMapper.

Last word: please comment and score question and my answer to make it better!

Best practices to structure a database to be scaling-ready

The question is really generic, but here are few tips:

Do not use any session variables (pg_backend_pid(), inet_client_addr()) or per-session control (SET ROLE, SET SESSION) in application code.
Do not use explicit transaction control (BEGIN/COMMIT/SET TRANSACTION) in application code. All such logic should be wrapped in UDFs. This enables stateless, statement-mode pooling which enables fastest possible DB pooling. (see pgbouncer docs, and pg wiki for more info)
Encapsulate all App<->Db communication in well defined DB API of UDFs - this will let you use PL/Proxy. If doing this with all SELECTs is too hard, do it at least for all data writes (INSERT/UPDATE/DELETE). Example: instead of INSERT INTO users(name) VALUES('Joe') you need SELECT create_user('Joe').
check your DB schema - is it easy to separate all data belonging to given user? (most probably this will be the partitioning key). All that's left is common, shared data which will need to be replicated to all nodes.
think of caching before you need it. what will be caching key? what will be cache timeout? will you use memcached?

What Are Your Tips for Best Practice for Web Application Structure