7 ms·

> 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 m

> 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 This definitely needs evidence to back it up since my personal experience (and apparently from reading the comments, others as well) is the opposite. Just be honest: the primary reason by far for the preference for GUIs using web tech over native is economics. One code base, multiple platforms. Native requires nontrivial per-target specialized code, which is expensive to develop and maintain. Web tech has given us the closest I can see to what Java promised but failed to adequately deliver: write once, run everywhere. I would guess there’s a secondary reason: the tech world has an excess of web tech developers running around, and they tend to use what they know - for better or worse.

hajile 4y ago
> I would guess there’s a secondary reason: the tech world has an excess of web tech developers running around, and they tend to use what they know - for better or worse. It's more about how users are affected by cost/performance tradeoffs. It costs less to make a web app than to make a native one on most platforms. The cost of porting that web app to multiple OSes is minuscule compared to writing versions of that app in several different languages/platforms. For users, it turns into "will you take 20% worse performance for 500% lower costs?" Most users will take that deal any day of the week.
- porcoda 4y ago
  You fixated on what I said was the secondary reason, and repeated in a rephrased way what I said was the primary reason - economics/cost. Given that users rarely get to make the choice, I’m not sure we have evidence saying people actually are happy with the sacrifice. I do know people complain a lot about battery life, laggy apps, and unpredictable behavior that often can be traced down to the technologies used to implement them. The problem is, your average user doesn’t actually know that’s the case, and doesn’t even realize that alternatives are even an option. People like me and the audience on HN are the outliers : most people have no clue what’s going on under their bank app, corporate app, ticket app, etc…
  - hajile 4y ago
    I know TONS of people (including high paid people) who refuse to pay $3 for a good app and instead opt for the free knockoff with tons of jank and nonstop ads.
- CyberDildonics 4y ago
  The cost of porting that web app to multiple OSes is minuscule compared to writing versions of that app in several different languages/platforms. I can never figure out where this idea comes from. Do javascript programmers not know about GUI libraries like Qt, FLTK, Juce, or that there are a huge number of cross platform libraries for C++ ? For users, it turns into "will you take 20% worse performance for 500% lower costs?" I think you mean running at 1/20th - 1/200th the speed of a native program and 10%-15% more time spent compiling and testing for each alternate platform. My experience is that it is mostly correcting errors that come from a different compiler. Almost every bit of C++ stays the same.
  - yamtaddle 4y ago
    The only time I've seen cross-platform webtech save meaningful amounts of time and money is when corporate weenies insist that the program look identical on every platform, rather than letting you use a native look for most of it. Styling every single input to look identical on every platform does indeed waste a lot of time—but that's not native's fault, it's the "everything must be On Brand at the expense of all other concerns" people's fault. Meanwhile I very much doubt the customer gives even a subconsious shit that your "app"'s radio buttons look identical to the (also custom) ones on your website. They probably do give a shit that they look unfamiliar compared with natives apps, so take a little more mental energy to process, and they probably do give a shit if your theming introduces any jankiness that wouldn't otherwise be there (and it very often does). But, yes, that level of making everything look and behave identically everywhere is far easier to achieve with webtech. But you could... just not, instead.
  - hajile 4y ago
    Qt development with C++ is slow. Development with QML means JS anyway (good luck finding JS devs with Qt experience) and still having to hire C++ devs too for non trivial apps.
    - CyberDildonics 4y ago
      Now you're changing your story. Before you said someone would have to "write versions of that app in several different languages/platforms." Qt development with C++ is slow. What are you basing that on? Development with QML means JS anyway That's actually only for parameters of the QML UI, which is a tiny part of working program. Actually the GUI that can be done through any library is a very tiny part of most programs. Declaring widgets and laying them out is not difficult or time consuming, there isn't much logic there. good luck finding JS devs with Qt experience Any competent C++ programmer can just start using javascript after a day or two of tutorials. There is no need to hire "a JS dev", you just hire a good programmer. Javascript is not that hard. Modern C++ is not even that hard, but as a language javascript is even easier. Anyone who calls themselves "a JS dev" is probably not that experienced to begin with. Learning languages is trivial to someone with experience. Have you ever made a GUI program with modern C++ and FLTK ? It's incredibly easy and the results are lightning quick while starting at 100KB.
- tmtvl 4y ago
  If application A costs $300 user/year and application B $60 user/year, then a 5% performance loss from using application B could easily cost a company $1200 employee/year. Though I may be misunderstanding your point.
  - hajile 4y ago
    The issue is UI jank and occasional UI slowness. If there’s any serious work, it’s probably implemented natively or with WASM, so computational performance isn’t terrible.
