13 ms·

Writing an app is like coding for LaserDisc

157 points by edent 4y ago

gumby 4y ago
The BBC laserdisc project mentioned in passing was actually modeled on the “Aspen Project” by Bob Mohl in the late 70s at the MIT ARCMAC, predecessor to the Media Lab. You could navigate in “street view” around Aspen, Colorado and yes it used video disks.
oneplane 4y ago
Ironically, the whole argument can be summarised and partially dismissed from one of its lines: > requirements have evolved.
- amadeuspagel 4y ago
  > app store requirements have evolved
  - oneplane 4y ago
    Yes, but the App Store part wasn't relevant to what has changed in the world. The world around technology has changed. Not just on apps, iOS, AppStores or Laserdiscs. The referred tweet aged like milk since this is neither app-specific nor phone-specific, and hasn't gotten any viable alternatives either.
daviddever23box 4y ago
If one doesn't maintain one's app, it won't matter what platform/target was used; it will eventually cease to function. This is why there is great benefit to adding a layer of abstraction underneath that someone else can maintain; all that is required is that the app be re-deployed with the latest upgrades and fixes.
- dagw 4y ago
  it will eventually cease to function. Sure, but there is a difference between "eventually" being 3 years or 30.
  - daviddever23box 4y ago
    The 30y scenario is pretty unlikely with zero maintenance.
    - mrguyorama 4y ago
      If you build your apps to the API as written, this is table stakes in the windows world.
- hedora 4y ago
  My dosbox installation respectfully disagrees.
m_eiman 4y ago
Yes, an app is to be treated as a disposable thing with a shelf life of a few years at best. But on the other hand, so are many "advanced" web apps that rely on vendor-specific implementations of specs that may or may not survive (not to mention HTTPS, certificates and their significance to browser behavior…). If you want something to live, be prepared to keep it up to date with the platform it's running on - regardless of what platform that is. The most stable platform to target is likely Win32, specially with Wine. I'd expect a simple HTML static document to continue working mostly as intended for a long time, but anything interactive and/or advanced is likely to bit rot IMHO.
- hddherman 4y ago
  > Yes, an app is to be treated as a disposable thing with a shelf life of a few years at best. The part that worries me is that a lot of physical items can only be configured via apps. That's effectively limiting the useful life of those as well, even if the hardware itself lasts for much longer.
  - m_eiman 4y ago
    Even worse are the ones that rely on a cloud service somewhere, even keeping an old device around won’t help you there…
  - whatarethembits 4y ago
    Hence, only buy hardware products that retain full functionality without a companion app, where applicable. Although the trend it clearly in the direction of locking everything down with software unfortunately.
- deleted 4y ago
  [deleted]
deleted 4y ago
[deleted]
siggen 4y ago
Also amusing is that things I wrote for win32 in 2000 still run now on Windows 11.
- jeroenhd 4y ago
  You might be able to make your application "modern" through something like http://www.boxedwine.org/ http://www.boxedwine.org/ to run it in the browser ;)
- actionfromafar 4y ago
  And Wine.
- ChrisLTD 4y ago
  Good point. Windows, Linux, and the web don’t suffer the kind of software churn we see on Apple platforms.
  - fortran77 4y ago
    Actually, Linux does, too.
  - dagw 4y ago
    Linux is every bit as bad on this front, especially when it comes to GUI apps. The only reason it isn't completely obvious is that most apps are recompiled from source for every version update of every distro out there.
    - TuringTest 4y ago
      Being recompiled from source for every distro update is the expected model for Linux software. Why should it be considered "bad"?
      - dagw 4y ago
        Because it leads to the problem described in the article, where an application from just 2-3 years ago won't work on your up to date Linux distro, unless you (or your distro maintainer) have access its source code. However many Linux users seem to consider this a feature.
Aaargh20318 4y ago
"The earliest websites are viewable on modern browsers." The problem with this statement is that a website is not the same thing as an application. The web was designed to publish documents, it was never intended to build applications. Saying that a document from the early web is still viewable while a fully interactive application from the same time is not is a bit disingenuous. As a platform for developing interactive applications the web is simply terrible. There is no good way to develop a UI in HTML/CSS/JS, all attempts to do so rely on layers upon layers of wat are essentially hacks to build something resembling a UI toolkit on top of a document markup language. The result a UI that is unnecessarily complicated and fragile. Laying out and rendering HTML and CSS is incredibly complex compared how traditional UI toolkits do the same task. That complexity comes at a cost, both in development time and in UX.
- danwee 4y ago
  Sure, but the lesson here is to improve the web (or to create some platform for apps, in the same spirit of the web), not to jump into walled gardens.
  - layer8 4y ago
    From a certain perspective the browser is much more of a walled garden than native desktop development.
- ChrisLTD 4y ago
  > The web was designed to publish documents, it was never intended to build applications. But the web has been evolving in that direction with the help of standards bodies and browser vendors since at least the late 1990s.
  - capableweb 4y ago
    > with the help of standards bodies and browser vendors Who are made out of people (developers) building for the web, and users of the web as well. Lets not pretend that these web applications were forced upon us by outside forces.
