Every time I take a stab at a web gui app, I’m daunted.
The toolkits, the apparently billions of dependencies, the vastly complicated build processes.
I tried again recently. HTML file and a separate JS file. Some SVG elements with a click handler.
I had mouse in and mouse out logic, and that worked great. But for some reason the click handler did not.
I tried it in Safari, Chrome, and Firefox. It worked in Firefox. It did not work in Safari, it did not work in Chrome.
Turns out in Safari, my Ad Blocker was hijacking my click handler. Chrome, still not sure what’s happening there.
But I projected what happened in Safari out to the wild. “Can’t get your app to work.” Except instead of a 50 line experiment, it’s a gazillion lines of God knows what 87 levels removed from whatever code I actually wrote.
Cross browser Hell. It’s supposed to be a sandbox only to find out the cat got there first.
And I give up. Again. It’s not my livelihood. It’s a hobby. I encountered these quickly enough to thwart me before I’ve actually invested any real time. Like starting out on a vacation and you have a flat tire and the drain plug pops out before you get out of town. Maybe there’s a cosmic message here.
And I feel stupid. Obviously folks manage, but I keep getting knocked down and kicked.
The idea of pain free distribution via a PWA is really alluring. I’d like it to work. But it seems every time I get back up, the lights go out again and the corners of the cabinets seek my head.
But then I think back to my rock climbing days, a friend used to climb in shorts. And I asked didn’t it hurt when he used his knees? He answered “it’s not supposed to hurt?”
Developers like you and I are a dying breed. We remember writing applications for operating systems that had straightforward APIs, and OS developers that worked hard to ensure any app which used those APIs would not break.
Most "full-stack" developers I know that write web apps have literally never written a line of C++ in their life, let alone written a rich text editor using an object oriented desktop GUI API.
I wish they were a dying breed, but no, you're not.
You're just looking at the past with extremely rose tinted glasses.
It's way,way easier to implement a UI like in the 90s with hmtl5.
You're just trying to make a modern UI with all it's bells in whistles and now complain how complicated it is.
The tech ain't any more complicated. The software you're imagining has a waaaay more complicated UI then what you did in the 90s
I right rich/native applications right now, using OS-provided APIs. It's a little bit of a pain point because I've chosen to transition to writing in Rust, and the Rust interfaces always have some friction. But the native APIs themselves? Smooth as butter and a joy to work with. It ain't complicated at all.
>You're just looking at the past with extremely rose tinted glasses
Dude, some of us still write 90s style code, even Delphi style stuff (FreePascal and Lazarus), and can still compare it everyday to modern web dev.
It was better without any "rose tinted glasses" needed.
Same for 00s C#/.NET or even "classic" Visual Basic - dead easy to make even an elaborate UI going.
>It's way,way easier to implement a UI like in the 90s with hmtl5.
No, it really is not. What you're describing is some simple form, as if 90s UIs were constrained to that.
>The tech ain't any more complicated. The software you're imagining has a waaaay more complicated UI then what you did in the 90s
Not even close to being right. Most web apps including Electron apps are dead simple and primitive functionality wise compared to the 90s (including not having all the functionality one got for free via integration with the OS), but their codebases and dev platforms are still over-engineered and haphazardly-engineered monstrocities. And then there's the resource consumption.
The "modern web stack" has an incredibly high ceiling wrt how complicated it can be.
It's floor isn't particularly complicated however, and definitely not higher then the equivalent software with the native APIs from the 90s.
You had buttons, inputs, text boxes. Pre-2k UI APIs were extremely limited. Did we even have hover in windows 95/98 or MacOS 9.0? The first time I've seen that was more towards 2010 then 2000 - windows XP/Vista and MacOSX, but it's been a long time since then
> No, it really is not. What you're describing is some simple form, as if 90s UIs were constrained to that.
Please provide an example then. I sure as hell can't think of one and googling didn't provide me with anything but that.
There were definitely many issues with Win32 that HTML has fixed, but the controls available in Windows 98 were significantly more numerous and featureful than what HTML5 offers, even today. You could certainly react to mouse hovers. It also had:
• Tree view controls
• Table views, with draggable, resizable and sortable headers
• Image list views
• Menu bars (something HTML will probably never have!)
• Context menus
• Embeddable file explorer views
• A rich text editor control that wasn't plagued with weird formatting and cursor movement bugs
• Embeddable Word/Excel/PowerPoint if you needed more than that
• Date/time pickers (something HTML didn't get until 2014 and I never see any real app use it)
To get these many of these on the web you need to import large third party frameworks, because HTML5 doesn't offer them out of the box. So apps are all very inconsistent.
> Did we even have hover in windows 95/98?
Hover how? Changing the appearance of a control when the mouse passes over it? Or having a tooltip appearing? Both can definitely be implemented quite easily. For the tooltip, I just checked on Delphi 2 (which I was using on Win95 ages ago) and it had the Hint and ShowHint properties (as the current VCL/LCL).
> Pre-2k UI APIs were extremely limited.
But that was largely enough for most GUIs. Nowadays people are putting a full browser (Electron) to create an interface with a few buttons and a progress bar. I'm thinking of an actual application, a relatively famous SD card writing program which weighs something like 200 MB. Make it with native GUI controls and it takes 50 kB (maybe even less) and will not eat the RAM and CPU of the users.
Moreover, people are doing fancy GUIs, with the result that no two application look the same, totally confusing some users (Windows itself is a mess, since Windows 8).
The tooltip hover is equivalent with the title attribute in hmtl5, so that once again as trivial as you can get.
The original comment made it sound like they wanted something else to happen.
The resource inefficency is a completely different argument. That's true, but has no bearing on how complicated the APIs supposedly are. Same with the coherence between applications. That's an issue entirely unrelated to the original claim which was just false.
Completely off topic, but... If you're on windows , use Rufus instead if balena etcher. And if you're on Linux/MacOS... dd works great, just make an alias with tab completion for devices/image
>That's true, but has no bearing on how complicated the APIs supposedly are. Same with the coherence between applications. That's an issue entirely unrelated to the original claim which was just false.
That's like your opinion, man.
First, it's not the invidual APIs themselves, it's several layers of APIs, and combinations thereof.
In traditional desktop UIs you just placed widgets together in a form/panel, hooked events, and wrote your application - normally all in the same language and with a single bundle of APIs from your lib (e.g. the Delphi API, the QT API, MS's API).
In web dev (I do both), it's an endless layer upon layer of cruft. Even just the browser UI base layer alone has HTML, CSS, JS, the DOM, SVG, Web Components and shadow DOMs, and several other items besides. Then there are the differences and incompatibilities between engines, between desktop and mobile, and so on.
Then there's the pre-processing of all those, JS (or typescript), bundlers stuff like Webpack, minimization and map files, then there are Frameworks like Next/React/Angular/Vue, and different varieties.
We haven't even touched the backend of those, written in the same (Node) or different languages, and with its own layers added.
I don't think it's possible to end this debate unless one of you finally names an example. Please provide a screenshot or at least a name of an UI/application from before 2000 that's not braindead easy to implement with pure html/trivial css and simple click handlers.
If you can provide one, I'll yield to your point. Otherwise you're just high on nostalgia and comparing today's complexities caused by a vastly bigger scope to yesteryears simple realities, where multi-platform, i18n, animations, dynamic rerendering, etc pretty much wasn't a thing... entirely
If you remove all these features, you end with a simple html file with inline css. And that's easier then it was in the 90s.
>Please provide a screenshot or at least a name of an UI/application from before 2000 that's not braindead easy to implement with pure html/trivial css and simple click handlers.
I'm not sure what exactly you think "UI/applications from before 2000" looked like and were.
You do know that, e.g. Word, Excel, Photoshop, Logic, WinAmp, Paint, Framemaker, 3ds Max, Final Draft, Lotus Domino/Agenda, Visio, QuickBooks, Cinema 4D, Encarta, Dreamweaver, ACDSee, Real Player, Outlook, AIM, ICQ, FL Studio, Maya, WinRar, WinZip, InDesign, Quark Xpress, Cubase, and countless others, commercial and freeware, including full featured KDE and Gnome DEs were made before 2000, right?
Oh yes, i do know that.
but do YOU know how they looked back then? because they're literally just toolbars with buttons on em and canvas frames which are just fricking images / application logic! rendering these viewports/canvases are challenging for sure -- back then just like today, because thats where where the domain logic goes.
the UI back then were fucking trivial, youre deluding yourself if you think anything else.
Lets go through your first examples one-by-one, as the theme continues i will stop at some point.
* Word: literally just 1 menu/text, 2 rows of icons. And a range picker. you can do that within ~15 minutes even as a beginner.
* Excel: same as word, with the addition of a grid in the body. the challenge is in chaining together the cells. trivial as hell -- as long as you ignore the application/domain logic, which would've been just as complicated back then.
https://winworldpc.com/res/img/screenshots/57db2161e19c9e95d...
It goes on and on. Every single example youre citing is just rows and rows of icons.
Thats extremely easy to implement with pure html and trivial css.
give any of these UIs to an experienced frontend dev and they'll provide you with a click dummy within 15 minutes to 3hours, depending on the quantity of elements on it.
I'd be pointless, precisely because nobody cares about such trivial UIs anymore... But hey, whatever floats your boat, right?
And everything I wrote here is ignoring the fact that every one of your example was the opposite of easy back in the 90s. They were developed by whole teams over years to get to that point, despite what was claimed initially. And duplicating this with html5 is trivial, that itself should tell you how much easier it's gotten if you just don't chase the hippest tech that's fotm right now
Am I taking crazy pills? I never mentioned the 90's! Here's my original post, which is unedited:
> Developers like you and I are a dying breed. We remember writing applications for operating systems that had straightforward APIs, and OS developers that worked hard to ensure any app which used those APIs would not break.
> Most "full-stack" developers I know that write web apps have literally never written a line of C++ in their life, let alone written a rich text editor using an object oriented desktop GUI API.
> They don't know it's not supposed to hurt.
HN doesn't allow editing comments outside of a very short edit window.
Well, the web (most common frameworks) doesn’t really have drag’n’drop UI editors. Writing complex widgets for the web had a long list of issues for a long time and only recently became feasible without hacks (they couldn’t be reasonably encapsulated from the rest of the website before shadow DOMs, and better js encapsulation).
As an example, there is no standard, no-one-gets-fired-for choosing complex table widget that can sort, filter, paginate, re-order, etc its rows/columns. Many of them fall just shy of a prod-ready implementation.
>The tech ain't any more complicated. The software you're imagining has a waaaay more complicated UI then what you did in the 90s
It was (it still is) SHIT (there are technically valid reasons), but being shit from moment 1 it was absolutely necessary to create a builder for that.
While simple UI in HTML5/js/css is wonderful to make, any user-contribution system (drag and drop builders, editors and what-have-you) is hell to manage and develop, breaks a lot more than you may think, has bold performance issues. The stack is shareware as a service, it's crazy, it's laughable thinking that probably the multi-billion system required for A-grade GPTs is more cost-efficient than living like we are accustomed to in big web development.
(Less snark: just browse cppreference.com. The standard library is updated to make use of new features, so just check out the changes between C++14, C++17, C++20, etc.)
"Cross browser Hell. It’s supposed to be a sandbox only to find out the cat got there first."
Hm, it is really not that bad anymore. Only if you target bleeding edge features, you will usually have issues. But a mouse click handler? I never managed to not have that working. Also I like vanilla JS. Web Apps can be really simple, if you avoid the bloat.
While I also don’t think that a mouse click handler would be problematic, my recent experience is that more complex apps are more and more often broken under firefox, but still work fine under chrome. E.g. miro boards are unusable under firefox, and it’s absolutely shameful of every company that can’t bother testing it on like 2 browsers.
Edge and samsung internet are basically the same as chrome, so there are only 3 browsers to check. Especially that most stuff just works fine across the browsers, it’s not like cross-platform across OSs, it really is a bare minimum.
> It is hard justifying extra effort for those 2.2% marketshare, unless you count in idealism. And most companies are there for profit.
To me, this attitude always sounds like a local business owner choosing to randomly kick 1 out of every 45 customers out of his store. Is it really that much time/cost/effort to test one more browser?
I have the same background (25 years of C and C++), and tried the same thing: Let's learn web programming by putting together a 700 line web app that allows you to edit, load, and save some proprietary file format. Sounds like a good learning project. How hard could it be? I'll use this JQuery thing, that looks popular. I guess I need HTML, CSS, and JS, not sure what should go in which file, but I'll learn it as I go.
But nothing has as thorough documentation as I'm used to in native / systems programming. It's all rando tutorials and incomplete/outdated web pages.
Weeks later, I have something barely working, but it looks ugly as sin because there is no nice, well-documented GUI library like Qt, wxWidgets, and so on. And the ones that are decent would require me to rewrite my whole app around them. I find JQueryUI which is still at the level of banging rocks together to create fire. In fact, the whole process of putting a web app together feels like I'm using stone tools and blunt chisels instead of the C++ workshop full of power tools and well-lit workbenches.
I don't know how developers can live with this pain. Good for y'all--I couldn't do it day in and day out.
Not popular on HN, but you should look into Dart/Flutter, especially if it's for a hobby.
I too was daunted like you and that's why I chose Dart/Flutter. Though if you're wanting web technologies I'd consider looking into: https://leanwebclub.com/
Nothing to do with them but they're all about franework-less web technologies.
> The toolkits, the apparently billions of dependencies, the vastly complicated build processes... Except instead of a 50 line experiment, it’s a gazillion lines of God knows what 87 levels removed from whatever code I actually wrote.
Instead start with pure HTML, SVG, CSS and JavaScript. Use MDN for documentation. Pick one browser to develop on (any one will do).
Why? Most importantly you are learning how the low level browser code works, and you are building your own taste about using the core languages. Just like learning machine code helps with your C++ development.
You don't need build processes unless you are developing commercially. The frameworks provide opinionated APIs, but they are often too abstract and are providing complex enterprisey features.
There is not that much difference between browsers now. And jQuery is bollocks (it was mostly golden for adding code to HTML pages that were served from a back end).
If you want to get a webdev job then maybe do some thinking on what framework and tools you want on your resume, and learn that framework/tooling after you have mastered non-framework browser development. But my guess is that webdev is likely not a good fit if you like engineering your software.
My experience is now outdated, but I wrote my own framework which morphed over time as we supported other browsers and newer versions of browsers. I started my career on embedded software, so perhaps I am more cynical than most! My framework was far better engineered than most (for the reliability we needed). Other frameworks delivered on other goals that were not aligned with our needs.
It is a very frustrating road writing pages for browsers because everything feels arbitrary and you have very little control over the engineering and you are at the mercy of browser quirks: you are often forced to come up with shitty expedient solutions that work if you are dong commercial work, and I very rarely felt clean. There is no beauty to web development: it is dirty work that I would try and do the best I could to achieve the outcomes we needed. Compromising constantly...
To be fair, that's one of the reasons why libraries like jQuery and React exist: to smooth over the difference between browsers.
Even today, big chunk of React is masking the subtle differences in event handling and other things. And whilst it forces you into a paradigm, I've never had a bug caused by the internals of React that I've had to dig into. But maybe I'm lucky or only do simple stuff?
As to it hurting, I guess I'd say, use the protective equipment! Sure, it can be bulky and awkward occasionally, but it works and it's often better than the alternatives.
It hurts, but it's not supposed to. The web stack is now pure hell, almost completely devoid of what makes programming software enjoyable in the same way as making furniture or machining a tool, which it used to be and still is in places. The web ecosystem has raced to the bottom with the goal of enabling less and less talented/experienced developers to be productive. That goal is good, but the changes didn't have to be so bad - however, the nature of the web means that it's almost completely nonviable to make large breaking changes to the foundations, which are they kinds of changes that actually improve things and benefit everybody. So instead we build up layers. It's so disappointing considering what it could have been like.
I think it just used to be a lot worse. Sure Web ui isn't great, but like in your list of browsers your complaining about you don't even have internet Explorer, let alone multiple versions of it. Docs are better, apis have more features, browsers auto update and nag to do it, libraries and frameworks for what ever coding style you prefer
I think I feel a bit like your friend: web development is not supposed to hurt that much, and it usually only happens if you start doing things in obscure ways, or unusual environments, or whatever else. Unfortunately, when you're just starting out, or trying something as a hobby, it's difficult to tell what the "correct" way of doing things is, so beginners often fall into these sorts of traps.
I don't think this is any different with web development, GUI programming, machine learning, embedded, or anything else. I did a bit of work with Pandas recently and spent the whole time going "but this is so dumb - why would it work like this?" In reality, it was not dumb, I was just inexperienced with the task and tools I was working with, and was running into problems because of that inexperience.
There are some ways to mitigate this, and good learning resources that show you how to get onto the happy path (without bombarding you with too many best practices up front) are worth their weight in gold. But I think it's very easy to forget what it feels like to learn something new, so often when we approach a new area of programming, we notice how difficult it is to learn, and that feels surprising to us - even though it surely took us a long time to get comfortable with the stuff we already know.
Would be interesting though to repeat this analysis today because the rise of AppStores considerably simplified the shareware model for those who use them (while they have huge drawbacks too).
1. Land on the site by searching
2. Click on the preferred/compatible AppStore link
3. Optional step for tech savy users : Read commitments and review to check if something is dubious
4. Use the app for X weeks of trying period or until a fremium limitation is reached
5. Pay in one click when you choose or when a popup remind you that you must pay to lift some limitations
That 4/5 steps instead of the 17 described by the OP, and that's probably the true value of AppStores for Developers. (Are margins fair? that's up for debate! But it's unfair to ignore the added value)
I actually find myself actively avoiding getting anything from application stores without prior outside knowledge.
Why? Because given no other context I cannot tell apart the decent from the bullshit, let alone the good. There are no differentiators because the storefront obviously accepts everything including the bull-est of shits, being paid-for or free-beer is hardly a useful measure these days (and $5 is nothing), and basically everything outside of a very small handful comes from no-name developers and publishers (bonus points if Suspicious Chinese(tm) names).
Back in ye olde days: I could count on stores since if they put something on their shelves they clearly sold enough volume. I could/can count on word-of-mouth websites with EXE and ZIP downloads. I could/can count on digital storefronts because their userbase could be trusted (eg: Steam, GOG).
The true death of desktop applications were system administrators and their draconian app policies.
What do you want to do? Ask the eternally overworked BOFH of duty to go through the month-long approval process of deploying a superior desktop app to the org, or just pay the monthly fees of a SaaS (conveniently below the approval required threshold) and have a mediocre solution right now?
The AppStore’s ease and security is what saved native apps on mobile.
Now that websites can use the File System Access API to load and save files, the Desktop is "solved" for me. Everybody can use my software simply by opening the url in their browser.
The new challenge is phones. Mobile browsers do not support the File System Access API.
What is a solution to this? Is there a reputable service that converts a web page into an Android/iOS app so that it can load and save files?
Phones just don't make a good analog to computers with a robust file system browser. My experience is if you're downloading something on a phone, it's never going be used again. It will sit there until a factory reset.
How many restaurant menus have I downloaded read once and never cleared off? I don't know. I also don't care. If I did care, I would want to use "Save As..." and save to google drive.
I think you are missing a step in your conclusion there. The reason users aren't as robust in organizing where their files come is because file browsing on phones isn't as robust.
On the android side the file browser that comes with the phone (if any) is bare bones. This combined with various sandboxing can make it pretty annoying to know exactly where your files end up.
Then there is the fact that the small UI on phones simply isn't all that great for browsing a large list of files.
So, putting it squarely on users isn't correct imho.
Total Commander is great but there are tons of real file explorers for any user "robust" enough. I think what user above is pointing out what we have all noticed, people browsing the web from a phone are usually younger, less intelligent and unrefined enough to be better off not given access to the file system .
You are only further affirming the point I am making. You need a third party app in order to be able to browse files well enough on Android devices. And even then you do not get the same experience as you would get on a desktop OS. Simply because the same amount of information (file name, icons, creation date, change date, file size) which does fit fine on desktop does not fit as well on a phone screen without creating huge clutter.
Of course, younger users never really having used a file system doesn't work either. But certainly calling them "less intelligent and unrefined" is a ridiculous hot take if I ever saw one.
And you affirm my point, that its incredibly easy for anyone to take 15 seconds to install a file browser but most won't because they are too daft. A good file explorer does does have all the bells and whistles on any OS (except iOS) not sure what straw man you are attacking there).
The people who don't bother to do so probably are better off without it anyway, so no harm no foul and everyone is better off.
One thing I'm missing is pkcs11 API in browsers. This seems to not make sense to US devs from what I could see but if you're in EU you can probably commiserate.
> Mobile browsers do not support the File System Access API
Unfortunately Safari on Desktop also doesn't support the File System Access API. Ditto for WebUSB, WebBluetooth, WebMIDI, etc. Whole classes of "desktop-lite" web apps that can only be shipped on Chrome.
It's kind of a hard sell to ship a web app that just doesn't work for normal users who bought a MacBook.
For me it makes sense when you start to see Chrome as an OS. Developers use Chrome specific API, which means the apps are not web apps, but Chrome apps (and the developers Chrome developers). Sure the Chrome (OS) is cross platform so it’s a great platform to develop your app. But it’s a little bit unfair (unless you consider that Google = the Web, which may be the reality I refuse to see).
>The new challenge is phones. Mobile browsers do not support the File System Access API.
Phones are an old challenge for now. Their OS is made upfront to coerce the user in having their data dealt by someone or something else out of the phone, somewhere through an Internet connection.
I partly agree with you, but File System Access API requires Chrome. Other browsers do not support it. And this API does not support checking for file changes on the file system, eg. To reload a changed file like desktop editors do.
Ya, it's odd to say it's not on other browsers when they all have it just to variable degrees... it's almost as if there are comment bots here that are trained on outdated data ;)
The ability to access the native filesystem (via showOpenFilePicker()) is indeed only available in Chromium.
For Firefox and Safari users, one can offer a fallback via "download file" and "upload file" functionality. Which is clunky, because it does not reliably remember the directory. So the user often has to navigate to the correct dir again. Also it does not offer to save with the same filename by default. So the user will be offered to download "myfile(2).txt" or something instead. But at least it works and you can tell your users to use Chromium for a better experience.
As someone trying to carve out a (non-commercial, for me personally) space for desktop apps, the author raises very good points and I believe they are right. (Although I still prefer working on non-web tech when I can.)
You could perhaps imagine web apps as a form of 2FA, half the app is on the client, and the other half is on the server and continually authenticating each other by communicating with each other.
There's no reason you can't do this with desktop apps, put a chunk of the functionality on the server and obtain security that way.
The trouble with web apps is compute and storage performance, for a web app you're limited by the browser - not so much for a desktop. Its not really an issue for a bingo card creator, it is if you're making blender or autocad.
> Its not really an issue for a bingo card creator, it is if you're making blender or autocad.
This is obviously valid, but considering how powerful even low-end computers are these days, I'd say that most of the stuff we do on a computer is more like bingo card creator than blender or autocad.
Software that is slow in spite of this is generally slow because it does a thousand network requests in the background.
A 2009-era argument could have been that desktop apps are more respectful of your privacy, but that ship has long sailed due to pervasive telemetry, and it wasn't really ever true for mobile anyway.
What did you have in mind with the browser being a limiting factor? It seems to me you can run stuff in the browser that makes use of all your local resources and can save things as well, considering tools like jupyter notebooks.
Also, from a end user point of view, unless you are downloading from a known and reputable software company, you assume the exe contains spyware and viruses by default. That has been the main reason for me to download desktop apps sparingly.
I feel like the author generalise too much. His points are valid for one app. I'm not surprised that the web version works better for him, given what kind of app it is, target audience etc. But he writes it as if he is dismissing desktop apps entirely which is way to drastic from this one example.
The most surprising thing is that that this was in 2009. Web apps was not common back then.
I have one big gripe with this:
> Don’t treat your newbies like you treat your power-users. You have a database. It records all their actions since the dawn of time. Use it. I have a couple very simple heuristics for “is probably still getting used to the software” and, if you are, the software treats you with kid gloves. For example, it hides complex, seldom used options by default.
First of all, your heuristics are most certainly broken. Hiding options is infuriating, if you are trying to evaluate the software you get the wrong idea of what is possible.
If you've used it before but started a new account you suddenly don't feel at home. If you are following a guide or recommendation they suddenly don't work. If you read the documentation I truly hope it is very clear that a feature might be hidden and what to do to enable it.
If you even consider the above make it very clear that you are in a simpler mode and make it easy to switch.
It's a bit of a one sided view. For someone trying to commercialize their simplistic application, it seems to make perfectly sense.
The article is missing the down-sides/limitations of web apps though, especially from a user perspective. Bingo Card users are in luck that the author has kept maintaining the site for 15years, but I'd say 9/10 "web apps" would not last 5 years, where a desktop application, I could at least continuing using, assuming the activation doesn't require external checks.
And then in this day and age, you never know when the enshitification of applications sets in. Yes, this can happen to desktop applications as well, but as the author points out, it's much faster to release something "new" on the web. You can A/B test the web app to max profitability, regardless of user experience or user needs.
Finally, for more complex applications, the latency on desktop applications has been severely underplayed. With web apps and web apps as desktop apps, people have been pushed into a new expectation of how fast computers can be.
Well we did more. By moving the compute and core to the other side of the fence within control of the seller it becomes hard(er) to pirate. Whereas as soon as you provide a working binary it is only a matter of time somebody has pirated it.
Browser-based software and desktop applications share some overlap but as the 15 years since the article have shown, that overlap isn't complete or even overly substantial (and thus desktop applications are as prevalent as ever). Just as a hammer and a nailgun are both tools that allow us to effectively build a structure, they both have their niches, benefits, and drawbacks. To pretend otherwise is simply juvenile and shortsighted.
The toolkits, the apparently billions of dependencies, the vastly complicated build processes.
I tried again recently. HTML file and a separate JS file. Some SVG elements with a click handler.
I had mouse in and mouse out logic, and that worked great. But for some reason the click handler did not.
I tried it in Safari, Chrome, and Firefox. It worked in Firefox. It did not work in Safari, it did not work in Chrome.
Turns out in Safari, my Ad Blocker was hijacking my click handler. Chrome, still not sure what’s happening there.
But I projected what happened in Safari out to the wild. “Can’t get your app to work.” Except instead of a 50 line experiment, it’s a gazillion lines of God knows what 87 levels removed from whatever code I actually wrote.
Cross browser Hell. It’s supposed to be a sandbox only to find out the cat got there first.
And I give up. Again. It’s not my livelihood. It’s a hobby. I encountered these quickly enough to thwart me before I’ve actually invested any real time. Like starting out on a vacation and you have a flat tire and the drain plug pops out before you get out of town. Maybe there’s a cosmic message here.
And I feel stupid. Obviously folks manage, but I keep getting knocked down and kicked.
The idea of pain free distribution via a PWA is really alluring. I’d like it to work. But it seems every time I get back up, the lights go out again and the corners of the cabinets seek my head.
But then I think back to my rock climbing days, a friend used to climb in shorts. And I asked didn’t it hurt when he used his knees? He answered “it’s not supposed to hurt?”
Is it supposed to hurt?