8 ms·

> what stops QT from taking over all multi-platform targeted applications The fact that Electron is much better. I know this in a highly unpopular opinion here

by 21 8y ago

> what stops QT from taking over all multi-platform targeted applications The fact that Electron is much better. I know this in a highly unpopular opinion here. I've programmed in them all (MFC/wxWidgets/QT/WinForms/WPF) and HTML/CSS/JS is just so much easier.

pjmlp 8y ago
CSS3 hackary better than native frameworks?! Not really. Maybe when I get to see Blend implemented with WebComponents.
- dimgl 8y ago
  Hackery*, and I'm not sure why the hate towards CSS3. With a few lines of code I can build a pretty good looking responsive UI that doesn't take hours to polish.
  - pjmlp 8y ago
    Yeah, when running on a specific browser version targeting a single OS.
    - pcwalton 8y ago
      That's hardly true when it comes to CSS3 stuff that's been around for a decade. Moreover, it's unfair to insist on portability when comparing native vs. Web without doing the same on the native side.
      - pjmlp 8y ago
        Only if the only browsers one cares about are latest version of Chrome and Safari. There plenty of deployment scenarios with other kinds of browsers. Of course it is fair, using something like Qt, wxWidgets, or even roll our own was never as complicated to get pixel perfect UI across OSes.
        crzwdjk 8y ago
        Is pixel perfect UI really what you even want these days? With high-DPI screens and screen scaling being a thing, not everyone's pixels are the same. And that's not even talking about accessibility for people with low vision who want text to be big and readable.
  - sireat 8y ago
    I'd give my left toe to learn to do this in a few lines of code in HTML/CSS3. Desktop centric UI toolkits provide a set of widgets which lets me build up a UI in a predictable way that respects my sanity. Windows Forms, WPF, Qt, vxWidgets, tkinter, Java AWT, SWT etc they all have warts but ALL of them feel faster than building UI for the web. The problem with web is that there are no consistent set of widgets. Let's take a stupid date picker. A year ago for a project I thought I'd use the HTML5 <input type="date"/> way no Javascript needed! Sadly I couldn't figure out a way to keep the calendar in an always on state so had to resort to jQuery datepicker. So jQuery widgets was an attempt to do what desktop UI does but now that is no longer in vogue. Today on the web there is no consistency, there is no agreed upon toolkit. How many different approaches to widgets does React have? Ideally you would be able to import a web component into your project and use it without worrying about any abstractions leaking.