dcminter 4y ago
Even though I'm on board with the "don't hand your product to someone else's walled garden" message here, this seems like a weird analogy to me. LaserDisc and the web weren't contemporaneous. So what's the web analogue supposed to be in that scenario? Plus, I don't think LaserDisc made many millionaires whereas writing apps for the iPhone clearly did. Anyone who went all-in on iPhone apps in 2011 probably did quite well for themselves.
United857 4y ago
Even in the web world, you're not immune. Good luck finding a browser that supports the latest version of TLS that e.g. your bank requires if you're running an "old" OS.
alin23 4y ago
As a macOS app developer with 5 years of experience, I agree with the "compatibility" and "absurd App Store requirements" arguments. But I still build apps instead of websites, because: 1. I can create experiences which are not possible on the web (e.g. controlling monitor brightness with https://lunar.fyi/ https://lunar.fyi/) 2. I can more easily make money from it (e.g. selling https://lowtechguys.com/rcmd https://lowtechguys.com/rcmd on the App Store was so much easier than integrating a payment/licensing SDK myself) In my view, the web is mostly used for information while apps are mostly created to provide an experience. With PWAs and their new native like features, we might be moving towards closing that gap on mobile in terms of experience. But the "making money" part still remains partly unsolved. It's much harder to sell a PWA than an app on the App Store, and this deters developers from pursuing that approach.
- selfmodruntime 4y ago
  In my experience, the web is perfect when it comes to presenting an interface to a service. If the service or experience exists entirely within your application, a mobile or native app seems to be the only option.
- rks404 4y ago
  completely unrelated but I love rcmd - it is 100% ingrained into my muscle memory at this point. Great work!
  - alin23 4y ago
    Thanks for the love! Always happy to see when my work helps others as well
- intrasight 4y ago
  > But the "making money" part still remains partly unsolved. This is the only thing that concerns me about my current app plans. But here's my current thought process. A PWA would be much easier to use to test the market. Because it's faster to iterate and to deliver on both mobile OSs. Monetization of a social media app comes after you've attracted tens of thousands of users. So two years out if you still have a business, you can invest in native implementations. Money comes either from users or from advertisers or both. I think Apple will direct more developers towards building PWAs because it will reduce their review burden. Why else would they be adding features (notifications, installation) that make PWAs better? Doesn't it make sense therefore that Apple will also add support for monitization?
dagw 4y ago
But a website from the 1990s still works three decades later. Unless they used Applets, or Flash, or ActiveX, or RealPlayer or any of the other dozens of proprietary 'web' technologies that came and went.
- drivers99 4y ago
  All that, and assuming it’s still being hosted! I ran across an old bookmarks file I saved and virtually every link was dead. Or it could be partly dead, with the image hosting only not working for instance.
- pjmlp 4y ago
  Most of them have WebAssembly emulators available.
  - NavinF 4y ago
    AFAIK there are no active projects that implement ActionScript 3.0 so most of the interesting Flash content is dead on the web.
    - pjmlp 4y ago
      https://leaningtech.com/cheerpx-for-flash/ https://leaningtech.com/cheerpx-for-flash/
      - NavinF 4y ago
        > Book A Demo Oof
        pjmlp 4y ago
        If you had spent a couple of minutes actually looking for information, https://leaningtech.com/demo/ https://leaningtech.com/demo/ That book demo is common for the business space they are targeting, as they offer consulting services to port applications to WebAssembly.
ghusto 4y ago
This is by design. The more times you can be made to pay for the same or similar thing, the more money the various stores make. Also, for those saying comparing web pages to applications is unfair because it's more like comparing _content_ to applications; what about the first things you would call "applications" that came out around that time? All that Javascript still works, because each iteration of our JS engines has been backwards compatible.
santimoller66 4y ago
[dead]
Jaruzel 4y ago
Nitpick: the BBCs Doomsday project used a proprietary data format on standard laserdisc medium, which is why they ended up not being able to access the data decades later as the custom hardware to decode it no longer worked. The laserDisc format was a standard format, and working players can still be found for sale on eBay etc. Compared to DVD and VHS, it's true it wasn't a commercial success though.
- jinto36 4y ago
  It wasn't a blow-out-the-doors commercial success, but it was successful enough that players and media were produced for 20+ years. It had broad adoption in Japan, where the random-access functionality was particularly useful for karaoke bars well before DVD and hard-drive based players. Indeed the attempts to turn it into an interactive media platform, such as LaserActive, were rather less successful and much shorter-lived than Laserdisc as a home theater video distribution medium.
  - Jaruzel 4y ago
    Following on from my comment which you replied to, I had over the years at least 50 discs and 2 different players. I loved the format, it was a good middle ground before DVDs finally took over the world. By importing Japanese discs, you could also get Dolby digital 5.1 sound. I even managed to get Phantom Menace on LaserDisc within a couple of weeks of the UK theatre premiere!
- sgarland 4y ago
  Also, if you're interested, there is a robust community around re-creating the Domesday project with modern hardware [0], as well as capturing LDs via the player's raw RF output, using both bespoke hardware [1] and off-the-shelf [2], then decoding the output in software [3]. [0]: https://www.domesday86.com https://www.domesday86.com [1]: https://github.com/simoninns/DomesdayDuplicator/wiki https://github.com/simoninns/DomesdayDuplicator/wiki [2]: https://github.com/happycube/cxadc-linux3 https://github.com/happycube/cxadc-linux3 [3]: https://github.com/happycube/ld-decode https://github.com/happycube/ld-decode
projektfu 4y ago
Apple's approach changed drastically over the years. Back in the 90s they were discouraging people from making apps that expected a screen size larger than 512x342 and color, because a lot of the installed base still had the equivalent of a mac plus. Your app was supposed to start with the basic functionality and ask the system if it supported more using the Gestalt manager. Then, finally, Open Transport made lots of machines obsolete and eventually 68k was gone altogether. Newer apps could assume 256 colors and at least 640x480. When they released Carbon, they were putting the handwriting on the wall for old apps. You will be left behind. Mac OS X frequently obsoleted old apps. Newer machines couldn't run your app, newer OS had different quirks and incompatibilities. New apps frequently obsoleted older machines and systems, just because. XCode made it somewhat less easy to code to an older standard, and if you did, it might not work in the newest system. Apple also had their writers chasing the latest and greatest look. Finished your glassy and lickable interface? iTunes is now brushed metal, you look so 2003. Got your icons' perspective looking like you're staring at the desktop? They're flat now, get with 2007. I think mac users have been happy so long as the actual machines last about 8-10 years before becoming obsolete, which they generally do. Phone users can make do with 4-6. But if you want to take an old app and run it, good luck. Apps are no longer finished products, ever. They adapt to the platform or die. * dates are approximate
- vinay_ys 4y ago
  > I think mac users have been happy so long as the actual machines last about 8-10 years before becoming obsolete, which they generally do. Phone users can make do with 4-6. This is exactly right. My MacBook Pro from 2013 is still running fine and all the day-to-day productivity apps I have been using still work just fine. 90% of things I do are via a web browser, so there's that. I might buy a new M2 based MBP this December, depending on what they release in September/October. Same is true for iPhone. iPhone 7 lasted till iPhone 12. I'll likely replace iPhone 12 only with iPhone 17 or so (likely when 5G is being replaced with 6G).
  - klooney 4y ago
    Isn't browsing the web painfully slow on that machine?
grishka 4y ago
Actually, Android is very good at maintaining backwards compatibility. You can, in fact, install a 10-year-old apk on your shiny new Galaxy S22 and it will run. The one problem you'll run into is that apps of that era expect a hardware "menu" button, which modern versions of SystemUI no longer provide.
- jeroenhd 4y ago
  I don't know about Samsung but on many phones you can add the menu button back to the button bar if you don't use gestures to control the phone. On my phone you can even have a floating button that opens a radial menu to provide access to things like a home/back/menu shortcut menu.
abra0 4y ago
>The same is true of most modern smartphones. If you wrote an app for an early version of iOS or Android, it simply won't run on modern hardware or software. APIs have changed, SDKs weren't designed with forward compatibility, and app store requirements have evolved. I wrote a simple niche app for Android a decade ago, when I got my first Android phone, just to play around: https://play.google.com/store/apps/details?id=com.abragame https://play.google.com/store/apps/details?id=com.abragame Forward compatibility is not perfect, it got taken down a few times for compliance reasons (I think I had to fill out a form on whether my app was intended to be primarily used by kids?) Still, it runs on modern devices with modern OS versions without a hitch. (Much faster than it used to on my HTC Hero in 2012). If you wanted to bemoan mobile functionality degradation, I'd aim at dependencies on communication with proprietary servers, which various companies don't feel obliged to keep around for long.
- cesarb 4y ago
  > I wrote a simple niche app for Android a decade ago [...] it got taken down a few times for compliance reasons And AFAIK, it's going to get taken down again, since IIRC Google is soon going to remove apps from its store unless they release a new version every couple of years at most, updated to match Google's new requirements.
stutsmansoft 4y ago
What I've been hearing is companies going mobile first and only adding web later to support a broader demographic. Anyone able to confirm/disconfirm that?
- jamil7 4y ago
  Yeah it's fairly common, especially for B2C.
gnufx 4y ago
Note that criticism of the BBC Domesday Project as short-sighted for using LaserDisc is mis-placed. It's worth reading https://catless.ncl.ac.uk/Risks/25.44.html#subj7 https://catless.ncl.ac.uk/Risks/25.44.html#subj7 (Some of Prof. Newby's career subsequent to overseeing the original loss of the Domesday data was sufficiently interesting to appear in Private Eye, for instance.)
teawrecks 4y ago
The only web stuff I've made in my software career don't work anymore because of JavaScript/browser changes. And those broke within a year or two of me making them. So I can't identify with the author's sentiment.
draw_down 4y ago
c7b 4y ago
Software depreciation is one thing, skills depreciation is another. The iOS dev had to update their app several times since 2011, but how often did they have to update their tech stack vs a web dev? Genuine question, I'm all for writing web apps and keeping the web open (I actually asked a question about how to get into web dev today [0], feedback very much appreciated :)), but from the outside it seems dizzying how fast frameworks and even languages change in this space. [0] https://news.ycombinator.com/item?id=32724950 https://news.ycombinator.com/item?id=32724950
- cxr 4y ago
  Web devs don't have to update their tech stack. That's something they sign up for. If your impression is that you should build with "Next.js/React, Tailwind and TypeScript" because you expect that they "will be state of the art at least for a while", then you risk being massively disappointed, because you're signing yourself up for the same thing. The state of the art does not have a good record wrt longevity. Don't reach for a framework without first understanding the Web platform's primitives (ideally trying to do what you want that way first) and then figuring out what exactly the framework is actually supposed to do for you and why you're choosing it, besides that you just heard that's what lots of other people are doing. Lots of other people do lots of very dumb and counterproductive things. > "[The Web] is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release." <https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...>
  - c7b 4y ago
    Thanks for the feedback! > Don't reach for a framework without first understanding the Web platform's primitives Can you elaborate on that - what are concrete topics you suggest learning first? I actually did a few Cisco Networking Academy semesters, in a different life, but that was about OSI layers, computing IPv4 subnet masks,... it really feels like there's a missing link between that stuff and the knowledge I'd need to make an informed choice between Next.js and Vue.js (or any of the half-dozen other tool choices I have to make) for my app idea.
