Bun is a fast JavaScript
test runner|
Develop, test, run, and bundle JavaScript & TypeScript projects—all with Bun. Bun is an all-in-one JavaScript runtime & toolkit designed for speed, complete with a bundler, test runner, and Node.js-compatible package manager.
Wow, never heard of this before. I have been using my own built docker images for tiddlywiki5 on nodejs, so I just went ahead and built a docker image for tiddlywiki5 using bun instead and it seems to run just fine. Performance wise, the bun version seems to take a little longer to load in the browser than the nodejs version, but once loaded it is just as responsive.
The docker image is smaller. My nodejs tiddlywiki5 image is 213MB while the bun tiddlywiki5 image is only 150MB.
That may not have anything to do with bun itself vs nodejs however, as I am using the official node:alpine image for the node version and the official oven/bun:alpine image for the bun version, so perhaps the bun:alpine source image itself has less packages than the node:alpine source image even before tiddlywiki is installed, so the node:alpine image may just have more bloat to begin with, or the full bun install may simply be more efficient and smaller than the nodejs install.
I did notice that the text rendering looks cleaner than the nodejs counterpart. Nodejs uses the V8 engine and bun uses the JavaScriptCore engine, and my wiki just looks better on bun, but I’m not sure why the JavaScript engine would have any effect on the HTML rendering, when that is the job of the browser engine, but maybe there is something I am missing? Or maybe it is all in my head and it doesn’t really look any different LOL
I’ll have to do more testing to see if it is indeed slower than the nodejs version, in which case I would probably stick with nodejs for my tiddlywikis, although I really do like the look of the wiki better on bun (possible placebo warning)
Placebo warning 
Thanks for this terrific reply…
I haven’t tested it yet but it seems like a healthy entrant in the solutions kitchen
Onwards…
I tried it quite some time ago, long enough ago that I completely forgot about it — until now.
That might tell you something about it – or me 
<shrug>
After reading more about bun, it would be interesting take a copy of tiddlywiki and rewrite it with the use of bun’s built in web apis without additional packages, the seamless switching between EMS and CommonJS, etc, and see if it boosts the performance as well as reducing the size of the final build. I think the idea of trimming up tiddlywiki in this way will have a greater effect on the performance I am testing rather than running tiddlywiki in its current form and simply replacing Nodejs for bun on the runtime side alone.
Bun also has SQLite, password and other features built-in, which may or may not be helpful for the performance of the new MWS that also uses SQLite
Node.js or Bun only “serve” the wiki. So they have no influence how your browsers displays the HTML text that is created by the server.
So if you use the same browser nothing should change.
You do not miss anything. The created HTML code should be the same. So there should be no difference.
That’s probably true.
1 Like
Using Bun-specific API, would create a hard coded dependency. So that would be a no-go.
Using EMS or CommonJs will not significantly change the performance of the code execution. It will also not reduce the size of the final build.
TiddlyWiki comes with it’s own bundler. The TW --build command does all the packaging that is necessary to get a working single file wiki.
TW uses the exact same code to run server-side and client-side. Since TW is much older than existing code-bundlers including Bun. They will not be able to handle TW modules atm.
You can not trim the tiddlywiki core code.
Trimming “unused” library code is only possible if you know, which code is not needed. In the TW core all the code is needed. With the TW UI all the code is needed - Even if it would not be used by the core-UI itself. Our users may use it.
So removing elements that are not directly used by the core can not be removed, because this will break the backwards compatibility.
There is only 1 thing, which can be done. The TW core code is “packaged” including all the white-space. So it’s easy to debug every wiki. This whitespace makes the code significantly bigger.
So what’s possible is to “uglify” the code. See: Uglify is even uglier. New features. Sourcemapping extravaganza which can make a single file wiki much smaller.
But that’s it.
This one is interesting, and would be worth to experiment with. The MWS plugin already knows about 2 different SQLite engines. So it should be straight forward to include a 3rd one.
@jeremyruston – Did you test this?
Thanks for the thorough breakdown and explanation. I now have a more in-depth understanding of tiddlywiki itself. Very enlightening. Much appreciated!
1 Like
So one of the new features with Uglify that I don’t think really got noticed is that it can strip features out of core. Right now, the only filter is to strip all server-side modules, and I didn’t elaborate it further because nobody asked. But with just a single tiddler, it could strip out everything from the editing, to the palette swapping, to a whole bunch of other stuff end-users might not use if you’re running a production TiddlyWiki.
If there’s actual interest, I can write up those filters.
2 Likes
I think this may be interesting. Now that you mentioned it, I think I can remember, that you wrote about it. But I did forget about that feature.
I would consider this a feature for extremely experienced users, while standard uglifying can probably be used by everyone, who needs a smaller production file.