- htor 8y ago
  ...and what do you think is used to style webcomponents?
  - pjmlp 8y ago
    Lots of CSS hacks to make them work properly across all browser versions and OSes.
    - littlestymaar 8y ago
      What year do you live in? 2010? The most wanted features from CSS3 have been supported everywhere for years! Look at the support for (flexbox)[https://caniuse.com/#search=flexbox https://caniuse.com/#search=flexbox] for instance.
      - pjmlp 8y ago
        In the year where not all deployment targets are using the latest Chrome and Safari. Where there are devices beyond computers and smart phones with browsers on them, the majority of them without any kind of update system in place and based in some kind of browser implementation.
    - hesarenu 8y ago
      You are not familiar with web are you?
      - pjmlp 8y ago
        Doing web projects since 1997, coding across multiple platforms since 1986.
        hesarenu 8y ago
        So not familiar with modern development? Since you don't need much CSS hacks now.
- littlestymaar 8y ago
  «native frameworks» => if you want a true native framework, you need one specific development per platform. Or more realistically, you end up developing for Windows only, unless you target a specific niche where MacOS is somewhat relevant, and never Linux. Or you use a cross-plateform (not so native then) UI toolkit, like Qt. You have a sub-part UI experience and you still need to write C++. Why would you do that ? (And that's why the vast majority of software isn't developed this way). CSS and JavaScript have quirks, but I mean, we're talking about C++ as an alternative …
  - pseudalopex 8y ago
    Qt has bindings for many languages, including JavaScript. It's capable of delivering experiences much closer to native than any Electron app I've ever seen. The catch is that a minimum-effort Electron app feels like a web page but a minimum-effort Qt app feels like a bad native app. There are also frameworks like wxWidgets that use actual native controls.
  - pjmlp 8y ago
    No, you develop like we did on the 16 bit days. Either do a new one for platform, which was the case when Assembly ruled. Or make a proper application architecture suited to the applications being done in-house, that wraps the native APIs into general ones. C++ is strongly typed and compiles to native code, a much saner alternative than "anything goes JS". And CSS + JS are miles away what something like VB, Delphi or Smalltalk allowed in the early 90's. Yes I know they weren't responsive and whatever. There were layout managers already available, it was just a matter of actually using them. Vast majority isn't developed that way, because it is cheaper to pay to young inexperience JS developers that are re-inventing the idioms of the 90's desktop UIs[0], than experienced C++ developers aware of what actually takes to make a good UI/UX. [0] - https://bitquabit.com/post/the-more-things-change/ https://bitquabit.com/post/the-more-things-change/
    - littlestymaar 8y ago
      > Vast majority isn't developed that way, because it is cheaper to pay to young inexperience JS developers […], than experienced C++ developers I think you just nailed the essential point: in 2010+, the young and cheap developers are JavaScript ones, and not C++ ones. Maybe that tells something about which one is the most accessible, don't you think?
sho_hn 8y ago
Having recently made a website with a non-trivial layout that required lots of ugly JS to implement adequate scaling and bevavior, boy, I can't disagree more. I do UI in QML in $dayJob and gained a whole new appreciation for how much simpler and faster it is to achieve similar results in a more consciously crafted language. Unfortunately it was our wedding website and I didn't think "let's hold off until I can use Qt/WASM" would go over too well ... :-)
- dimgl 8y ago
  > QML > consciously crafted LOL
  - sho_hn 8y ago
    Now QML has its warts for sure, but it benefits from being designed with well-known use cases in mind, so it has lots of features suitable to them. HTML was designed for structured, flowing text documents and everything else got bolted on top with only partial awareness of where the journey was headed (reading up on the origins of stylesheets and the relevant discussions is interesting in this respect). As a result it's just a mess for what it's used for now, pain-alleviating salves like flexbox notwithstanding. When I do any non-trivial UI in the web stack, I can feel I am in continuous workaround territory. I'm trying to bend something ill-suited to my will. I don't get that feeling with QML.
    - martin_ky 8y ago
      > When I do any non-trivial UI in the web stack, I can feel I am in continuous workaround territory. I'm trying to bend something ill-suited to my will. I don't get that feeling with QML. That has been my experience as well. I think the web dev crowd advocating HTML/CSS originates in a) limited knowledge beyond the web tech field, and/or b) thinking that web is the state-of-the-art of computing. The trouble with modern web is, that it was not so much designed as it evolved. But evolution in general is doggone slow and produces mistakes and mutations. I think the evolution of the web platform is still in a very early phase.
- 8y ago
shittyadmin 8y ago
Try writing something as simple as a dialog in Qt. It all makes sense, you subclass a QDialog, instantiate it and show it. Try doing that in pure HTML/CSS/JS, you're basically left with a clusterfuck. There's piles and piles of libraries built to workaround this clusterfuck from Bootstrap to react-modal and even the best of them have worse APIs for this than Qt does. Ultimately, drawing widgets just makes more sense for desktop applications than trying to hack document-oriented HTML to be a usable UI framework. Don't get me started on layouts...
- htor 8y ago
  if you're having a hard time doing modals and layouts with html and css you should perhaps start over and try grasping the core concepts. this system, unlike qt, is about separation of concerns, so structure and presentation are defined separately. far from a clusterfuck, it's actually a very good idea. if you are having a hard time finding non-crap libraries, then build your own pile of shit library. at least there are plenty of choices to pick from. it's called an ecosystem and it, unfortunately, is what you people don't have.
