4 ms·

Building desktop (or mobile) apps in JS is not compatible with craftsmanship, nor is it compatible with excellence. To those that truly care about excellence a

by blub 10y ago

Building desktop (or mobile) apps in JS is not compatible with craftsmanship, nor is it compatible with excellence. To those that truly care about excellence and don't merely pay lip service to it, there is only one way of building: using that platform's native toolkit. For project or ideological reasons one can make a compromise and use something like Qt, Xamarin or wxWidgets, etc. This leaves JS native-like apps for those that care about doing things fast by only using the knowledge they already have. That would perhaps be understandable, if they admitted that it's a big quality and performance compromise. Yes, we tried our best, but this is the only thing we could do with this budget/team/whatever. Totally fine. Instead we get uppity devs claiming that desktop apps will be killed and bragging about how they're delivering the best experiences. It's this toxic cocktail of arrogance and lack of ability that is intolerable.

pcwalton 10y ago
> To those that truly care about excellence and don't merely pay lip service to it, there is only one way of building: using that platform's native toolkit. Since you are clearly an expert here, can you explain to me how an immediate-mode API from the 1980s in which all painting is done via the painter's algorithm and context switches to kernel mode on every operation is superior to a declarative model that allows for global optimizations to minimize state changes and batch draw, in addition to using hardware Z-buffers to minimize overdraw?
- mixedCase 10y ago
  Aren't you the guy behind this https://github.com/pcwalton/libui-rs https://github.com/pcwalton/libui-rs ? Kind of strange to write bindings to something you hate so much. Or was it a changed of mind in the last 11 months? With that said, I do agree with you, but there's not a single solution out there that does this efficiently, a browser is a ginormous level of indirection after all. But if you want to spearhead such a thing I'm sure as hell interested.
  - pcwalton 10y ago
    Yeah, I wrote those bindings, though they're incomplete, and libui's memory management is so broken that I lost interest in finishing them. It's a fair point, however. :) Much of my interest in libui was (a) to provide platform support for the browser engine; (b) to provide a solution for simple projects that don't want large dependencies. I've always believed the native UI frameworks from the '90s to be poor fits for modern graphics hardware. But sometimes your workload is so simple you don't care about whether your UI is as fast as possible, and minimizing dependencies is a more important criterion. That's where simple native UI layers can be a good fit.
    - mixedCase 10y ago
      > I've always believed the native UI frameworks from the '90s to be poor fits for modern graphics hardware. Is there anything out there taking a better approach that works for native desktop? React Native and Flutter look like interesting solutions, but RN attempts to do all the hard work with JS, which is far from ideal; and Flutter is limited to Dart (which not that much better) and isn't getting any traction on desktop outside of the experimental Fuchsia.
  - Rapzid 10y ago
    What is this comp sci politico? Somebody writes a few bindings and that's evidence of their UI party affiliation?
    - mixedCase 10y ago
      What the hell? I knew the bindings because I've been investigating GUI solutions for Rust for the past few days, and was very surprised to see the author speak so poorly of a solution he poured time on; now people treat technical doubts as some sort of witch hunt?
      - Rapzid 10y ago
        I apologize if I miss-read that. At first it seemed like you were questioning his opinion based on his binding work. This whole section has a very polarized/aggro vibe that's putting me on guard against false dichotomies and dogmatic arguing :| I need a chill pill myself.
- pseudalopex 10y ago
  To me, "native toolkit" means standard UI elements, not the lowest-level API.
- blub 10y ago
  I'm not an expert and I don't want to be one, I just want to have access to quality tools (preferably open source) and I want the majority of developers to use those tools. Native UIs are efficient, web UIs aren't. It doesn't matter to me that they're built using painters, batch drawing or pixie dust as long as the API is sane and performant. I think your post is a nice summary of the thinking that got us here in the first place: experts always looking at the possible future optimizations and not stopping to think at the present quality or if it's at all reasonable to build complex UIs in a document mark-up language.
derefr 10y ago
> This leaves JS native-like apps for those that care about doing things fast by only using the knowledge they already have. What about the devs who care about shipping a lockstep-feature-parity multiplatform app, and are willing to go through whatever hassles it takes to get "write once, run [with platform-conformant controls + behaviors] anywhere"? Because that—and not "doing things fast" or "only using the knowledge they already have"—is the argument I hear for developing Electron apps. What would you suggest for those developers? Just give up on their desires and do 10x as much work (likely meaning being 10x as many people) to ship for every platform, like Facebook? Or go through months/years of initial effort to develop a cross-platform UI toolkit abstraction to build their app upon, like the browser chrome of Firefox and Chrome is targeted at? Use something like Java's Swing, and pretend that's better just because "at least it's not Javascript"? Ship a GTK or QT app that doesn't look/work natively on half your platforms?
- pseudalopex 10y ago
  When I've worked on multi-platform apps, the case for "write once, run anywhere" has always boiled down to developer hours and current knowledge. Sometimes someone suggests that a single GUI will mean less code and fewer bugs, but the ones with cross-platform GUI experience know that's optimistic. "10x as much work" is a huge overstatement, especially when platform conformance is a goal. For native look and feel, I'd pick Qt over Electron any day. The catch is that no toolkit can abstract away all the platform-specific details. A minimum-effort Electron app looks like a web page; a minimum-effort Qt app falls into the uncanny valley. There can be good reasons to choose Electron! But it also has drawbacks, and it isn't the only option.

