Sometimes I wonder if instead of struggling with office suites, I'd be better off running VisiCalc in an emulator. Low memory usage, high portability, and you know they're not going to change the UI on you.
It depends upon your needs, but the over simplified answer is: probably not.
I'm not talking about the over all design philosophy behind such old software. It may be better for getting things done in terms of the interface and, as you mentioned, there's high portability. By portability, I assume you mean you can run it on anything that has an emulator for it.
The trouble is how tied to the hardware it was. For example: 80 column mode was limited to particular video cards, and support didn't include the 80 column support found on later Apple II's. Have extra memory (such as an emulated 128 kB Apple IIe, so again were talking about very common hardware)? Well, you're stuck to the 64 kB (or less) of an Apple II or II+. Given that you have to restart the program to reclaim unused memory, this may be a bigger deal than anticipated.
Such old software is finicky. Even Lotus 1-2-3 on a PC emulator would have its quirks, albeit not to the same extreme.
Author here.
I address data portability in a step-by-step process in the blog post. Long story short, it’s too much hassle while still being imperfect. If data sharing is important, it’s not a good choice. If you’re content to build a little spreadsheet that exists solely within the VisiCalc and VisiClone world, then it might suffice. I suspect the average user has higher baseline expectations than VisiCalc can deliver. You need to really try it out yourself (Dan Bricklin has the 80-column DOS version for free on his site) and see what it lacks firsthand.
I guess whichever has the most parseable format and plays nice with virtual printer drivers. And when sharing a spreadsheet with someone, you can share the entire spreadsheet application software, no incompatibilities :)
There were/are some horrible bugs with Reduce Transparency mode in iOS 26, let's hope this new mode gets added to the fully-tested set of configurations.
Spritemate is built with TypeScript + Vite + JQuery, and has a pretty organized structure: https://github.com/Esshahn/spritemate (I do not condone its use of the 'any' type everywhere tho)
I wouldn't use JQuery for a new project, as you can do almost everything it does with straight DOM manipulation. But there are still some strategic vanilla JS/TS packages that come in handy, e.g. clipboard, mousetrap, file-saver, split.js.
Web Components with Lit is kinda fun, though you'll have to deal with DOM shadow roots or disable them.
I would challenge that using a framework leads to less security. In vanilla JS you've got to use something like dompurify religiously to avoid XSS bugs, and you're tempted by the shiny candy-like innerHTML attribute.
Thanks for the reference! Yep, part of why I made this post is to see how I can avoid the innerHTML attribute. Do you think Obsidian's use of dompurify is closely related to their choice of going vanilla?
Haha, yeah this kind of stuff made HTTP long polling requests over mobile pretty fun. IIRC, we ran HTTP over IMAP and POP3 ports for cases where port 80 was unreliable.
My least favorite animation is in Mobile Safari, when you tap the search bar and it expands and brings up the controls at the bottom. There's a sort of shiny sweep transition from top to bottom, but it's distracting and it's not obvious why it exists. I assume it's to highlight the bottom control bar, but that's just a guess.
I also notice that CarPlay has more contrast now, and not much Liquid Glass. Kinda telling.
My VanillaTS project has been working well for the last six years. The most painful part was when I moved everything to esbuild w/ async imports (and ES2017 modules) but now I don't even think about it. npm audit gets kinda mad though.
On the Vectrex you could only draw lines between 256 x 256 grid points, so in theory 800 x 600 with antialiasing would be enough. But dunno if it would have the same contrast, OLED is as good as you can get I guess.
On a tiny screen like that, I suspect 800x600 is probably high enough DPI to fake the lines themselves well enough to the point where the pixels aren't discernable to the eye.
This alone still wouldn't remotely resemble a real vector display...
They would also need to accurately simulate the glow/bloom of the lines, and the phosphor decay rate over time that leads to effects like the "trail" behind the bullets in Asteroids. That is all extremely feasible. In a lot of ways, much easier than emulating a raster CRT display.
However, I have never seen a commercial emulation product do this with any competency.
Presumably because the number of people who would actually care is not large enough to affect the sales figures in any meaningful way.
Not really. One of the advantages of vector displays is the fact that the drawn lines are razor sharp with zero aliasing. Another is the fact that the hardware has very fine control over the brightness, allowing for very bright or very dim lines to be drawn. The bright ones are brighter than could be replicated with raster CRT displays, and combined with slow-decay phosphors made for some beautiful "trail" effects. A pixelated display of any sort can only yield a rough approximation at best.
and combined with slow-decay phosphors made for some beautiful "trail" effects
Thank you. This is such an under-appreciated aspect of vector games' unique look on real hardware.
A pixelated display of any sort can only yield a rough approximation at best.
Why do you feel this way? With sufficient DPI, to me this is fairly easy to achieve. A few examples of emulation that look like they're doing a very good job:
I think they have the bloom dialed up way too high, and maybe the trails aren't prominent enough, but I assume those are easy things to tweak.
Last time I played a well-maintained Asteroids cabinet, bullets had obvious bloom, but I was surprised to not see a trail. There wasn't any noticeable bloom or trails on the other objects. I believe the arcade monitors have fast decay phosphor like in regular TV sets, so any trail would come from persistence of vision, probably due to the brightness of the bullet.
I'm not sure about the Vectrex CRT, it may have longer persistence phosphor.
The Asteroids I've played had a slow-decay phosphor and trails on the bullets (not so much the asteroids, UFOs, etc). If the cabinet you played had its tube replaced with a TV picture tube, its display characteristics may have changed.
The bloom might be all right if they could replicate the intensity. Maybe with an OLED and sufficient HDR color depth, but I'm not seeing that here. It doesn't look like they did much CRT effect processing on the second two. The fireballs in Star Wars should glow the way the bullets in Asteroids do (albeit with quicker phosphor decay so not much in the way of trails).
