It's amusing how we see web apps as the solution to deployment woes. I miss proper custom desktop apps with horrible looking cluttered interfaces. Soo productive compared to any web based interface for almost all tasks.
Eh, yes, and the yells of "Over budget, we can not afford new machines for the whole team, just because your app is not 386 backwards compatible."
And the partial rollouts, with teams being split into and stuck- and demanding you hack together tooling on the fly to allow for work to continue anyway.
And the horrible cross-application databases, which would went inconsistent if you didn't include basically a reduced data version controlling in every of your applications.
And those proto-typed tools, made by some intern in obscure languages, that would in secrecy fester into the "Main-Tool" of a department. And all hell would break loose, if some virtual environment update would break those env-dependcies.
You know what- it was bad back then. Real bad. And today is better. And even nostalgia cant save it.
You wouldn't have to use antiquated tools and practices just to use desktop apps. I'm not arguing to use the old apps, I'm arguing that a lot of new development should be desktop when it's often made as web apps without thought.
We threw all the good stuff with desktop out at the same time as we moved to intranets.
You can still have centralized deployment, thin clients etc, but have the niceties of proper native apps (good multi screen/multi window support, better, good support for complex interactions like shortcuts, ctrl-clicks etc).
Even on mobile where native has fewer benefits than on desktop we can't make web based apps that are better than native ones.
A clean understandable web UI is good for a seldom used app, but a lot of the intranet apps are "constant use" and were faster to use in their legacy dos implementation than the newer web version. Browser hell just makes the problem worse.
> A clean understandable web UI is good for a seldom used app, but a lot of the intranet apps are "constant use" and were faster to use in their legacy dos implementation than the newer web version. Browser hell just makes the problem worse.
This. Click, wait, click, wait, click, wait is in no way better than how quickly you can fly with a well memorized set of keyboard shortcuts in a native app.
This is not a web vs. native problem. You can implement keyboard shortcuts in a webapp. You can neglect to implement keyboard shortcuts in a native app.
This is all about attention to detail, which internal corporate apps almost always lack.
You can add keyboard shortcuts to a webapp. What you can't do is control or override the keyboard shortcuts that the browser adds, and you can't make use of the full suite of possible keyboard shortcuts. I've looked at adding shortcuts to my webapps many times over the years, and it's never been worth the effort because the result is just confusing to the user.
> (good multi screen/multi window support, better, good support for complex interactions like shortcuts, ctrl-clicks etc).
Totally do-able on the web. It's often the web apps architecture that prevents a good UX, not the browser's capabilities (which are really good now).
> Even on mobile […] we can't make web based apps that are better than native ones.
That's an issue of the developer, not the browser itself. I do admit that Safari/iOS is really hurting here but you can work around that if you really want to (it will still be a sub-par UX, though).
I still think VB6 was the pinnacle for writing line of business CRUD apps. I've been told there are still some VB6 apps I wrote ~15 years ago running at a big enterprise I once worked for.
I find C# and WinForms at least as simple as vb6. They did make Lightswitch to really dumb down the one-off crud app development, but I'm not sure if that still lives.
>I miss proper custom desktop apps with horrible looking cluttered interfaces. Soo productive compared to any web based interface for almost all tasks.
You mean where everything runs on the UI thread? Gotta pass on that. :)
Not necessarily - although that's usually fine. I prefer a non responsive UI when waiting for io/db, to a poorly implemented background execution where you aren't sure anything is actually happening.
> I prefer a non responsive UI when waiting for io/db, to a poorly implemented background execution where you aren't sure anything is actually happening.
You can't be sure anything is happening on a locked desktop app either though, so at least you can close it gracefully if it's doing that on another thread
IME customers close stuff if Windows shows "Not Responding" but not if you just have a fake progress bar.
There quite a few ways around that with async APIs and WebWorkers, even ServiceWorkers now. A lot of devs just don't use them properly.
Edit: Did you mean the browser itself could freeze? That's a thing of the past with Firefox being the last browser to separate the content and chrome process. So the web page may freeze, the browser window itself shouldn't.
WebWorkers are not a new "feature". The last browser to support it was (on desktop) IE in v10 (4 years ago) and on mobile Android 4.4 (3 years ago). Though that doesn't really matter since you can polyfill it, which obviously does not give you multithreading in those older browsers but it still forces you to think async.
Regarding other APIs, a great number has been available since many years, and any newly introduced API since at least 5 years is either non-blocking or async.
In my experiences being forced to use various SPAs from various venders, more often than not async just means I need to behave single threaded rather than the app lest I wish to trigger race conditions that desync the local model and I end up having to hard refresh.
Heh, the MS Windows file/folder permissions tab comes to mind when you mention that. Been single-threaded for 20+ years now. Clicking on the Add... button always freezes the UI while it communicates with the domain controller or whatever it does.
