8 ms·

The problem I see with many electron applications isn't just that they're bloated (they probably are in about the same relation to average RAM that Tcl/Tk apps

by mhd 7y ago

The problem I see with many electron applications isn't just that they're bloated (they probably are in about the same relation to average RAM that Tcl/Tk apps were or early Gnome/Mono ones). [Edit: To clarify, I mean the average RAM at the time they were accused of bloat] It's that they're quite non-native. And not just in the "button borders are 1 pixel wider than usual" sense -- they're usually styled to resemble web applications, with big data views, Material UI, etc. Going from this to something more lightweight/native doesn't just require a different API, it requires a completely redesign. In other words: The Big Rewrite That We're Definitely Going To Do Someday(tm).

jlongster 7y ago
I agree with this too but this problem can be addressed by caring. I care. You can find a bunch of non-native interactions in my app but every time I work on it I make it better and implement more of a native feel (like disabling selecting text when you shouldn't be able to, etc). It's a balance - personally I think apps that focus on a specific platform is exclusionary. So accepting some non-native feel means more people can use my app. I agree that browsers make it hard though.
- mhd 7y ago
  I'd argue that despite all cries about non-native styling and behavior, MacOS Classic, OS X, Windows 95, OS/2, Next, Swing etc. had more in common with each other than they do with webapps (unless we're talking about ExtJS enterprise apps or the like). This won't matter as much for rich-text chat apps or the like, which always looked horribly non-native, over-styled, skeuomorphic (cf. Trillian)… But let's picture a database client or IDE. Those used to resemble regular desktop apps. Nowadays? Note that I'm not arguing about your article or even approach, I was just chiming in on the dislike for Electron in general, where I think bloat is the least of our worries. All this wasn't something new, the downturn of desktop UIs started way before, as people are now used to mobile and webapps and expect that kind of look and feel everywhere. The OS manufacturers definitely seem to approve and comply. You saw this happening in other places, before. Just look at enterprise Windows applications that were targeted to people used to terminal UIs (3270, VT220). Current UI trends are the same, just with spurious rounded corners instead of closely-grouped form elements…
  - SiVal 7y ago
    Yes, major desktop GUIs 20 yrs ago had more in common with each other than they have with web apps. They also had more in common with each other than with iOS and Android phones. Yet today, most people in the more-developed economies use desktop apps, web apps on desktop, phone apps and web apps on phone every day. Some even have GUI apps in their cars and on their wrists. And among the new desktop apps, they have apps that work with touch UI or keyboard and/or mouse, that are available on multiple platforms with significant UI differences, and that have mobile versions. The result for most users is that they use a whole medley of different UIs daily and are far more flexible about UIs than back in the day when you were either a Mac person or a Windows person exclusively and all of your apps were native apps on your one machine. As clients continue to diversify, as Web apps spread, as companies like Apple keep bumping the Mac UI to lower and lower priority and claim Mac (which mustn't have touch)/iPod/iPhone/AppleWatch all need different UIs and all must have some sort of web support, and Google, Facebook, Twitter, and Amazon apps in their wide and ever-changing variety are used more and more...the demand for consistent UI in the fine details is not nearly as big an issue for most people as it used to be.
- amelius 7y ago
  Also, as a user, I expect the UI of my apps to be somewhat inconsistent. If the app is perfectly consistent with the native guidelines, then that's a small plus. But any slightly inconsistent behavior can be quickly learned, and I don't consider it a big deal (again, as a user). Of course, if every app out there was perfectly consistent, then perhaps it would be a different story.
- jpwgarrison 7y ago
  > like disabling selecting text when you shouldn't be able to This is the worst thing in computers. Why would you EVER _block_ the ability to select text? I am engaged enough to want to select something you made! Embrace that, don't stop it!
  - jniedrauer 7y ago
    This is one of the reasons I despise touching Windows. Why on earth are error dialog boxes not selectable??
    - dflock 7y ago
      Yeah. However, when the dialog is focused you can press ctrl+c to copy it's contents to the clipboard.
      - j6m8 7y ago
        WHAT?! This changes everything.
      - jniedrauer 7y ago
        Who thought this was a good UX?
        dflock 7y ago
        The same people who wrote the Windows API, I guess.
  - automathematics 7y ago
    I got one. Because my electron app is a game. I don't want you interacting with text as text, it's supposed to be more of a "texture" like one would expect from a native DirectX implementation
  - Lerc 7y ago
    On the other hand I hate apps that have user interface elements where you can select the text by accident instead of interacting with the element that contains the text. Imagine what it would be like if a click and drag on a window title bar moved the window but a click and drag on the text part of the title bar just selected text. Back in the Amiga days there was a nice little app that let you go into selection mode and then draw a rect around anything and it would pseudo-ocr it. Surely something like that exists on current machines, but I havn't seen it.
vedantroy 7y ago
Most of the time, I don't see an issue with non-native looking UIs. Oftentimes, non-native UIs look better. VSCode and Atom both look great and they're non-native. I also think Slack looks pretty good too. Except for MacOS, native UI widgets generally seem to be pretty ugly. Even Microsoft is embracing non-native UI for its own Microsoft Office platform. Web-apps/material design, look sexy.
- weberc2 7y ago
  Microsoft has never had a consistent look and feel across its suite of applications. Windows Live Mail, Zune media player, Windows media player, the Office suite, etc all looked different and they all looked different than other Microsoft applications.
  - nradov 7y ago
    Microsoft has never had a consistent look and feel across consumer applications. The business applications are highly consistent.
    - weberc2 7y ago
      Interesting point, but that wasn't my experience. The office suite was consistent, but SharePoint differed markedly (at least in ~2010 when I last used it). IIS was different yet. I'm trying to think of other business-oriented MS products that I used (it's been a while)...
    - beart 7y ago
      Microsoft Teams, Skype, VS Code, Internet Explorer, System Center. Not sure you could argue these are non-business applications, and none of them seem very consistent to me.
      - Crespyl 7y ago
        Amusingly, Skype looked much more native before MS bought it out and redesigned everything.
pmarin 7y ago
The normal tclkit runtime with Tk is 6.1 Mb of disk space and 10-15 Mb of ram. The most bloated Tcl/Tk runtime I could find (undroidwish tcl/tk running on SDL + OpenGL and Anti-grain backend) is 23 Mb of disk space and 42 Mb of ram (including all the shared libraries). Hard to compare with a web engine in functionality and ram usage.
- jlongster 7y ago
  I just tried to get started with tclkit to try it out. The first result for "getting started tclkit" has links with 404. I was able to download a prebuilt binary for macOS which does run, but I can't find any clear tutorials for how to start building apps (the top result for "getting started" is from 2008). I decided to try some example apps instead, so downloaded some .kit files and tried to run them: % ./tclkit-8.6.3-macosx10.5-ix86+x86_64 fractal.kit 2019-06-25 12:14:12.541 tclkit-8.6.3-macosx10.5-ix86+x86_64[18970:1942703] -[TKWindow setCanCycle:]: unrecognized selector sent to instance 0x10023a910 2019-06-25 12:14:12.542 tclkit-8.6.3-macosx10.5-ix86+x86_64[18970:1942703] * Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[TKWindow setCanCycle:]: unrecognized selector sent to instance 0x10023a910' It crashes. Hard to compare with the ecosystem and maturity of the web.
  - hdfbdtbcdg 7y ago
    In my experience as a webdeveloper this is exactly the experience of the web.
- mhd 7y ago
  I was comparing it to the average RAM of computers when Tcl/Tk was still in its hype cycle and you heard bloat arguments against it, which must've been the 90s. When Tk was still yellow-ish.
  - pmarin 7y ago
    I am sorry I misunderstood your comment.
jrochkind1 7y ago
I think it's quite possible that the majority of users are the moment have no idea how to recognize "native UI" and won't know the difference either way. I do believe that a well-designed UI makes a difference, whether users realize it consciously or not. I am not sure whether how much an app stick to OS "native" idioms is actually significant for a well-designed UI in 2019; I think users don't spend enough time off the web to be used to those idioms anyway.
- AnIdiotOnTheNet 7y ago
  Can we, as an industry, please stop pointing to some strawman "majority of users" to justify our poor decisions? I'm kind of sick of everything sucking too, but can we at least admit that they suck because of us?
  - jrochkind1 7y ago
    I know what you're saying, but I think there's something here that isn't just BS or an admission of defeat. What if the way most people use their computers/devices now, sticking to a standard "OS native" design language simply doesn't benefit them. Then if it takes you more time/money to do so, that is time/money spent without actually helping anyone, when you could have been working on something that did. I'm not even talking about "helping your startup succeed", I mean literally, helping the users. Design matters, I'm a big believer in that. But you've got to design for your actual users in the actual world they are in, designing for the world you wish you had with the users behaving how you wished they behave... is the programmer's fallacy. I think it's a legitimate question, does an app "behaving native" (as far as UI/UX elements and the OS design patterns) actually help the users? Or do we just imagine/wish it would? Does it actually matter? Does it actually benefit real people users in the actual world? Maybe. I'm not sure it doesn't. But I'm suspicious enough to ask.
    - AnIdiotOnTheNet 7y ago
      > I think it's a legitimate question, does an app "behaving native" (as far as UI/UX elements and the OS design patterns) actually help the users? Hmm... does an application behaving according to the UX language of the rest of the system actually benefit the people using that system? Let me think about that. Nothing about the current trends in UI design are about a better experience for the user. Nothing. Ask anyone who relies on accessibility features, for instance. I'm sure we all love hijacked scrolling, pop-in content, pop-up boxes, etc. which is why they're there right? No, as usual users are just resigned to putting up with the bullshit that crappy developers deliver to them, and it is getting easier over time as they forget that things used to be better. You're not designing for users, you're designing for money, so at least take responsibility for making shit suck so you can put food on the table.
bsder 7y ago
> It's that they're quite non-native. To be fair, nobody cares. And I'm not just being snide. One of the social apps proudly wore it's "hard to use" interface as a way to scare off the grownups. And, personally, I'd rather have an app that scales it's interface elements nicely rather than the "detents" that we get at particular monitor resolution (Try scaling something like Reaper (They're not the only ones) to anything other than 2x on a 4K monitor--Umm, if I wanted a 1920x1080 monitor, I'd have bought one, thanks. What I want is for you to scale to about 150% so that I get more screen elements AND they're larger). Add the fact that "screencasting" is much easier if the application renders all its elements, and you've got a lot of reasons to go non-native and never look back.
- zapzupnz 7y ago
  > To be fair, nobody cares I think people do care, but they don't know what they dislike. I mean, there are certain things we tolerate on the web, like a UI taking a while to load. We don't tolerate that in native apps — even if the content is missing, I still expect the interface to show up instantly. It's not a question of native vs web apps. It's a question of "does this fulfil the expectations I set for native apps?" My position is that frameworks like Electron and React Native aren't amenable to fulfilling those expectations but they are capable of doing so if the developers put in the extra work. It's just a shame that so many developers don't, and their sloppy efforts become the poster children for these web apps. At the same time, my position is also that if you're going to put in that extra work to make web apps feel right natively, you could probably have done native UIs to start with.
tinus_hn 7y ago
Allowing cross platform development of complex user interfaces automatically leads to that.

by mhd 7y ago

jlongster 7y ago

I agree with this too but this problem can be addressed by caring. I care. You can find a bunch of non-native interactions in my app but every time I work on it I make it better and implement more of a native feel (like disabling selecting text when you shouldn't be able to, etc). It's a balance - personally I think apps that focus on a specific platform is exclusionary. So accepting some non-native feel means more people can use my app. I agree that browsers make it hard though.

mhd 7y ago
I'd argue that despite all cries about non-native styling and behavior, MacOS Classic, OS X, Windows 95, OS/2, Next, Swing etc. had more in common with each other than they do with webapps (unless we're talking about ExtJS enterprise apps or the like). This won't matter as much for rich-text chat apps or the like, which always looked horribly non-native, over-styled, skeuomorphic (cf. Trillian)… But let's picture a database client or IDE. Those used to resemble regular desktop apps. Nowadays? Note that I'm not arguing about your article or even approach, I was just chiming in on the dislike for Electron in general, where I think bloat is the least of our worries. All this wasn't something new, the downturn of desktop UIs started way before, as people are now used to mobile and webapps and expect that kind of look and feel everywhere. The OS manufacturers definitely seem to approve and comply. You saw this happening in other places, before. Just look at enterprise Windows applications that were targeted to people used to terminal UIs (3270, VT220). Current UI trends are the same, just with spurious rounded corners instead of closely-grouped form elements…
- SiVal 7y ago
  Yes, major desktop GUIs 20 yrs ago had more in common with each other than they have with web apps. They also had more in common with each other than with iOS and Android phones. Yet today, most people in the more-developed economies use desktop apps, web apps on desktop, phone apps and web apps on phone every day. Some even have GUI apps in their cars and on their wrists. And among the new desktop apps, they have apps that work with touch UI or keyboard and/or mouse, that are available on multiple platforms with significant UI differences, and that have mobile versions. The result for most users is that they use a whole medley of different UIs daily and are far more flexible about UIs than back in the day when you were either a Mac person or a Windows person exclusively and all of your apps were native apps on your one machine. As clients continue to diversify, as Web apps spread, as companies like Apple keep bumping the Mac UI to lower and lower priority and claim Mac (which mustn't have touch)/iPod/iPhone/AppleWatch all need different UIs and all must have some sort of web support, and Google, Facebook, Twitter, and Amazon apps in their wide and ever-changing variety are used more and more...the demand for consistent UI in the fine details is not nearly as big an issue for most people as it used to be.
amelius 7y ago
Also, as a user, I expect the UI of my apps to be somewhat inconsistent. If the app is perfectly consistent with the native guidelines, then that's a small plus. But any slightly inconsistent behavior can be quickly learned, and I don't consider it a big deal (again, as a user). Of course, if every app out there was perfectly consistent, then perhaps it would be a different story.
jpwgarrison 7y ago
> like disabling selecting text when you shouldn't be able to This is the worst thing in computers. Why would you EVER _block_ the ability to select text? I am engaged enough to want to select something you made! Embrace that, don't stop it!
- jniedrauer 7y ago
  This is one of the reasons I despise touching Windows. Why on earth are error dialog boxes not selectable??
  - dflock 7y ago
    Yeah. However, when the dialog is focused you can press ctrl+c to copy it's contents to the clipboard.
    - j6m8 7y ago
      WHAT?! This changes everything.
    - jniedrauer 7y ago
      Who thought this was a good UX?
      - dflock 7y ago
        The same people who wrote the Windows API, I guess.
- automathematics 7y ago
  I got one. Because my electron app is a game. I don't want you interacting with text as text, it's supposed to be more of a "texture" like one would expect from a native DirectX implementation
- Lerc 7y ago
  On the other hand I hate apps that have user interface elements where you can select the text by accident instead of interacting with the element that contains the text. Imagine what it would be like if a click and drag on a window title bar moved the window but a click and drag on the text part of the title bar just selected text. Back in the Amiga days there was a nice little app that let you go into selection mode and then draw a rect around anything and it would pseudo-ocr it. Surely something like that exists on current machines, but I havn't seen it.

vedantroy 7y ago

Most of the time, I don't see an issue with non-native looking UIs. Oftentimes, non-native UIs look better. VSCode and Atom both look great and they're non-native. I also think Slack looks pretty good too. Except for MacOS, native UI widgets generally seem to be pretty ugly. Even Microsoft is embracing non-native UI for its own Microsoft Office platform. Web-apps/material design, look sexy.

weberc2 7y ago
Microsoft has never had a consistent look and feel across its suite of applications. Windows Live Mail, Zune media player, Windows media player, the Office suite, etc all looked different and they all looked different than other Microsoft applications.
- nradov 7y ago
  Microsoft has never had a consistent look and feel across consumer applications. The business applications are highly consistent.
  - weberc2 7y ago
    Interesting point, but that wasn't my experience. The office suite was consistent, but SharePoint differed markedly (at least in ~2010 when I last used it). IIS was different yet. I'm trying to think of other business-oriented MS products that I used (it's been a while)...
  - beart 7y ago
    Microsoft Teams, Skype, VS Code, Internet Explorer, System Center. Not sure you could argue these are non-business applications, and none of them seem very consistent to me.
    - Crespyl 7y ago
      Amusingly, Skype looked much more native before MS bought it out and redesigned everything.

pmarin 7y ago

The normal tclkit runtime with Tk is 6.1 Mb of disk space and 10-15 Mb of ram. The most bloated Tcl/Tk runtime I could find (undroidwish tcl/tk running on SDL + OpenGL and Anti-grain backend) is 23 Mb of disk space and 42 Mb of ram (including all the shared libraries). Hard to compare with a web engine in functionality and ram usage.

jlongster 7y ago
I just tried to get started with tclkit to try it out. The first result for "getting started tclkit" has links with 404. I was able to download a prebuilt binary for macOS which does run, but I can't find any clear tutorials for how to start building apps (the top result for "getting started" is from 2008). I decided to try some example apps instead, so downloaded some .kit files and tried to run them: % ./tclkit-8.6.3-macosx10.5-ix86+x86_64 fractal.kit 2019-06-25 12:14:12.541 tclkit-8.6.3-macosx10.5-ix86+x86_64[18970:1942703] -[TKWindow setCanCycle:]: unrecognized selector sent to instance 0x10023a910 2019-06-25 12:14:12.542 tclkit-8.6.3-macosx10.5-ix86+x86_64[18970:1942703] * Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[TKWindow setCanCycle:]: unrecognized selector sent to instance 0x10023a910' It crashes. Hard to compare with the ecosystem and maturity of the web.
- hdfbdtbcdg 7y ago
  In my experience as a webdeveloper this is exactly the experience of the web.
mhd 7y ago
I was comparing it to the average RAM of computers when Tcl/Tk was still in its hype cycle and you heard bloat arguments against it, which must've been the 90s. When Tk was still yellow-ish.
- pmarin 7y ago
  I am sorry I misunderstood your comment.

jrochkind1 7y ago

I think it's quite possible that the majority of users are the moment have no idea how to recognize "native UI" and won't know the difference either way. I do believe that a well-designed UI makes a difference, whether users realize it consciously or not. I am not sure whether how much an app stick to OS "native" idioms is actually significant for a well-designed UI in 2019; I think users don't spend enough time off the web to be used to those idioms anyway.

AnIdiotOnTheNet 7y ago
Can we, as an industry, please stop pointing to some strawman "majority of users" to justify our poor decisions? I'm kind of sick of everything sucking too, but can we at least admit that they suck because of us?
- jrochkind1 7y ago
  I know what you're saying, but I think there's something here that isn't just BS or an admission of defeat. What if the way most people use their computers/devices now, sticking to a standard "OS native" design language simply doesn't benefit them. Then if it takes you more time/money to do so, that is time/money spent without actually helping anyone, when you could have been working on something that did. I'm not even talking about "helping your startup succeed", I mean literally, helping the users. Design matters, I'm a big believer in that. But you've got to design for your actual users in the actual world they are in, designing for the world you wish you had with the users behaving how you wished they behave... is the programmer's fallacy. I think it's a legitimate question, does an app "behaving native" (as far as UI/UX elements and the OS design patterns) actually help the users? Or do we just imagine/wish it would? Does it actually matter? Does it actually benefit real people users in the actual world? Maybe. I'm not sure it doesn't. But I'm suspicious enough to ask.
  - AnIdiotOnTheNet 7y ago
    > I think it's a legitimate question, does an app "behaving native" (as far as UI/UX elements and the OS design patterns) actually help the users? Hmm... does an application behaving according to the UX language of the rest of the system actually benefit the people using that system? Let me think about that. Nothing about the current trends in UI design are about a better experience for the user. Nothing. Ask anyone who relies on accessibility features, for instance. I'm sure we all love hijacked scrolling, pop-in content, pop-up boxes, etc. which is why they're there right? No, as usual users are just resigned to putting up with the bullshit that crappy developers deliver to them, and it is getting easier over time as they forget that things used to be better. You're not designing for users, you're designing for money, so at least take responsibility for making shit suck so you can put food on the table.

bsder 7y ago

> It's that they're quite non-native. To be fair, nobody cares. And I'm not just being snide. One of the social apps proudly wore it's "hard to use" interface as a way to scare off the grownups. And, personally, I'd rather have an app that scales it's interface elements nicely rather than the "detents" that we get at particular monitor resolution (Try scaling something like Reaper (They're not the only ones) to anything other than 2x on a 4K monitor--Umm, if I wanted a 1920x1080 monitor, I'd have bought one, thanks. What I want is for you to scale to about 150% so that I get more screen elements AND they're larger). Add the fact that "screencasting" is much easier if the application renders all its elements, and you've got a lot of reasons to go non-native and never look back.

zapzupnz 7y ago
> To be fair, nobody cares I think people do care, but they don't know what they dislike. I mean, there are certain things we tolerate on the web, like a UI taking a while to load. We don't tolerate that in native apps — even if the content is missing, I still expect the interface to show up instantly. It's not a question of native vs web apps. It's a question of "does this fulfil the expectations I set for native apps?" My position is that frameworks like Electron and React Native aren't amenable to fulfilling those expectations but they are capable of doing so if the developers put in the extra work. It's just a shame that so many developers don't, and their sloppy efforts become the poster children for these web apps. At the same time, my position is also that if you're going to put in that extra work to make web apps feel right natively, you could probably have done native UIs to start with.

tinus_hn 7y ago

Allowing cross platform development of complex user interfaces automatically leads to that.