- dchest 8y ago
  <dialog> <p>Hello world</p> <button>OK</button> </dialog> <script> let dialog = document.querySelector('dialog'); dialog.querySelector('button').addEventListener('click', () => dialog.close()); dialog.showModal(); </script>
  - deleted 8y ago
    [deleted]
  - yoavm 8y ago
    Yeah, it would be great when it'll work for more than just 60% of the internet users. Maybe then we can actually use it!
    - dchest 8y ago
      I'm so sorry that a little bit of HTML and JavaScript reminds you and other commenters under my post of web developer's Old Browser nightmares and brave endeavors of satisfying 100% of Web users at any the cost, but we're talking about Electron which ships a quite recent version of Chromium :-)
remoroid 8y ago
No... Leaving aside your opinion that Electron is easier, Electron forces an unsolvable problem on you - the performance of the app is horrible. A bare bones nothing Electron app idles using 150mb ram and has a huge binary size, all 25 million lines of chromium and nodejs. And Javascript is slow and not designed for application programming.
- 21 8y ago
  Sounds like the argument C++ programmers use against Python.
  - remoroid 8y ago
    You're not responding to my point though? I have a slow laptop, and I cant run Electron apps. If I run a Qt app, it runs beautifully. Would people use VLC if it was made in Electron? No. I like Python too.
    - 21 8y ago
      Not everybody has a slow laptop. And while people wax how computers from 80s were booting in 2 seconds and everything was lightning fast compared to the bloated software of today, there doesn't seem to be much of a movement towards ditching todays computers and going back to Windows 95 and Mac OS 9. https://insights.stackoverflow.com/survey/2018/#development-environments-and-tools https://insights.stackoverflow.com/survey/2018/#development-...
      - remoroid 8y ago
        > Not everybody has a slow laptop No shit, my point was, and still is, Electron has extremely poor performance, and theres no reason to use it over Qt.. You still havent responded to my point..
Tehdasi 8y ago
It's more DOM vs. whatever framework. DOM is very good for laying out webpages, but seriously falls over when trying to do layout for applications. The layout of the frameworks you mention are all designed around making application layout as efficient as possible. Although WPF stands out, it's layout is for more DOM like than the others, and suffers for it.

by 21 8y ago

pjmlp 8y ago

CSS3 hackary better than native frameworks?! Not really. Maybe when I get to see Blend implemented with WebComponents.

dimgl 8y ago
Hackery*, and I'm not sure why the hate towards CSS3. With a few lines of code I can build a pretty good looking responsive UI that doesn't take hours to polish.
- pjmlp 8y ago
  Yeah, when running on a specific browser version targeting a single OS.
  - pcwalton 8y ago
    That's hardly true when it comes to CSS3 stuff that's been around for a decade. Moreover, it's unfair to insist on portability when comparing native vs. Web without doing the same on the native side.
    - pjmlp 8y ago
      Only if the only browsers one cares about are latest version of Chrome and Safari. There plenty of deployment scenarios with other kinds of browsers. Of course it is fair, using something like Qt, wxWidgets, or even roll our own was never as complicated to get pixel perfect UI across OSes.
      - crzwdjk 8y ago
        Is pixel perfect UI really what you even want these days? With high-DPI screens and screen scaling being a thing, not everyone's pixels are the same. And that's not even talking about accessibility for people with low vision who want text to be big and readable.
- sireat 8y ago
  I'd give my left toe to learn to do this in a few lines of code in HTML/CSS3. Desktop centric UI toolkits provide a set of widgets which lets me build up a UI in a predictable way that respects my sanity. Windows Forms, WPF, Qt, vxWidgets, tkinter, Java AWT, SWT etc they all have warts but ALL of them feel faster than building UI for the web. The problem with web is that there are no consistent set of widgets. Let's take a stupid date picker. A year ago for a project I thought I'd use the HTML5 <input type="date"/> way no Javascript needed! Sadly I couldn't figure out a way to keep the calendar in an always on state so had to resort to jQuery datepicker. So jQuery widgets was an attempt to do what desktop UI does but now that is no longer in vogue. Today on the web there is no consistency, there is no agreed upon toolkit. How many different approaches to widgets does React have? Ideally you would be able to import a web component into your project and use it without worrying about any abstractions leaking.