by blub 10y ago

pcwalton 10y ago

> To those that truly care about excellence and don't merely pay lip service to it, there is only one way of building: using that platform's native toolkit. Since you are clearly an expert here, can you explain to me how an immediate-mode API from the 1980s in which all painting is done via the painter's algorithm and context switches to kernel mode on every operation is superior to a declarative model that allows for global optimizations to minimize state changes and batch draw, in addition to using hardware Z-buffers to minimize overdraw?

mixedCase 10y ago
Aren't you the guy behind this https://github.com/pcwalton/libui-rs https://github.com/pcwalton/libui-rs ? Kind of strange to write bindings to something you hate so much. Or was it a changed of mind in the last 11 months? With that said, I do agree with you, but there's not a single solution out there that does this efficiently, a browser is a ginormous level of indirection after all. But if you want to spearhead such a thing I'm sure as hell interested.
- pcwalton 10y ago
  Yeah, I wrote those bindings, though they're incomplete, and libui's memory management is so broken that I lost interest in finishing them. It's a fair point, however. :) Much of my interest in libui was (a) to provide platform support for the browser engine; (b) to provide a solution for simple projects that don't want large dependencies. I've always believed the native UI frameworks from the '90s to be poor fits for modern graphics hardware. But sometimes your workload is so simple you don't care about whether your UI is as fast as possible, and minimizing dependencies is a more important criterion. That's where simple native UI layers can be a good fit.
  - mixedCase 10y ago
    > I've always believed the native UI frameworks from the '90s to be poor fits for modern graphics hardware. Is there anything out there taking a better approach that works for native desktop? React Native and Flutter look like interesting solutions, but RN attempts to do all the hard work with JS, which is far from ideal; and Flutter is limited to Dart (which not that much better) and isn't getting any traction on desktop outside of the experimental Fuchsia.
- Rapzid 10y ago
  What is this comp sci politico? Somebody writes a few bindings and that's evidence of their UI party affiliation?
  - mixedCase 10y ago
    What the hell? I knew the bindings because I've been investigating GUI solutions for Rust for the past few days, and was very surprised to see the author speak so poorly of a solution he poured time on; now people treat technical doubts as some sort of witch hunt?
    - Rapzid 10y ago
      I apologize if I miss-read that. At first it seemed like you were questioning his opinion based on his binding work. This whole section has a very polarized/aggro vibe that's putting me on guard against false dichotomies and dogmatic arguing :| I need a chill pill myself.
pseudalopex 10y ago
To me, "native toolkit" means standard UI elements, not the lowest-level API.
blub 10y ago
I'm not an expert and I don't want to be one, I just want to have access to quality tools (preferably open source) and I want the majority of developers to use those tools. Native UIs are efficient, web UIs aren't. It doesn't matter to me that they're built using painters, batch drawing or pixie dust as long as the API is sane and performant. I think your post is a nice summary of the thinking that got us here in the first place: experts always looking at the possible future optimizations and not stopping to think at the present quality or if it's at all reasonable to build complex UIs in a document mark-up language.

derefr 10y ago

> This leaves JS native-like apps for those that care about doing things fast by only using the knowledge they already have. What about the devs who care about shipping a lockstep-feature-parity multiplatform app, and are willing to go through whatever hassles it takes to get "write once, run [with platform-conformant controls + behaviors] anywhere"? Because that—and not "doing things fast" or "only using the knowledge they already have"—is the argument I hear for developing Electron apps. What would you suggest for those developers? Just give up on their desires and do 10x as much work (likely meaning being 10x as many people) to ship for every platform, like Facebook? Or go through months/years of initial effort to develop a cross-platform UI toolkit abstraction to build their app upon, like the browser chrome of Firefox and Chrome is targeted at? Use something like Java's Swing, and pretend that's better just because "at least it's not Javascript"? Ship a GTK or QT app that doesn't look/work natively on half your platforms?

pseudalopex 10y ago
When I've worked on multi-platform apps, the case for "write once, run anywhere" has always boiled down to developer hours and current knowledge. Sometimes someone suggests that a single GUI will mean less code and fewer bugs, but the ones with cross-platform GUI experience know that's optimistic. "10x as much work" is a huge overstatement, especially when platform conformance is a goal. For native look and feel, I'd pick Qt over Electron any day. The catch is that no toolkit can abstract away all the platform-specific details. A minimum-effort Electron app looks like a web page; a minimum-effort Qt app falls into the uncanny valley. There can be good reasons to choose Electron! But it also has drawbacks, and it isn't the only option.