Writing an app is like coding for LaserDisc(shkspr.mobi)
shkspr.mobi
Writing an app is like coding for LaserDisc
https://shkspr.mobi/blog/2022/09/writing-an-app-is-like-coding-for-laserdisc/
198 comments
> The web was designed to publish documents, it was never intended to build applications.
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/
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/
I consider (paper) forms to be documents as well. In my opinion, it's a minor evolution of what is considered a "document" to go from a paper form to a dynamic, interactive form. A media application or video game in a browser is quite different. That doesn't mean it's not now a valid use of browsers, it's just not what the intended use of the web originally was.
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.
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.
[deleted]
The early '90s only had GET in the HTTP protocol (0.9) so you couldn't actually build any CRUD applications. Quite far from it. POST came in 96 (1.0) and PUT, DELETE in 97 (1.1). REST was introduced in 2000 by Fielding and the idea that the web could used to build large scalable applications slowly gained momentum as CRUD was mapped to POST/GET/PUT/DELETE and the proposal gathered steam in '00s. In the meantime massive amount of engineering went into making JavaScript workable, performance wise (Chrome/V8). Everything came together only in the late 2000's. So, quite far from claiming web as a viable mechanism for building applications in the early '90s.
HTTP POST was in common use well before 1996. It was standardized with HTTP 1.0 in 1996, but form POSTs were common well before then. People were developing "web apps" in the 90's using Perl CGIs, ASP pages (VB script), and even Javascript (Netscape's web server supported server side Javascript applications.)
It's funny that there's contention on this. Here's someone trying to answer the question in 2002:
> 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
<http://www.rogerclarke.com/II/WCBirth.html>
> 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
<http://www.rogerclarke.com/II/WCBirth.html>
In addition to icedchai's comment, there are two more issues worth quibbling about what's written here:
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.
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.
Yet there I was building online shopping apps in 96 in my internship. Get was more than good enough for a search of the catalog to find what you needed. Our system just sent an order email in and we called you for payment. That was via post.
Amazon went public a year later.
Amazon went public a year later.
You can definitely make a crud app with only GET. E.g. PHP used to have support for automatically adding session ids to urls in links, for people who didn't like cookies.
I think it's right on the money. The Web has long sucked even for presentation, let alone for application delivery. It's not that you can't do it now; but it's still a hack upon a hack.
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.
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.
Sure, you could write apps using forms and POST, but how prevalent was it? One of the most popular frameworks for early-ish apps was Flash eg, for which support has been thoroughly discontinued.
Maybe my memory is fuzzy, but I don't remember Flash being used for apps. It got used for video playing and games mostly, as well as unnecessary animation on restaurant/hotel websites. The occasional enterprise app used it, but generally they were ActiveX.
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).
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).
>Maybe my memory is fuzzy, but I don't remember Flash being used for apps
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).
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).
Adobe really wanted it to be used for serious stuff. There was AIR, a Flash desktop runtime. They started integrating
Flash into their tools, I recall a few Illustrator palettes that would make my computer’s fans come on just by opening them because they would make the Flash runtime wake up and start busy-waiting for input on them.
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.
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.
That's what I remember too - but what's the difference between an app and a game? Usually your score would be sent back to the server too.
A managed switch we use somewhere for something uses flash to display port status (I think?). I guess that part doesn't work anymore...
[deleted]
Up through 2008 we made very heavy use of posts in web apps where I worked, js was more of an accelerant for things like autocomplete and client side validation. Amazon retail was still building mostly post based experiences when they were doing the universal detail page project in 2015.
I never used flash seriously from 1996-2015 when I switched to an electron front end and then mostly to backend work.
I never used flash seriously from 1996-2015 when I switched to an electron front end and then mostly to backend work.
> But we had forms and POST and everything you need to make a CRUD application
The same is true for PDF, yet it’s still primarily a document format.
The same is true for PDF, yet it’s still primarily a document format.
Not to mention it has a js interpreter[1]...
1: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsd...
1: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsd...
"App" is short for application, which is just a fancy word for program. If a page does computations locally (using javascript), then it is a program; if the page does nothing locally but push requests to the server (get/post), then this is a user interface. By this distinction, the early Web even with POST had no application, it was just at best a remote interface.
A remote interface to an application living on the server.
> 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.
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.
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.
I'm sorry, but the web development experience is god awful compared to the 90s development experience using something like delphi or even (ugh) visual basic
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")
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")
For me, VB + Visual Studio was the highlight of late 90s programming - true drag&drop wysiwyg ui design, a clean link between code and ui, lightning fast prototyping. ahhh good times
correct. as an industry we threw out battle-tested GUI toolkits and programming models for something completely backward. 15-20 years later we have excel in the browser. great. The no-deployment (for deployment is too often an after-thought of the main functionality) model was too attractive and blinded people to the costs.
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.
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.
> the added complexity of needing [...] half a dozen build tools
You don't need those for the Web. You can choose to use them. You can choose not to, too.
You don't need those for the Web. You can choose to use them. You can choose not to, too.
The web enables the famed „write once, deliver anywhere“ which native desktop always aspired to be
We recommend viewing this sentiment in Chrome. It’s not been tested elsewhere.
We recommend viewing this sentiment in Chrome. It’s not been tested elsewhere.
> Browsers HTML and CSS parsers are incredibly generous in what they accept
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.
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.
> Parsers should be fail-fast and deterministic
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...)
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...)
> 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.
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.
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.
The only reason developers write malformed documents was because they can get away with it. And yet, millions of lines of code are written every day in programming languages that absolutely do not accept malformed code, and that all works out just fine.
Another problem with it is that everyone who can get something to display in their browser suddenly thinks of themselves as a developer.
Another problem with it is that everyone who can get something to display in their browser suddenly thinks of themselves as a developer.
How does such a system reconcile the need to be opt-in to maintain backwards compatibility with the web as it exists with the likelihood that the audience you want to reach (developers who can't be bothered to Do It Right) are just the ones who will not opt in?
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).
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).
[deleted]
I think you misunderstand the comment you're replying to. He's not saying that the internet is bad, or that it doesn't make it much more convenient or profitable to deploy and sell software. he's just saying that's it's much easier to develop an application with say Windows Forms rather than HTML+CSS+JS
I'm not sure that's true if you consider the "last mile" of packaging and distribution.
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.
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.
It's simply toxic behavior, to show up & flame something obviously quite capable like they had.
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.
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 didn't see it as rage. It simply pointed out that the web as it exists is a document format that had self modification, and then full apps bolted on. It is a hacky mess and I don't understand how anyone just using js wouldn't find that readily apparent? There exists great tooling to hide that fact, but even then I have to agree with the gp that we still aren't to a place that is as cohesive or easy to use, or as predictable a UX for the end user as those 90s tools he mentions. There is no hate there, just hope. I am hoping that wasm and webgl can bypass html css and js for people who just want to make a webapp. Direct calls into the dom with no js wrapper should be here any minute, and webgl hopefully will follow? Once that is all sorted you'll see some development environments like delphi pop up I suspect.
> I didn't see it as rage. It simply pointed out that the web as it exists is a document format that had self modification, and then full apps bolted on
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.)
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.)
> 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.
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.
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.
I'd really like to keep both webs, but the reality is that everyone trying to monetize wants an app, and failing that a webapp that is a complete black box. So that is probably the way it will go. I like document only websites for conveying information. Know a lot about X and want to share your knowledge? Make a document. I can see room for some partial interactivity for hands on tutorials, like notebooks. But I don't really want any interactivity on my news sites, sadly they will head for the blackbox model first for the money. For a payment portal, a banking app, a multiplayer videogame, probably even a web ide or chat client, I don't want any document like behavior, I just want an app, and if it can be sandboxed in my browser, all the better.
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.
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.
[deleted]
Do you guys actually use the word disingenuous in face to face conversations?
Usually gets couched more softly for the person being accused of it, but when talking about statements it certainly gets used
I said “I think that argument is disingenuous, at best” to someone recently.
Their response wasn’t glowing.
Their response wasn’t glowing.
I had a boss that said this in a variety of contexts at least once per week. He was fun…
>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.
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.
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.
I discovered this unfortunate reality recently myself. In 2012 I was gifted by my parents a first gen Kindle Fire. I got a lot of free apps back then because Amazon had a "free game of the week" deal going on where a lot of normally paid apps would be temporarily free.
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
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
As a hobbyist game developer with several games of my own no longer available due to the marching on of OS versions, I sympathize. There just isn't enough time or incentive for me to keep old codebases current with arbitrary API changes.
I wish Android had a compatibility layer, along with some sandboxing measures to keep security threats from being too serious. That way old programs can still stick around, and leave more time for devs to focus on new programs instead of maintaining old ones.
This is why it's important to oppose the ambitions of people who pose the threat of making their way into influential positions at browser makers and arguing that it's okay to throw the whole thing out the window and start treating browser-based app development like any other platform. There is no other platform like the Web.
Previously:
<https://news.ycombinator.com/item?id=28056416>
<https://news.ycombinator.com/item?id=27368152>
Previously:
<https://news.ycombinator.com/item?id=28056416>
<https://news.ycombinator.com/item?id=27368152>
>iOS app from 2010
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.
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.
> Indeed, though running a Java Applet from 1995 is a lot easier than running an iOS app from 2010
Applets weren’t even easy to run in 1995.
Applets weren’t even easy to run in 1995.
But somehow still way easier than booting up an old iOS.
> Most JavaScript-based single-page applications from 2010 should still run flawlessly in modern browsers.
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.
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.
Honestly I think Perl CGI scripts stand a better than most chance of still being executable 25 years later. Maybe just behind win32 apps. Whether you'd want to with the high rate of command/sql/html injection vulnerabilities in those days is another question.
> How confident are we that the backend code from 1995 will still run?
This seems like it would apply equally to native and web.
This seems like it would apply equally to native and web.
You can run pretty much any native app from 1995 for any platform in emulation. Network requirements were uncommon outside of networking-specific apps.
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.
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.
Win32 applications from (almost?) 30 years ago also still run on modern Windows. By a far margin, it’s a choice of keeping compatibility or not.
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.
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.
I run all 64 bit Windows 10. But, if I was on 32 bit, I wouldn't count out Windows 1.0 16 bit PE's from running:
https://docs.microsoft.com/en-us/troubleshoot/windows-client...
If you want to try, extract disk4-apps.img:
https://winworldpc.com/product/windows-10/101
https://docs.microsoft.com/en-us/troubleshoot/windows-client...
If you want to try, extract disk4-apps.img:
https://winworldpc.com/product/windows-10/101
> Windows 1.0 16 bit PE's
Point of order: 16-bit applications used the NE format, while PE was introduced to support 32-bit applications.
Point of order: 16-bit applications used the NE format, while PE was introduced to support 32-bit applications.
Win32 apps also run extremely well in dosbox on Linux, etc.
> 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.
But the web has been evolving in that direction with the help of standards bodies and browser vendors since at least the late 1990s.
> 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.
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.
[deleted]
> The web was designed to publish documents, it was never intended to build applications.
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?
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?
> This is false. Various inputs and forms were in html since its early days
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.
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.
You are changing the topic with photoshop and VS, I or no one else on this thread claimed they should be web apps. PDF like say word and excel documents can be made to write applications.
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.
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.
Many, many web developers would disagree with your assertion that you can't build great apps (including desktop and mobile (hello Electron and Capacitor)), or that the UI technologies available to web developers are a "hack" or aren't actually extremely productive and enjoyable to use. The argument that the web is only for documents and not app experiences is simply a relic of a different time.
> your assertion you can't build great apps (including desktop and mobile (hello Electron and Capacitor))
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 ?
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 ?
In fairness we seem to have managed to cock up the standard UI toolkit on native applications as well. Things like office, chrome, Spotify all invent there own UI these days.
That’s strongly influenced (actually, caused) by mobile UI design, though. For all the benefits of mobile, it is destroying the desktop UI experience.
This is just your opinion and perception then, because Electron apps have been hugely commercially successful and teams using it have built very strong experiences that users love. If they were so "terrible" and "out of place" users would reject them, and they don't. The HN crowd has been consistently wrong about this.
> strong experiences that users love
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.
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.
Ah yes, the classic attacking of the author instead of engaging in a debate on substance
> If they were so "terrible" and "out of place" users would reject them, and they don't.
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.
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.
You are certainly entitled to feel that way about Teams and these kinds of apps. My point is that's just your opinion and doesn't necessarily reflect the majority of the users of those products. I can just as easily say that I love the UX of Spotify/Slack/Discord/etc and don't care at all that they don't use platform UI controls to render most of the app.
> or that the UI technologies available to web developers are a "hack"
In the year 2022, multitouch gestures on the web still feel janky and wierd and just don’t work all that well.
In the year 2022, multitouch gestures on the web still feel janky and wierd and just don’t work all that well.
From the article, in the same paragraph, just before the quote you lifted:
"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.
"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.
> 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.
The earliest fully interactive web apps are still usable, and native apps from the same time are not.
The earliest fully interactive web apps are still usable, and native apps from the same time are not.
The statement is still true though. A over engineered react app built in 2022 should still work perfectly fine in 2032.
> As a platform for developing interactive applications the web is simply terrible.
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).
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).
With CSS Flexbox and Grid, the web is the best GUI app platform I know of (and I was a WinForms developer before). It is made for apps now, and it has been the goal for some time already - since HTML 5 at least, but I'd say it began as stated goal with DHTML.
I don't know. Some of the things I could do with a pirated copy of VB5 as a 14 year old would take me 10x as long to do on the web even using modern tools which I'm reasonably familiar with.
Hmm, your Vb5 apps were responsive? Mine definitely weren't - but it's fairly easy with Flexbox/Grid.
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.
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.
Haha, mobile phones came with snake at the time. No one expected to be browsing the internet on them (which had barely passed into mainstream use). I remember around the time my dad's friend coming over with his work laptop (a rare thing at the time) to show us "the internet". Everyone just assumed a lowest common denominator resolution and got on with it!
My pet peeve was not being able to use 2 windows next to each other on my 1280x1024 screen because the UIs assumed full screen usage.
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.
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.
So tell me how I can build an infinite scroll panel that supports (a) jumping to any point without a single dropped frame, (b) smooth sub-pixel scrolling on browsers that support it, e.g. edge or firefox, (c) full accessibility support
Pretty standard on any other platform, but on the web, no one gets it right.
Pretty standard on any other platform, but on the web, no one gets it right.
> With CSS Flexbox and Grid, the web is the best GUI app platform I know.
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.
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.
Agreed. Flexbox and Grid are the most productive I've ever been with a UI toolkit, and I've used pretty much everything available for native mobile and desktop dev. CSS is certainly weird at first, but once you really learn it it can be far more productive than traditional UI programming.
Ironically the CSS grid is based on WPF grid, and was originally proposed by the WPF team.
Don't see the irony, WPF was a nice idea that should be copied - unfortunately they axed it before it could grow and then the general uncertainty forced me off the platform.
It is still there on Visual Studio, and with a more certain future than WinUI will ever get.
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.
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.
WPF might be there, but with all the "deprecated - oh not deprecated again - not deprecated but no updates for many years - deprecated again - not deprecated again" cycles I'm not going to touch it with 10-meter pole for anything that I need to support - same with anything else related to .NET.
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.
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.
Blend is your friend.
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.
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.
They might be using apps, but my customers don't want to pay for developing for four or more separate platforms (Windows, macOS, Android, iOS - also notice that nobody would develop for Linux), so they solve it by having a single platform - the web. Many of my customers previously had (only) a Windows app but found out that onboarding new customers is much faster (and thus happens more) with web apps.
.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.
.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.
Yeah we don't get NuGet packages that only offer a single function...
Much better to have a bunch of one-function packages that you can simply avoid than to have a dead package registry with 1/10 of the useful stuff (so not the one-function packages).
With the difference that in 10 years those packages will still have support, just like VB 6 runtime and MFC are still shipping on Windows 11.
Flex box and Grid only help in creating layouts. It doesn't help anything with regards to reactivity, which is what most web UIs can lack compared to a desktop application.
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.
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.
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
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
> 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).
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).
Isn't browsing the web painfully slow on that machine?
I have a couple of old Core 2 Duo machines (2006-2008) and the web is largely fine on those, so long as you have uBlock Origin installed and make a point to avoid the sites that haphazardly slather on Javascript.
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.
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.
I can't speak for OP, but I am typing this on the mid-2014 MBP which has nearly identical processor and graphics specs. The only thing that this machine struggles to do is video editing. Besides that, it feels as fast as the day I got it.
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.
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.
Even as a power user I dislike PWAs. Give me a native app that is buttery smooth instead of 200m of JavaScript.
Does anyone want to install a PWA over a native app? Genuinely curious.
Still wondering what the purpose of PWA’s existing is.
Still wondering what the purpose of PWA’s existing is.
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.
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.
I don't want to install an native app for every restaurants that I visit every 3 month. I want to use PWA instead.
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.
Unless they used Applets, or Flash, or ActiveX, or RealPlayer or any of the other dozens of proprietary 'web' technologies that came and went.
And not HTML5 games circa 2010. I remember reading a more recent tweet from a prolific web developer that 90% of his web HTML5 games from that era are broken.
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.
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.
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.
Or it could be partly dead, with the image hosting only not working for instance.
Don't even need those things. They won't work if they used DHTML, or IE specific JavaScript, or (I think?) framesets.
Flash players likr Ruffle are available, and web apps at the time made it such that the .swf files remain easily extractable.
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.
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.
Most of them have WebAssembly emulators available.
AFAIK there are no active projects that implement ActionScript 3.0 so most of the interesting Flash content is dead on the web.
> Book A Demo
Oof
Oof
If you had spent a couple of minutes actually looking for information,
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.
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.
Ok that's neat and all, but I don't see any way to upload my own SWF files. Unfortunately most interesting Flash content are still dead on the web.
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:
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.
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.
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.
If the service or experience exists entirely within your application, a mobile or native app seems to be the only option.
I didn’t know your app was a thing. I’m on my iPhone now but I will purchase it as soon as I go back upstairs to a Mac. Thanks!
> 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?
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?
Native support for buying PWAs (or at least in-app purchases) would probably be a game changer yes.
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.
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.
> Small devs want an easy to use monetization framework and are happy to give a percentage of their income for that
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.
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.
I don't see any intersection of Apple and Netflix. Big media services like Netflix have their own subscription services.
>This is where I think the incentives are not aligned
But could be aligned to everyone's benefit.
>This is where I think the incentives are not aligned
But could be aligned to everyone's benefit.
You might not be familiar with the App Store restriction on in-app links/buttons to external payment methods. An app on the App Store must only provide subscriptions through Apple's own means which gives them a 30% cut of every subscription payment.
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.
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.
> Why else would they be adding features (notifications, installation) that make PWAs better?
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.
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.
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.
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.
> 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.
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.
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.
Even worse are the ones that rely on a cloud service somewhere, even keeping an old device around won’t help you there…
[deleted]
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
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.
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.
>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
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.
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.
> 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.
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.
Also amusing is that things I wrote for win32 in 2000 still run now on Windows 11.
You might be able to make your application "modern" through something like http://www.boxedwine.org/ to run it in the browser ;)
It's not particularly amusing, because it's normal and what users expect (by not caring in the slightest when the program was written).
Good point. Windows, Linux, and the web don’t suffer the kind of software churn we see on Apple platforms.
Actually, Linux does, too.
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.
GTK and Qt basically¹ churned their code once on this century. The other widget libraries didn't change at all.
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.
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.
On a 500kloc Qt codebase I had maybe 4/5 files which needed changes following Qt5 -> Qt6, plus a couple of bugs that cropped up in the early versions. Plus most of the issues were in private API uses which are outside of the stability contract anyways. Now I know that I'm safe from breaking changes for at least 3/4 years until Qt7 ... Wouldn't call that churn haha.
Yes, but gnome two and three cannot coexist on the same box, so distros like Mint ended up forking Debian to preserve access to the old gtk ecosystem.
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.
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.
Being recompiled from source for every distro update is the expected model for Linux software. Why should it be considered "bad"?
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.
Yes, because that's the design of the whole system. Having the source code of the software you use is an important feature, and not having it is the cause of the problem you describe - as well as many others.
And Wine.
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.
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.
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
[0] https://news.ycombinator.com/item?id=32724950
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-hypert...>
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...>
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.
> 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.
Nothing like that. Basic HTML elements, esp. e.g. those related to forms.
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.
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.
Thanks for the links! So I've had a look at the resources - [0] for example goes to great lengths explaining why JSON APIs are not true to the original "spirit" of REST, but it doesn't exactly do a great job at explaining what problems would be solved (better) by hypermedia-based APIs rather than JSON (or GraphQL,...).
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/
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/
> For example, would I be able to create a nice-looking game app with smooth animations such as [1] using mostly basic HTML
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.
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.
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.
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).
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).
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
(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.)
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.
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.
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.
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.
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!
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
[1]: https://github.com/simoninns/DomesdayDuplicator/wiki
[2]: https://github.com/happycube/cxadc-linux3
[3]: https://github.com/happycube/ld-decode
[0]: https://www.domesday86.com
[1]: https://github.com/simoninns/DomesdayDuplicator/wiki
[2]: https://github.com/happycube/cxadc-linux3
[3]: https://github.com/happycube/ld-decode
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?
Anyone able to confirm/disconfirm that?
Yeah it's fairly common, especially for B2C.
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.
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.
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.
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.
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.
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.
it will eventually cease to function.
Sure, but there is a difference between "eventually" being 3 years or 30.
Sure, but there is a difference between "eventually" being 3 years or 30.
The 30y scenario is pretty unlikely with zero maintenance.
If you build your apps to the API as written, this is table stakes in the windows world.
My dosbox installation respectfully disagrees.
[deleted]
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
[1] https://dockyard.com/blog/2022/09/01/dockyard-r-d-build-elix...
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...
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.
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.
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.
Ironically, the whole argument can be summarised and partially dismissed from one of its lines:
> requirements have evolved.
> requirements have evolved.
> app store requirements have evolved
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.
The referred tweet aged like milk since this is neither app-specific nor phone-specific, and hasn't gotten any viable alternatives either.
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.