jonathanstrange 4y ago
That's why I gave up supporting MacOS entirely and forever. Since the end of the 90s my application had almost only "bugs" due to Apple's API changes - practically no problem was caused by me and I still had to constantly test on new OS versions, make changes here or there, etc. It's just not worth the effort.
revskill 4y ago
Because backward compatability is an unsolved problem.
- moogly 4y ago
  I'm not sure Microsoft agrees with that statement.
StevePerkins 4y ago
1. Average consumers are not going to install your PWA. I am sorry. Get over it. Geeks and power users maybe, but for the average consumer if you're not in the App Store and Google Play then you don't exist. All further discussion is academic/hobbyist. 2. Even as a developer, I reasonably expect to migrate or re-write an app after 5 to 10 years. If I wanted to work on mainframe or AS/400 systems, then I would do that. But not trying to maintain a mobile app for 30 years without any significant evolution is a feature, not a bug. 3. Even if I did crave multi-decade stability, I would feel no envy toward SPA web frameworks on this front.
- isatty 4y ago
  Even as a power user I dislike PWAs. Give me a native app that is buttery smooth instead of 200m of JavaScript.
  - polshaw 4y ago
    You don't get that choice. Except for the biggest apps/companies, economics dictates that you'll probably get a packaged webapp as the alternative. With more tracking etc, less accessibility, and a little more drive space.
  - deleted 4y ago
    [deleted]
  - miniBill 4y ago
    How about 1.2Mb of JS?
