What matters is the scale at which you plan to build your project. If the project is only ever meant for one person to use, then it's practically trivial. But being on the Web, you expose yourself to a much larger potential market, so I think it's easier for estimates to get blown out of the water. Desktop applications scale horizontally be default. Web applications scale vertically by default [0]. So if there is some "difficulty", then it is in that most Computer Science degreed people [1] first train in single-user, runs-on-a-desktop programming, so that is what they are initially familiar with. But it's a difference of starting point, not a difference in overall difficulty.
There is a cultural issue that a lot of companies continue to treat the Web as a sub-standard platform, a lot of engineering teams continue to treat "The Front End" as an after thought, and they continue to hire only junior developers who have only ever written programs for themselves. This is not to knock Jr. Devs. We all start somewhere. But there are a lot of companies that expect way too much out of someone with 0 to 5 years of experience because they don't expect enough out of the Web as a platform.
Other than that, concerns like accessibility, internationalization, cross-platform compatibility, they're all easier across the board on all platforms today than they've ever been on any of the platforms. I don't think there is any argument to be made there.
[0] Hence the desire to make SPAs. A good SPA scales horizontally as well as any desktop application.
[1] Myself included in this group.
I can't see how that's not a MASSIVE difference. That's adds a whole extra layer of complexity.
There is virtually nothing in web apps that is easier, almost by very definition. What web apps made easy was deployment. Please name one other thing that's easier than in a desktop app. HTML wasn't even designed for apps.
I just cannot comprehend how you can believe what you wrote. I really haven't written many desktop apps, but generally speaking when I did in say VB6 or Silverlight, they have been trivial to make compared to a web app of identical complexity.
Cross-form-factor compat is infinitely easier in HTML. If you think HTML is bad, try getting the same Qt app to run on a 4k desktop screen and a smartphone.
And contrary to popular belief, HTML was indeed originally designed for applications. Why do you think it has the form and input elements? Why do you think HTTP has OPTIONS, POST, PUT, PATCH, and DELETE? If it were just about document delivery, GET would be enough.
Mutli-user systems are significantly easier on the web. What you mention as a boon for the desktop is only a boon if you're only interested in supporting one user at a time.
You rightly mention deployment is easier. That's no small thing. I've seen entire departments grind to a halt for entire days, once a month, because they sucked at deployment.
What you are talking about being easy belies your values in what an application should be. If you valued different things in your applications, then you'd find the desktop system to be more difficult than the web. And that's why I say they are not fundamentally more or less difficult than each other.
Indeed, the original draft for HTML did not include forms or input elements[0]. While HTTP had POST, PUT, and DELETE, those were supposed to be used for uploading new content or replying to newsgroups. In particular, the semantics for POST were quite different[1]: “Creates a new object linked to the specified object. The message-id field of the new object may be set by the client or else will be given by the server. A URL will be allocated by the server and returned to the client. The new document is the data part of the request. It is considered to be subordinate to the specified object, in the way that a file is subordinate to a directory containing it, or a news article is subordinate to a newsgroup to which it is posted.”
While these features were added quite early in the development of HTML and HTTP, respectively, they certainly were not part of the original design.
For questionnaires and guest books. It was only later discovered that this allows to have an application that runs server-side, but is displayed on client's side.
> HTML was indeed originally designed for applications. [...] Why do you think HTTP has OPTIONS, POST, PUT, PATCH, and DELETE?
What on earth do HTTP verbs have to do with what HTML was designed for?
The market for all types software is huge and we only ever hear from a very small section of it. It's why I don't take the concept of programming-language-oriented "communities" too seriously. There is a huge body of dark-matter programmers out there--probably 90% in any particular language--who do not participate in the meetups and conferences and discussion forums. They just work and then go home at the end of the day to do something completely unrelated to programming.