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?
V5.3.2: story river fails to scroll to open linked tiddler ... why? (conflict w plugins that uglify)
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.
1 Like
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.
1 Like
Could you explain what you mean here?
A key value with tiddlywiki is you can use its own code to explore how it works, to make modifications and even find out how to do your own thing based on the existing core.
It would seem to me that source mapping as I imagine it to be would benefit from readable code.
On an external core
In a very simple way to understand an externalised core is consider the plugins in a wiki, it always comes with the “$:/core” plugin. Now imagine this in a separate file that gets loaded when you open your wiki. Only your customisations are stored in your wiki, making it quicker to load and save every time.
- Your wiki will not load if it cant find the external core.
- Multiple wikis can use the same external core.
- Download once use many times.
I’m starting to see documentation on external cores. Didn’t know Tiddlywiki could do that. I’ll look into it. I guess tiddlyhost uses that too?
sourcemapping is when a server provides uglified javascript for browsers to run, but if the end-user should open up their debugger, their browser will ask the server both the original source and a “map”, which is a JSON file following specific ECMA notation or whatever that indicates what parts of the uglified code correspond to the original source. It lets people use ugly code while still being able to debug with the original at the same time.
It’s not perfect, Uglfifying can rearrange stuff, so stepping through even with a source map can be a little strange sometimes, but it’s viable, and you get all the original variable names and such.
If you run TW-Uglify on NodeJS, then it provides sourcemapping automatically. You can check it out. It would make sense if TW-Uglify can do the same with these external cores, and I’d be happy to look into it sometimes soon if y’all think you’d make use of it. Though I would like to know if there’d be interest. It sounds like this recent mishap with Uglify and 5.3.2 has turned this group off of using Uglify, which I’d understand.
(Sorry about that, everyone!)
1 Like
Thanks for the explanation, I would however expect you don’t even need source mapping if you don’t uglify, but surely any tools could use a pretty source as well?
I would however expect you don’t even need source mapping if you don’t uglify
That is true, and I understand if you guys drop it. Though I am sad that Uglify disappointed you all enough to not bother with it anymore.
External-core wiki is an option, not on by default, but available as part of the interface for generating a new wiki at tiddlyhost.
On the contrary! I think it’s very useful! My suggestion is simply that for the external core used at tiddlyhost, the benefit of shrinking the code is minimal (because it’s download-once, read-many). I think there are instances where uglify can really cut down on both server and download burdens.
The suggestion that it be not on (especially for the external core) by default was simply an upshot of frustration over how long it took to troubleshoot the issue in this thread. Perhaps something like sourcemapping actually can avoid that frustration. I don’t know enough to understand whether — when you say it’s “not perfect” — it’s good enough to conveniently enable people to read what they need to from the source.
1 Like
Not at all, it is critical to have such options, its particularly good to help those with older computers and not very good internet. Apparently in India and other places a lot of USB drives are exchanged packed with software and media people have difficulty accessing. Similarly its great to add to Rasbery Pi’s and other small computers and devices.
- Just because I have broadband and a 32GB multi-core processor on SSD does not mean others do.
See the discussion about Editions, it would be great to add a minified core editions of empty.html to the set.
1 Like
For those of you who are interested. Just dropping a message here to let you all know that Uglify can now sourcemap with external-js setups, and even tiddlywiki files. It generates a directory of sourcemaps and original sources beside your files.
I’m not super familiar with TiddlyHost, but if you guys were interested, Uglify and its sourcemapping should be able to work with it now. Up to you all. I just released a new topic discussing the most recent Uglify improvements.
1 Like