How did things come to this?
(1) You can tell people to go to a URL and it almost always "just works". Contrast that to considerable work to develop a Windows installer, Mac DMG file, RPM/DEB/other packages for Linux, etc.
(2) Once you put installers and packages in the field you will discover some people have machines in an odd state and your software won't work on them. Some people will give up (either your competitor wins or indifference wins), others will lead you into a rabbit hole solving their problems.
(3) Something will go wrong with your software. For a low risk change, say fixing a typo, you can deploy a change to a web app in minutes even with the discipline of version control, automated tests, and cache invalidation in place. For other platforms the process of building and testing installers, wait for/fight with the app store, then getting the people to really upgrade is a huge hassle that could stretch on for days or weeks.
(4) If you don't have the software versions synchronized, client/server protocol mismatch will complicate your efforts to fix bugs and add features.
(5) Data is safer in a data center or a cloud than it is for a client device that could can be lost, stolen or destroyed in a opportunistic or targeted way
(6) No cross-platform UI framework is better than the web browser in terms of (a) UI quality (b) ease of development or (c) range of devices supported.
(7) Any system for e-commerce, internet of things, digital twins, machine learning, space travel, compilers, data structures, weapons systems, etc. has a user interface on the critical path
My heroes right now are people like Walt Disney and Jim Henson who built seductive systems and spaces to enchant people. I find that opportunity meaningful in U.I. work.
It completely eliminates 1).
( Ah, perhaps 'windows like installer' could be misleading. I meant windows only, but like a 'installer' mechanism'. Since it installs, updates, ... Out of the box. Didn't exactly knew how to write it as short as possible)
(Then you could get the same critiques as java web start.)
It's a great experience in Windows though. We have multiple internal applications running on it.
Although it's not a one size fits all solution. But internal apps that can leverage windows are extremely quick to setup with the winforms/click-once combo.
Shared network drive and everyone has an installation + auto update mechanism.
( But i guess that combo isn't popular here )
Msix is better, but still not well supported - you can deploy a service for example, but not on a windows server.
We deployed click-once in an Enterprise env for internal apps though. Didn't had much issues with what you mentioned.
To debug/install windows services, we combine them with TopShelf - http://topshelf-project.com/
Think of all the apps you might use in a business context: CRM, e-mail, messaging, any shared database. All of these need real-time input by multiple people with the right access controls, and these are most easily built on a web environment.
Ironically these were rapidly eclipsed by the first-generation web applications that worked exactly like the old 'green screen' mainframe apps.
The SPA brought back the 'client-server' application but embedded in the web browser. There were many reason it was more successful in this new environment, one of them the asynchronous communication model that is required to make a web browser responsive.
It's a difficult programming model which makes web browsers the domain of the biggest corporations and that so many alternative browsers such as HotJava have been doomed, but it makes it possible for browsers to show you partially downloaded pages and rarely lock up the UI.
It seems like a hassle to deal with async comms in a Javascript SPA but if you were programming with a synchronous comm model you would find it very easy to get to 'hello world' but past that you'd be dealing with the window locking up, coordinating threads, etc. All stuff you get little experience with because the industry has given up on it.
I'm sure many a homeowner is annoyed that they can't get a great architect to do their renovations, yet few are annoyed enough to influence the market.
You develop software. How do you get it in the hands of users? Shrink-wrap, on-premises, downloadable executables and installers, SaaS (through the browser in one environment, or supporting lower browser cardinality than user environments').
Once you choose SaaS as distribution mode, you're writing for the web. Therefore a part of your problem, an important one, becomes web development.
That being said, if you prefer not to work in web technologies, those jobs certainly exist: middleware/platforms, embedded systems/IOT, some of the stuff FAANG does, etc. Remember, all those people writing web stuff rely on a very tall stack of layers and platforms to do what they do. You can find these jobs, with a little patience and persistence.
Web development in its infancy was simple so a whole generation of developers could learn as the technology improved.
As a developer in the 90s and early 00s it wasn't cheap or easy for everyone to get Visual Studio/Delphi/Borland C++ Builder, not to mention obtaining the knowledge to drive those tools effectively.
Web development might be more difficult today but for a decade or two it massively smashed barriers to entry.
- There's a place for backend focused development for the web. So you don't have to be an expert in frontend. But it helps to understand frontend concerns so you can speak a frontend dev's language to build interfaces that work for their needs. Be it server-side or APIs.
- there are fun technicalities of frontend - state management, asynchrony, software architecture for these problem spaces - lots of things that turn out to be technically interesting where you might be able to carve out a niche for yourself so you don't have to spend most of your time pushing pixels
- like desktop and probably mobile app development has gui frameworks where you can assemble UIs with components with largely existing styling that just needs configuration, the web frontend space has component libraries with style plugins like bootstrap and material ui, where a lot of styling is done for you, and you can focus on assembling the application rather than visual design or pixel pushing. It's not perfect for all cases, but it's effective for many. Which means if you don't want to be designing and building websites, you can still build good looking applications for the web and focus most of your time on functionality.
You don't have to do frontend if you don't want to. Obviously if you want to work in startups and build a product from scratch it'll be pretty important. If you want to work in big companies, the backend path has less skills churn (we don't throw out our framework every 6 months) and higher growth potential (it is easier to have a big impact on the org vs. churning out features, which is a low to mid level position).
Also, it’s the solution we wanted for decades for true portability, but most people just haven’t accepted that fact.
Web development is just the opportunistic parasite that snuck in after enterprisey dev blew apart the industry.
Everything that sucks about enterprisey dev also sucks about web dev.
Then pile on top the insanity of HTML, CSS, JavaScript... Almost makes one wistful for X-Windows.
Web dev didn't have to suck. It could have just been an update to time sharing and smart terminals.
But every generation has to reinvent everything from scratch every time. It's some kind of natural law.
Lather, rinse, repeat.
--
There are precisely two good parts that "the web" bequeathed onto the world: HTTP and URLs (URIs). Those really were game changers.
For one, both are "open".
All of the alternatives were in the same idea space as Xanadu. Closed gardens, proprietary.
At the moment, I don't recall any other contenders for the use cases HTTP and URI solve.
The only close analogs I can think of are the SNMP stack based on ASN.1 and MIBs (OIDs). And omg that stuff sucked.
Oh, some of it's coming back to me. X.500 (for addressing) and CORBA (for RPC) and the like.
We are SO LUCKY HTTP and URIs showed up.
There are far more gatekeepers when you've got an application spread across the internet. The ISP or Cloud providers can lock you out, you can lose your certificate, DNS, connectivity. The browser, ad-blocker, or a random change to java/javascript, etc can change your results. Governments of all levels, along with their spy agencies, and large profit driven corporations can intervein between your code and the end user.
A cable could get cut, or WiFi go down, a Telco or Apple or Google could decide your "app" isn't in their interest.
>more users -
I agree, but they're used to "free", and aren't always the customer.
>lower development costs
How is having an "app" that works through all the above simpler than a program installed (or just thrown into a folder, and run as a "portable" program) not far easier to support?
You can write to the screen almost directly, and probe files/folders in the same way, with no gatekeepers.
>tighter feedback loops.
Since you can't run it on your desktop and be confident, you have to test across all your users, or a wide swath of output devices, browsers, OSs, etc.
Purity does not always win out over utility.
I don’t particularly miss having to decipher which version of MSCVRT.DLL I need for which Windows app.
We were able to cobble together enough things via the web to make it possible for the user to get things done, with very rough edges, which have been sanded off a bit in the past decade. It is still light years less productive than the desktop power user, but the corporations and end users don't care.
Eventually we'll have programs that run on the end user's machine inside a VM, talking to the servers hiding behind web servers, doing a crude imitation of IBM 3270 terminals used in the 1970s for data entry. Everyone will herald it as success.
Users already have to go to your website: why even bother having an extra step of downloading your app if they don't need to?
https://www.amazon.com/Dream-Machine-M-Mitchell-Waldrop/dp/1...
https://www.amazon.com/Dealers-Lightning-Xerox-PARC-Computer...
That's so powerful that, over time, it ends up sucking a lot of devs in, who do great work which struggles with visibility.
Like I could probably look up a Haskell library right now which is a monumental feat of software engineering, that has like 1k users, total. Then I could look up some web dev app that's piss poor compared to that, which has like 1 million users.
That ends up exerting a gravitational pull over time, and that's why web dev dominates the software development discourse.
I just wanted to add that what we really need is a form of distributed operating system, and the web is the closest implementation of that, albeit a painfully poor one.
So, follow up questions might be: how come we have been unable to agree on some shared abstraction of a user and an app at the OS level? And are we now stuck forever in a world where software is grown organically rather than engineered? (as per Dijkstra's famous analogy)
If I can get you to use my hardware to do computations you were perfectly capable of doing on your own hardware given the same code, you're more liable to be comfortable paying me rent. Throw in that web apps have a lower barrier to entry in terms of grokking libraries written in a systems programming language, and you have the "Software Engineering world being dominated by Web Dev".
Sad, isn't it?
Ask anyone who does it. Fixpack releases, bug fixes, packaging and dependency management over N operating systems... it's a special he'll. Now, do it in the browser and you can update the page without notifying anyone, making a formal release or jumping thru many flaming hoops