In several of the standard/popular javascript libraries, like jQuery and d3, there are many very tiny files that are built up to make the final library file, in many cases the files are just a few lines long.
I am not sure I appreciate the reason for the degree to which this partitioning occurs. It would seem to make navigating/comprehending the code base much tougher. Note that I realize that jQuery breaks some things up to allow custom builds with just specified modules, but there are still many tiny files within those module directories.
I was thinking it might be for unit testing purposes, but it looks like a lot of the files don't have anything in them that could be tested in isolation.
This really just comes down to personal preference. With javascript, it all just gets concatenated and minified anyways, so it really doesn't matter what the file structure looks like. The file structures you see are what the owners/maintainers think makes the most sense for that particular project.
Splitting large libraries like these allow the developers to write decoupled, modular code split up into related functionalities. It also helps with merging in contributions from a large number of people (great for open source software)
here are some worthwile resources
Writing module of javascript code, use require (amd)
Wiki page on coupled code here
Wiki page on modular programming here
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 realize this may not be the right place to ask this question so feel free to send me elsewhere. I am looking to internationalize a set of apps that have strings in a combination of java, tsp and javascript files. We have some use of resource bundles in a. few of the java apps but I am looking for a unified approach for all to both reduce the number of translation files and provide a single point of reference for them. I have yet to stumble upon a solution that is not specific to one or the other.
What I have thought of so far:
Database-driven - this would achieve the two stated objectives but, unless I am missing something, would result in a lot of db calls and likely performance degradation.
External files - this is the most feasible approach as I can read from a shared location. The only part I am struggling with is how to organize them so as to make it possible to load all the tags for, say, a single page together.
I would recommend the "External files" approach... decouple your translation files from your code... this would help your localization process a lot.
For i18n you might read this article (focus JavaScript but not only) ...
I would recommend looking into a i18n lib that is ready to be used in different frameworks, i.e. i18next
There is some java based lib too: i.e. i18next-android
As said in the beginning, you should not only consider that you have to instrument your code (i18n) to get your app/website translated. You should think about the process too - how will you solve continuous localization, how you keep track of progress, etc...
For a translation management+ system you might eg. have a look at locize it plays well with all json based i18n frameworks and in the core has a very simpe api... and provides a lot more than traditional systems...
What is the best way to deal with multiple client side templates?
I noticed that if I keep them in my "mother" html file, it soon gets bloated with stuff, so I thought that maybe it would be better if I just put them in separate js files and load them one by one.
Another idea of mine was to avoid putting them separately as templates, but rather write them as strings and sort of couple them with the backbone.js views which are going to use them. I know that this would bring a lot of negative from designers, web developers, and software engineers in general, but for the projects I am working on, this seems like a very speedy way to develop because I have logic and layout at the same place. Plus, by reverse engineering, I proved that a bunch of prominent web services are doing the same so ...
One option is to use RequireJS, which includes a 'text' plugin for templates.
You can then use the r.js optimizer to combine all of these (plus JS modules, if you go that route) into a single file.
The optimizer can be run either as part of your build process, or in-process if you're using node.js.
You can have them in separate files, but combine into one file on a server side.
And take a lot of negative from me for your idea to keep templates in strings :). It might work until they are simple, but when they get more complex it gets badly, because html structure is not so obvious, so it is harder to write css and so on.
As #stusmith said, require.js is a good option.
also, take a look at the boilerplate's examples
http://backboneboilerplate.com/
https://github.com/thomasdavis/backboneboilerplate/blob/gh-pages/js/views/backbone/page.js
cheers
Let's say you are building a large application, and you expect to have tons of javascript on the site. Even if you separated the javascript into 1 file per page where javascript is used, you'd still have about 100 javascript files.
What is the best way to keep the file system organized, include these files on the page, and keep the code structure itself organized as well? All the while, having the option to keep things minified for production is important too.
Personally I prefer the module pattern for structuring the code, and I think this article gives a great introduction:
http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth
It keeps my global scope clean, enables namespacing and provides a nice way to seperate public and private methods and fields.
I'd structure the code in separate files, and seek to keep coupling low and cohesion high. Although multiple files are bad for client performance (you should minimize the number of requests), you'll easily get the best from both worlds using a compression utility.
I've some experience with YUI Compressor (for which there is a Maven plugin:
http://alchim.sourceforge.net/yuicompressor-maven-plugin/compress-mojo.html - I haven't used this myself). If you need to order the javascript files in a certain way (also applies for CSS), you could make a shell script, concatenating the files in a given order in advance (Tip: YUI Compressor defaults to STDIN).
Besides, either way you decide to minify your files will probably do just fine. Your focus should instead be on how you structure your code, so that it performs well on the client (should be highest priority in order to satisfy a good UX), and is maintainable in a way that works for you.
You mention namespaces, which is a good idea, but I'd be careful to adopt too many concepts from the traditional object oriented domain, and instead learn to utilize many of the excellent features of the javascript language :)
If the overall size is not too big, i'd use a script to compile all files into a single file and minify this file. Then I'd use aggressive caching plus the mtime in the url so people load that file only once but get the new one as soon as one is available.
Use:
jslint - to keep checks on code quality.
require.js - to get just the code you need for each page (or equivalent).
Organise your js as you would any other software project, break it up by roles, responsibilities and separating concerns.
Although I am using the Zend framework, MooTools JS library and my questions revolves around them, this is a more generic question.
I am working on a web app, in which I am using many elements which are sometimes useful on other pages (for example OpenLayers related MooTools classes).
Mootools already allows this "segmentation" by "classing" (creating "Class"..) so I feel tha the next thing to do is to have separate JS file for every class, then send a request to a PHP page with the classes I want and get in return JS file with what I need.
At the same time this mechanism will minify and gzip and cache locally on the server (for future requests) and send me back this one file.
I didnt go into design yet and was wondering if such / similar solution is out there?
Alternatively I see libraries like labJS that speeds things up by multi threading the requests, this however does not complete the solution with minification and gzip (I have to take care of this server side with another complementary solution).
Is any one using similar dynamic JS "Class" loading solution?
Cheers,
Roman
I think the tool you want to look at is the minify project. Here's a description:
Minify is a PHP5 app that helps you
follow several of Yahoo!'s Rules for
High Performance Web Sites.
It combines multiple CSS or Javascript
files, removes unnecessary whitespace
and comments, and serves them with
gzip encoding and optimal client-side
cache headers.
It's very straightforward to use, and, say you have it installed in http://example.com/min/, and you have two files to compress:
/resources/js/lib/library.js
/resources/js/main.js
You would call this url:
http://example.com/min/b=resources/js&f=lib/library.js,main.js
And the code looks like:
<script type="text/javascript"
src="/min/b=resources/js&f=lib/library.js,main.js"></script>
So basically there is a consistent URI based way to merge files together.
I'm not familiar with zend and only somewhat familiar with mootools so take this with a larger-than-average grain of salt.
Wouldn't it be easier to have a process that generates/minifies all the possible combinations of the classes you have and then just request a particular combination? You could automate this with a script pretty easily.
Also, I've used the HyperCache and WP_Minify plugins for wordpress and they do pretty much everything you are talking about so you might want to look there for inspiration.
What you describe is pretty much what the YUI PHP Loader does, although it is tailored towards the YUI JavaScript library. However, the project is open-source under the BSD license so it is a good place to get some ideas to implement your own.
Do also have a look at Lissa (which is based on YUI PHP Loader) that is a generic JavaScript (and CSS) loader.