What old devices are we trying to support?

#1

Most modern browsers can run on a variety of hardware, and older devices still generally are able to update to the latest version of a browser. Per our current discussions about upgrading to ES 2017, I’m trying to figure out what the oldest browser is that anyone on here knows about that is still active and likely to be used for TiddlyWiki.

I’m basically trying to figure out if any browsers exist on any devices that are so old they can’t be updated to the latest version with all the new JavaScript features, or are we trying to support a scenario that doesn’t match the ecosystem?

So do you have any old browsers you are currently using which the app store is refusing to update to the latest version? And do you have problems on a lot of websites you visit?

#2

Perhaps we could provide two versions: one for most modern browsers and another for older browsers that doesn’t support new features. If we’re always forced to maintain compatibility with old devices, development could be hindered, which would be unfair to other users and new users.

#3

Wouldn’t “another for older browsers” simply be the existing versions of TW that have already been released that are known to support older systems already?

#4

Chromium v109.x should be supported. This is the last version that supports Windows 7 and 8.1. Many people are still using Windows 7 (especially in Chinese).

When I was using Android 5, I once noticed that Chomium (perhaps v95 higher) has dropped support for Android 5. On the Internet I could found that Chromium v125 dropped support for Android 7.

For browsers on macOS I don’t know, we may support macOS Mojave and above.

#5

I don’t know if it’s any good, but there’s a project that maintains chromium going back to XP

This was mildly amusing:

This branch is 5648 commits ahead of, 115986 commits behind chromium/chromium:main

The latest version of Chrome officially on windows 7 is 109.

ES 2017 should be supported on vsn. 109 per this chart

https://caniuse.com/?search=ES2017

#6

Debian Bookworm has Firefox-128.13.0 while the latest release is about 141.0.2.

But in the topic title you’re asking about old devices rather than old browsers, which one exactly is your question of interest? Please elaborate because it may make my answer offtopic if I misunderstand your question.

I brought up Debian Bookworm for a reason, it’s still the stable version, but just for a couple more days when Trixie will get released and becomes the new stable. Bookworm will remain the last Debian stable version with i386 support. And I run it on a device that I think fits into the definition of old hardware, maybe with a slight stretch past that definition :laughing: . To give you an idea, this is its CPU:

# cat /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 6
model		: 8
model name	: mobile AMD Athlon (tm) 1400+
stepping	: 0
microcode	: 0x1
cpu MHz		: 662.580
cache size	: 256 KB
fdiv_bug	: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow 3dnowprefetch vmmcall
bugs		: fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips	: 1325.16
clflush size	: 32
cache_alignment	: 32
address sizes	: 34 bits physical, 32 bits virtual
power management: ts fid vid

Pay attention to the lack of SSE2 support. This makes the repo version of Node.js out of question, because it is compiled with SSE2 support. But surprisingly, it can run X, load Firefox (which was presumably compiled without SSE2 support), albeit one has to be veeeery patient until it loads, and, even more surprisingly, Firefox can then open a quite big (about 10MB, encrypted!) single HTML file TiddlyWiki! I’m not claiming this is a setup for regular daily usage, more like a trivia extreme case, because it is too slow.

To be honest, by lack of support in this scenario I rather understand the lack of non-JavaScript (because see the Node.js issue above) third party command line tools written in a scripting language like Python for performing a set of generic tasks like:

  • convert between single HTML file TiddlyWiki and one-tiddler-per-file directory, which is suitable for both being managed by Node.js on new computers and just for being handled as plain text files using a text editor and a grep-like tool on ancient setups like the above, eventually not even running GUI apps
  • support single HTML file encrypted TiddlyWiki

This means that one could keep almost the whole TiddlyWiki experience of adding/deleting/modifying tiddlers with static content by:

  • exporting the plain text or encrypted single file wiki to one tiddler per file
  • hacking on static tiddlers by treating them as text files, yet keeping the .tid format, search through their content with grep/ag/ripgrep
  • generating the updated plain text or encrypted single file wiki
  • moving it to a new device that can run a modern JavaScript browser for fiddling with tiddlers with dynamic content (containing wikitext code)

Maybe such third party tools exist and I just didn’t invest enough time yet to find them and see if they are usable.

#7

You are right. Browsers can be updated. The question is, if users do update their browsers. Some devices are managed by companies to a certain set of applications, that can not be changed by users.

Also with iOS the browser is locked to the OS. I do not know, which devices can handle which OS and what’s the latest Safari browser that is installed. @jeremyruston may know this one. We did have a discussion about IOS versions and safari, but I can not find it atm.

#8

