<story><title>Why do we create modern desktop GUI apps using HTML/CSS/JavaScript? (2022)</title><url>https://gerrysweeney.com/why-do-write-desktop-gui-desktop-apps-in-html-css-javascript-making-them-just-glorified-web-pages/</url></story><parent_chain><item><author>alerighi</author><text>I think the difference is about frameworks. Typically desktop application frameworks (Windows Forms, GTK, QT, etc) follow an imperative approach, where you design your UI (maybe with a graphical designer) and attach callbacks to events, than then update the UI elements directly.&lt;p&gt;Web frameworks (and modern desktop frameworks are starting to do so) use a functional approach, the view is a pure function of the state of the application, when you need to change something you change the application state and the view updates automatically. This solves a lot of problems that you otherwise have.</text></item><item><author>JCWasmx86</author><text>&amp;gt; the desktop&amp;#x2F;UI sucks, its awful in almost every way, you are essentially targeting X11 which was developed in the 70’s and it shows.  It works and it brings a couple of quirky features to the table which are quite nice, but, in essence, if you love Linux, just forget targeting GUI desktop stuff, you need a graphics screen, a browser (for a real UI) and a terminal window – that’s it… there is the Wayland stuff but its far too early, it’s also disjointed, barley supported and is grappling with compatibility with legacy stuff…&lt;p&gt;When would you even want to target X11&amp;#x2F;Wayland directly? Just use a toolkit and ignore the underlying stuff. For 90% of the application it does not matter.&lt;p&gt;&amp;gt;  I find it difficult to see why this is going to change any time soon, the performance of a well written UI in a modern browser out-performs a native desktop application in every category of sped, usability and presentation for most usual use cases.&lt;p&gt;I always encounter the exact opposite. I&amp;#x27;ve never found any web application with a good UI or any web application that outperformed a native one.&lt;p&gt;&amp;gt; Could you imagine a future where desktop applications were built like this, and in every sense of the word, “portable between operating systems” with the experience being identical on all platforms…&lt;p&gt;This sounds more like a really crappy future, if anything looks everywhere the same. Applications must integrate with the &amp;quot;host&amp;quot;-OS.&lt;p&gt;The only reason the web stack is used for desktop applications is because it is a bit cheaper and less effort than writing a good - native application.&lt;p&gt;The lock-in argument is just a very weak one. At some point you depend on something. Oh, your HTML only renders fine in Chromium or you use Chromium only JS APIs - you are locked-in to Chromium now.</text></item></parent_chain><comment><author>xg15</author><text>Web &lt;i&gt;frameworks&lt;/i&gt; do, but the web platform, i.e. browsers don&amp;#x27;t. The basic abstraction of browsers is still the DOM, which follows the same basic idea of desktop UI toolkits: A tree of elements which you can modify imperatively, combined with event handlers. Only, it&amp;#x27;s far less sophisticated than the data models of UI toolkits and still optimized for the web&amp;#x27;s original use case, which were text documents.&lt;p&gt;A lot of the bloat and complexity of web frameworks comes from the issue that they basically have to implement a modern, functional UI toolkit on top of an ancient, imperative one.</text></comment>
<story><title>Why do we create modern desktop GUI apps using HTML/CSS/JavaScript? (2022)</title><url>https://gerrysweeney.com/why-do-write-desktop-gui-desktop-apps-in-html-css-javascript-making-them-just-glorified-web-pages/</url></story><parent_chain><item><author>alerighi</author><text>I think the difference is about frameworks. Typically desktop application frameworks (Windows Forms, GTK, QT, etc) follow an imperative approach, where you design your UI (maybe with a graphical designer) and attach callbacks to events, than then update the UI elements directly.&lt;p&gt;Web frameworks (and modern desktop frameworks are starting to do so) use a functional approach, the view is a pure function of the state of the application, when you need to change something you change the application state and the view updates automatically. This solves a lot of problems that you otherwise have.</text></item><item><author>JCWasmx86</author><text>&amp;gt; the desktop&amp;#x2F;UI sucks, its awful in almost every way, you are essentially targeting X11 which was developed in the 70’s and it shows.  It works and it brings a couple of quirky features to the table which are quite nice, but, in essence, if you love Linux, just forget targeting GUI desktop stuff, you need a graphics screen, a browser (for a real UI) and a terminal window – that’s it… there is the Wayland stuff but its far too early, it’s also disjointed, barley supported and is grappling with compatibility with legacy stuff…&lt;p&gt;When would you even want to target X11&amp;#x2F;Wayland directly? Just use a toolkit and ignore the underlying stuff. For 90% of the application it does not matter.&lt;p&gt;&amp;gt;  I find it difficult to see why this is going to change any time soon, the performance of a well written UI in a modern browser out-performs a native desktop application in every category of sped, usability and presentation for most usual use cases.&lt;p&gt;I always encounter the exact opposite. I&amp;#x27;ve never found any web application with a good UI or any web application that outperformed a native one.&lt;p&gt;&amp;gt; Could you imagine a future where desktop applications were built like this, and in every sense of the word, “portable between operating systems” with the experience being identical on all platforms…&lt;p&gt;This sounds more like a really crappy future, if anything looks everywhere the same. Applications must integrate with the &amp;quot;host&amp;quot;-OS.&lt;p&gt;The only reason the web stack is used for desktop applications is because it is a bit cheaper and less effort than writing a good - native application.&lt;p&gt;The lock-in argument is just a very weak one. At some point you depend on something. Oh, your HTML only renders fine in Chromium or you use Chromium only JS APIs - you are locked-in to Chromium now.</text></item></parent_chain><comment><author>ognarb</author><text>With Qt you can use QML and use a declarative language and this was way ahead of it&amp;#x27;s time when it was first released in 2009.</text></comment>