TW v5.3.8 currently only uses uses ES5 (2009) JS features, to work with old browsers.
With version v5.4.0 we intend to allow Javascript specification ES2017, which “allows” a lot of newer features. There are some JS features, that would be nice to use, which belong to ES2020, which was ruled out by the veto of Jeremy.
So the real question in this thread is not to use browser spec from 2024. IMO the question is, when to use ES2018, -19 and -20
I suppose such changes won’t break Tiddloid any time soon? I’ve recently had the opportunity to try using TiddlyWiki on a phone much newer than mine and the save time of my biggest encrypted wiki went from almost 30 seconds to like 2-3. Needless to say I’m euphoric (and said state shall persist till autumn 
).
Tiddloid uses the system WebView, which depends on the Android version and whether it receives updates anymore. (And so we go right back to the initial question.) But 10x speed gains are more likely to be from advances in mobile CPUs. Modern devices are being made increasingly faster.
It never drops to zero, but does it drastically change shape? ie, would a “support 9 year ES version but not newer” policy always be 5% left behind?.
It’s a genuine question - I don’t know. My gut feel is that in the short term the shape may change a little with more falling behind, but every now and then you get circumstances that provide extra impetus and pushes some of those that cling to move to something newer afterall. The example that springs to mind is the big shift to universal SSL over the last decade - which in turn makes me wonder if “the expiry of trusted certs built into a device” would make a reasonable metric for support? (it’s imperfect, given browsers can provide their own trusted certs, plus trusted root certs expire at different times, plus discovery of all that info for any given device!)
But Jeremy was suggesting that one-half of 1 percent was too much.
Over time I would expect that whatever the number is (2% ?) that it will grow with time. Because there will continue to be people and companies that hang on to particular technologies. Somewhere out there, someone is using Netscape Navigator.
The author of “What technology wants” says that no technology ever goes completely extinct. He reviewed a Montgomery Wards catalog from 1894. Taking a page about agricultural tools, he found that every single item was still being made and used somewhere (Although maybe quite a few were being used by the Amish).
I just came across a job listing where they still wanted people to know COBOL, which I thought would have been retired after all the Y2K fixes were complete.
I could freshen that up a little.
The specific number is irrelevant to my point though…
…which is that regardless of the number, I only agree with this idea for some short term windows. Not in the long term.
I disagree with that. I think some technologies DO go completely extinct - but that they’re generally not noticed because by the time they do, because (almost by definition) very few people have cared about them for a long time at that point.
Anyway, I don’t think our views overly differ for the question of TW backwards compatibility, I just don’t think “but older and older and older systems still get used” is a good argument, because as (…checks notes) you succinctly put it earlier “These are people for whom shopping, banking, and netflixing have already failed. Presumably their expectations have adjusted.”
Assuming 5.4.0 comes out some time in 2026, then it supporting ES2017 is a 9 year browser compatibility window. Is there any reason not to just call this the compatibility window going forward? ES2018 in TW2027, ES2020 in TW2029, etc? (I’m not suggesting a new TW each year supporting each ES version in turn, just that it seems to provide a good basis to go by. Maybe even round it up to an even decade in the future for extra compatibility safety and memory convenience)
How does that work? Don’t a lot of services (shopping, banking, streaming services) stop working?
How do they manage to keep using the machines?
Though many people have upgraded to Windows 10 and higher, there still exists some people who stick to older OS because the software they’re using still supports it. As far as I know, many Chinese software are still compatible with Windows 7, and some banking websites (like Bank of China) even don’t use HTML5 and require an Internet Explorer ActiveX plugin to work.
If we valued the past more.
Every advancing edition of Windows since XP/'95 has been a locking down.
Why should I upgrade when all my stuff works?
IMO Upgradeitus is an unnecessary disease.
.O'Reilly -- Differences Between NT Server and Workstation Are Minimal
We have found that NTS and NTW have identical kernels; in fact, NT is a single operating system with two modes. Only two registry settings are needed to switch between these two modes in NT 4.0, and only one setting in NT 3.51. This is extremely significant, and calls into question the related legal limitations and costly upgrades that currently face NTW users.
John McClane gif : “Welcome to the party, pal!”
if you think its your stuff
read the TermsOfService! ,
sadly it appears
ppl running the update push server have other ideas
IMO it’s software rather than kernal that matters. Debian, Fedora & Android as well as OpenBSD & NetBSD all uses identical kernals, but they have huge differences.
Pedantically, Debian, Fedora and Android all use a Linux kernel (though not necessarily the identical one), but the BSDs use their own kernel based on an unrelated codebase (afaik OpenBSD and NetBSD (and FreeBSD) keep their own kernel source trees, but based on a common ancestor)
in the case of eg reactos and similar eg ravynos id agree
for plan9 / inferno it matters allot (afaik)
perhaps other metrics play a large part
eg
how you grow your code
.en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
…
this point was more about the possibilities
or lack there of
when marketing obfusticates verifiable details
see also (historically) tobacco-advertising
/os-tangent
…makes me think of
.Project Cecily - a zooming user interface for TiddlyWiki
which reminds me a bit of
which apparently also had a a [zooming user interface] (ZUI)
Windows 7 (retired Jan 2020) – Firefox 115 (last on Windows 7).
NB: this is a machine I will keep until it dies.
I do still use it online sometimes.
TT
Not sure I should create a new topic, so I’ll rather post here.
I have recently learned about https://chawan.net - a TUI browser with some degree of JavaScript support. Is it realistic to expect that at some point TiddlyWiki will work with it? Is it a matter of that browser evolving over time? Asking because I tried a regular single file wiki and an encrypted one - neither worked.
perhaps you need more ram? 
…
neither worked
begging the question
exactly how did they fail ?
(presumably some method to debug/log exists ?..
-edit-
or even we can read about https://git.sr.ht/~bptato/chawan/tree/HEAD/doc/architecture.md what gets crunched before being dumped in their pager implementation;
*ponders* was tail -f the original infinite scroll 
… well i managed to build nim (… then found
Releases · nim-lang/nightlies · GitHub
binary’s !) and chawan & dep’s
it can load a wiki
and displays this
This TiddlyWiki contains the following tiddlers:
then a list of titles from
<!--~~ Static content for Google and browsers without JavaScript ~~-->
<noscript>
<div id="splashArea">
same happens if i disable scripts in gui-browser
so it loads wiki/html but apparently with out scripts
same thing with amd64 Linux
build from .Chawan: 0.3.0
so apparently not just my build failing
…
.GitHub - ferus-web/ferus: A toy web engine written in Nim
apparently builds with same js lib and says
Ferus has some initial JavaScript support. Our JavaScript engine is hovering around 2% of passing tests in Test262, so don’t expect to be able to daily drive Ferus!
and
.https://git.sr.ht/~bptato/chawan/tree/HEAD/item/lib/monoucha0/README.md
mentions
There is an optional
jserrormodule which enables error handling that is generic to Nim and QuickJS using the nim-results library.
)
if you find some info i hope/guess it would end up in
a new topic one way or another
that alone has my interest! My memory is that some version of links/elinks experimented with JS support many years ago, but it didn’t go anywhere, but I’ve always felt there are some JS things that should be able to work in a text browser. If TW is one of them (without awful coding overhead), that’d be amazing
idk ( see updated post above) how functional js support is tbh it appears more aspirational )
im more optimistic about , this sort of thing
.TIP: Loading TiddlyWiki in CGI on an HTTP Server - #5 by tomzheng
for creating plain text output ( from cgi in this case )
it appears chawan has its own take on cgi
which might offer interesting possibilities for intertwingle-ing