0

I'm currently working with a large-ish Javascript codebase (currently around 150k minified) which is being included on a bunch of websites. As more features have been added, it's been growing in size, so I'm now investigating ways in which the size can be reduced.

One of the options available at the moment is switching from pure JavaScript to a compile-to-JS library. This could potentially help during development, as features such as class based OOP and compile time type checking would save us some work. However, it's important that such a change wouldn't increase the size of the codebase over working purely in JS. None of the languages I've investigated seem particularly concerned with output size. Dart looks like the nicest to work with, but the compiled output is ridiculously large. GWT introduces more problems than it solves, and the output isn't particularly pleasant to work with. I haven't tried Haxe myself, but a colleague has, and he tells me its output is very bloated. CoffeeScript seems the most promising so far, as the output is fairly standard Javascript, but it still produces larger JS files than we're currently writing by hand (although I've only tried porting small fragments of our codebase).

Is there a compile-to-JS language that produces terse JavaScript and minifies well (especially with Google Closure), while making the development process easier? Or are we better sticking with hand written JS?

If hand written JS is the way to go, are there any tools or techniques that can make a particularly big difference in output size? Google's closure libraries look interesting, as there's a lot of overlap in functionality between them and our our own code, but the benefit would have to be significant, as there's be a lot of work involved in switching to this.

Jim
  • 713
  • 1
  • 6
  • 23
  • If you know that only segments of the codebase will be used at a time, and you can properly segregate the codebase into necessary and optional, you might be better off using something like PHP to concatenate only the parts you need to serve. QueryStrings should work for selecting pieces to include. – TheZ Aug 10 '12 at 18:26
  • Create CommonJS/AMD modular plain javascript files and then http://requirejs.org to optimization and packaging. – Marcelo De Zen Aug 10 '12 at 18:29
  • We're already doing something along these lines, some optional segments of code are loaded in as plugins (though we use our own plugin manager). Unfortunately, we can't build the whole thing on the fly, as it's a library that's included on third party websites, and we don't usually have much control of the server side environment it's served from. The 150k script I'm working with at the moment is actually just the "core" component of our library, so almost everything in there is going to be needed almost all of the time. – Jim Aug 10 '12 at 18:33

1 Answers1

2

If you are looking at non-JS language options, you should consider simply using annotated JS in a style compatible with Closure Compiler's ADVANCED optimizations. This is likely to give you the smallest code size while still being able to leverage pure JS libraries.

For wilder options, I have heard good things about JSX and UberScript (type enhanced CoffeeScript) both of which produce reasonable Closure Compile style javascript.

Source level debugging via source maps should make the "prettiness" of the underlying JS source less relevant. I don't know the state of Source Maps for those two projects. Dart, GWT, and Closure Compiler all produce them.

John
  • 5,443
  • 15
  • 21
  • Getting the codebase working with Closure's advanced optimizations is a priority at the moment - whichever route we take, advanced optimization compatibility will likely be a minimum requirement. Both JSX and UberScript look good in terms of features, but neither project really feels mature enough to rely on. I think we'll probably end up sticking with annotated pure JS. I didn't realise source maps were ready to use yet, that's likely to make our lives much easier when debugging the output. – Jim Aug 12 '12 at 12:36
  • 1
    Source map support in Chrome is good, Firefox patches are back on track (the intern is back as an engineer), but no word from Microsoft that I've heard. Various docs and links: https://code.google.com/p/closure-compiler/wiki/SourceMaps – John Aug 14 '12 at 15:40