Uglify is even uglier. New features. Sourcemapping extravaganza

Plugins
#1

Uglify is back. Very ugly, but reliable. Dependable. Supportive. There for you.

First: Sourcemapping

Before, Source mapping was something that only worked for basic server setups. Now it can work for everything.

  • I’m talking single standalone html files. It can generate a source map directory to sit beside it.
  • I’m talking offline-external-js html files. The tiddlywikicore.js file can be versioned, so you can multiple versions of uglified, sourcemapped core code on your WebDAV server or whatever.
  • I’m talking external-js Node.JS servers. Uglify your core code, then only load it once anyway.

It’s also just better. Before it initialized sourcemapping through a startup module, which meant all the startup modules before it weren’t sourcemapped. Dumb. and stupid.

Now it uses a boot library, kinda like sjcl.js. It’s secret and hidden, and works much more magically. Every single module will be sourcemapped now.

Second: Pruning

The feature nobody asked for but everybody wants. Uglify can now strip away unwanted features out of Tiddlywiki while it uglifies. Currently, there are only two pruning rules

  1. uglify: This rule already existed. It strips uglify down to virtually nothing and removes all uglify configuration files from other plugins. Why? Because after uglify is done, you don’t need any of its junk. It will see itself out.
  2. server: This one is new. And awesome. Since the dawn of time, Tiddlywiki has shipped with all its Node.JS fluff, like commands and server handlers. Why do we need that in an html file? Why do we need that stuff sent to browsers? We don’t. We never did. Now we don’t have to. Uglify cuts it all away and saves you about 70kb.

But this is just the start, kids. The infrastructure for pruning is complete, and new rules are as simple as writing the filters. Here are some ideas I have if people like this idea.

  • Remove sjcl and all encryption. I think maybe 1% of people actually encrypt their tiddlers. Yet every tiddlywiki since the beginning of time has shipped with the entire Stanford Javascript Crypto Library.
  • Remove all content for editing tiddlers. This would be useful who use Tiddlywiki as a website for end-users. One that’s complete as-is, and shouldn’t be edited. This could trim a LOT from the core code. You’d still be able to change stuff with actions and messages though.
  • Remove importing and saving. Again, if you’re generating your Tiddlywiki to be customer facing, you don’t need this stuff.
  • Remove all unused themes, color palettes, tweaks, and controls to change them. Same idea

I could go on and on, but I’d love to hear what people would actually be interested in (if any) before I invest time into this. If you have something super custom you’d like to prune, you’re also able to build your own rules. The documentation goes over this.

Your thoughts?

Flibbles

5 Likes
Make an identical tiddlywiki code compression wizard according to the official website
#2

