We have a number of asp and asp mvc web apps that need to share static resources. I'd like to be able to put these in a common project that can be shared across sites but I'm unsure how to do this? I understand we could use a CDN, but would prefer a common project approach. Any examples would be greatly appreciated!
There are really two (or three) issues here, and resolving the problem is not as simple as it should be.
The first issue is having the shared resources available at runtime - for that, putting the resources on a CDN may work, but you're probably going to need to reference these during design, as well as include them in your version control system.
The second is sharing common resources across ASP.Net Projects & Solutions, and sadly the ability to do this will depend on the third item, your source control system.
If you're using VSS, well, you have my sympathies, and you're stuck for now. It's time to upgrade anyways.
Other version control systems (including TFS) don't have quite the same inflexible link between projects & solutions and the repository. You should be able to have multiple solutions & projects overlapping, something along the lines of:
Root
Web\
App1\
App2\
SharedResources\
Class1\
Class2\
etc
You can have multiple Web app projects - one can reference Web\App1 and resources in Web\SharedResources, another Web\App2 and overlapping resources in Web\SharedResources, and then have multiple solutions tied to a single source control repository. Unfortunately, I haven't found a way to do this and have the resources and apps in separate structures.
Depending on where you want to keep your .sln and .proj files, you may have to manually edit them to update the paths - Visual Studio won't really like creating this type of overlapping structure.
You could create your own CDN by hosting those static files in a separate web server.
Related
I have two JavaScript single-page applications in two separate GIT repositories. I want to keep them separated as much as possible (different teams working on them etc.), but they are still very closely related and even co-exist within the context of the same web page as part of one large SPA. Naturally, these two applications share large amounts of library code and it is very wasteful to bundle each with its own copy of libraries.
Is there any way I can reuse the library code? What would be a possible approach?
What I am describing seems to be achievable using the DLL plugin. Basically, I create a vendor.js file, which requires all of the dependencies. Then, from that file generate a bundle of all the libraries and a manifest.json file. Then, using DllReferencePlugin it should be possible to tell webpack in each of my apps to take the dependency from the vendor bundle. Both apps can be built independently. As a last step, simply load of the three bundles on the page.
I am creating a site that uses Java Script and CSS from jQuery and jQuery Mobile. Right now I am not hosting any of the files but rather referencing URLs on the jQuery site. This has the disadvantage that I have to load resources from jQuery every time the page loads and I cannot alter the files myself. I want to switch to hosting this stuff locally and would like to go about it in an organized and scalalable fashion. Is there any better way to do this than just copying the code from the links and pasting it into my own local .css and .js files?
Modifying the jQuery source is not ideal as you would be required to maintain it with every new release. If there is additional functionality you would like to add, it is better to create jQuery plugins. As for managing your project with respect to CSS and JavaScript files, most IDEs will generate a series of folders following the convention of JavaScript and CSS files being placed in a scripts and styles directory, respectively, under your project root. On top of this, it is wise to catalog your changes with some form of source control, such as git. There is plenty of documentation on the web on how to use this tool, and explaining how to use any form of source control is far too broad for an answer on StackOverflow. There is a certain level of mental discipline you must maintain, however, especially if you are manually managing the structure of your web project. This will come with time and experience as to what works best for you.
I have a fairly large web app and am using JQuery with JQuery UI, a couple JQuery plugins, a couple other javascript widgets. And DataTables. These pieces have been piling on throughout development and what I now have is a substantial mess of files and folders. Some are duped, some I cannot tell if they belong at at all, but the biggest problem seems that some of these pieces rely of certain assets and folders having specific relative paths to one another.
So my question: What is a folder/file structure that will work. DataTables in particular seems most picky and easily breaks when I move stuff around. I expected to be able to find this in the JQuery docs, and if not that then via some googling, but neither have panned out.
Thanks in advance.
With big JS applications, I would recommend using JS MVC framework like backbone: http://documentcloud.github.com/backbone/
Multiple sites reference combining JavaScript and CSS files to improve web page performance, including examples of using ANT build scripts to concatenate the files prior to deployment.
I've search, and haven't found any information how to automate updating references to those files in HTML and other documents. I am looking to avoid hacking together something error prone, and want to learn from others who have automated builds in the past.
Are there automated tools in the wild to complete this task that I'm not seeing? Are there recommended processes to update the script and link tags in HTML? Can these solutions be integrated with ANT or similar build tools?
There sure is and it's a smart thing to do.
I found a PHP solution, don't know it that's okay for you, but if it isn't you can still read it's source (it's not difficult) and learn a lot. The solution works like this:
Rewrite your requests like this: from css/main.css and css/skin.css to css/main.css,skin.css (of course you can put many more).
Use apache's mod_rewrite to redirect this request to a script (in our case combine.php), that will combine all files to a single one.
The script combines all the files and sends the combined file. Then it saves it to a cache folder.
Next time around it checks if there is an up-to-date version of the cache and serves that one. If the latest file modification time has changed, it discards the cache.
The solution works great and it even makes use of HTTP cache headers and spits out an [ETags], which you should do anyway.
You are correct this is a great way to speed up page loading. It will even work in conjunction with a CDN, which the other poster recommended.
Here is a small script that will pack multiple files in to one for deployment. It supports both JS and CSS, and will even "minify" them by removing whitespace, etc. Just hook this in to your build and deploy scripts.
juicer: http://cjohansen.no/en/ruby/juicer_a_css_and_javascript_packaging_tool
What even better, it will follow JS and CSS import statements, so you only need to point your HTML files to the loader file and it will work in both development and production. (Assuming you replace the loader file with the combined file on deployment.)
There are others, including some run-time solutions. But it sounds like you have a build process in place anyway.
As far as HTML updating, if you still need it, since automated deployments are very popular in the Ruby world, and you may find some standalone utilities to help even for non-ruby projects. (As above) Methinks this would be best handled by your own project's template language, though. (With a static resource revision id, or such.)
Good luck, and let us know what you find.
I think what you really want is a CDN Content Delivery Network.
Read about it here
http://developer.yahoo.com/performance/rules.html
http://en.wikipedia.org/wiki/Content_delivery_network
Nowadays, we have tons of Javascript libraries per page in addition to the Javascript files we write ourselves. How do you manage them all? How do you minify them in an organized way?
Organization
All of my scripts are maintained in a directory structure that I follow whenever I work on a site. The directory structure normally goes something like this:
+--root
|--javascript
|--lib
|--prototype.js
|--scriptaculous
|--scriptaculous.js
|--effects.js
|--..
|--myOwnScript.js
|--myOwnScript2.js
If, on the off chance, that I'm working on a team uses an inordinate amount of scripts, then I'll normally create a custom directory in which we'll organize scripts by relationship. This doesn't happen terribly often, though.
Compression
Though there are a lot of different compressors and obfuscators out there, I always come back to YUI Compressor.
Inclusion
Unless a site is using some form of a master page, CMS, or something that dictates what can be included on a page beyond my control, I only included the scripts necessarily for the given page just for the small performance sake. If a page doesn't require any script, there will be no script inclusions on that page.
First of all, YUI Compressor.
Keeping them organized is up to you, but most groups that I've seen have just come up with a convention that makes sense for their application.
It's generally optimal to package up your files in such a way that you have a small handful of packages which can be included on any given page for optimal caching.
You also might consider dividing your javascript up into segments that are easy to share across the team.
Cal Henderson (of Flickr fame) wrote Serving JavaScript Fast a while back. It covers asset delivery, not organization, but it might answer some of your questions.
Here are the bullet points:
Yes, you ought to concatenate JavaScript files in production to minimize the number of HTTP requests.
BUT you might not want to concatenate into one giant file; you might want to break it into logical pieces and spread the transfer cost over several pages.
gzip compression is good, but you shouldn't serve gzipped assets to IE <= 6, so you might also want to minify/compress your JavaScript.
I'll add a few bullet points of my own:
You ought to come up with a solution that works for both development and production. In development mode, it should pull in extra JavaScript files on demand; in production it should bundle everything ahead of time. Switching from one behavior to the other should be as easy as setting a flag.
Rails 2.0 handles all this through an asset cache; other web app frameworks might offer similar solutions.
As another answer suggests, placing third-party libraries in a lib directory is a good start. You can also divide your own JS files into sub-directories if it makes sense. Ideally, you'll be able to arrange them in such a way that the files in a given sub-directory can be concatenated into one file.
I will have a folder for all javascript, and a sub folder of that for 3rd party/shared libraries, and sub folders for each component of the site to keep everything organized.
For example:
/
+--/javascript/
+-- lib/
+-- admin/
+-- compnent1/
+-- compnent2/
Then run everything through a minifier/obfuscator during the build process.
I'v been using this lately:
http://code.google.com/apis/ajaxlibs/
And then have a "jscripts" folder where I keep my custom code.
In my last project, we had three kinds of JS files, all of them inside a JS folder.
Library code. A bunch of functions used on most all of the pages, so they were put together in one or a few files.
Classes. These had their own files, organized in folders as needed, but not necessarily so.
Ad hoc JS. Code that was specific to that page. These were saved in files that had the same name as the JSP pages they were supposed to run in.
The biggest effort was in having most of the code on the first two kinds, having custom code only know what to call, and when.
This might be a different approach than what you're looking for, but I've been playing around with the idea of JavaScript templates in our blog engine. In a nutshell, you assign a Javascript template to a page id using the database and it will dynamically include and minify all the JavaScript files associated with that template and create a file in a server-side cache with the template id as a file name. When a page is loaded, it calls the template file which first checks if the file exists in the cache and loads it if it does. If it doesn't exist, it creates it on the fly and includes it. I also use the template file to gzip the conglomerate JavaScript file.
The template idea would work well for site-wide JavaScript (like a JavaScript library), but it doesn't cover page-specific JavaScript. However, you can still use the same approach for page specific JavaScript by including a second file that does the same as above.