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.
Related
The Chrome Dev Tools JavaScript and CSS Coverage Drawer is pretty neat, except for one thing... It would be nice if it could be left on, and not reinitiate its analysis between pages.
I would like to be able to analyze an entire site, a subset of pages, or a set of websites, and find what is unused amongst them.
I get that it would mean browsing entire projects and using every feature (or setting up tests) to be thorough/precise, but that's not as tedious as what I have to do entirely without such a utility/feature. (And it doesn't seem like you would need to be meticulous to obtain usable or initial observations from a sub-thorough audit. The DevTools utility doesn't facilitate automated tests on its own either.)
The codebase at issue is huge (1.9mb uncompressed on the front end), and (possibly) contributed to by many developers who may or may not have left relics, legacy code, or abandoned dependencies. There is possibly also code that is only relevant in parts of projects, which could reveal opportunities for reducing dependency scope.
Is there a way to begin to crack into code use without a laborious manual deep dive?
It was one of the first things that came to mind when learned about the Google's coverage utility, and I assumed it would be capable of analyzing multiple pages collectively, but it doesn't.
Is there anything else that does this? Does any utility exist that can search an entire site or multiple pages and find unused JS and CSS?
Side note: The CSS is in SASS. For that and other reasons I may need to manually analyze the results and improve the code, which is trivial comparatively, so I'm not looking for a feature to automate code improvements. It's a similar situation with the JS which is minified.
This is not a request for a recommendation on poduct/software. It is asking if task X is possible, which is technically answerable with a yes or no.
UPDATE: It does seem like there are utilities for CSS, but still nothing found for JS.
For Static Analysis:
Try unusedcss.com to analyse unused CSS code across the entire website. More - Helium CSS
Try deadfile which is a simple util to find deadcode and unused files in any JavaScript project.
For Dead-code Removal:
Try purgecss to remove unused CSS code from your project.
Try Google's closure compiler which parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left.
That being said, detecting unused code is a hard problem to solve, because there are countless ways to invoke a given piece of code. Hence, these tools wisely and with your best judgement.
I've found a control on another webpage that I like. Assuming the site developers didn't build it from scratch, how do I determine what scripting framework and/or plugin they're using to transform and style it?
It's like a selection control of sorts in "bar form".
It's on the realtor.com site here.
I've gotten the class names used for the parent container and its children, but searching for occurances of those in the javascript docs using Opera's dragonfly didn't yield any matches. How do I find out how this is being constructed???
There's no easy way that I know of that will tell you which code did render which elements. However you can go by deduction here. First of all, is the code rendered on the server or the client? An easy way to know for sure would be to inspect the initial source of the page and check if the elements are already present. If they are, it would mean that they were rendered server-side or they already existed in the initial static document.
As far as I can tell, the search bar markup doesn't seem to be generated client-side.
However, behaviour is certainly added client-side. I went through the code and from what I can tell they seem to be using a library that's also used on http://www.move.com/
The scripts of interest would be:
http://static.move.com/getstatic/getfile.ashx?chl=rdc&typ=js&vr=7.2.0.2340&fls=core/jquery/jquery-1.7.1.min,core/jquery/jquery.cookie.min,core/jquery/jquery.validate.min,core/jquery/jquery.json-1.3,core/jquery/jquery.ba-hashchange,core/legacy/legacy-move,core/legacy/movedialog.min,core/namespace,core/utils/underscore-min,core/utils/storage-util,core/movecore,core/cookie/cookies,core/tracking/edwtracking,core/tracking/clientevents,core/tracking/dwgtracking,core/tracking/omnituretracking,core/tracking/comscoretracking,map/hashmapping,core/utils/hash-util,core/utils/support,core/utils/captcha-util,s_code,seo/_seoparagraphs,core/ui/bootstrap
http://static.move.com/getstatic/getfile.ashx?chl=rdc&typ=js&vr=7.2.0.2340&fls=nopaindoubleload4v6,core/utils/jquery.dropkick-1.0.0,search/searchview/_topsearchview,geography/didyoumean/_didyoumean,modal/_modalview,search/_propertysearchcore,search/_partialviewcontainer,core/ui/bootstrappopovertooltip,core/utils/fb_connect_util,core/utils/rc4encrypt,registration/_registrationwidget,core/ui/slider,search/facets/_facetconcepta,geography/_predictivetext,core/ui/bootstraptabs,map/mapview/_mapview,map/map,search/listview/_resultscount,core/ui/bootstrap,search/featuredhomes/_featuredhomes,search/listview/_listviewsort,core/ui/_loadingindicator,search/listview/_listview,admedia/_admedia,search/listview/_resultsperpage,fcma/_fcma,propertydetail/_freemovingquotehandler,propertydetail/leadforms/_leadmodels,core/ui/datepickr,propertydetail/_movingcalculator,search/_trackpageview,search/_tracksearch,registration/_rdcmyitemswidget,admedia/_trackingpixel,instruments,pagetophat/_pagetophat,admedia/_admediamanagercore,breadcrumb/_breadcrumb,contentmanagement/_linkingmodule
They seem to be passing module names to the getfile.ashx page. You could probably eliminate the modules that seems useless for what you are looking for, which would make the code analysis easier.
Once you retrieved the sources, you can use http://jsbeautifier.org/ to format the code.
Have a look at everything namespaced in MoveCore and MoveLib. The library seems to be broken down by modules, where the page would register the modules it needs with MoveCore.Tracking.addService.
Please note that I doubt it's actually legal to "steal" the code and I would strongly advise you to roll your own solution instead.
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.
the new guy here. I've been looking for a good solution to using Stylus (compiled CSS) client side.
Now, I know the tips regarding not using compiled CSS client side because:
It breaks if JS is not in use.
It takes extra time to compile in a live client environment.
It needs to be recompiled at every single client, which just isn't green.
However, my environment is an extension made for Chrome and Opera. It works in a JS environment and it works offline, so neither 1, 2 or 3 applies. What I'm really looking for here is just a way to write CSS more efficiently with less headaches, more variables, nesting and mixins.
I have tried Less, which is the only one of the trio Less, Sass and Stylus which currently works nicely client side. So, does anyone know a good solution for Stylus?
CSS Preprocessors aren't actually meant to be run client-side. Some tools (i.e. LESS) provide a development-time client-side (JavaScript) compiler that will compile on the fly; however, this isn't meant for production.
The fact that Stylus/Sass do not provide this by default is actually a good thing and I personally wish that LESS did not; however, at the same time, I do realize that having it opens the door to people that may prefer to have some training wheels which can help them along in the beginning. Everyone learns in a different way so this may be just the feature that can get certain groups of people in the door initially. So, for development, it may be fine, but at the time of this writing, this workflow is not the most performant thing to do in production. Hopefully, at some point, most of the useful features in these tools will be added to native CSS then this will be a moot point.
Right now, my advice would be to deploy the compiled CSS only and use something like watch or guard or live-reload or codekit (or any suitable equivalent file watcher) in development so your stylus files are getting re-compiled as you code.
This page likely has the solution: http://learnboost.github.io/stylus/try.html
It seems to be compiling Stylus on the fly.
Stylus is capable of running in the browser
There's a client branch available in the GitHub repo
I don't totally understand your question but I'll offer some of the experience I've have with compiled css using LESS.
Earlier implementations needed javascript to compile the LESS files into CSS in the browser, I've never tried to work this way didn't seem that great to me and as you say if JS is switched off your in for a rough time.
I've been using applications recently to compile the LESS code into valid CSS, this gets around the need for JS to convert the source code.
The first application I used was crunch http://crunchapp.net/ which worked quite well but didn't compile the css on the fly.
The application I'm using now is called simpless http://wearekiss.com/simpless and this creates valid css on the fly so as soon as I've hit save in sublime text and refresh in the browser I can see my changes to the css.
Using this work flow, I'm able to get around the issues your raised above, when I'm done doing development I just upload my css file outputted from simpless which is also heavily minified which also saves time in terms of needing to optimise the css further.
I hope I have understood the question correctly, if not apologies.
Cheers,
Stefan
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.