I fear the discussion has slightly been sidetracked into gnarly technical considerations, but it’s hard not to take the bait!
Personally, it’s pretty clear that PWAs are not a universal panacea for TiddlyWiki. Everything about them is designed to work as a cache for an online service, with some limited and crazy support for going offline. So they could have a role with an online TW5 service like Xememex, but don’t help the single file configuration. As I have to say regularly, there’s no way on earth I would commit anything important to browser local storage, nor could I in all good conscience recommend it to anyone else. I don’t think the heart of it is even a technology problem. It’s a much deeper philosophical question. In the deepest possible sense, TiddlyWiki is the way that it is because of the context in which it was built and used. It is designed from the ground up as an open source application trying to accommodate the needs of hundreds of thousands of diverse users. Almost every decision I’ve ever taken about TiddlyWiki’s development would have been completely different had I been working on a commercial shrink wrapped product. What I’m trying to say is that the technology and the business model of TiddlyWiki are intimately intertwined. Change the business model too much and suddenly many of those technology choices become liabilities. For example, TiddlyWiki allows deep customisation by end users, down to adding new JavaScript modules. The only way to get that level of customisation on a commercial service would be to buy a low level service like a virtual machine, and run something like TiddlyWiki within it. For a business model like, say, Evernote’s it is completely impractical to offer that level of customisation while taking care of security and keeping support costs reasonable. I can and do imagine building a shrink wrapped, mass-market product that did what TiddlyWiki does, but I’m pretty confident that it’s not possible to turn TiddlyWiki 5 into that product in any direct way. So, that’s why I’m so keen to focus on the opportunities presented by the architecture we have now, and the investments we’ve made in it to date. In particular, TiddlyWiki 5 has shown how people who are not conventional software developers can create intricate custom applications that meet the needs of arbitrarily specific niches. Best wishes Jeremy > On 6 Jul 2019, at 05:48, Jed Carty <[email protected]> wrote: > > I am a bit lost about what we would gain by adding the parts of a progressive > web app as defined on wikipedia to what already exists with tiddlywiki. > > Progressive enhancement doesn't fit very well with tiddlywiki as the > framework for the wiki has to be loaded before content can be displayed, > responsiveness is already part of tiddlywiki even if it could be improved, > tiddlywiki has always been connectivity independent, in fact adding service > workers would make it more complex and I don't see what they would add > applike is already true, fresh is a concept that assumes that there is a > remote server providing updates and doesn't really apply to tiddlywiki > Tiddlywiki is independent of the mechanism used to read it, so the safe > component is part of the server used and you can't set https as a universal > component of tiddlywiki, and it has no real meaning when you are using a > local file > Discoverable doesn't have much meaning for a local application like tiddlywiki > Re-engagable is something that will result in a rather long rant from me > about the relationship between people and technology and privacy. The short > bit is that in my opinion push notifications are one of the worst parts of > the current iteration of the internet. Also tiddlywiki doesn't have events > that would use push notifications without some significant changes and a > server implementation beyond what currently exists. > Installable already fits > linkable doesn't have meaning if it is a local file, otherwise it is already > true. > > So everything in that list is either already part of tiddlywiki or doesn't > apply to tiddlywiki as the core wiki. I don't know what benefit we would be > getting by adopting 're-engagable' as part of the core with push > notifications other than me forking the project to remove push notifications. > The same for service workers, there is no reason to make tiddlywiki dependent > on a remote server and that would just put limits on it. > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/tiddlywiki > <https://groups.google.com/group/tiddlywiki>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/00c864c9-185a-40a1-9613-6e3860034e46%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywiki/00c864c9-185a-40a1-9613-6e3860034e46%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/627E2173-EE23-473A-B554-DC5F2454BBAE%40gmail.com. For more options, visit https://groups.google.com/d/optout.
