I’m like a cat watching ping-pong here. This has been fascinating. I did start comparing all the settings between the two wikis. And every time I found a difference: “Aha”, only to have it not fix the issue. I could never have found what Jeremy determined… which reinforces for me how much further I have to go in my journey.
Did you ever figure out what plugin was introducing Uglify?
I recall from some earlier exchanges here that uglify is incorporated in some plugins by @Mohammad. I don’t recall which ones, but several of Mohammad’s plugins are essential to my work (especially the biblio site), so the idea of assembling a version without those plugins, in order to troubleshoot an intermittent/whack-a-mole problem, was not looking good!
Actually, I found this thread where Mohammad seems to be indicating that all kookma plugins incorporate uglify…
IMPORTANT NOTICE
From Tiddlywiki 5.2.3, the packaged form of kookma plugins are distributed as minified tiddlers. The minification are done using Uglify from Flibbles.
I don’t really understand the difference between uglifying only some elements (within a plugin) and uglifying the whole wiki — which apparently was happening with my wikis (without my ever invoking such a process directly), given the discrepancy in some core shadow tiddlers, noticed by @buggyj above.
As @Mohammad pointed out, this isn’t actually the case any more.
The source for these plugins is available on GitHub. So we can repackage them relatively easily.
If you need help getting versions of these plugins without the uglification, please let me know. If you’re comfortable with the command line and don’t mind installing Node and Git, I can give you instructions. If not, I can do them for you. I’ve just done it for RefNotes. Of course, even better, as @CodaCoder says, would be if @Mohammad can offer both versions. But I haven’t seen much of him lately.
The version on Kookma is 43,031 bytes. When I packaged it as source it’s 60,284. So uglification reduced it by 30%, which is meaningful but perhaps not important enough to insist on it.
Dear all,
Sorry for the late reply. I will update the plugins without Uglify, but if you kindly be patient for a few days to use the new planned TW 5.3.3.
The current structure of kookma plugin repos is:
From TW 5.3.3 onward, I will publish demo+plugin without minifying.
Again, I appreciate your patience and sorry for not being more active on the forum.
The issue is with Uglify. There is a report of issue on GitHub by Mohammad.
For those use kookma plugin, they can install latest kookma plugins from CPL (Chinese Community Plugin Library) without minimizing (no Uglify)
Hi @CodaCoder
The source is not uglified! Only the packaged one (also distributed in demo page). Please see my recent reply in the thread.
Reading through this thread, I’m wondering if it would be better to stop uglifying the external core js on Tiddlyhost.
The size differences are as follows:
2349000 tiddlywikicore-5.3.3.js
1355873 tiddlywikicore-5.3.3.min.js
424214 tiddlywikicore-5.3.3.js.gz
291541 tiddlywikicore-5.3.3.min.js.gz
I expect most browsers fetch the gzipped version and cache it, so the benefit is a roughly 30% smaller one-time download. Maybe that benefit isn’t worth the extra difficulty it brings with troubleshooting and debugging.
Are there any arguments in favor of keeping the uglification? If not I’ll probably remove it soon from the “external core” TiddlyWiki on Tiddlyhost.
I think @saqimtiaz mentioned the he has some users with very limited data plans or really limited mobile connectivity. @saqimtiaz what do you think about the minified core?
Perhaps its not as importiant to minify a core that is externalised for all tiddlyhost site?
Thankfully there has been progress in the last few years and limited bandwidth is far less of a concern than it used to be for that group of users (in Central Asia). To my knowledge, none of them use TiddlyHost.
I think that it makes sense to not uglify the external core version.
As you wrote in your size-comparison – The savings for a 1 time download is about 100kByte if the server “gzipps” the code.
So it’s probably an advantage to go with a conservative approach an use the default core gzipped.
Just some thoughts.
Hi Simon,
Uglify has been updated to 1.8 and TiddlyWiki updated to 5.3.3.
Now these two work great! So, I think you can keep the minified core on Tiddlyhost if you like.
I’m delighted that the current conflict is resolved by the combined updates!
Still, I think part of the motivation of @simon’s idea here was to maximize ease of troubleshooting if/when there is any kind of unexpected behavior. It’s sobering that even @jeremyruston was not able to grok the problem until I could rebuild an internal-core version that replicated the issue. In theory, any issue that requires inspecting the source code — even an issue that turns out to be unrelated to uglify — would be harder to troubleshoot if/when it affects projects that have been compressed this way.
Since uglify is not easily reversible, it seems wiser to me to have the tiddlyhost setup default to a non-uglified default for external-core wikis.
This compromise seems to hit the “sweet spot” of avoiding redundant server-side and bandwidth burdens — especially important for users like me who run multiple tiddlyhost projects, and who also store the backup history (grateful to @simon for making such things possible!) — while minimizing the risk of the code being virtually unparsable to human eyes when that’s what’s needed.
Surely, those who wish to use a compressed / uglified version of the already-lean external core can of course still do so, correct?
It would be fitting to conclude this thread with a shoutout to this suggestion. Tiddlyhost is an amazing tool for the community, and the fact that @simon has allowed for a free level is fantastic as a resource for beginners and those whose storage needs are modest.
The paid plan is very reasonably priced, and helps to keep the servers running while also enabling further features.
Hear! Hear!
This is one of the most useful tools imaginable!
What are people using Uglify to do here? You guys keep mentioning an external core. What does that mean?
Is that a server? Because Uglify does sourcemapping. Or at least it does it with NodeJS. I think you guys are using TiddlyWiki in a way I’m not familiar with.
I agree, in particular if we taking in to account the value of the externalised core, it is downloaded once to the browser, for all wikis using that externalised core. Any uglification will theoreticaly save bytes only once.
What if Tiddlyhost and Uglify played well with sourcemapping? Would that make a difference? I’ve just never done anything with Tiddlyhost, but I don’t see why sourcemapping wouldn’t be possible.
Yes, there’s been plenty of discussion here about it.
Here’s one about external core being enabled at TiddlyHost:
… and this more extensive discussion:
The benefit for me (for example) is that we avoid the redundancy of hosting my core for each of my tiddlywiki projects, and I (and my students!) avoid the download bandwidth burden of downloading that core each time (beyond the first) that one of my tiddlyhost projects is loaded.