keithnz 4y ago
I think the clue is in the article, he worked on some badly designed legacy app....which he blames on the language / tech stack. I see this a lot across many tech stacks, people create some monster, but critical, application and then blame their woes on the tech stack :)

hajile 4y ago

> I would guess there’s a secondary reason: the tech world has an excess of web tech developers running around, and they tend to use what they know - for better or worse. It's more about how users are affected by cost/performance tradeoffs. It costs less to make a web app than to make a native one on most platforms. The cost of porting that web app to multiple OSes is minuscule compared to writing versions of that app in several different languages/platforms. For users, it turns into "will you take 20% worse performance for 500% lower costs?" Most users will take that deal any day of the week.

porcoda 4y ago
You fixated on what I said was the secondary reason, and repeated in a rephrased way what I said was the primary reason - economics/cost. Given that users rarely get to make the choice, I’m not sure we have evidence saying people actually are happy with the sacrifice. I do know people complain a lot about battery life, laggy apps, and unpredictable behavior that often can be traced down to the technologies used to implement them. The problem is, your average user doesn’t actually know that’s the case, and doesn’t even realize that alternatives are even an option. People like me and the audience on HN are the outliers : most people have no clue what’s going on under their bank app, corporate app, ticket app, etc…
- hajile 4y ago
  I know TONS of people (including high paid people) who refuse to pay $3 for a good app and instead opt for the free knockoff with tons of jank and nonstop ads.
CyberDildonics 4y ago
The cost of porting that web app to multiple OSes is minuscule compared to writing versions of that app in several different languages/platforms. I can never figure out where this idea comes from. Do javascript programmers not know about GUI libraries like Qt, FLTK, Juce, or that there are a huge number of cross platform libraries for C++ ? For users, it turns into "will you take 20% worse performance for 500% lower costs?" I think you mean running at 1/20th - 1/200th the speed of a native program and 10%-15% more time spent compiling and testing for each alternate platform. My experience is that it is mostly correcting errors that come from a different compiler. Almost every bit of C++ stays the same.
- yamtaddle 4y ago
  The only time I've seen cross-platform webtech save meaningful amounts of time and money is when corporate weenies insist that the program look identical on every platform, rather than letting you use a native look for most of it. Styling every single input to look identical on every platform does indeed waste a lot of time—but that's not native's fault, it's the "everything must be On Brand at the expense of all other concerns" people's fault. Meanwhile I very much doubt the customer gives even a subconsious shit that your "app"'s radio buttons look identical to the (also custom) ones on your website. They probably do give a shit that they look unfamiliar compared with natives apps, so take a little more mental energy to process, and they probably do give a shit if your theming introduces any jankiness that wouldn't otherwise be there (and it very often does). But, yes, that level of making everything look and behave identically everywhere is far easier to achieve with webtech. But you could... just not, instead.
- hajile 4y ago
  Qt development with C++ is slow. Development with QML means JS anyway (good luck finding JS devs with Qt experience) and still having to hire C++ devs too for non trivial apps.
  - CyberDildonics 4y ago
    Now you're changing your story. Before you said someone would have to "write versions of that app in several different languages/platforms." Qt development with C++ is slow. What are you basing that on? Development with QML means JS anyway That's actually only for parameters of the QML UI, which is a tiny part of working program. Actually the GUI that can be done through any library is a very tiny part of most programs. Declaring widgets and laying them out is not difficult or time consuming, there isn't much logic there. good luck finding JS devs with Qt experience Any competent C++ programmer can just start using javascript after a day or two of tutorials. There is no need to hire "a JS dev", you just hire a good programmer. Javascript is not that hard. Modern C++ is not even that hard, but as a language javascript is even easier. Anyone who calls themselves "a JS dev" is probably not that experienced to begin with. Learning languages is trivial to someone with experience. Have you ever made a GUI program with modern C++ and FLTK ? It's incredibly easy and the results are lightning quick while starting at 100KB.
tmtvl 4y ago
If application A costs $300 user/year and application B $60 user/year, then a 5% performance loss from using application B could easily cost a company $1200 employee/year. Though I may be misunderstanding your point.
- hajile 4y ago
  The issue is UI jank and occasional UI slowness. If there’s any serious work, it’s probably implemented natively or with WASM, so computational performance isn’t terrible.

keithnz 4y ago

I think the clue is in the article, he worked on some badly designed legacy app....which he blames on the language / tech stack. I see this a lot across many tech stacks, people create some monster, but critical, application and then blame their woes on the tech stack :)