htor 8y ago
...and what do you think is used to style webcomponents?
- pjmlp 8y ago
  Lots of CSS hacks to make them work properly across all browser versions and OSes.
  - littlestymaar 8y ago
    What year do you live in? 2010? The most wanted features from CSS3 have been supported everywhere for years! Look at the support for (flexbox)[https://caniuse.com/#search=flexbox https://caniuse.com/#search=flexbox] for instance.
    - pjmlp 8y ago
      In the year where not all deployment targets are using the latest Chrome and Safari. Where there are devices beyond computers and smart phones with browsers on them, the majority of them without any kind of update system in place and based in some kind of browser implementation.
  - hesarenu 8y ago
    You are not familiar with web are you?
    - pjmlp 8y ago
      Doing web projects since 1997, coding across multiple platforms since 1986.
      - hesarenu 8y ago
        So not familiar with modern development? Since you don't need much CSS hacks now.
littlestymaar 8y ago
«native frameworks» => if you want a true native framework, you need one specific development per platform. Or more realistically, you end up developing for Windows only, unless you target a specific niche where MacOS is somewhat relevant, and never Linux. Or you use a cross-plateform (not so native then) UI toolkit, like Qt. You have a sub-part UI experience and you still need to write C++. Why would you do that ? (And that's why the vast majority of software isn't developed this way). CSS and JavaScript have quirks, but I mean, we're talking about C++ as an alternative …
- pseudalopex 8y ago
  Qt has bindings for many languages, including JavaScript. It's capable of delivering experiences much closer to native than any Electron app I've ever seen. The catch is that a minimum-effort Electron app feels like a web page but a minimum-effort Qt app feels like a bad native app. There are also frameworks like wxWidgets that use actual native controls.
- pjmlp 8y ago
  No, you develop like we did on the 16 bit days. Either do a new one for platform, which was the case when Assembly ruled. Or make a proper application architecture suited to the applications being done in-house, that wraps the native APIs into general ones. C++ is strongly typed and compiles to native code, a much saner alternative than "anything goes JS". And CSS + JS are miles away what something like VB, Delphi or Smalltalk allowed in the early 90's. Yes I know they weren't responsive and whatever. There were layout managers already available, it was just a matter of actually using them. Vast majority isn't developed that way, because it is cheaper to pay to young inexperience JS developers that are re-inventing the idioms of the 90's desktop UIs[0], than experienced C++ developers aware of what actually takes to make a good UI/UX. [0] - https://bitquabit.com/post/the-more-things-change/ https://bitquabit.com/post/the-more-things-change/
  - littlestymaar 8y ago
    > Vast majority isn't developed that way, because it is cheaper to pay to young inexperience JS developers […], than experienced C++ developers I think you just nailed the essential point: in 2010+, the young and cheap developers are JavaScript ones, and not C++ ones. Maybe that tells something about which one is the most accessible, don't you think?

sho_hn 8y ago

Having recently made a website with a non-trivial layout that required lots of ugly JS to implement adequate scaling and bevavior, boy, I can't disagree more. I do UI in QML in $dayJob and gained a whole new appreciation for how much simpler and faster it is to achieve similar results in a more consciously crafted language. Unfortunately it was our wedding website and I didn't think "let's hold off until I can use Qt/WASM" would go over too well ... :-)