I found a few sites that offer stats on browser/OS versions. For example this one for macOS has nice interactive graphs. As expected, the data suggests that the majority of people do upgrade to the latest version relatively swiftly.

Something that makes these decisions difficult for us is that TiddlyWiki is a lot of fairly different things at once: from a local note taking tool to a platform for building cloud apps, with a myriad of niche and unique use cases. Decisions like this affect those different constituencies differently

For example, consider the perspective of a user publishing their home page as a TiddlyWiki, say via TiddlyHost or GitHub Pages. If even 0.5% of users have an out of date browser that breaks TiddlyWiki then there is a significant impact: out of 1,000 visitors to my site about 5 users will not be able to access the site. Nobody would use WordPress if it didn’t work for 0.5% of visitors.

1 Like
#10

The question is whether the wikitext syntax is maintained on both branches.

That is whether new wikitext syntax would be backported to the “legacy” branch so that users could use new plugins (if the plugins were written completely in wikitext).

Presumably the code on the legacy branch would run slower, be more bloated, and lag behind the code on the main branch. But it would work in more devices.

#11

I’m not a mac person, but if I’m reading the numbers correctly, Mac is a bit more restrictive.

You need MacOS Sierra to run Safari 11 to run ES 2017.

That cut-off point then is 2016. Your Mac device has to be younger than nine years.

Except these aren’t random people. These are people for whom shopping, banking, and netflixing have already failed. Presumably their expectations have adjusted.

Also, per DDG assistant WP already uses ES 2017.

Not that I’m eager to see a change.

#12

I still use an old tablet with Android 9. Browsers based on the operating system’s webview have increasing difficulty displaying apps like Lemmy or Forgejo, that used to work. Discourse now crashes the browser outright.

By way of contrast, TiddlyWiki 5 used to load and run just fine on my previous, ancient phone with Android 5.1 and 512MB of RAM. That meant a lot to me at the time.

1 Like
#13

System webview should be able to be upgraded by Google Play. I upgraded my system Webview on Android 8 from v8x.x to v130.x by installing an newer apk.

#14

I don’t have a Google account and don’t use the Play Store. My device doesn’t receive any kind of updates anymore, except for the apps in F-Droid. Please don’t ask me to upgrade; that’s the whole point of the question posed by this topic. The eternal upgrade treadmill is vile anyway.

1 Like
#15

@nosycat TiddlyWiki does not try and support devices, rather it supports browsers, primarily to deal with new releases as the browser tend to go through increased lock downs. There maybe a few places where older browsers have trouble with moden tech in TiddlyWiki, however using an older tiddlywiki version or making changes can give tiddlywiki a longer life.

  • It has always being the case if you dont need the features of a tiddlywiki version you can just keep using an old version.
  • You dont need to stay on the upgrade treadmill at least with tiddlywiki
#16

…The title of this topic is literally,

What old devices are we trying to support?

It’s not like I’m asking for TiddlyWiki 5 to keep working on Internet Explorer 6. I gave an honest answer to the initial question.

1 Like
#17

And my Honest Answer it the device is not relavant if it has a browser, the browser is relavant. So if you can get a resonable browser for a given device, it will support that device. Especialy the single file wiki version.

  • Any device beyond a sandstone tablet, may have a browser, or you can find a third party browser that supports tiddlywiki (most will) then your device could be said to be supported.
    • If your device does not have a supported browser you may even be able to package a custom chromium browser yourself.
  • As a team we Try to support various browsers, not even a specific app of that version, but any app with that version.
    • That is we dont try and support devices, we support browser standards.
#18

The problem I see with the idea of backporting any updates to wikitext syntax to a legacy branch is that it’s likely disproportionately harder to develop, and is for an audience that is perhaps orders of magnitude smaller (based on the numbers bandied about in this thread of 0.5%) with the associated “smaller population of folks to test” (and the main testing crowd didn’t pick up the bug in 5.3.7 that was critical enough to warrant 5.3.8!)

#19

You are right, we can not realistically maintain 2 TW versions

#20

But can you realistically support the 0.5% who are using older technology? (Jeremy’s number above).

Because as time goes on, the number of people remaining behind will only increase. While most people upgrade rapidly, the ones who don’t tend to cling to the tech forever. So the trailing curve never completely drops to zero.

#21

That is the question: at what point does the maintenance burden outweigh the needs of those five people in a thousand? It’s important to figure that out, and complicated. Without maintainers, the software falls apart for everybody. Without users, the software might as well not exist. If the answer turns out to be, “going forward we only support browsers released this year”, then so be it. But it shouldn’t be automatic or for the sake of novelty.