Why not embed styles/scripts in HTML instead of linking?

Simply because Web performance really matters ! 99% times it will give you faster end-user response times.

Here are a few exampels from Velocity Conf.

• Bing – A page that was 2 seconds slower resulted in a 4.3% drop in revenue/user.
• Google – A 400 millisecond delay caused a 0.59% drop in searches/user.
• Yahoo! – A 400 milliseconds slowdown resulted in a 5-9% drop in full-page traffic.
• Shopzilla – Speeding up their site by 5 seconds increased the conversion rate 7-12%, doubled the number of sessions from search engine marketing, and cut the number of required servers in half.
• Mozilla – Shaving 2.2 seconds off their landing pages increased download conversions by 15.4%, which they estimate will result in 60 million more Firefox downloads per year.
• Netflix – Adopting a single optimization, gzip compression, resulted in a 13-25% speedup and cut their outbound network traffic by 50%.

From Steve Souders, pioneer in Web Performance Optimization,

80-90% of the end-user response time is spent on the frontend - Start here first.

Using external files produces faster pages because the JavaScript and CSS files are cached by the browser/networks/proxies (as defined in HTTP protocol with Cache headers). JavaScript and CSS that are inlined in HTML documents get downloaded every time the HTML document is requested. This reduces the number of HTTP requests that are needed, but increases the size of the HTML document. If you're using Jquery-like scripts, it's easy to refrence 300 KB of scripts and do not believe that everyone has a 100 MBits/s bandwidth with low latency, running a single application -the browser- opened on your web site. 99% times it will give you faster end-user response times.

The frequency with which external JavaScript and CSS components are cached relative to the number of HTML documents requested is also important. If users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets (bundles), there is a greater potential benefit from cached external files.

But inlining is -sometimes- preferable for single page application or web sites with one single page view per session. There is no golden rule, and generally forget it as it concerns mainly very specific web sites really involved by end-user performance.

You can read here why performance matters (Disclaimer : I am the author)

The separation of content from the styling of its presentation is usually a bigger advantage than fewer http requests.

Separating out all the styling enables and encourages reuse and shared files.

The contents of the files will also be more static and available for caching on both servers and clients for both that page and other pages that are visited.

To you specific question though...If the server is made to do the minification itself it makes the assets harder to maintain and to debug issues. However many frameworks do now do this at the file level, e.g. all cs and all js. For example the ruby on rails framework now minifies its assets for production. 5-10 extra http requests are usually not the bottleneck, its more if there are 100+ http requests (which you often get with images).

The extra step of actually including the code in the pages itself would have the disadvantage of bigger pages that you'd have to manage the download sequence carefully and the page not being able to display content often without the rest of the (now large) page being downloaded.

1. Minimize duplicate coding. for save time (You can reuse the style and JS function coded for one page).
2. Minimize change effort. (If your client ask you to change the button color of the web site. you need to go one page by one ).
3. Reduce the load time (If your CSS and JS duplicate it means individual pages size increase and time consuming to download. but common CSS JS no need to download again and again).
4. Remote usage. (you can place your common CSS js JS in a remote place. not the same hosted server)
5. Reduce Bug fixing time. If there is a bug in one function you need to go page by page to fix the bugs in embedded JS and CSS.
6. To increase SEO (simply separate content with meta data)
7. Cleaner and understandably of code (If you embed all in one file debug and code clarity gone away. and each page will be a very long page).
8. Additionally this will help you to reduce the size of the product.
9. But still you can consider to embed most unique thing in the same page.

The latest version of HTTP was created way back in 1999. In 1999, everybody connected to the Internet with dial-up. The Internet was very slow. 16 years later, things have moved on a great deal, but the protocols we use have not.

The answers that we shouldn't inline 'because it interferes with caching' is a little misleading, particularly in the era of superfast Internet. When you actually do the calculations, there is often negligible difference between loading times with cache-warm and cache-cold users if you have inlined. The fact that there is a small difference is not inherently because you have inlined, but because of the inflexible design of HTTP/1.1.

The SPDY protocol implements something called server push. This essentially takes inlining out of the HTML document itself, and into the protocol. An intelligent server will know what resources the client already has. A dumb server will just send everything regardless -- that will still be a performance benefit, but may cost in terms of bandwidth. If the browser has the contents in its cache, it can simply discard the incoming copies. The server waits until the HTML is loaded before sending the additional resources -- in theory the browser can send a signal to cancel the server push.

HTTP/2.0 is based on SPDY and will most likely implement server push, but you can in theory start using SPDY today. So the real reason we don't inline is one of legacy -- the protocols that currently exist are old and are not flexible enough to achieve 'protocol-level inlining'.