- lostgame 4y ago
  Does anyone want to install a PWA over a native app? Genuinely curious. Still wondering what the purpose of PWA’s existing is.
  - spiffytech 4y ago
    I will for some things. I have a couple web apps I visit throughout the day and it's nice to have a shortcut on my homescreen, and to not have the address bar taking up space. Speaking from a technical perspective, adding a PWA to the home screen is useful for recognizing user intent to have a richer experience with an app. Push notifications, adding an app to the share sheet, etc. - things you don't want just any website to do, but might want to permit for a privileged site.
samsquire 4y ago
This is an interesting post, thank you for writing it. There's some things that just last, such as BSD sockets which I've mentioned a number of times on my journal and Unix POSIX APIs and Win32 APIs as mentioned by someone on this post https://news.ycombinator.com/item?id=32725209 https://news.ycombinator.com/item?id=32725209 Some of my ruby, nodejs and python projects no longer run due to dependencies not being pinned at creation time. My living systems document editor is written in AngularJs 1 and I eventually got it running at one point on my new laptop (it was built on a mac) but unfortunately I've not reproduced the setup due to problems with Ruby, nodejs and python dependencies. My JSBin (an editor for HTML, CSS and Javascript) installation has moved machines and I never set it up a third time, so my data is effectively lost without randomly trying different versions to see if it works. And trying to avoid having to run migration scripts for the data. In theory the CSS, javascript and HTML are all available in the SQLite database, so I could write a script to extract them all. But some of the jsbins had server side components. I want software to just work and last for a long time. This requires thinking. Most software is written in an ad hoc or agile or waterfall approach. Unless long term compatibility is seen as a requirement, then the software shall not be runnable for a long period of time. When I go to use some software it takes an inordinate amount of time to set things up. Nowadays we have Docker, but that didn't always exist.
ralmidani 4y ago
One possible solution to this problem is the Free, Open Source Software community continuing to work toward more sophisticated tech that can bridge the gap between popular server-side languages for Web Dev and native platforms. PhoneGap was a failure because it was JS running on the phone, rather than compiling to something faster and with a more “native feel”. React Native is, IMHO, not that much better (and the React ecosystem has ridiculous fragmentation and churn). Flutter seems cool, but Dart is not a popular server-side language (and from what I heard anecdotally, Flutter also has API complexity and churn). Personally, I think Elixir is a natural choice for this kind of task (disclosure: I am incredibly biased in my love for Elixir). Macro-based DSLs are not beloved by all, but they can take you pretty far with minimal overhead, since you can theoretically target multiple platforms without even having to ship a custom runtime to the phone. Aside from the language itself, there is a great community, less fragmentation and churn, and a tendency to build thoughtful, robust libraries and frameworks with good docs. For inspiration, take a look at Mitch Hanberg’s Temple project[0] which compiles valid Elixir code to something that eventually gets turned into HTML. DockYard is also doing really cool, bleeding edge stuff with LiveView Native[1], even if it’s a bit early to predict how viable it will be for large, complex apps. If we can have a way to build efficient, truly native apps for multiple platforms using a stable, expressive API, a lot of the heartache associated with mobile development might fade away. [0] https://github.com/mhanberg/temple https://github.com/mhanberg/temple [1] https://dockyard.com/blog/2022/09/01/dockyard-r-d-build-elixir-web-native-apps-seamlessly-with-liveview-native https://dockyard.com/blog/2022/09/01/dockyard-r-d-build-elix...
rektide 4y ago
There's a remarkable irony isln that there is such a sizable vocal camp that feels like malleability & focus on good low-level primitives for the web (see: Extensible Web Manifesto) is the weakness, that it takes native tool build good experiences. The lovely point here is that change keeps happening, is everywhere. The fancy good stuff today becomes a bad fit for what happens next, stops being a strength & becomes a limit. What is so cherishable about the web, it's enduring quality, is that it's still a pretty good pretty flexible model. It's low level model, without a ton of opinions, that we can compose higher order systems out of. (Just by making some new elements, ideally, in many cases, although issues like front end data stores & routers sometimes/often end up as orthogonal concerns, not integrated into the document as a (tree) set of resources (elements). But they can be: react-router for ex shows using the page computation. Flexibility & low-level capability arent the be-all, but the lack of commitment to specifics has allowed the web to keep going. The web as a system of opinions doesnt meed a lot to say for itself; the page is both structure, and, if we choose, the mechanism and machine too (again vsible in react-router, or works like Use.GPU's Live environment).
michaelwww 4y ago
I always thought apps were introduced because website weren't designed with "touch" in mind and still aren't for the most part. When you take away the mouse you need something to replace it that works just as naturally.

157 points by edent 4y ago

The BBC laserdisc project mentioned in passing was actually modeled on the “Aspen Project” by Bob Mohl in the late 70s at the MIT ARCMAC, predecessor to the Media Lab. You could navigate in “street view” around Aspen, Colorado and yes it used video disks.

oneplane 4y ago

Ironically, the whole argument can be summarised and partially dismissed from one of its lines: > requirements have evolved.

amadeuspagel 4y ago
> app store requirements have evolved
- oneplane 4y ago
  Yes, but the App Store part wasn't relevant to what has changed in the world. The world around technology has changed. Not just on apps, iOS, AppStores or Laserdiscs. The referred tweet aged like milk since this is neither app-specific nor phone-specific, and hasn't gotten any viable alternatives either.

daviddever23box 4y ago

If one doesn't maintain one's app, it won't matter what platform/target was used; it will eventually cease to function. This is why there is great benefit to adding a layer of abstraction underneath that someone else can maintain; all that is required is that the app be re-deployed with the latest upgrades and fixes.

dagw 4y ago
it will eventually cease to function. Sure, but there is a difference between "eventually" being 3 years or 30.
- daviddever23box 4y ago
  The 30y scenario is pretty unlikely with zero maintenance.
  - mrguyorama 4y ago
    If you build your apps to the API as written, this is table stakes in the windows world.
hedora 4y ago
My dosbox installation respectfully disagrees.

m_eiman 4y ago

Yes, an app is to be treated as a disposable thing with a shelf life of a few years at best. But on the other hand, so are many "advanced" web apps that rely on vendor-specific implementations of specs that may or may not survive (not to mention HTTPS, certificates and their significance to browser behavior…). If you want something to live, be prepared to keep it up to date with the platform it's running on - regardless of what platform that is. The most stable platform to target is likely Win32, specially with Wine. I'd expect a simple HTML static document to continue working mostly as intended for a long time, but anything interactive and/or advanced is likely to bit rot IMHO.

hddherman 4y ago
> Yes, an app is to be treated as a disposable thing with a shelf life of a few years at best. The part that worries me is that a lot of physical items can only be configured via apps. That's effectively limiting the useful life of those as well, even if the hardware itself lasts for much longer.
- m_eiman 4y ago
  Even worse are the ones that rely on a cloud service somewhere, even keeping an old device around won’t help you there…
- whatarethembits 4y ago
  Hence, only buy hardware products that retain full functionality without a companion app, where applicable. Although the trend it clearly in the direction of locking everything down with software unfortunately.
deleted 4y ago
[deleted]

deleted 4y ago

[deleted]

siggen 4y ago

Also amusing is that things I wrote for win32 in 2000 still run now on Windows 11.

jeroenhd 4y ago
You might be able to make your application "modern" through something like http://www.boxedwine.org/ http://www.boxedwine.org/ to run it in the browser ;)
actionfromafar 4y ago
And Wine.
ChrisLTD 4y ago
Good point. Windows, Linux, and the web don’t suffer the kind of software churn we see on Apple platforms.
- fortran77 4y ago
  Actually, Linux does, too.
- dagw 4y ago
  Linux is every bit as bad on this front, especially when it comes to GUI apps. The only reason it isn't completely obvious is that most apps are recompiled from source for every version update of every distro out there.
  - TuringTest 4y ago
    Being recompiled from source for every distro update is the expected model for Linux software. Why should it be considered "bad"?
    - dagw 4y ago
      Because it leads to the problem described in the article, where an application from just 2-3 years ago won't work on your up to date Linux distro, unless you (or your distro maintainer) have access its source code. However many Linux users seem to consider this a feature.

Aaargh20318 4y ago

"The earliest websites are viewable on modern browsers." The problem with this statement is that a website is not the same thing as an application. The web was designed to publish documents, it was never intended to build applications. Saying that a document from the early web is still viewable while a fully interactive application from the same time is not is a bit disingenuous. As a platform for developing interactive applications the web is simply terrible. There is no good way to develop a UI in HTML/CSS/JS, all attempts to do so rely on layers upon layers of wat are essentially hacks to build something resembling a UI toolkit on top of a document markup language. The result a UI that is unnecessarily complicated and fragile. Laying out and rendering HTML and CSS is incredibly complex compared how traditional UI toolkits do the same task. That complexity comes at a cost, both in development time and in UX.

danwee 4y ago
Sure, but the lesson here is to improve the web (or to create some platform for apps, in the same spirit of the web), not to jump into walled gardens.
- layer8 4y ago
  From a certain perspective the browser is much more of a walled garden than native desktop development.
ChrisLTD 4y ago
> The web was designed to publish documents, it was never intended to build applications. But the web has been evolving in that direction with the help of standards bodies and browser vendors since at least the late 1990s.
- capableweb 4y ago
  > with the help of standards bodies and browser vendors Who are made out of people (developers) building for the web, and users of the web as well. Lets not pretend that these web applications were forced upon us by outside forces.

dcminter 4y ago

Even though I'm on board with the "don't hand your product to someone else's walled garden" message here, this seems like a weird analogy to me. LaserDisc and the web weren't contemporaneous. So what's the web analogue supposed to be in that scenario? Plus, I don't think LaserDisc made many millionaires whereas writing apps for the iPhone clearly did. Anyone who went all-in on iPhone apps in 2011 probably did quite well for themselves.

United857 4y ago

Even in the web world, you're not immune. Good luck finding a browser that supports the latest version of TLS that e.g. your bank requires if you're running an "old" OS.

alin23 4y ago

As a macOS app developer with 5 years of experience, I agree with the "compatibility" and "absurd App Store requirements" arguments. But I still build apps instead of websites, because: 1. I can create experiences which are not possible on the web (e.g. controlling monitor brightness with https://lunar.fyi/ https://lunar.fyi/) 2. I can more easily make money from it (e.g. selling https://lowtechguys.com/rcmd https://lowtechguys.com/rcmd on the App Store was so much easier than integrating a payment/licensing SDK myself) In my view, the web is mostly used for information while apps are mostly created to provide an experience. With PWAs and their new native like features, we might be moving towards closing that gap on mobile in terms of experience. But the "making money" part still remains partly unsolved. It's much harder to sell a PWA than an app on the App Store, and this deters developers from pursuing that approach.

selfmodruntime 4y ago
In my experience, the web is perfect when it comes to presenting an interface to a service. If the service or experience exists entirely within your application, a mobile or native app seems to be the only option.
rks404 4y ago
completely unrelated but I love rcmd - it is 100% ingrained into my muscle memory at this point. Great work!
- alin23 4y ago
  Thanks for the love! Always happy to see when my work helps others as well
intrasight 4y ago
> But the "making money" part still remains partly unsolved. This is the only thing that concerns me about my current app plans. But here's my current thought process. A PWA would be much easier to use to test the market. Because it's faster to iterate and to deliver on both mobile OSs. Monetization of a social media app comes after you've attracted tens of thousands of users. So two years out if you still have a business, you can invest in native implementations. Money comes either from users or from advertisers or both. I think Apple will direct more developers towards building PWAs because it will reduce their review burden. Why else would they be adding features (notifications, installation) that make PWAs better? Doesn't it make sense therefore that Apple will also add support for monitization?

dagw 4y ago

But a website from the 1990s still works three decades later. Unless they used Applets, or Flash, or ActiveX, or RealPlayer or any of the other dozens of proprietary 'web' technologies that came and went.

drivers99 4y ago
All that, and assuming it’s still being hosted! I ran across an old bookmarks file I saved and virtually every link was dead. Or it could be partly dead, with the image hosting only not working for instance.
pjmlp 4y ago
Most of them have WebAssembly emulators available.
- NavinF 4y ago
  AFAIK there are no active projects that implement ActionScript 3.0 so most of the interesting Flash content is dead on the web.
  - pjmlp 4y ago
    https://leaningtech.com/cheerpx-for-flash/ https://leaningtech.com/cheerpx-for-flash/
    - NavinF 4y ago
      > Book A Demo Oof
      - pjmlp 4y ago
        If you had spent a couple of minutes actually looking for information, https://leaningtech.com/demo/ https://leaningtech.com/demo/ That book demo is common for the business space they are targeting, as they offer consulting services to port applications to WebAssembly.

ghusto 4y ago

This is by design. The more times you can be made to pay for the same or similar thing, the more money the various stores make. Also, for those saying comparing web pages to applications is unfair because it's more like comparing _content_ to applications; what about the first things you would call "applications" that came out around that time? All that Javascript still works, because each iteration of our JS engines has been backwards compatible.

santimoller66 4y ago

[dead]

Jaruzel 4y ago

Nitpick: the BBCs Doomsday project used a proprietary data format on standard laserdisc medium, which is why they ended up not being able to access the data decades later as the custom hardware to decode it no longer worked. The laserDisc format was a standard format, and working players can still be found for sale on eBay etc. Compared to DVD and VHS, it's true it wasn't a commercial success though.

jinto36 4y ago
It wasn't a blow-out-the-doors commercial success, but it was successful enough that players and media were produced for 20+ years. It had broad adoption in Japan, where the random-access functionality was particularly useful for karaoke bars well before DVD and hard-drive based players. Indeed the attempts to turn it into an interactive media platform, such as LaserActive, were rather less successful and much shorter-lived than Laserdisc as a home theater video distribution medium.
- Jaruzel 4y ago
  Following on from my comment which you replied to, I had over the years at least 50 discs and 2 different players. I loved the format, it was a good middle ground before DVDs finally took over the world. By importing Japanese discs, you could also get Dolby digital 5.1 sound. I even managed to get Phantom Menace on LaserDisc within a couple of weeks of the UK theatre premiere!
sgarland 4y ago
Also, if you're interested, there is a robust community around re-creating the Domesday project with modern hardware [0], as well as capturing LDs via the player's raw RF output, using both bespoke hardware [1] and off-the-shelf [2], then decoding the output in software [3]. [0]: https://www.domesday86.com https://www.domesday86.com [1]: https://github.com/simoninns/DomesdayDuplicator/wiki https://github.com/simoninns/DomesdayDuplicator/wiki [2]: https://github.com/happycube/cxadc-linux3 https://github.com/happycube/cxadc-linux3 [3]: https://github.com/happycube/ld-decode https://github.com/happycube/ld-decode

projektfu 4y ago

Apple's approach changed drastically over the years. Back in the 90s they were discouraging people from making apps that expected a screen size larger than 512x342 and color, because a lot of the installed base still had the equivalent of a mac plus. Your app was supposed to start with the basic functionality and ask the system if it supported more using the Gestalt manager. Then, finally, Open Transport made lots of machines obsolete and eventually 68k was gone altogether. Newer apps could assume 256 colors and at least 640x480. When they released Carbon, they were putting the handwriting on the wall for old apps. You will be left behind. Mac OS X frequently obsoleted old apps. Newer machines couldn't run your app, newer OS had different quirks and incompatibilities. New apps frequently obsoleted older machines and systems, just because. XCode made it somewhat less easy to code to an older standard, and if you did, it might not work in the newest system. Apple also had their writers chasing the latest and greatest look. Finished your glassy and lickable interface? iTunes is now brushed metal, you look so 2003. Got your icons' perspective looking like you're staring at the desktop? They're flat now, get with 2007. I think mac users have been happy so long as the actual machines last about 8-10 years before becoming obsolete, which they generally do. Phone users can make do with 4-6. But if you want to take an old app and run it, good luck. Apps are no longer finished products, ever. They adapt to the platform or die. * dates are approximate

vinay_ys 4y ago
> I think mac users have been happy so long as the actual machines last about 8-10 years before becoming obsolete, which they generally do. Phone users can make do with 4-6. This is exactly right. My MacBook Pro from 2013 is still running fine and all the day-to-day productivity apps I have been using still work just fine. 90% of things I do are via a web browser, so there's that. I might buy a new M2 based MBP this December, depending on what they release in September/October. Same is true for iPhone. iPhone 7 lasted till iPhone 12. I'll likely replace iPhone 12 only with iPhone 17 or so (likely when 5G is being replaced with 6G).
- klooney 4y ago
  Isn't browsing the web painfully slow on that machine?

grishka 4y ago

Actually, Android is very good at maintaining backwards compatibility. You can, in fact, install a 10-year-old apk on your shiny new Galaxy S22 and it will run. The one problem you'll run into is that apps of that era expect a hardware "menu" button, which modern versions of SystemUI no longer provide.

jeroenhd 4y ago
I don't know about Samsung but on many phones you can add the menu button back to the button bar if you don't use gestures to control the phone. On my phone you can even have a floating button that opens a radial menu to provide access to things like a home/back/menu shortcut menu.

abra0 4y ago

>The same is true of most modern smartphones. If you wrote an app for an early version of iOS or Android, it simply won't run on modern hardware or software. APIs have changed, SDKs weren't designed with forward compatibility, and app store requirements have evolved. I wrote a simple niche app for Android a decade ago, when I got my first Android phone, just to play around: https://play.google.com/store/apps/details?id=com.abragame https://play.google.com/store/apps/details?id=com.abragame Forward compatibility is not perfect, it got taken down a few times for compliance reasons (I think I had to fill out a form on whether my app was intended to be primarily used by kids?) Still, it runs on modern devices with modern OS versions without a hitch. (Much faster than it used to on my HTC Hero in 2012). If you wanted to bemoan mobile functionality degradation, I'd aim at dependencies on communication with proprietary servers, which various companies don't feel obliged to keep around for long.

cesarb 4y ago
> I wrote a simple niche app for Android a decade ago [...] it got taken down a few times for compliance reasons And AFAIK, it's going to get taken down again, since IIRC Google is soon going to remove apps from its store unless they release a new version every couple of years at most, updated to match Google's new requirements.

stutsmansoft 4y ago

What I've been hearing is companies going mobile first and only adding web later to support a broader demographic. Anyone able to confirm/disconfirm that?

jamil7 4y ago
Yeah it's fairly common, especially for B2C.

gnufx 4y ago

Note that criticism of the BBC Domesday Project as short-sighted for using LaserDisc is mis-placed. It's worth reading https://catless.ncl.ac.uk/Risks/25.44.html#subj7 https://catless.ncl.ac.uk/Risks/25.44.html#subj7 (Some of Prof. Newby's career subsequent to overseeing the original loss of the Domesday data was sufficiently interesting to appear in Private Eye, for instance.)

teawrecks 4y ago

The only web stuff I've made in my software career don't work anymore because of JavaScript/browser changes. And those broke within a year or two of me making them. So I can't identify with the author's sentiment.

draw_down 4y ago

c7b 4y ago

Software depreciation is one thing, skills depreciation is another. The iOS dev had to update their app several times since 2011, but how often did they have to update their tech stack vs a web dev? Genuine question, I'm all for writing web apps and keeping the web open (I actually asked a question about how to get into web dev today [0], feedback very much appreciated :)), but from the outside it seems dizzying how fast frameworks and even languages change in this space. [0] https://news.ycombinator.com/item?id=32724950 https://news.ycombinator.com/item?id=32724950

cxr 4y ago
Web devs don't have to update their tech stack. That's something they sign up for. If your impression is that you should build with "Next.js/React, Tailwind and TypeScript" because you expect that they "will be state of the art at least for a while", then you risk being massively disappointed, because you're signing yourself up for the same thing. The state of the art does not have a good record wrt longevity. Don't reach for a framework without first understanding the Web platform's primitives (ideally trying to do what you want that way first) and then figuring out what exactly the framework is actually supposed to do for you and why you're choosing it, besides that you just heard that's what lots of other people are doing. Lots of other people do lots of very dumb and counterproductive things. > "[The Web] is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release." <https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...>
- c7b 4y ago
  Thanks for the feedback! > Don't reach for a framework without first understanding the Web platform's primitives Can you elaborate on that - what are concrete topics you suggest learning first? I actually did a few Cisco Networking Academy semesters, in a different life, but that was about OSI layers, computing IPv4 subnet masks,... it really feels like there's a missing link between that stuff and the knowledge I'd need to make an informed choice between Next.js and Vue.js (or any of the half-dozen other tool choices I have to make) for my app idea.

jonathanstrange 4y ago

That's why I gave up supporting MacOS entirely and forever. Since the end of the 90s my application had almost only "bugs" due to Apple's API changes - practically no problem was caused by me and I still had to constantly test on new OS versions, make changes here or there, etc. It's just not worth the effort.

revskill 4y ago

Because backward compatability is an unsolved problem.

moogly 4y ago
I'm not sure Microsoft agrees with that statement.

StevePerkins 4y ago

1. Average consumers are not going to install your PWA. I am sorry. Get over it. Geeks and power users maybe, but for the average consumer if you're not in the App Store and Google Play then you don't exist. All further discussion is academic/hobbyist. 2. Even as a developer, I reasonably expect to migrate or re-write an app after 5 to 10 years. If I wanted to work on mainframe or AS/400 systems, then I would do that. But not trying to maintain a mobile app for 30 years without any significant evolution is a feature, not a bug. 3. Even if I did crave multi-decade stability, I would feel no envy toward SPA web frameworks on this front.

isatty 4y ago
Even as a power user I dislike PWAs. Give me a native app that is buttery smooth instead of 200m of JavaScript.
- polshaw 4y ago
  You don't get that choice. Except for the biggest apps/companies, economics dictates that you'll probably get a packaged webapp as the alternative. With more tracking etc, less accessibility, and a little more drive space.
- deleted 4y ago
  [deleted]
- miniBill 4y ago
  How about 1.2Mb of JS?
lostgame 4y ago
Does anyone want to install a PWA over a native app? Genuinely curious. Still wondering what the purpose of PWA’s existing is.
- spiffytech 4y ago
  I will for some things. I have a couple web apps I visit throughout the day and it's nice to have a shortcut on my homescreen, and to not have the address bar taking up space. Speaking from a technical perspective, adding a PWA to the home screen is useful for recognizing user intent to have a richer experience with an app. Push notifications, adding an app to the share sheet, etc. - things you don't want just any website to do, but might want to permit for a privileged site.

samsquire 4y ago

This is an interesting post, thank you for writing it. There's some things that just last, such as BSD sockets which I've mentioned a number of times on my journal and Unix POSIX APIs and Win32 APIs as mentioned by someone on this post https://news.ycombinator.com/item?id=32725209 https://news.ycombinator.com/item?id=32725209 Some of my ruby, nodejs and python projects no longer run due to dependencies not being pinned at creation time. My living systems document editor is written in AngularJs 1 and I eventually got it running at one point on my new laptop (it was built on a mac) but unfortunately I've not reproduced the setup due to problems with Ruby, nodejs and python dependencies. My JSBin (an editor for HTML, CSS and Javascript) installation has moved machines and I never set it up a third time, so my data is effectively lost without randomly trying different versions to see if it works. And trying to avoid having to run migration scripts for the data. In theory the CSS, javascript and HTML are all available in the SQLite database, so I could write a script to extract them all. But some of the jsbins had server side components. I want software to just work and last for a long time. This requires thinking. Most software is written in an ad hoc or agile or waterfall approach. Unless long term compatibility is seen as a requirement, then the software shall not be runnable for a long period of time. When I go to use some software it takes an inordinate amount of time to set things up. Nowadays we have Docker, but that didn't always exist.

ralmidani 4y ago

One possible solution to this problem is the Free, Open Source Software community continuing to work toward more sophisticated tech that can bridge the gap between popular server-side languages for Web Dev and native platforms. PhoneGap was a failure because it was JS running on the phone, rather than compiling to something faster and with a more “native feel”. React Native is, IMHO, not that much better (and the React ecosystem has ridiculous fragmentation and churn). Flutter seems cool, but Dart is not a popular server-side language (and from what I heard anecdotally, Flutter also has API complexity and churn). Personally, I think Elixir is a natural choice for this kind of task (disclosure: I am incredibly biased in my love for Elixir). Macro-based DSLs are not beloved by all, but they can take you pretty far with minimal overhead, since you can theoretically target multiple platforms without even having to ship a custom runtime to the phone. Aside from the language itself, there is a great community, less fragmentation and churn, and a tendency to build thoughtful, robust libraries and frameworks with good docs. For inspiration, take a look at Mitch Hanberg’s Temple project[0] which compiles valid Elixir code to something that eventually gets turned into HTML. DockYard is also doing really cool, bleeding edge stuff with LiveView Native[1], even if it’s a bit early to predict how viable it will be for large, complex apps. If we can have a way to build efficient, truly native apps for multiple platforms using a stable, expressive API, a lot of the heartache associated with mobile development might fade away. [0] https://github.com/mhanberg/temple https://github.com/mhanberg/temple [1] https://dockyard.com/blog/2022/09/01/dockyard-r-d-build-elixir-web-native-apps-seamlessly-with-liveview-native https://dockyard.com/blog/2022/09/01/dockyard-r-d-build-elix...

rektide 4y ago

There's a remarkable irony isln that there is such a sizable vocal camp that feels like malleability & focus on good low-level primitives for the web (see: Extensible Web Manifesto) is the weakness, that it takes native tool build good experiences. The lovely point here is that change keeps happening, is everywhere. The fancy good stuff today becomes a bad fit for what happens next, stops being a strength & becomes a limit. What is so cherishable about the web, it's enduring quality, is that it's still a pretty good pretty flexible model. It's low level model, without a ton of opinions, that we can compose higher order systems out of. (Just by making some new elements, ideally, in many cases, although issues like front end data stores & routers sometimes/often end up as orthogonal concerns, not integrated into the document as a (tree) set of resources (elements). But they can be: react-router for ex shows using the page computation. Flexibility & low-level capability arent the be-all, but the lack of commitment to specifics has allowed the web to keep going. The web as a system of opinions doesnt meed a lot to say for itself; the page is both structure, and, if we choose, the mechanism and machine too (again vsible in react-router, or works like Use.GPU's Live environment).

michaelwww 4y ago

I always thought apps were introduced because website weren't designed with "touch" in mind and still aren't for the most part. When you take away the mouse you need something to replace it that works just as naturally.