This is what interest me the most personnaly ! I’d like to be able to use tiddlywiki as a CMS for my personnal website, or to create small books / guide (like for example this one I’ve made : https://steamdeckguide.tiddlyhost.com/). I’m also playing with the idea of making games with tiddlywiki, so shaving off weight will probably be rather important to keep everything fast and smooth.

Could the uglify process be automated so I could push update to my website minus all the stuff related to editing / saving / etc. ? I guess it’s intended to be used in the node.js config, and then the uglify plugin remove the extra stuff when a single file wiki is exported ?

#3

Yep. That’s exactly how it would work. Uglify works best in Node.JS form, and it injects itself whenever you start a server or export a wiki with --render.

I’m not sure how the Tiddlyhost development environment works. Could you describe it to me? TiddlyHost seems to be becoming increasingly popular, so I’d like it if Uglify could work in that environment too. From what I remember of my poking around, it’s not Node.JS, right? You do all of your content creation through TiddlyHost, sort of like you do with WordPress. But you’d have, two different wikis? The development one, and then a production one?

1 Like
#4

The way I understand it, Tiddlyhost act like github page but use a put saver based on the WebDAV protocol, so we have one wiki that save change if the user is logged in with the right credentials. A wiki can be private or public, but there is no backend like with wordpress.

@simon has added a way to tell if the user is logged in by setting the login status in $:/status/IsLoggedIn, so it’s possible to switch the template used by the save button to trigger a download of the full wiki if the wiki was made with an external template, or hide some ui elements with a startup action: Read only TW — experiment for a read only wiki hosted on tiddlyhost

With saq’s plugin to embed external content from other wikis, I think it should be possible to have a bi-wiki setup, one with all the tools needed to create content, and the other that would recieve the content (minus the capability of editing). Then, maybe your uglify plugin could be used to trigger a save of the wiki in a compressed state ? @simon are you using uglify behind the scene ? If not, maybe you could make it optionnal to allow saving more space for your server ? I’m doing all I can to keep my tiddlyhost wikis as light as possible, but I’m dangerously reaching the 30MB mark…

#5

I think CPL will auto crawl your plugin library (relink library only I think), so hopefully this can be installed from CPL. I wonder if JSON version of this plugin installed from CPL still works.

#6

@telumire If $:/status/isLoggedIn isn’t accessible until after startup tasks are run and such, that’s much too late to potentially switch to an abridged version of the core. I’ll check it out if there’s particular interest. A bi-wiki setup could theoretically work, but it sounds like it might be too complicated for end-users.

I think I’ll have to actually get a TiddlyHost account to see if such switching can be done.

@linonetwo, I didn’t know the CPL existed until reading your comment. I don’t think the CPL knows I exist either. It looks like all they have of my work are two supplemental plugins of Relink, but not all, and not Relink itself, which makes it particularly useless.

1 Like
#7

I made a TiddlyHost account and played around with it a bit. The way it works is it’s effectively a fancy file server. There isn’t anything I could do to make Uglify integrate with it, and there isn’t really anything elegant @simon can do on his end that wouldn’t complicate the otherwise-simple workflow his customers get. I’m certainly happy to spitball ideas with you or him, but I’m sure everyone will eventually conclude the same thing.

But I did play around with it, and I see how Uglify can be used with TiddlyHost. TiddlyHost provides a means to upload a Tiddlywiki from your local machine to replace whatever currently exists on TH. That means you can develop your tiddlywiki all you want on your own computer. Then when you’re ready to publish, you drop your tiddlywiki into the Uglify wizard, and upload the resulting file to TH. This would work just fine.

The downside to this is it eliminates the primary feature that makes TH preferable for Tiddlywiki over other file hosting sites: it’s workflow. You wouldn’t be able edit your file in your browser and just press “save”. But if you’re willing to do without that, you can use Uglify all you want.

#8

I see, so the way to go would be a nodejs setup + exporting to tiddlyhost (I think it is possible to setup the tiddlyhost saver on a local wiki…). But then it might be better to simply host on github page, to avoid burdening tiddlyhost server with a wiki that would be purely for read-only purpose. Thanks for taking the time to look into this !

1 Like
#9

If you put it in your plugin library, it will be auto crawled

If you have other library, you can add it here, it auto updates per 1h.

#10

Like, add it again? Cause it looks like you added that entry 6 months ago (thank you for that), but it never properly crawled my Relink library.

#11

I really appreciate the pruning feature, @Flibbles! And further thanks for making it independent of the normal uglification process. I edit my plugins often, so it’s nice to keep them readable, but I’m very glad to dump all the palettes I wasn’t using. I think I’ll probably do a second pass to remove the encryption tools, and I’d be interested in your thoughts (or anyone else’s) on other core features that most people probably don’t use.

#12

You’re already enjoying having dumped all your palettes? You must be writing custom rules. I’m glad to hear that.

Also, be wary about cutting out sjcl. The reason I didn’t include it with this release is because it’s a little more complicated than it seems. A few Tiddlywiki utilities make use of sjcl, including the sha512 filter operator. They expect global.sjcl to be there. That’s why I think it’ll require something like hotswapping sjcl with a barebones version rather than removing it entirely.

#13

No, your new plugin is not in relink library. You’d either add it to relink library (not recommended), or add it as a tiddler like other plugins, or add a new library contain it.

It is now fixed.