Uglify v1.5.0: Minify your tiddlywiki with ease (now with source mapping!)

Plugins
#1

The new version of Uglify is out. Minify your Tiddlywiki to nearly half its size! This release comes with a bunch of new wikitext rules and some fixes, but most importantly…

It comes with Source Mapping!

That means if you’re running uglify on your Node.JS server, it can now supply javascript source maps and original files on demand (when you open your web developer console). You can still debug your code as though it weren’t uglified.

Sourcemapping has its limitations, however, which is why it’s is (and always has been) possible to disable uglifying with a simple button on the Uglify plugin readme page. You can also configure specific plugins or tiddler types to be ignored.

Let me know what you all think!

(The new wikitext rules trim an additional 12K off of the core. Not much, but it means a lot to me.)

5 Likes
Lightweight Edition of Tiddlywiki
#2

@Flibbles, this is one of those things that needs deep thought. I’m really focused on singular wiki. Your comments on plugin obfuscation / option to not Uglify, are highly relevant.

Basically…

1- I think it an excellent aid on performance.

2 - Slightly concerned we might need more docs to optimise case-by-case?

Just a comment
TT

#3

It’s about single file wiki size “over the wire”. So it’s an improvement for “loading time” and transfer price. It has no effect on browser performance.

I think it should only be considered, if file size is a “real” concern. So for users with slow internet connection and high data-transfer prices.

For users with WiFi connections and flat-rates, it’s more psychological than a “real” problem.

Many servers already send a single file wiki as a compressed file, that is uncompressed by the browser. So technically it doesn’t make a big difference, if the TW core is compressed or not.

Users may have a problem that an empy.html file is 2.2MByte in size. … But they have no problem to send 10 – 4MByte images to their “messenger” groups or to a “you name it” service.

1 Like
#4

It kinda does. I have a few optimizations in there, but yes. You’re right. It’s mostly about file size.

Believe it or not, I actually agree with you, despite the time I just sunk making this. My primary reason was so that plugin developers would stop minifying their own plugins, because now anyone can minify on their own. The Source Mapping was a neat novelty since the javascript uglify engine I was using already supported it.

#5

Also, it would be really nice if core developers could stop being stingy about commenting their code/wikitext, and maybe indent stuff so it’s easy to read. This plugin means they can, and they don’t have to worry about size impact if it concerns them.

#6

First of all, brilliant! This and @joshuafontany’s TW Syntax highlighting are two of the brilliant meta-tools for TW5. As somebody who keeps a relatively large amount of TW5s (with small amounts of data), this minification does indeed help in cutting down space usage.

I see that you do have wikitext minification in your plugin. Would it be possible to transfer this knowledge for the other side of things - beautification of wikitext? *cough*

4 Likes
#7

Following to @anon9140225 comments, I would to add my two cents.

Uglify is an important tool for my workflow! We distribute a lot of single wikis. Most students are not comfortable to export -import tiddlers as JSON, and prefer to send/receive single file TW.
We send/receive these files through emails and keep them on thumb drive for portability!
So, for us 50% reduction is size is a big deal!

4 Likes
#8

Thanks a lot for your efforts on this addon ! My tiddlywiki folder is around 5.24GB (lots of backups and experiments), so any way to shave off some of that size is very welcome.

#9

Beautification is not out of the question, but it’s such a different direction than uglify went that it might as well be its own plugin. It wouldn’t even share the same injection point. However, hopefully if Uglify becomes popular, people will no longer feel any reluctance to properly indent their wikitext.

I’m glad this can be of help, but I’d reiterate what @pmario said above. If you have a lot of backups, nothing is going to shrink them down quite like good 'ol fashion zip.

#10

I have to say your plugins and core improvements on the way to create them, are great and very high quality. I personally like it when we can reduce the “base” size of empty.html.

And yes, we definitely should improve the readability for all the core wikitext elements we use. … But this will be a lot of work and it isn’t trivial, since in TW wikitext whitespace matters. So changing indentation may have an impact on the DOM elements that are created. …

1 Like
#11

I am in the process of adding “\whitespace trim” to the core. Just waiting on my current PRs to be approved. With that pragma, whitespace has no performance impact at all (and uglify can go hog-wild on wikitext when “whitespace trim” is present).