We have Tabs-Menu controls which rely on jQuery library and the dev-manager insist that i should get the functions that controls are using into a separate java-script file so we don't have to reference/rely on the whole jQuery, so it made me wonder.. is it a bad idea to edit the jQuery files ?
Yes it is a very bad idea. It would be a nightmare to maintain with all the bug fixes and feature changes the jQuery team would make.
You should write plugins to modify the behavior as you want.
The gzipped production version of jQuery is 31K. Not only is this an unmaintainable idea, but this is a pre-optimization. Any images beyond tiny PNGs or GIFs will likely be as large or larger than the entire jQuery library.
Additionally, this is time that could be spent addressing actual problems. I don't know what sort of userbase you're targeting, but unless every one of your users is on dialup, 31K will take no time at all to download.
is it a bad idea to edit the jQuery files ?
Yes. If you edit the core jQuery library, you make it much more difficult to use future versions of jQuery, which may include important new features, bug fixes, etc. If you make your changes in plugins, as you should, you can just drop in the new versions of jQuery when they're released.
Well I'd say it's a pretty bad idea. You really want the responsibility of maintaining the mess you have left after chopping it out? Are you an expert on the jQuery library? Do you understand all of the side effects? You would be better off rewriting portions of your Tabs-Menu controls without jQuery than trying to chop out bits of jQuery. I presume that the issue is that you don't want the "overhead" of including a relatively large script for a small set of features. This is unfortunately the way of jQuery. Either
Accept that you have to use jQuery, and make the most of having it referenced
Rewrite your Tabs-Menu controls without jQuery
any other option is going to be painful. Insist that your dev-manager reads the answers to the question.
Related
I wanted to use some functionality in jQuery-UI. So, I downloaded a custom version of the same from jQuery website, including only those things in my download that were needed by me. This was supposed to trim down the total size of my page, but to my surprise, the page size remained almost the same even after following the procedure provided at jQuery website.
Did I do something wrong? Or is this the expected behaviour?
You should have a look at JQuery UI Packager, it lets you pick what functionality you want.
It bundles it up with both a custom and a minified JQuery.
When I tried it, I removed everything but core functionality, and it ended up 15kb uncompressed.
Then I tried it without removing anything, it ended up 206kb uncompressed.
If you're that concerned you should think about gzipping.
Look at this chart of filesizes and how they improve with the different methods.
Here's a post about a guy asking a similar question, and the answer explains what you should focus on.
Here's a discussion about gzip and minify.
Things I am aware of:
Screen flicker if scripts alter styles / content (not an issue for me as I currently load scripts at the end of the page and so have workarounds already)
Inability to detect script load failure (not too concerned about this either as everything I develop is required to work with or without javascript. Might affect my workarounds for item 1 but happy with this risk)
It looks to be a very good option to me but I am hoping for some references (feel free to say only positive things!) before I invest time in incorporating it into my next project.
Currently we develop mid-to-large sized sites with, generally, a moderate amount of Javascript (although this is growing rapidly). We also use the jQuery library for the bulk of our Javascript.
Anyone have any experience? Good or bad! :)
P.S. for those interested this is head.js
Nope. As long as you put any code that is dependent on the loading files inside head.ready {} then you will not face any problems with your code.
Here is my conclusion for head.js, I have done some benchmarks myself:
http://blog.feronovak.com/2011/03/headjs-script-is-it-really-necessary.html
It is subjective opinion and benchmarks are not by any means scientific.
I was/am interested and thinking of maybe also using head.js BUT i found something not so nice: In the url that you gave me there are three tab buttons:
SCRIPT SCRIPT SRC head.js
SRC in head on bottom on head
Shift+Ctr+Refresh gives very little differences for me (+/-10ms between the three # 120mbit line, firefox 3.6.13)
When I use Ctr+R refresh, the results on the head.js are consistently 100ms slower than the other two versions without head.js... So, its NOT always faster.
There would be no problem on using jquery or javascript library heavily. Try to main each library as unique.
I am using prototype, scriptaculous, jquery and many more jquery additional plugins. I faced an error while loading entire scripts. Then i found out its due to $ sign which is an important parameter of jquery and prototype.
i had used
$.noConflict();
jQuery(document).ready(function($){
//jquery codes here
})
So keep your script library unique
head.js() gave a problem to my pages. None of my asp:button OnClick events were working. But if I include the scripts in the traditional way (<script type="text/javascript src="") then the events worked perfectly. I tried EnableClientScript = "false" and also CausesValidation="false". But nothing worked. Finally just scrapped the head.js idea since it did not make a lot of difference to my page load time, anyway.
I have a question about Javascript widgets. The widget I am working on simply embeds content on a page instead of using iframes. So far it looks good. But there are cases where some users layouts are messing up the widget. For example, the widget might require a width of 300px to appear. But the parent div is set to 250px and hence the right part of the widget is cut off.
I was wondering what sort of precautions should be taken to prevent this? I was talking to the product manager who mentioned he wanted me to check the parent div elements and get the size and then show an alternate message if their size is not accurate. But again, since this is Javascript and the widget is supported in many diff browsers(including IE6), I am wondering how fail-safe this method would be? What if I need to iterate the DOM all the way up before getting a valid size? I am also worried about performance here. This extra checks would slow down the delivery of my widget content to "good users" since I am adding a layer of complexity to all users. I don't want to penalize good users just because of the few errant ones.
I am not using any sort of JS library here, so any solution should not suggest the use of one. Also, the reason for not using a library was simply not to add extra weight to the page load to deliver a widget. I understand that "jquery" for example is small, but in my case, even 24k compressed seems like an overkill for a widget delivery that contains no core code for the widget.
Has anyone dealt with such issues before? What are your solutions to these?
There are reliable ways of determining the size of an element using JavaScript. You're quite right that you may need to iterate up the tree in some cases, but the answer you get will ultimately be quite valid.
Although you don't want to directly include any library code in this project, you may consider looking at how the major libraries implement their "what's the width of this element" functions to drive your own implementation.
Beware of quirks mode too.
I'd check to see of the page has Jquery, if not load it into the page using no-conflict mode. Then use jQuery to examine the page.
See: How to embed Javascript widget that depends on jQuery into an unknown environment
I am intrigued by IxEdit and its full-javascript approach that should allow to build nice web pages powered by JQuery effects.
I like also the opportunity to use it on many platforms.
But, is it worth a try ?
Is it complete ? Has it compatibility issues ? Are there better alternative tools ?
Don't rely on WYSIWYG editors--My guess is that this editor screws up performance like Frontpage, Dreamweaver -and the likes screws up HTML.
jQuery is pretty simple to understand, once you get hold of the concept of anonymous functions.. And with Stack Overflow at hand, you should be able to get where you want to go in no time.
Also: jQuery is the framework with the largest community and the framework with the largest plugin repository--need a gallery-thingie? No biggie, just browse the tons of plugins and find one that fits your needs.
Well, as JQuery isn't THAT complicated, I wouldn't pay for tools like that.
They also don't support any plugins I guess.
But it's free, so just try it...
I've just d/l IxEdit and am actually kind of excited about it.
It seems you do have to be careful about starting with a blank slate: I tried applying it to an existing page with a few jQ plugins and and it broke.
As for the WYSIWYG aspect of it, I think it would be great for beginners, as it generates the code on the fly, and you have to copy and paste the code into the page. This can give a noob the opportunity to see the code that's made and make sense of how it works.
My two cents.
I was wondering if anyone happens to know of a jQuery (or pure javascript) mind map. I found this one a few times, but it uses MooTools, unfortunately.
I decided to port the one you found into a jQuery plugin, which can be found LINK REMOVED - SEE EDIT. It was written up in about 2 hours last night, so is probably riddled with bugs. If you find any bugs, feel free to email me at the email listed in my StackOverflow profile.
Edit: I've contacted the author of the original Mindmap, and my jQuery conversion has become the core of development. You can get it, as well as speed improvements and new functionality here, on the Github page.
I think you should try http://thejit.org/
I use it all the time and is perfect for my needs.
There's also arbor.js, much newer then the ones cited in other answers. It implements the force directed algorithm for layout, similar to js-mindmap that you cited, but with better performance since it uses webworkers. The actual rendering is left for you, so you can use jquery or whatever you prefer.
Also, if you decide to write your own implementation, a good visualization library is d3.js.
I wrote this one for a project, it's an enhanced jQuery plugin version of other js node maps I found online suitable for dynamic contents (i.e. also supports dynamic adding/removal of nodes, selection marks, customizable callbacks and styles).
Notice: IE wasn't in the compatibility targets since it's also officially being dropped