The JQuery let's you do all that wonderful stuff, while taking care of browser difference and maintaining a smooth language.
But what if I don't need all of this ..
Maybe all what I need is just the ajax call (that what most of really want anyway) and I don't want to pay the cost 90+K library just for that feature alone "or with a couple of other features"
Is there a way to "extract" the options you mainly need from JQuery?!
Something similar to what modernizer are doing? See here: http://modernizr.com/download/
Don't get me wrong here, I'm still a "lazy dev" who wouldn't like to reinvent the wheel & care about different browsers compatibility etc. .. so I still want to use a library .. but just tailored for my needs.
RobG pointed out the existence of MyLibrary which have a builder to deliver what I "only" need. Checking it out & it looks very cool. will certainly try it.
You can get an unminified copy of the jQuery source and remove the methods you don't need. Just be careful with removing methods that AJAX might have dependencies on.
For those developers who aren't "lazy dev"s, getting examples of what you are trying to do from the source of any open source libraries and forming your own modules is a great way to go.
There are resources out there to get you to just snippets you need such as Micro.js and james padolsey's jquery source viewer.
Once you have build a nice set of modules and established what dependencies you have internally, you can create min files specific to a page or portion of a project and cutting out all of the extra weight you don't need
This is can be the answer to the question regarding how to extract jquery needed part(s)
http://projects.jga.me/jquery-builder/
it divides the library (v1.10.2) to
ajax, css, deprecated($.uaMatch, $.browser, $.sub), dimensions , effects , event-alias , offset & wrap.
But for the purpose of the question, which is not paying that much valuable kilobytes over the precious network... it turn out that, using this builder, cutting everything only reduce the filesize by only 30% ...
so :) practical solution (till the moment) remains the same 1- not using jquery (use your or another library) or 2- accept the price of those 90k
Related
I am building my own JS library;
The idea is that the library should be comprised of small, independent modules, and some slightly larger utilities, that serve mainly to iron out browser differences.
I am having trouble getting anything done, because I am not being able to decide between staying dry or being loosely coupled.
An example? Given:
A small library that takes care of generating dom elements from a template
Another one that takes care of duck-typing issues (is_function, is_array...)
And a last one that creates modal boxes. That last one needs:
some type checking
will be creating the modals using only one function from the templating library
My options for the modal box library:
Be 100% dry, and dependant on the two other libraries. But that means if you are a user wanting to download only the modal box lib, you'll have to make with the two others
Allow users to pass an object of options on initiation that would allow them to specify the functions needed; defaulting to the ones of the libraries. This is better, but in practice, it still means, in 90% cases, using the provided libraries, as creating functions with the same signature might be cumbersome. Furthermore, it adds complexity to the modal box code.
Be 100% loose, and reproduce the functions needed in my modal box library; possibly more efficient because more targeted and there is no need to check for edge cases; but: any bug will have to be fixed in two places, and my download size increases.
So I am wasting time oscillating between the two extremes, refactoring a million times and never being satisfied.
I was going for a more generic question, but then I realized it is really pertaining to JS, because of the size & performance concern as well as the widespread usage.
Is there any known pattern to follow in such cases? What's the accepted way to go about this? Any thoughts are welcome.
[edit:]
This is the only article I found that spells out my concerns. Like the article says,
DRY is important, but so are [...] low coupling and high cohesion. [...] You have to take all [principles] into account and weigh their relative value in each situation
I guess I am not able to weigh their value in this situation.
Personally, I've always taken the view that Loose Coupling refers to creating seams in your code. In classical languages, such as Java, this is achieved by creating Interfaces which hide the concrete implementation. This is a powerful concept as it allows developers to 'unpick the seams' in your application and replace the concrete implementations with mocks and test doubles (or indeed, their own implementation). As JavaScript is a dynamic language developers rely on duck-typing instead of Interfaces: as nothing is frozen, every object becomes a seam in your code and can be replaced.
In direct answer to your question I think it pays dividends to always aim to decompose and modularize your code into smaller libraries. Not only do your avoid repeating code (not a good idea for a host of reasons) but you encourage re-use by other developers who only want to re-use parts of your library.
Instead of re-inventing the wheel, why not leverage some of the more popular JavaScript libraries that are out there; for example, underscore.js is a lightweight library which provides a rich toolkit for duck-type checks and Mustache.js may well take care of your templating needs.
Many existing projects already use this approach, for example, Backbone.js depends on underscore.js and jQuery Mobile depends on jQuery. Tools such as RequireJS make it easy to list and resolve your application's javascript dependencies and can even be used to combine all the separate.js files into a single, minified resource.
I like the concept of DRY, but your right it has a couple of problems.
Your end-user-developers will need to know that they need to download the dependencies of components.
Your end-user-developers will need to know that they need to configure the dependencies (i.e. the options to pass in).
To help solve 1. your project website could customise the download on the fly, so the core code is downloaded along with optional components. Like the modernizer download page.
To help solve 2. Rather than allowing users to pass in options, use sensible defaults to detect what parts of your packages have been loaded in the browser and automatically tie them up.
This loose coupling could also give you the great advantage that could also rely on 3rd party frameworks if the user already has them installed. For example selectivizr allows you to use jquery or dojo etc etc depending on what the browser has already loaded.
Perhaps you could use requirejs to help solve dependency management. I get the impression it's not really meant for libraries to use directly, but instead the end-user-developer... but it could be a nice fit.
I realise my answer doesn't answer your question directly, but perhaps it could help balance out some of the negative points of DRY.
Is it possible to ONLY use portions of JQuery, just like with JQuery UI: customize ones own build in an easy way?
What i mean is imagine you ONLY need JQuery library for a silly, tiny but handy tool on youw site, lets say the Dialog boxes.
Are there JQuery builts available specifically supporting portions of functionality, at a fraction of the current Javascript code sizes?
If you only need a tiny portion of jQuery on your site, chances are good you don't need jQuery. Have you considered a smaller library such as underscore or head.js? Is there something particular about jQuery that you need that can't either be handwritten or found in a smaller library?
The minified version of jQuery is 82kb, and for speed's sake can be hosted on google's CDN. Check out the CDN Hosted jQuery section of this page: http://docs.jquery.com/Downloading_jQuery
You need to think of it from the opposite angle. What you need is dead-code removal (i.e. remove things not used), not "include things that are used."
The only popular dead-code removal processor I know of is the Closure Compiler's Advanced Mode. Beware I am NOT talking about Simple Mode, which only does minification and not dead-code removal nor any other optimizations.
jQuery, unfortunately, is not (yet) compatible with the Closure Compiler's Advanced Mode.
However, you can consider the Dojo Toolkit, which is compatible with Advanced Mode after certain modifications. Read it here.
If you want to use a popular JavaScript library, but don't want to include everything, you can look into Dojo.
A Dojo application with only very light usage of the Core functions, after compiling with Advanced Mode, can be reduced to less than 40% of the size of a only-minified version (e.g. Closure Simple Mode).
Not that I know of. Except for css based selector which is sizzle incorporated into jQuery. But I am sure you can write or find pure js library that has only the functionality you need and skip jQuery if you really want to.
You can have at jQuery in pieces: https://github.com/mythz/jquip
It is unofficial, though.
You could feed jQuery plus all of your code through the Closure Compiler; that would remove everything you weren't actually using. I don't know how much smaller it would get, though; it might be all interdependent on the inside.
just wondering if it possible to build the jQuery library with just a selection of components:
e.g. without Effects or Manipulation?
Sounds like it would be mission impossible!! :)
Thanks everyone!
Reason:
I read somewhere a long time ago about jquery being modular since version 1.4.x . Not being able to find anything on jQuery.com and elsewhere I gave up and came here.
Like always the answers are always helpful, even though a question doesn't have an answer.
Any ideas? Thanks guys :)
Not without modifying the source yourself. (which I recommend against)
John Resig WAS going to do this because of jQuery Mobile but they decided on one large bundle. Just use theversion hosted by Google's CDN and you shouldn't have to worry too much about load speed, chances are it'll already be in the user's cache.
I can't find the duplicate right now but the bottom line is no, it's not possible without huge effort; but it doesn't matter, because it's loaded just once, and if there were any serious performance advantages to gain, the founding fathers jQuery developers would have created a provision for it.
I suppose it would be possible, but it would take a ton of work. Many of the methods inside the jquery library are dependent on eachother - it would take hours and hours of debugging to get a non-broken version. You are better off just including everything - it's not that large of a resource hog anyways.
Developer time is more important and fiddling for that task is gonna be expensive :)
I suggest that you just use the one on Google's hosted, most of the time its already cached on their browsers
My favorite version btw is 1.2.6 and packed
http://jqueryjs.googlecode.com/files/jquery-1.2.6.pack.js
I have extensively used Prototype before and it helped us add considerable interactivity to our web applications. However we are looking at making the move to use jQuery in order to standardize on something better supported in Visual Studio.
I understand that we can use the jQuery.noConflict to run it alongside Prototype, but we would like to avoid having users need to download both libraries to use our website.
So, is there a good resource that can help us move old scripts from Prototype to jQuery?
I can't really help you too much with your question, other than to say that I haven't heard of any such tool, and that I'd be really surprised if one actually existed.
While I think jQuery is a great library, and that you're right to be wanting to only use one library, just remember that the cost of you changing over all your scripts is going to be many many hours of work. The cost of your users downloading an extra 30kb of scripts is going to be roughly 0.3 seconds. Perhaps try to slowly phase out Prototype and only refactor your existing pages when a) you have to, or b) if you've got nothing better to do.
Falkayn,
There is no automated process available for conversion of JavaScipt code written against one JS library to another one. Moreover there cannot be one. Different libraries implement different proramming models as well as they arrange their APIs in different manner.
So, before you have found a solution to your problem now ask yourself a question: Am I going to convert my jQuery code once another even "cooler" "X-type" JavaScript library became available?
If your answer is no, take your time and convert the code manually no mater how long will it take. In case you answer "yes" don't convert the code at all.
So it goes.
Thanks guys for your input. I was looking for more of a syntax comparison than anything automated, but nickf makes a good point in that the real cost need not be too great. We only used Prototype on a few pages that really needed a high level of interactivity, so as long as mind out Ps and Qs it should not hurt to use jQuery everywhere else.
I was recently tasked to document a large JavaScript application I have been maintaining for some time. So I do have a good knowledge of the system.
But due the sheer size of the application, it will probably take a lot of time even with prior knowledge around the code and the source code itself in uncompressed form.
So I'm looking for tools that would help me explore classes and methods and their relationships in JavaScript and if possible, document them along the way, is there one available?
Something like object browser in VS would be nice, but any tools that help me get things done faster will do.
Thanks!
Firebug's DOM tab lets you browse the contents of the global window object, and you can inspect a particular object by entering inspect(whatever) in the command line.
You won't be able to use it to detect relationships unless an instance of one object holds an instance of a related object, but it's a start.
You can also use the Options menu on the DOM tab to restrict what's shown to user-defined functions and properties, which should help reduce clutter.
Take a look at Aptana, they have an outline that can help you to determine what are the objects and somtetimes their relationship.
Firebug + uneval(obj) is a simple trick that is often helpful.
I see a lot of people talking about examining the DOM within Firebug. However, from your question it looks like you want something like jsdoc? just add type and class information through comments and jsdoc generates documentation including class relationships. http://jsdoc.sourceforge.net/
Google has a fork of it with added functionality http://code.google.com/p/jsdoc-toolkit/
UPDATE: It's not a fork, it's a rewrite by the developer that wrote jsdoc originally as a perl script. It aims at being more adaptable so you can use whatever js inheritance/events/properties style you'd like. Another feature is that it lets you modify the templates used to generate the HTML in a much simpler way.
We don't know if this JS application is designed to run in a Web browser...
If yes, as advised, Firebug (a Firefox extension) is excellent at debugging JS and exploring Dom.
On the IE side, you have some tools like IEDocMon, Web Accessibility Toolbar (it does more than its name) or Fiddler (unrelated to your question, but still a good tool to have).
Firebug (Firefox) / Dragonfly (Opera) can help you with viewing objects in realtime
Aptana / JS/UML(Eclipse) can help with relationships of objects
This is an old question, but let me answer it anyway.
Use an IDE. Integrated Development Environments were made for jumping around rapidly among the code. The key features you will exercise during exploration are viewing the file structure or outline, jumping to a declaration or usage, and searching the entire project for all instances of a string. If you are using WebStorm, set up a custom scope for files except generated files and node.js to aid in searching.
Run 'npm la | less' which lists all your dependent modules with one line descriptions. You may have never seen moment.js and never need to read the documentation, but taking the time to read a one line summary of it is worthwhile. If you need more information on a tool than one line summary, search for the term on SlideShare. Slides are faster than ReadTheDocs.
Document a little as you go. I'm a fan of forcing people to use notebooks constantly rather than scratch paper. Also, I find adding a one line comment to each JavaScript file is worthwhile. You want to know what should be in each directory of your project. I also recommend building a glossary of the exact meaning of domain terms in your system, e.g., what does "job" in your system.
Finally, you may need to just fire up the application in a debugger and start stepping through parts of it. Most large projects have accreted worth from programmers of various skill levels and motivations.
You are aiming for a level of "conceptual integrity" (to quote Yourdon) or to "grok" the software (to quote Heinlien). It does take some time, cannot be bypassed, and can be done efficiently.