dimgl 8y ago
> QML > consciously crafted LOL
- sho_hn 8y ago
  Now QML has its warts for sure, but it benefits from being designed with well-known use cases in mind, so it has lots of features suitable to them. HTML was designed for structured, flowing text documents and everything else got bolted on top with only partial awareness of where the journey was headed (reading up on the origins of stylesheets and the relevant discussions is interesting in this respect). As a result it's just a mess for what it's used for now, pain-alleviating salves like flexbox notwithstanding. When I do any non-trivial UI in the web stack, I can feel I am in continuous workaround territory. I'm trying to bend something ill-suited to my will. I don't get that feeling with QML.
  - martin_ky 8y ago
    > When I do any non-trivial UI in the web stack, I can feel I am in continuous workaround territory. I'm trying to bend something ill-suited to my will. I don't get that feeling with QML. That has been my experience as well. I think the web dev crowd advocating HTML/CSS originates in a) limited knowledge beyond the web tech field, and/or b) thinking that web is the state-of-the-art of computing. The trouble with modern web is, that it was not so much designed as it evolved. But evolution in general is doggone slow and produces mistakes and mutations. I think the evolution of the web platform is still in a very early phase.
8y ago

shittyadmin 8y ago

Try writing something as simple as a dialog in Qt. It all makes sense, you subclass a QDialog, instantiate it and show it. Try doing that in pure HTML/CSS/JS, you're basically left with a clusterfuck. There's piles and piles of libraries built to workaround this clusterfuck from Bootstrap to react-modal and even the best of them have worse APIs for this than Qt does. Ultimately, drawing widgets just makes more sense for desktop applications than trying to hack document-oriented HTML to be a usable UI framework. Don't get me started on layouts...

htor 8y ago
if you're having a hard time doing modals and layouts with html and css you should perhaps start over and try grasping the core concepts. this system, unlike qt, is about separation of concerns, so structure and presentation are defined separately. far from a clusterfuck, it's actually a very good idea. if you are having a hard time finding non-crap libraries, then build your own pile of shit library. at least there are plenty of choices to pick from. it's called an ecosystem and it, unfortunately, is what you people don't have.
dchest 8y ago
<dialog> <p>Hello world</p> <button>OK</button> </dialog> <script> let dialog = document.querySelector('dialog'); dialog.querySelector('button').addEventListener('click', () => dialog.close()); dialog.showModal(); </script>
- deleted 8y ago
  [deleted]
- yoavm 8y ago
  Yeah, it would be great when it'll work for more than just 60% of the internet users. Maybe then we can actually use it!
  - dchest 8y ago
    I'm so sorry that a little bit of HTML and JavaScript reminds you and other commenters under my post of web developer's Old Browser nightmares and brave endeavors of satisfying 100% of Web users at any the cost, but we're talking about Electron which ships a quite recent version of Chromium :-)

remoroid 8y ago

No... Leaving aside your opinion that Electron is easier, Electron forces an unsolvable problem on you - the performance of the app is horrible. A bare bones nothing Electron app idles using 150mb ram and has a huge binary size, all 25 million lines of chromium and nodejs. And Javascript is slow and not designed for application programming.

21 8y ago
Sounds like the argument C++ programmers use against Python.
- remoroid 8y ago
  You're not responding to my point though? I have a slow laptop, and I cant run Electron apps. If I run a Qt app, it runs beautifully. Would people use VLC if it was made in Electron? No. I like Python too.
  - 21 8y ago
    Not everybody has a slow laptop. And while people wax how computers from 80s were booting in 2 seconds and everything was lightning fast compared to the bloated software of today, there doesn't seem to be much of a movement towards ditching todays computers and going back to Windows 95 and Mac OS 9. https://insights.stackoverflow.com/survey/2018/#development-environments-and-tools https://insights.stackoverflow.com/survey/2018/#development-...
    - remoroid 8y ago
      > Not everybody has a slow laptop No shit, my point was, and still is, Electron has extremely poor performance, and theres no reason to use it over Qt.. You still havent responded to my point..

Tehdasi 8y ago

It's more DOM vs. whatever framework. DOM is very good for laying out webpages, but seriously falls over when trying to do layout for applications. The layout of the frameworks you mention are all designed around making application layout as efficient as possible. Although WPF stands out, it's layout is for more DOM like than the others, and suffers for it.