This week Microsoft released a Web based version of Visual Studio Code which needs zero installation but lets you to create/edit files locally! It allows you to access to your local file system!
See:
Also:
My question is:
Q1. Does this news give a good signal that we can have a similar saving mechanism for Tiddlywiki?
Q2. For those use VS Code for Tiddlywiki+Node.JS (and perhaps @joshuafontany TW syntax highlighting) is this new release facilitate the development of Tiddlywiki tools?
It uses the File System API, Chrome and Edge only at present.
Thanks Saq!
I read saving and sharing here: Please see also here:
Visual Studio Code for the Web but no details on technical.
If so, I think one of developer has already prepared prototype for Tiddlywiki + File System API!
Wow. This is great! I just tried opening my files from github through vscode.dev. When commit a change, it goes to github directly (without having to push). This is really cool.
What would be interesting to explore is if this in any way would make it easier for users to create documentations PRs.
I don’t think so:
This project uses git-subtree to sync with TiddlyWiki 5 as described in Git subtree: the alternative to Git submodule | Atlassian Git Tutorial.
LogSeq https://logseq.com uses this API.
It is only available over HTTPS — so doesn’t work in file:// contexts I believe. LogSeq uses it with Electron for local usage, OR when hosted on a secure server.
As Saq said, it is Chrome only (Edge is based on Chrome). The API has been available for a while, I think August of 2019 is when it was first available in beta https://web.dev/file-system-access/
70% of the market share is chrome-based, so not much of a limitation. Edge, Vivaldi, Brave – all the “alternatives” are chromium. The only other major player is Safari, which AFAIK is Mac only. FF is now down to 4%. I expect it will eventually go below 2%.
Jeremy tries hard to make TiddlyWiki work with IE, which isn’t even listed anymore and 30% market-share is “not much of a limitation”. … Hmmm ?!
See: https://gs.statcounter.com/browser-market-share … Browser usage is varying a lot if you look at the different continents and even countries.
Safari holds close to 20% with a release cycle of 1/2 a year or longer and not 4 or 6 weeks as other browsers. So that is a problem from my point of view.
It’s about the availability of new features.
WebKit (the web-engine Safari uses) is known to delay new functions for years. eg: WebP image format. AV1 open video format and AFIV open image format not even in sight.
I’m in favour of discussing to drop IE support. … It will be fun to discuss to drop Safari too 
It’s not much of a limitation because there are other (possibly less convenient) ways to save with those other browsers. And, at the moment, everyone has to scrounge for their own save mechanism. Having a save mechanism that worked on 70% of desktops automatically would be a substantial improvement over the current situation.
More importantly, it’s a browser that everyone has access to, and probably comes installed by default on 90% of desktops. Which means you don’t have to beg your boss or the IT department to let you install it on your work desktop.
If things work out with chromium, then maybe the remaining browsers will adopt the technology as well.
Actually, since I don’t have a Mac I don’t know how most people save TW on those desktops. Does saving happen automatically, or is some other tool required?
I would be in favour of adding a saver for the File System API to the core. (Eventually we should be able to use it to support wiki folders in the browser too).
The restriction to https:// URIs means that it couldn’t become the universal fallback saver, but it would still be very useful to a large segment of users.
Safari is also the browser on the iPad and iPhone; the default download saver works fine on modern versions.
TiddlyWiki 5 was originally developed to be compatible with Internet Explorer 10 and above, because back in 2012 it still had quite a significant market share. The present position is that we try not to knowingly break backwards compatibility with IE, but we would do so if there was a compelling case.