4 ms·

I fundamentally can't agree with this because desktops apps are generally synchronous with one computer involved and web apps are asynchronous with at least 2 c

I fundamentally can't agree with this because desktops apps are generally synchronous with one computer involved and web apps are asynchronous with at least 2 computers involved. 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.

dasil003 10y ago
Hello World is much easier.
moron4hire 10y ago
Cross-platform compat is infinitely easier on the web. 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.
- dozzie 10y ago
  > And contrary to popular belief, HTML was indeed originally designed for applications. Why do you think it has the form and input elements? 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?
- mmarx 10y ago
  > 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. 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. [0] https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt [1] https://www.w3.org/Protocols/HTTP/Methods.html https://www.w3.org/Protocols/HTTP/Methods.html
  - moron4hire 10y ago
    Useless pedantry
ryanbrunner 10y ago
In my experience with desktop apps beyond toy examples in VB6, asynchronicity is something you have to pay way more attention to in the desktop world than on the web. Sure, the web is sort of fundamentally asynchronous, but the interactions you're making with the server tend to be more coarse-grained and easy to reason about than a desktop app with a UI thread and processing threads that need to communicate often and at a fine-grained level of detail.

dasil003 10y ago

Hello World is much easier.

moron4hire 10y ago

Cross-platform compat is infinitely easier on the web. 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.

dozzie 10y ago
> And contrary to popular belief, HTML was indeed originally designed for applications. Why do you think it has the form and input elements? 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?
mmarx 10y ago
> 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. 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. [0] https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt [1] https://www.w3.org/Protocols/HTTP/Methods.html https://www.w3.org/Protocols/HTTP/Methods.html
- moron4hire 10y ago
  Useless pedantry

ryanbrunner 10y ago

In my experience with desktop apps beyond toy examples in VB6, asynchronicity is something you have to pay way more attention to in the desktop world than on the web. Sure, the web is sort of fundamentally asynchronous, but the interactions you're making with the server tend to be more coarse-grained and easy to reason about than a desktop app with a UI thread and processing threads that need to communicate often and at a fine-grained level of detail.