Writing an app is like coding for LaserDisc
shkspr.mobi
shkspr.mobi
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.
But the web has been evolving in that direction with the help of standards bodies and browser vendors since at least the late 1990s.
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.
Indeed, though running a Java Applet from 1995 is a lot easier than running an iOS app from 2010. Although browsers haven’t natively supported Applets for a very long time, there are several third-party tools that let you run them as standalone applications. Good luck virtualizing a 10 year old version of iOS to do the same for the old app.
That said, the argument in the OP holds true if we don’t go back in time quite as far. Most JavaScript-based single-page applications from 2010 should still run flawlessly in modern browsers.
Applets weren’t even easy to run in 1995.
Out of nostalgia I downloaded the Amazon App Store to my phone last month and found that not only were most of my favorite apps not in my library anymore, but that the few left over were built for a version of Android so old that it is no longer compatible with my phone. It was a very sad moment for me, as I had a lot of fun with those games
Previously:
If they're purely client-side, sure, but there's a good chance that anything we could reasonably call a web application, also has a backend component on a server. How confident are we that the backend code from 1995 will still run?
1995 is when Microsoft Frontpage launched. PHP was a year old. I'd be surprised if anything written in those sorts of environments still functions without being run on a 1995 version of Windows/Linux on 1995 era hardware.
Software is a process, it always has been, it always will be.
This seems like it would apply equally to native and web.
You can render a web page from 1995 but you can’t run any server-side logic if you don’t have a copy of the server.
Isn't this an Apple thing? Seems like you should still be able to find and run old Android VMs. They ship with the SDK unless they retroactively pulled them.
The irony that the Web needs to keep copying native development experience, and it is still miles behind of what VB and Delphi were offering 30 years ago, unless one is paying for stuff like OutSystems or PowerApps.
Also the UI designer experience for WPF is much worse than it used to be with WinForms - so bad I just wrote the code manually, and at that point I can just write HTML/CSS. But perhaps they fixed that - I left .NET in 2015.
It doesn't run in the browser anyways - and the browser is what my customers want, because everyone has a browser, but not everyone has Windows desktop - especially today, when many people don't even own a PC and use something with Android/iOS as their primary computing device.
The only reason I went back to cloud and Web development, is that pre-covid it was the best way to get 100% remote jobs, so I put up with it.
By the way, most of those iOS/Android users are using apps and not Websites.
.NET is dead to me, I simply don't trust the platform/libraries to continue existence and receive updates. Also the JS/NPM ecosystem is much larger and that's truly what's keeping me there.
But yeah, having such a nice GUI designer would be awesome - I miss Delphi a lot, and the WinForms designer was good too. Now finally Flexbox/Grid have support on all major browsers so perhaps we could get this part of the workflow back.
Phones - for sure, that's a modern development. But it's been more than a decade now, there are adult people who don't remember world without iPhones and Androids! Crazy... Myself, I started on Windows 98, but it's Windows XP (and Delphi) that defines my childhood.
This is exactly how I would summarize it too. Before we had grid, I would be forced to agree with the original comment.
Now that we have these things, thick CSS/JS frameworks like Bootstrap aren't really a big deal anymore. 95% of the reason I used this stuff in the past was because I couldn't figure out the magic spell for getting things positioned properly. We even have media queries now, which can be combined with Grid to toggle between 2 or more layouts depending on viewport or other device factors. Our current web app handles all of the dynamic/responsive layout crap within about 30 lines of js & css.
I will only go back to native application development if someone pays for a one-off contract deal that only has to be supported for <3 years. For any long-term project with a user interface, I feel like the web is the safest default for building your product. We are signing contracts with B2B clients right now with terms measured in half-decades, so I really don't want to be playing games in traffic with 5 major versions of iOS and Android if I can avoid it.
Pretty standard on any other platform, but on the web, no one gets it right.
IMO Flexbox and Grid only remove the need to have a stylesheet dedicated to layout like Bootstrap and foundation. That may be important for building tiny sites with no dependencies, but for an application, there will usually be a bunch of npm cruft required anyway. Having a bootstrap.min.css in the mix doesn't really impact my quality of life.
I have yet to see a great app built on web technology. All Electron apps provide a terrible UX, they are slow, unresponsive and feel out of place with the rest of the OS I'm running on. I want my apps to feel native, to look and feel exactly like all other apps.
One of the greatest tragedies of web UI's is the lack of a standard UI toolkit. Almost evert web-based app has to roll their own UI components, there is no consistency. This is terrible for usability, especially for users that are not as tech-savvy as we are. It's one thing to have to explain what a certain UI component is and does once, but it gets infinitely worse if every app has their own spin on it. Who doesn't love teaching their grandma 1232043 different variations on a checkbox ?
Oh my god, that sounds so cringey, right out of a marketing copy. It’s hard to wrap my head around someone writing this with a straight face.
You are acting like users have a choice. For example: Microsoft Teams is an abomination of an app. It's slow, clunky, eats memory like there is no tomorrow and feels totally out of place on macOS. Still it's a huge commercial succes and I use it every day, even though as a user I absolutely hate it. I simply have to use it because my employer chose it as the company collaboration tool. And they didn't choose it because of it's incredible UX, they chose it because we already have an Office365 subscription and it was included in that, so we already paid for it anyway.
Some Electron apps have been huge commercial successes despite their terrible UX.
In the year 2022, multitouch gestures on the web still feel janky and wierd and just don’t work all that well.
This is where you lose me. For such a "terrible" platform, it sure has a lot of users now, don't it? Maybe you mean from a developer's perspective, and it's not unreasonable that someone might consider web tech terrible, so I'd be interested to know why they see it that way.
> There is no good way to develop a UI in HTML/CSS/JS
Nonsense. Most UIs suck in general. On the web, they suck a little more because HTML/CSS/JS have such a low barrier to entry, and the industry requires very little intellectual rigor that would cause one to think twice about "just npm install that shit, bruh." Despite that, there's no sensible reason why a "good" UI can't be built with web tech. The web is what you make of it.
> all attempts to do so rely on layers upon layers of wat are essentially hacks
You're going to have to explain what makes working within the confines of a webpage a "hack." Sometimes we create workarounds, but everything may need workarounds.
> to build something resembling a UI toolkit
It is a UI toolkit.
> on top of a document markup language.
Which many people agree is well suited for describing UIs, whether it's HTML or something else.
> The result a UI that is unnecessarily complicated and fragile.
The cause not being something wrong with webpages, but the choices developers make and the way organizations approach software development. Give me a fragile web app and I'll show you a fragile and hard to work with native codebase.
> Laying out and rendering HTML and CSS is incredibly complex
It's as complex as you make it out to be. None of what's on a webpage has to be complex. We make it complex because of a lack of actual engineering mindset and because HTML/CSS is relatively abstract and forgiving. If one doesn't prefer something that's forgiving, they can work with native code or something that transpiles to HTML/CSS. Doesn't mean HTML and CSS aren't capable of performing the job they've been doing for almost my entire lifetime now.
> compared how traditional UI toolkits do the same task.
Depends on the task. Depends on the toolkit.
> That complexity comes at a cost, both in development time and in UX.
As already stated, that complexity comes from no one but the developer. Given reasonable time, a developer should be able to build most UIs using web tech and have it working as intended. HTML, CSS, and even JS aren't really what most people consider complex about web development. What's insanely complex about modern web development, that people frequently complain about, is everything we've done to turn web development into Java development (i.e. a churn of build steps, toolchains, transpilers, runtimes, and so on).
In contrast, I had to stop using my favorite SSH application on iOS because the author had died and Apple stopped supporting 32-bit apps instead of providing a compatibility layer.
https://docs.microsoft.com/en-us/troubleshoot/windows-client...
If you want to try, extract disk4-apps.img:
Point of order: 16-bit applications used the NE format, while PE was introduced to support 32-bit applications.
This is so disingenuous and untrue that I‘m close to calling it an outright lie. Development of UI has never been easier, more accessible and better for the disabled than with web tooling. Any businesses from tiny startups to gigantic corporations can build value creating applications which generate billions of dollars of revenue which runs on almost all devices, using just one language and one code base. Browsers HTML and CSS parsers are incredibly generous in what they accept, allowing small markup mistakes in a latest update to not grind your operation to a halt. Modern HTML and CSS are dead simple to use, deliver sane defaults and capabilities which most browsers understand all the same. Never before has it been so easy to develop an application for your business with a language and frameworks millions of developers speak. Prototyping is incredibly simple. Modern browsers deliver incredibly tight sandboxes so malicious applications can neither access the information of other applications nor anything else on a targeted users system. Fake applications can be identified with SSL certificates in ways native applications never could.
The web enables the famed „write once, deliver anywhere“ which native desktop always aspired to be. My apps run on android, iPhones, MacOS, rare Linux operating systems, Windows and Tablets alike. The only thing they need is a browser. I only need one programming language for this.
One developer can do with the web what 10 couldn‘t do with native. How one could take a look at fortune 500 companies which are almost all at their size in thanks of the web and its advantages and then go on to declare the latter the worst platform to build is beyond me.
We recommend viewing this sentiment in Chrome. It’s not been tested elsewhere.
There's a lot of people receptive to this toxicity- it's fact-free rage people want to hear, it's viral & it spreads- but the truth is webdev works fine & we have many perfectly reasonable frameworks to pick from that do a very fine job. Even straight vanilla js is not unreasonable an option, especially with webcomponents.
I dunno, it looked pretty aggressive to me. There was maybe a kernel of fact, but mostly opinion:
> As a platform for developing interactive applications the web is simply terrible.
Many disagree. Many would rather use Electron than native apps & find it nicer.
> 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.
I laughed out loud. There were already interactive buttons & form controls from the start. Vanilla JS is fine today. One of the web's strongest suits is that you can take a static page & sprinkle in just a little interactivity, just a little applicationization, if you want. Ultra-thin ultra-simple libraries like Enhance are doing great to provide just a little common shape & definition, tiny code but some norms & practices to adopt. It can be extremely incremental to move from document to application, with very little work at each step. We see what we want to see, and a lot of people want to see it as hard, as hugely complicated, but here's an industry heads down cranking without a ton of internal complaint, plenty of simple ways of doing things, and plenty of people doing fine.
> The result a UI that is unnecessarily complicated and fragile.
Sources wanted. Not all sites are perfect but a huge amount of things work very well. And unlike apps, users have a toolkit of capabilities they can learn & apply everywhere to help them (forward, back, bookmark, share link). Extensions let users go further than apps permit. Again, it's just, like, ya'll's downer opinion, man.
Anyhow, I like your note on hope. A lot. I don't see this ancestor post as having much hope there; it seemed set up to ruin. Trying to identify more constructive opportunities, trying to figure out new architectures we might layer onto the platform: that stuff should be exciting.
One place I lose excitement rapidly though is replacing the web with rendered canvases, as you say here:
> I am hoping that wasm and webgl can bypass html css and js for people who just want to make a webapp.
This is my nightmare. If folks want to do something else, fine, go somewhere else. But don't break the web. Don't break every user agent. Don't break view source, scraping, & accessibility tools. Just because alternate paradigms are succeeding as much as laserdisc doesn't mean they should come in & break the web next. That should be enragening.
The web is for more than pushing pixels into peoples faces. There's some value here, some shared expected experience, & coming in crashing it all because the only stakeholder you can imagine is those who "just want to make a [not-so-web]app" and damn all the rest.
I've had this bone to pick with Flutter, which is doing this imperialistic web takeover plan with CanvasKit, effectively turning the browser into a vnc session for an app. Incredibly hostile & deeply cruel way to snub hypertext & make yourself unintelligible to the rest of the ecosystem.
(The "direct calls into the DOM" wasm desires are going to be a bit chaotic & hurtful to view-source, but we've already made that hard; so ok, fine, and yeah, it is exciting to give people a post-JS web.)
Ideally I want security sensitive apps to turn into blackbox webapps. I want most everything else to be pure html+css. With interactivity there when you really need it to convey your meaning or to generate documents more quickly.
In reality, I think your nightmare scenario is far more likely. It just makes serving ads so much easier. And they still will keep making native apps for things that should be websites (which is my nightmare) because that makes it even easier to get valuable data.
This is nothing new. We used to have Flash, after all. (And I doubt Flutter on web will come close to reaching the ubiquity of that platform.)
Given how the web is embarking a takeover of desktop via Electron and of mobile to a much lesser degree with Ionic, to the annoyance of many users, turnabout is fair play.
Yes, that is part of the problem. Parsers should be fail-fast and deterministic, this is one of the many problems of the web. Developers don't notice their incorrect code due to this and without noticing rely on the implementation-specific way one browser handles the issue. Then 3 versions later or in a different browser they whole house of cards comes tumbling down.
> One developer can do with the web what 10 couldn‘t do with native
Building a non-trivial app is always faster to do native. By a huge margin.
This was XHTML documents when sent with the correct Content-Type. "Just don't display anything if the document is malformed" is worse for users if devs still create malformed documents.
Another problem with it is that everyone who can get something to display in their browser suddenly thinks of themselves as a developer.
Ancient history now, but HTML5 was developed by WHATWG specifically as pushback against priorities of W3C at time (chief among which was push for XHTML).
That's not to say things cannot be improved, just to say this has all happened before and it will all happen again (and it is worth paying attention to what happened last time).
Raise your hackles about the choice not to fail fast if you want, but when they fail, they do fail deterministically. It's a too-common myth that they don't. (A little perverse that people who make a big deal out of others unable to follow spec, but by doing so prove they haven't checked what the spec says—because if they did, they'd know this...)
Their response wasn’t glowing.
the UI was consistent across the entire platform, all the accessibility worked out of the box
yes, the main advantage is that the web runs on "everything", but then the added complexity of needing 4 different programming languages and half a dozen build tools don't put it in a state where it has "never been easier"
even Java+Swing was better in pretty much every respect (other than providing employment for tens of "web developers")
(same as people who <3 visual studio today obviously haven't tried JetBrains...)
The 90s were great, not because they had the best experiences possible at the time, but because there was such anticipation for the future. Sadly the web did not evolve quickly enough, and we have been paying the price ever since.
The only place where GUI apps have reigned supreme is in trading applications in finance, although I suspect that dominance is beginning to erode.
You don't need those for the Web. You can choose to use them. You can choose not to, too.
The ability of web apps to be instantly installed and updated is a huge win, as is the fact that it runs on everything from a phone to a desktop with zero additional effort. Certainly it comes with tradeoffs, but if your goal is not just to write code but to put it in front of customers, it's hard to do better than Html plus JavaScript.
I find that repeated a lot, but to me, it's somewhere between an overstatement and a misconception.
Sure, the early web wasn't anywhere near the versatility of what we have today, and interactivity was extremely limited (and as you say, is still more complex than it ought to be). But the semantics of HTTP+HTML, from the early days, allowed for application development. If all we had had were <p>, <h1>, <aside> and GET, sure, documents it is. But we had forms and POST and everything you need to make a CRUD application from the early 90s. It was pretty basic, but so was support for documents (tell Desktop Publishing people that HTML in the 90s was good for documents, and they're not likely to agree much).
Just as one example, what is this, of not an application: https://thehistoryoftheweb.com/postscript/pizzanet/
The same is true for PDF, yet it’s still primarily a document format.
1: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsd...
What we had was server-side frameworks. Generated HTML, click a link that does a GET or POST. That's how my webmail at University worked, that's how the control panel for my web hosting worked etc.
I think my first exposure to proper clientside UI was GMail (lunched 2004, I think I signed up ~2006).
They had the same vision for it that Sun had for Java, with the same flaws that would become apparent when that vision was finally manifested in Electron: write once, run anywhere, and be hideously inefficient compared to native code.
Flash was used for apps; I remember one webmail provider which had built their frontend in Flash (can't remember the name sadly), and there various enterprise apps that were deployed with Adobe Flex (I remember Paychex being one of them).
I never used flash seriously from 1996-2015 when I switched to an electron front end and then mostly to backend work.
Further, to quote Tim Berners-Lee directly on his intention when he created the first version of the WWW (emphasis mine):
"Creating the web was really an act of desperation, because the situation without it was very difficult when I was working at CERN later. Most of the technology involved in the web, like the hypertext, like the Internet, multifont text objects, had all been designed already. I just had to put them together. It was a step of generalising, going to a higher level of abstraction, thinking about all the documentation systems out there as being possibly part of a larger imaginary documentation system." — Tim Berners-Lee
https://en.wikipedia.org/wiki/Tim_Berners-Lee#Career_and_res...
edit: cleaned up formatting and attributed emphasis.
> The purpose of this document is to answer the question "When did we start seeing web-forms that captured credit-card details, and passed them to CGI-scripts, thereby enabling interaction with server-side applications
Amazon went public a year later.
It's odd to say something like "REST was introduced in 2000 by Fielding", since it makes it sound like support for a feature. But REST is just a description of how the Web works. Fielding's dissertation is a retrospective, documenting what the real work of standardization at IETF and among browser makers and server distributions had already earlier enabled.
Secondly, JS was workable performance-wise in the early 2000s in Netscape 6, even without a JIT.
I also don't think the longevity of Web sites will necessarily continue. The earliest sites will render today, but will the same be said of today's "single-page-application" sites that rely on scripting?
And finally, I think the LaserDisc comparison is dumb. LaserDiscs from the '70s were playable through the format's demise in the 2000s. "Coding" for it... makes even less sense.
This is false. Various inputs and forms were in html since its early days, these are not required to simply publish and view a document but to interact with text and graphical content.
It did lack the ability to do "rich" content/apps and flash tried to fill in that gap, html5 came a bit late but I hope it is forward compatible. Would an html5 app from 2015 run fine in 2035?
The same is true for PDF files, they support forms and can even POST to a server. Would you consider PDF a format designed to build apps instead of one designed to publish documents ?
HTML is great for these kinds of 'apps', like this website. This is where HTML is fulfilling its original purpose. Reading text, filling out a few forms, that's exactly what it is for. I'm not arguing against interactive websites such as e.g. Reddit or Slashdot. What I'm arguing about is actual full-fledged apps built in HTML. Photoshop should not be a web app, nor should Visual Studio.
With classic html, you can do similar things as with PDF but it was used to write anything from IRC clients, school exams, games and a lot more. Like PDF, it contained support for scripts to allow applications not mere documents to be implemented but unlike PDF it was especially made for the web.
People did implement full fledged apps in plain html powered by powerful server side languages like php or jsp. The trend of doing a lot of heavy lifting in clients is fairly modern after clients were able to handle such workloads and internet speeds were not a deterrent. For clienr capabilities of the time, html was very much meant to implement apps in the browser with all the heavi lifiting done on the server side because pentium 1 with 500mb ram,dialup and windows 98 can't do modern types of apps even with flash well.
The earliest fully interactive web apps are still usable, and native apps from the same time are not.
"The web has none of that."
I'm pretty sure that indicates that the author knows web pages aren't like apps.
And cherry picking quotes out of context to misrepresent what's said isn't cool.
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
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).
Honestly a Core 2 Duo has more than enough power to cover the overwhelming majority of web site/app use cases if only developers cared about optimization.
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.
Still wondering what the purpose of PWA’s existing is.
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.
Unless they used Applets, or Flash, or ActiveX, or RealPlayer or any of the other dozens of proprietary 'web' technologies that came and went.
Or it could be partly dead, with the image hosting only not working for instance.
Oof
That book demo is common for the business space they are targeting, as they offer consulting services to port applications to WebAssembly.
Meanwhile the AS2 Flash games I released on newgrounds in 2002 are still working fine.
I kind of feel like the people calling for the destruction of Flash didn’t have quite the same dedication for creating a robust platform out of web standards.
The point is that the web at least encourages some of the hacking spirit of reverse engineering that makes computers interesting. Apple shuts that down unilaterally.
But I still build apps instead of websites, because:
1. I can create experiences which are not possible on the web
2. I can more easily make money from it
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.
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?
There's a team at Apple that owns PWA's and is iterating on them. Large organizations like Apple usually don't follow some grand strategy.
It sounds possible in theory: Apple gets to keep their 30% cut while allowing devs to sell even more apps.
But they would have no way of screening the PWAs, and if a PWA reaches enough feature parity to be usable by big sellers of subscriptions like Netflix, those sellers will surely invest effort in creating a PWA with their own payment SDK that bypasses Apple’s cut.
This is where I think the incentives are not aligned. Small devs want an easy to use monetization framework and are happy to give a percentage of their income for that, but Apple might want more large sellers which bring far more money for less managing effort.
>This is where I think the incentives are not aligned
But could be aligned to everyone's benefit.
It took a long legal battle to allow Netflix to show a button to their own external subscription website: https://www.reuters.com/technology/apple-says-japan-fair-tra...
But even so, there are a lot of other big sellers which haven't yet got their external button approved.
Small devs want competition. Apple goes out of their way to prevent that, you can't sing it's praises when it's literally the only option.
If the service or experience exists entirely within your application, a mobile or native app seems to be the only option.
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.
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.
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
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.
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
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.
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.
And at least Debian comes with the previous version of GTK, if you want to depend on it. What, of course, nobody does, because staying up to date is a matter of recompiling and changing a few function calls. (It doesn't have Qt3, probably because it's much harder to ship multiple Qt versions system-wide.) And, of course, you can always include your widgets with your code.
This is basically the amount of churning you get for any general application because of the glibc instability. That one is hard to circumvent, but there shouldn't be more of it on the future.
1 - Qt has had two incompatible changes, one of them removed almost nothing, GTK literally has had one. There is, of course the Qt6 thing, that breaks everything again, but I doubt people will migrate.
Later, gnome announced they were moving to a rolling release model that would routinely break backward compatibility.
Since then, I've stopped paying attention, but noticed that QT utilities are slowly replacing all the (still maintained, but stalled, feature wise) gnome programs I used to use.
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-hypert...>
> 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.
HTMX doesn't completely spit in the face of how the Web was designed and what browser makers implement. <https://htmx.org/essays> Again, though, knowing what problem something is actually intending to solve is important.
Tbh, some of this feels a bit like "What you're referring to as Linux, is in fact, GNU/Linux...". I am eager to do studying before I just hack away with whatever tool I don't really understand (hence why I created the post) and it seems there are some useful resources there. But my main goal is to study for the sake of building, not getting drawn into a niche for the sake of purism. For example, would I be able to create a nice-looking game app with smooth animations such as [1] using mostly basic HTML, like HTMX seems to encourage?
[0] https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... [1] https://figure.game/
You will need CSS and/or SVG for the graphics and animation (or a graphics and animation library that builds on top of those). Games are different from form-based Web applications. The HTMX essays are about protocol design and application decomposition between client and server and what effect this has on how robust the app is, the user experience implications, etc. It's not super relevant if what you're doing is more or less a game that 15–20 years ago would have been created with Flash.
> I am eager to do studying before I just hack away
No, start hacking. No amount of study is going to enable you to arrive at an informed decision.
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).
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.
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.
[0]: https://www.domesday86.com
[1]: https://github.com/simoninns/DomesdayDuplicator/wiki
Anyone able to confirm/disconfirm that?
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.
Sure, but there is a difference between "eventually" being 3 years or 30.
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
[1] https://dockyard.com/blog/2022/09/01/dockyard-r-d-build-elix...
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.
> requirements have evolved.
The referred tweet aged like milk since this is neither app-specific nor phone-specific, and hasn't gotten any viable alternatives either.