jQuery's primary role is to normalize the DOM API which is the one thing browsers haven't agreed on for over a decade (until IE9 came out). It's better thought of as a tool than a library. It's basically just a factory function that returns an adapter merged with a bit of decorator that wraps and normalizes the DOM object API with lots of cruft reduction and some additional goodies like the animate function and an event system that lets you fire and listen for new events on the fly on any object without even defining them somewhere first.
What it doesn't do is help you with writing more complex, maintainable app-oriented code (well, the event thing is neat-o but easy enough to DIY), use objects well, or use any of the core ECMA spec obects that really form the basis for the core language of JavaScript.
Among proper JavaScript devs, it takes very little time to filter out the devs who are going to be useful on a project from web designers or CMS-only devs gunning for a salary increase by doing awful things with a tool they'd rather not understand under the hood if they can avoid it.
Also, the DOM API is pretty verbose with method names that practically write their own documentation (by approaching paragraph length basically), which is a good thing, IMO. We want the core native stuff to be obvious and spelled out. But the tedious nature of writing with it encourages us to use JavaScript to do something it's very good at. Eliminate cruft, normalize, and bend the API to a paradigm that works better for us. I personally think jQuery did a bang-up job of this compared to most of its contemporaries and that you can learn a lot about JavaScript (like how to keep your objects really lightweight as far as memory is concerned) by studying jQuery under the hood.
But I wouldn't use it as a pre-fab UI library namespace. And I wouldn't discard loops in favor of using .each on everything. And I often downshift to DOM API methods when JQuery is adding work without really eliminating cruft which brings up one of the most important features of jQuery to those of us who actually know what we're doing. It doesn't get in your way when you don't want it there.
But make no mistake. If you don't know how to do it without jQuery you're at best an entry-level JavaScript/client-side dev. On the flip-side if you only know JavaScript and only have minimal understanding of CSS, you better be focused on something other than UI problems.
Edit: I realize I focused on JQ a bit too much for a question that was asked more generally.
Most other popular JS tools/libraries/frameworks are either UI libraries, none of which I'm a big fan of (too inflexible typically), and rapid-application building frameworks that apply concepts from MVC or similar patterns. I'd rather DIY architecture personally (and I'm a little wary of this model-binding in templates trend) but these new frameworks aren't the sorts of things implemented by JS devs who can't handle code problems that require JS-literacy themselves I would wager.
One tool that appears to do part of what you need, at least for Java webapps, is Web Resource Optimizer for Java (wro4j).
Free and Open Source Java project which brings together almost all the modern web tools: JsHint, CssLint, JsMin, Google Closure compressor, YUI Compressor, UglifyJs, Dojo Shrinksafe, Css Variables Support, JSON Compression, Less, Sass, CoffeeScript and much more. In the same time, the aim is to keep it as simple as possible and as extensible as possible in order to be easily adapted to application specific needs.
Easily improve your web application loading time. Keep project web resources (js & css) well organized, merge & minify them at run-time (using a simple filter) or build-time (using maven plugin) and has a dozen of features you may find useful when dealing with web resources.
You might also check into RequireJS to see if that would help you define which js files the client should download in a particular environment.
RequireJS is a JavaScript file and module loader. It is optimized for in-browser use, but it can be used in other JavaScript environments, like Rhino and Node. Using a modular script loader like RequireJS will improve the speed and quality of your code.
Best Answer
Short answer:
Use aliases?
If it can be automated, I don't see any harm in copying.
Long answer:
Listed below are some of the tools and techniques I use.
Bower
Grunt.js
grunt-bower-task
... Also worth mentioning:
Git submodules
Real world example ...
Within my
Gruntfile.js
, I have abower
task:... the above requires a
bower.json
(next to theGruntfile
):When the above
bower
task is run, I get a folder structure that looks like (organized by "component"):plugins/
normalize-css/
(component)normalize.css
foo/
(component)css/
foo.css
foo.min.css
scss/
foo.scss
partials/
_variables.scss
_functions.scss
_mixins.scss
_other.scss
Note: Using
exportsOverride
option, I was able to "grab" resources other than themain
resource that was specified via the endpoint's (foo
, in this case)bower.json
.Based on the above setup, I now have a folder called
plugins/
(like, I assume, yourvendor/
folder) and I can now point my Gruntfile tasks at said directory and/or files.Alias technique #1:
Question: Based on the above Bower install, how does one include
normalize.css
as a SASS partial?One solution is to create an alias (
cwd
= my project'sscss/
folder):From there, I can treat the alias as an SCSS partial and
@import
into myscss
files as I please.Alias technique #2:
Question: Based on the above Bower install, how does one include
foo
'sscss
partials?Assuming
foo.scss
includes all of the partials, it's not going to work as a direct alias because the@imports
are relative.Why not alias the whole folder then?
Now I can easily include the 3rd party dependency's
scss
partials (or justfoo.scss
) in my project's build process without having to do much leg work.Copying technique ...
I see no problems with this approach either. Optimally, you'd automate the copy with a task like:
grunt-contrib-copy
One approach could be a
copy
target that runs via aninit
task which would copy source files to the locations you specify in your build directory. From there, you'd run your other/process tasks to generate/build/copy the development/production files like you would normally.Here's the copy task from one of my latest projects:
Direct linking technique?
Depending on your needs, there's not much stopping you from relatively linking to 3rd party assets in your
vendor/
folder. I'd say if direct linking doesn't work (due to some sort of relative import or something), then the above two aliasing options are good alternatives. Personally, I find that aliasing is nice because it keeps my path strings clean.Minimize and/or uglify?
I say, for production environment, definitely yes.
My personal approach is to have two build processes, one for "dev" and one for "prod". The former links to source files whereas the latter links to the min/uglified files.
I've given a basic outline of my build process here:
Have Grunt generate index.html for different setups
For me, the goal is to have a "dev" build for development (where I can easily use to hunt for bugs) and a "prod" build for production (keeping in mind, that new bugs may get introduced when the source files have been combined/minified/uglified).
Grunt tasks I use on a regular basis to generate my min/ugly files:
Note: I always strive to include un-minified/uglified versions of 3rd party code in my builds; if I decide to use already compressed files, I skip the compression step (for these files) in my build process and just do the file concatenation instead.
3rd party uses different preprocessor/other?
That's definitely a predicament. A few solutions I can think of:
Just prepare yourself for these eventualities. It's usually not too hard to install packages (homebrew helps), so once you're system is setup it should be easier the next time you encounter this type of situation. From there, it shouldn't be hard to find a Grunt task to incorporate the source files into your build. A lot of times I'll use a
temp/
folder to store "inbetween" build files, and then I'll use other tasks to combine/minify/uglify said code with other code (for example, let's say I want to combine thesass
/less
generated files ... just slap them into/temp
and combine them at some point during my build process).Find a version of that framework that's using the tools you prefer. For example, Twitter's Bootstrap uses
less
; well, luckily, there happens to be asass
version. Problem solved (hopefully). :)If it exists, and if you can get away with it, use the "generated" version of the framework. For example, I try to include a generated source file for every project I create ... I dunno about you, but I like having the option of viewing/using an already generated version of a plugin, especially if said plugin can work out-of-the-box in my project.
Other? I'm currently out of ideas on this one.
With all that said, I am by no means an authority on this topic ... The above is just what works for me. My personal preference for when it comes to this stuff is to strike a balance between simple and complex.