I like the idea of cutting out 80% of jQuery by using Zepto.js. However, when making the switch, it is clear some of the jQuery plugins I'm using, for example jQueryUI draggable(), can't find in Zepto what they need.
Is there a sane way to go about switching to Zepto? Or Am I just going to have to extend it function by function until I stop getting errors?
Hear me out. In a perfect world we always have frameworks that are exactly what we need. But we don't live in such a world. Different projects - different requirements. JQuery is designed to cover ALL of the usual requirements, therefore saving time. It may sound tempting to try to optimize it for the project needs, but in the wrong run, will it be worth building frameworks for every small project? In the end it's only 15 kbs of difference, a fraction of a second. As javascript is not compiled you don't save from compilation-time or anything. Just that little tiny bit of bandwidth. I'm not aware of the importance of your project, but I personally wouldn't sacrifice my time to build a custom jQuery distribution for every new project I'm creating.
If the stripped down Zepto doesn't work out, I'd stick with jQuery. But if you are determined to do this, I think it would be easier to start striping jQuery down, instead of upgrading Zepto. That way you can instantly tell when your modules break and see the reason.
Related
Probably any experienced web developer would be familiar with this problem: over time your css files can grow pretty huge and ugly because of all the no longer used selectors, which might be pretty tricky to find. I'm working on a rails project where we tend to re-design things quite frequently, which leads to a tonne of deadweight css. What's the best way to find and remove it?
Now, I do know that there is a rails plugin called deadweight built specifically for that purpose. However, here's my problem with deadweight: first of all, it completely ignores selectors used in javascript. Next, it scans only those pages that you configure it to scan which means there's a risk of removing something that is used on pages that you didn't scan for some reason. Finally, it finds unused selectors only in compiled css (we use LESS) - matching these against the actual code is a bit too involved.
I have also tried http://unused-css.com/ - they're great, but can't access localhost and, again, can only scan compiled CSS.
I really think there must be a better way of doing this. Actually, some time ago I decided to optimise one particular css file by grepping each selector in the entire project directory (emacs + rinari mode make it super-easy and super-fast), and each time I didn't see any html or css in the results I removed the style. Zero problems, worked like a charm. Obviously, I'm not going to do that for the entire site. However, I really don't believe that this couldn't be automated. Now, before I fire up my python and code this up, can anyone actually tell me if I'd be reinventing the wheel?
Check out uCSS library from Opera Software.
It helps you to find unused CSS, as well as duplicate CSS. Also, you can get an overview of how many times each rule has been used in your markup. Several options are available by setting up a config file.
Update:
Another great alternative: csscss.
Written in Ruby and supports SASS, Less.
Update:
Another great alternative: uncss.
It works across multiple files and supports Javascript-injected CSS.
Dust Me Selecters and/or CSS Usage Firefox extensions can help you weed out unused CSS.
In Chrome's Developer Tools you can use the Web Page Performance tool to find unused CSS rules.
Ext.js is of interest to me because it appears to have a fairly complete widget set (though I've certainly run into shortcomings of the widgets after a very short time). The problems I potentially have with it, however, include these:
in my opinion it's very ugly, and looks like a cross between a Windows UI and some PHP content management system (yes I know I can write my own theme, but there may be limits to what I can change, and it may not be as easy as it should be, and I'd rather work with something that is clean, elegant, and attractive out of the box.)
the graphs currently use Flash, which limits the clients it can be useful on (version 4 promises to resolve this problem)
the license is a bit restrictive, which is not an issue now, but it makes me think twice about becoming intimately familiar with a tool that I may not be able to use in the future.
Honestly the look & feel is probably the biggest issue to me: I've seen in the past that developers (or companies) who don't place a high value on aesthetics often can't be bothered by other 'details' either.
So: is there a other better alternative?
UPDATE:
Another problem with Ext.js, is that it seems to be an all-or-nothing proposition. That's one reason I'm not looking seriously at SproutCore, which in other respects is awesome. (Well... it needs some performance improvements, but it'll get there eventually I think...)
Cappuccino seems to be the same way: you're not using it on a web page, rather you're building a Cappuccino app that just happens to use the web as its runtime environment.
In other words, ideally I don't want a JS version of Flex: it's own little walled garden. jQueryUI would be ideal if it were more complete, since it doesn't break with normal web development methods and paradigms. But if walled gardens are all there are, I'll live with it.
If you are looking for a RIA-Framework you shouldn't use jQuery(UI). Instead use one of the following frameworks.
Qooxdoo (www.qooxdoo.org): Pure Open-Source RIA-Framework with the most of the features of ExtJS. There were coming up some interessting new themes in the last weeks
Cappuccino (http://cappuccino.org): Nice framework with a nice GUI
ZK (http://www.zkoss.org/): ExtJS like RIA-Framework
SproutCore (http://www.sproutcore.com/): Apple-Style RIA-Framework
I undestand your pain - I use to got same - in ExtJS I saw only problems (those what you mentioned, and belive me much more others), however because I was a little forced to use it, I started to use it and I followed in love - It very complex and optimal solution for javascript driven apps.
You can go and look for alternatives like jQuery (I was there for 1 year), dojo, and others frameworks, but whoever says that they are better than ExtJS, he rather did not have ..... time to know ExtJS
It my very subjective opinion
I dont know much about PHP, and I am using ExtJS with ASP.Net MVC, they fit well. I wish I could use an integrated JS Widget set, but Jquery UI widget set was not rich enough when I last evaluated and I dont think it still is. But it is at least included in the last version of MVC.
My only complain about ExtJS would be the number of user extension controls that you need to use, I'd like to see those as part of ExtJS core widget set, but they are not, but still distributed with the library. ExtJS is a very nice fit for a cross-platform Rich Web Application. I would recommend trying ExtJS, I have really no complains about it other that what I already said above.
When does it make sense to turn your code into a jQuery plugin?
What are the criteria / signs that parts of your code might be better as plugins?
Actually, your code is a jQuery plugin as soon as you start adding new stuff to $.fn.
But besides that, it makes sense for reusable code or code which is not specific to your application.
Also have a look at the Plugin Authoring Guide - it shows you some best-practices you should follow; especially if you might release your jquery plugin at some point. But it might also give you some ideas about when it makes sense to make your code a plugin.
It is more than anything a matter of if the code is at all abstrable/reusable at all and if so, if you think you will actually need to be reusing it at any point in the near future. I generally end up with a mixture of both; common functionality abstracted into plugins, and page-specific custom code intializing those plugins and setting up whatever is unique to that page.
I know exactly what you mean about where to make the decision to abstract it and there are no hard and fast rules to follow. If it isn't completely obvious, you can at least try to write the custom code with an eye to the future that you might be making it into a plugin. Javascript really makes that easy with its closures.
I have noticed that sometimes people have to use multiple versions of jQuery in the same page (See question 1 and question 2). I assume people have to carry old versions of jQuery because some pieces of their code is based on an older version of jQuery. Obviously, this approach causes inefficiency. The ideal solution is to refactor the old code to use the newer jQuery API. I wonder if there are tools that automate the process of upgrading a piece of code to use a newer version of jQuery. I've never written programs in in either Javascript or jQuery. So, I'd like to hear from programmers experienced in these language about their opinion on this issue. In particular, I'd like to know the following.
How much of problem it is to have to load multiple versions of jQuery?
Have you ever had to load multiple versions of any other library in the same page?
Do you know of any refactoring tool that helps you migrate your code to use the updated API?
Do you think such a refactoring tool is useful? Are you willing to use it?
Please don't consider this question closed. Current responses have already gave me good insight about the process and tools available for upgrading jQuery code. But, please feel free to add your own experience with upgrading jQuery code.
your questions are all big. But from my personal experience except from very little problems in the first version which happened after migrating to later ones. Pretty much you should not run into any problems unless something is wrong with the code you have written and not jquery.
I have not seen any proper js developer who uses two different versions at the same time.
JQuery now itself offers a pretty nice api for unit testing called qunit. and if you start implementing test functions there you should be certain that your code works seamlessly.
I Use QUnit for heavy projects. which requires maybe alot of ajax requests etc. ofcourse it is not really worth it to use it for couple of animations etc.
I hope this information is helpful
Ignoring the fact that you can do this with JQuery, using 2 versions of any API is unusual and error prone. It is a rare practice, but at least with JQuery, it is done.
If I were evaluating a vendor's components for a new project and there was a requirement for an older library, I'd think twice before investing in that component. Vendors who supply tools that require old verions are one of:
1) Very cautious and stability minded (good)
2) Not up to speed (not too good)
3) Low on resources (bad)
4) Not motivated to update their tools because not enough people are demanding the tool (really bad)
Of course (5) could be that their tool is so good and they have such a big customer base they don't feel the need to update it. That is ok as far as it goes, and eventually goes back to one of the other issues.
I use enough 3rd party tools to know that sometimes, a tool does a job so well that I pick it anyway, but in general, I want a tool to be current for a new project. There are a lot of "fly by night" vendors out there that just aren't maintaining their products and you don't find it out until you ask for support or new features.
I also use two versions of jQuery on the same page sometimes, but for a different reason. This is code that runs as a third-party widget on the page; in that situation you cannot count on a specific version of any libraries being present.
If you need a library such as jQuery in such code, it's safest to load your version and do something such as myNamespace.jQ = jQuery.noConflict(true) so that you have a namespaced, separate version that you can rely on, and that is decoupled from the rest of the page.
That way, if that page changes their code, your third-party code won't be affected. In this case, by eliminating possible dependencies on the library version in someone else's code, I'd argue that using multiple jQuery versions actually facilitates refactoring.
I have developed one of my modules using Dojo. Its gone really well and I have done a lot of custom plugins and server support in Dojo to allow AJAX calls, RPC + SMD communication with my server.
However, now that I am getting onto the user side of things, I am seeing that jQuery has some really nice already built plugins. Do you think it is possible to support both JS libraries realistically without it being a massive problem?
What kind of integration can I achieve? Does anyone have experience in this?
I have probably written somewhere in the region of 30k lines in Dojo for my Administration panel...
jQuery is very good about not messing with the prototypes of built in javascript objects (unlike Prototype), this allows it to be used with other libraries quite easily.
A source of potential conflict is jQuery's use of $ as a shortcut for jQuery. I'm not a dojo user, but if this conflicts with dojo in some way, there are instructions addressing this.
That said, I think you'd be better off looking at these jquery plugins and rewriting them and porting them to dojo. I'm sure the dojo community would appreciate it, and it would give you experience. It'd also make your application a little slimmer in the waist area.
Edit: I've noticed a couple answers trivializing the download speed of adding an additional library. I'd take this with a grain of salt.
As developers we tend to see only the extra 10ms it takes to download the library over localhost, or from our development server on a 100 Mbit LAN. The download speed is not so trivial from California to Virginia, or especially from USA to Europe. Additionally, it adds further burden on your client's javascript engine. If they are using a 1-2 year old good computer with Safari or Chrome, this would be negligible, but if they're on IE, FF2, or some versions of FF3 the difference can be severe, or at least measurable.
When using 2 libraries (both of which, I'm sure - were designed to be used by themselves) you have 2 main worries:
That one library will effect the other.
That having a dependency on 2 libraries will bloat your pages.
In this case, I would bet that #1 is not going to happen. Although #2 is still a concern.
Most of the popular JS libraries can be scoped to their own global shortcuts. JQuery can be set to not initialize the $ variable. JQuery aside, I hear that Dojo and Prototype can work together without conflicting.
Regardless of what combination of JS libraries you decide to use, the best way to get information on compatibility issues is to hit the mailing lists relevant to the JS libs you'll be using with each other.
http://docs.jquery.com/Using_jQuery_with_Other_Libraries
http://www.dev411.com/blog/2006/06/13/dojo-and-prototype-together
Query.noConflict() makes for fairly easy interoperability because you can redefine $. As hobodave draws attention to, Prototype is lousy in this regard (because you can't easily just redefine $ with Prototype). I am not sure but I think Dojo doesn't have any issues of it's own and plays nicely with others out of the box (please someone correct me if that's not true).
The biggest problem I've had is the number of "must have" libraries written in specific frameworks, such as for things like sophisticated graphing that would be non-trivial to implement from scratch.
Bloat is bad, but compared to image sizes JS script sizes are of negligible concern (because it's so small and connections are so fast and it's only on first page load if you get your caching right, it's almost a non issue). I'd say maintiainablity being more of a worry, and it's a matter of deciding if you want that must-have-plugin that you don't have the time or inclination to reinvent in whatever framework you are using.
I have used Prototype, jQuery, and ExtJS on several projects (for various reasons) and almost always use jQuery and ExtJS together. One way to limit trouble would be to avoid mixing libraries in any given page - keep Admin page to dojo and new pages to jQuery - but what fun would that be? :-)
I find few problems when integrating jQuery and ExtJS. I pick a framework for classes/objects/inheritance (I use ExtJS) and stick to it. Then, I use ExtJS to create most widgets and I use jQuery for low-level DOM manipulation and simple widgets. Again, I cannot recall running into conflicts when using two libraries, but FireBug is a good tool to uncover suspected causes of such conflicts.