@Flibless has recently updated the Uglify plugin and created a production interface online to drag and drop your full wiki and get a compressed Tiddlywiki!
I have a specific use case where I want to include two video files in a wiki (so they will always work locally, even if the net is down). I will do some tests to see what the final size would be after “Uglify”.
Because the underlying Javascript compressor it uses is called UglifyJS, so I just went with it. And technically if you’re looking for code obfuscation, Uglify is your solution for that too.
I don’t know how much Uglify will do for you. It targets javascript files inside plugins, and it compresses the plugin tiddlers themselves a little bit. An included video file would be a base64 encoded file, and it’d already be compressed as much as its video format allows.
Also, I’m guessing such videos are adding oodles of megabytes already, which may dwarf whatever compression Uglify can do to what remains.
Are there any negatives when compressing the javascript? How will upgrading the wiki to the next version work when the current javascript is compressed? I am hesitant because it also seems like an irreversible operation.
@Odin : The downside (if you’re using a standalone tiddlywiki) is that if you ever need to use your browser’s debugger, you basically can’t now, because all the javascript has been obscured, and mostly fits on one line. That’s the only downside though.
It won’t prevent you from upgrading your wiki to the next version. Upgrading would replace uglified code with pristine code, which you could uglify again. Uglify only ever touches plugins, not non-plugin tiddlers, so it’s reversible (sort of) in that you could just drag-and-drop reinstall all your plugins and undo all the effects of Uglify. If you’re using NodeJS instead of a standalone tiddlywiki, then uglify is completely reversible, since your server will do its own uglifying and send the uglified versions to the client, but all your files on the server remain untouched.
However, if you do have concerns, then I wouldn’t worry too much about it. I developed the plugin for people who have particular reason to be concerned with file sizes and network bandwidth. It won’t noticeably speed up your Tiddlywiki or anything.
@TiddlyTitch : Also, I think technically uglify is the more correct term. It modifies javascript and json source code to be smaller, but it’s still technically uncompressed. In fact, if there was a TW5-compressor, you could apply that along with TW5-uglify and gain benefit from both.
Hi Flibbles,
thank you, this is great, and there is even another great benefit, that is not mentioned yet:
It also is an easy way to do the update to the new version 5.2.
You can use a special template to externalise TiddlyWiki’s core code into a separate file. This configuration allows the browser to cache the core for improved efficiency.
I wonder if this could work with the Uglify plugin?
In my opinion Uglifier best works with single files where you pass TW through emails work with may people like a graduate class! So you enjoy the simplicity and portability of a single html while you work with small files in range of 1.5 to 2MB instead of 3 to 5MB.
For those who may be interested, the new Uglify version is out which compresses static css. It’s not much gains, but it’s nifty.
@TW_Tones, I actually did not know about external JavaScript templates, but I see no reason why Uglify wouldn’t work with them. It should work automatically.