We Keep Coding

javascript embedded inside html

I have a web application that is currently split into like 40+ javascript files. When I run the application some subset of those files need to be downloaded by the browser. Obviously, given that browsers use ~6 threads to download files, this is not the optimal solution. One optimization idea that come to my mind was to embed all those javascript files (except external ones) inside the served .aspx page. So that the browser just gets one big html file and does not need to make any round trips to the server. The html page alone may contain user specific data that will be different on every request. The scripts, however, are not changing between requests. In typical use case the page (complete with scripts) has 180KB (scripts not minified) or 130KB (minified).
Now the question: does this approach have any drawbacks performance wise (network, browsers' javascript engines)? Do you know of any big applications doing something like that? Note that I am not interested in arguments about eg. maintainability as the individual scripts will still be available as separate files during development. Same question applies to css files (even though this is less of an issue in my app).
One bit of information that may be important here: the application is one big multipage form that does not require postbacks to go between the pages, validate form, submit the form, etc. However, the application in which it is embedded may have multiple such forms.

In general, it is a very good idea to concatenate javascript and css files together. I'm just not so sure about "your concept". My biggest concern and question here would be, can that .aspx file change potentially in any way through (dynamic) code ?
That would make in impossible for the browser to cache the file, which would be a horrible scenario.
The great thing about concatenating files is, that we have one big downstream (which still is a lot faster then downloading with several single requests and HTTP overhead) and the browser can cache this file afterwards.
There are some great build-tools and scripts available, Apache ANT is one I can really suggest. You should have a look on the HTML5 Boilerplate where they make usage of ANT very frequently.

Managing ServerSide FileSystem through Web Application

I am developing a web application that will manage directories and files through its web interface.
Developing a web interface is one part, and it is in advanced progress. However, I start thinking, how should I develop the server application, that will manage the files and directories based on user input.
The client will be created using standard tools:
HTML5
CSS3
JavaScript
PHP - Despite it is server side application, it will be responsible mostly for Dynamic Websites
MySQL - Despite it is server side application, it will be responsible mostly for keeping information about users, their settings, etc..
Would you advise me please, what would be a server-side programming language of choice to manage server-side file system? Is there any API available, that will allow me to do exactly what I wish? Is it possible to manage the server-side file system in server-side JavaScript, or should I chose another tool? Server-side JavaScript comes to my mind as a logical chocie, as I use it for the client side as well.
This is what I wish to achieve:
To create new directories and files
To delete directories and files
To track the directory and file size
To move files between directories
To provide content of the directories and subdirectories
Ideally, the solution should be platform independent and should work on both, Linux Ubuntu and Windows Server OS.
I understand that my question is a bit broad. I would be thankful, if you point me to the right direction, which technologies to start studying, to be able to accomplish the above mentioned.
Thank you.

You already have a very capable serverside language in your list. PHP.
PHP can do all of the things you listed above... and a few you didn't list as well :)
To create new directories and files
New files can be created with the touch() function, and new directories with the [mkdir()](http://php.net/manual/en/function.mkdir.php function.
To delete directories and files
Deletion is done with rmdir() and unlink().
To track the directory and file size
File sizes can be monitored using the filesize() function. Couldn't find a native folder size function but this Stack Overflow post may be useful - https://stackoverflow.com/a/478161/558021
To move files between directories
Moving files and directories can be accomplished by using the rename() function.
To provide content of the directories and subdirectories
One of the functions PHP gives us to scan folders is called glob() it glob - it allows you to find pathnames matching a pattern, so if you give it a wildcard character * it will find all the files in a certain location.

Organizing script files

I usually have jQuery code that is page specific along with a handful of functions that many pages share. One approach is to make seperate files for organizing, but i'm thinking that putting all the script in one file and making comments in the file for readability would also work. Then when the site goes live I can minify and obfuscate if needed.
I think the question comes down to limiting http requests or limiting file size. Is one of these a bad habit?

You can have it both ways. Develop with as many individual .js files as you need. Then use a build/deployment process that assembles the files into one larger one, then pushes them through something like Google's Closure Compiler. Compression can be handled transparently by your web server if configured properly.
Of course, this implies a structured development and deployment workflow -- e.g., with files to be assembled/compiled in a specific directory, separated from files that should be served as-is.
References:
Closure Compiler
Apache Ant
Automating the Closure Compiler with Ant

If you can put all the scripts in one file which is minified then that's what you should do first.
Also if your webserver sends out gzipped content the actual script transfer would be small, and the script will be cached on client. Since tcp transfers starts out slow and increase in speed, limiting the number of requests is the best way to speed up the overall loading of a page.
This is the same reason you see sites concatenating images into one larger image, and using CSS to display the correct part of it.

Working on large JavaScript applications

Our file structures is pretty good, organizing functionality in separate folders. My question is how do others work on applications that involves upwards of 500 JavaScript files.
We have written a maven plugin to concatenate these files together (also runs YUI compressor). However, this involves 3-10seconds of compiling for every change.
Is this step necessary for organization of a large application, I feel like a well structured HTML file pulling in all these resources would save me 45minutes every day.

For my own framework projects, typically monitoring, testing, or in-page services to orchestrate other toolkits (but not as high as your file count), my approach has been to target the individual and dynamically loaded files during development. For test, I'll run one build to compress and version the individual files, and test the individual files again because, depending on the concatenation order, compression technique, and browser, I may wind up with a script error and it's a pain to dig it out of one monster file. Third, I'll concatenate together and test once more.
In the HTML reference, I'll either target the uncompressed file, which loads specified dependencies, or the compound file. A separate bootstrap file names the dependencies, which are either included in the compound file, or loaded dynamically as needed.
This way I can add or change a file, and start developing and testing without rebuilding.

The solution is likely to concatenate and compress for user testing and production only.
For development, it's probably best to simply import them all into the HTML file. It speeds up the dev process, and also simplifies debugging. It also allows the browser to cache some of those files.
When you can't rely on cached copies (which, with 500 files, I don't think will be very often), it will slow down load times.

You can likely save a lot of time by only running the compressor in production. The YUI compressor is notoriously slow, because it uses Java Rhino interpreter to actually parse the JavaScript and analyze it etc.

How to organize OO js code in files? Local network application

I'm currently developing an application that will be run on local network in B2B environment. So I can almost forget about micro(mini?) optimizations in terms of saving bandwidth because Hardware Is Cheap, Programmers Are Expensive.
We have a well structured Object oriented js code in the project and obviously lots of js classes. If all the classes will be stored in separated files then it will be quite easy to navigate through this code and hence maintain it.
But this will bring my browser to generate a couple dozens of HTTP requests to get all the js files/classes I need on the page. Even in local environment it is not super fast on first load(with empty cache), and later when you modify it and cache has to be invalidated.
Possible solutions:
violate rule "one class per file"
use YUI compressor all the time(in development & production) for generating one big js file.
But if we choose YUI compressor for this(no minify action in dev environment, and minify for production) - then we need to reload/recompile this big js file on every modification in any js file.
What would you recommend for solving this problem?

Keep all the .js files separate. Keep your "one class per file" rule.
Then, use a server-side technology to aggregate the script into one request.
Options:
Use an ASPX or PHP or whatevver server-side scripting thing you have, to aggregate all the JS into one request. The request for a .js is no longer a static file, but with caching on the server it should be relatively cheap to serve.
Use Server Side Includes in a consolidated .js file.
<!--#include virtual="/class1.js"-->
<!--#include virtual="/class2.js"-->

Your approach of having separate files for each class is good - practices that make development easier are always good.
Here's some tips for making the loading faster:
Compress your code. As you say, you could use YUICompressor, or the newly released Google Closure Compiler.
When concatenating multiple files into one, think of what you need and when: If you only need files A, B and C when the app starts, but not Z and X, put only A, B and C into a single file. Load another file with Z and X concurrently after A/B/C.
You can use Firefox plugins YSlow and Page Speed to test for load performance bottlenecks
As you mention, you would need to rerun the compressor each time you make a change. I don't think this is a big problem - on a decent machine, it should run pretty fast even with a lot of files. Alternatively, you could use a daily build process using some tool, which could build the latest revision from your source control (you do use scm, right?), and run unit tests and deploy if everything goes OK.
I would recommend using Ant or some other automation tool to create a build script. This will make it as simple as running one command to build your compressed script, reducing the repetitive work you would otherwise need to do. You could even have Ant deploy your code to the server.

You may have the best of both worlds - a development environment with one class per js file without the need to compile/deploy for every iteration AND one (or several) concatenated larger js files (minified if desired) in production.
Depending on your build environment this may be setup in a number of different ways, but using Ant may be the easiest way. Using Ant you can run tasks for both concatenation and minification (running YUICompressor through the Java task). This will produce the concatenated and minified large js file.
However, to maintain productivity you want to avoid doing this for every code iteration. Changing the tags from one to several (for every class file) is out of the question.
So, you load your big js file as expected:
<script src="application.js"></script>
When deploying to production this file is the concatenated/minified version of all your js files.
However, during development this file is a bootstrap/loader file that simply loads all your individual js-files (illustrative example using jQuery).
$.getScript('/class1.js');
$.getScript('/class2.js');
$.getScript('/class3.js');
$.getScript('/class4.js');
$.getScript('/classn.js');
....
If you are using YUI 3 look into the module behavior and how to specify dependencies.
Using different Ant targets the generation and copying of these files to the correct location may easily be managed.
And now you may simply reload your browser whenever you need to test a change in a file, but get the performance benefit during production. All without sacrificing productivity or maintainability.