6 ms·

> What other rendering engine are you going to use? the native window environment? > any serious UI toolkit in 2022 is certainly going to need a WebView UI co

> What other rendering engine are you going to use? the native window environment? > any serious UI toolkit in 2022 is certainly going to need a WebView UI component citation needed. why do slack and discord - communication applications - need a web view component? > In that case, why not just use the web rendering engine as your main rendering engine? because, aside from the frankly obscene memory usage, it adds so much to the binary (mIRC used to fit on a floppy), it’s slow, is bad for battery usage, it doesn’t look in line with native apps, and it’s a huge attack vector.

qorrect 5y ago
> it’s a huge attack vector. I'm confused by this phrase. Wouldn't it have a 'huge attack vector space' ? I never really understood that phrase.
- nurettin 5y ago
  vector is like an angle and a magnitude, perhaps you mean attack surface, which is the integral of known attack vectors.
- otterley 5y ago
  Vector is being used here in the epidemiological sense, not the mathematical sense.
klabb3 5y ago
> the native window environment? I'd rather build an app that doesn't require me to start with the question "which OS and window environment are you using?" followed by "sorry, we couldn't afford to build for that". The idea that app developers have resources, skills and manpower to build ~3-7 UIs using ~2-3 different stacks – for exactly the same app – is imo more preposterous imo than assuming most users have enough ram to run a chrome+node instance. The failure of standardizing UI has led to this. Electron is a stop-gap, a good one. As a Linux user, I am very happy that Electron exists, otherwise I would have far fewer apps. Yes, Electron hogs resources. I am personally using Tauri, which has a much lower footprint. Importantly, I can write my app once.
- foxhill 5y ago
  > I'd rather build an app that doesn't require me to start with the question "which OS and window environment are you using?" followed by "sorry, we couldn't afford to build for that". i can’t help but feel your catastrophising a bit here. in any case, you have options that would greatly ease pains of this sort, wx, QT, SDL, etc. there are many. the point is that the problem with electron isn’t UI abstraction in general, just this particular implementation of it. > [it’s safer to assume] most users have enough ram to run a chrome+node instance. so in an effort to avoid saying that you “couldn’t afford some feature”, you’re presuming that users can afford the resources for another multi-gigabyte ram hog, which is most likely, for all intents and purposes, a pretty wrapper around JSON getters and setters? > The failure of standardizing UI has led to this. Electron is a stop-gap, a good one. As a Linux user, I am very happy that Electron exists, otherwise I would have far fewer apps. strong disagree here. i’d bet that electron and it’s ecosystem exists strictly only because of the abundance of engineers proficient in javascript. electron absolutely did not standardise UI. sorry if that’s come across as inflammatory, it’s not intentional. i guess i get a bit irrationally upset when i see i can trigger a full page refresh of what should be a native application when i hit CTRL+shift+R.
  - porcoda 5y ago
    > i’d bet that electron and it’s ecosystem exists strictly only because of the abundance of engineers proficient in javascript. electron absolutely did not standardise UI. Bingo. We have a glut of developers who only really know web tech, and when they decide they want to do something for the desktop they just go with what they know instead of learning something different. The argument about portability that people make in support of Electron-based stuff doesn't hold up when you see that there exist cross-platform tools for other languages. At the end of the day, the tech world is crawling with JS developers who appear to be unmotivated to learn something other than JS (or one of its transpiled cousins).
    - klabb3 5y ago
      > they decide they want to do something for the desktop they just go with what they know instead of learning something different Shouldn't the burden of proof be reversed? If the stack works, why relearn in a different stack? The HN crowd loves to shit on web developers for not being good enough even at their own domain, yet at the same time encourage them to learn new tech. Proficiency takes time. As for the environment itself, web has the best inspect/debugging experience by far, an extremely capable and flexible layout engine and accessibility built in. It's also not controlled by a company, and has ubiquitous platform support. Obviously there's a network effect, which to a large extent led to this situation. But it also makes sense to learn today. If I was advising a junior it'd be criminally myopic to suggest learning Qt instead of web.
zarzavat 5y ago
> the native window environment? This means you’ll be limited to the intersection of features of each platform native rendering engine. On the other hand you get the union of all bugs and performance issues over each native rendering engine on each platform. Text will be a particular nightmare, what browsers do in terms of pixel consistent yet native-feeling text rendering and input is a miracle. > citation needed. why do slack and discord - communication applications - need a web view component? Perhaps those apps specifically don’t use it, but it is a standard component and all modern UI toolkits are expected to have one because many apps do need this functionality.
- foxhill 5y ago
  > This means you’ll be limited to the intersection of features of each platform native rendering engine. > On the other hand [...] we already live in this world. electron utilises the same APIs you would use. it doesn’t have a back way around these, and is subject to the same bugs and issues from the windowing system would be. it might be tempting to suggest here that electron devs can mitigate issues themselves and remove the need for that work on your part, but now you need to update your app: shared libraries aren’t exactly in fashion right now, so every electron based app needs updated. that in itself has a bunch of issues/consequences. if nothing else, it’s incredibly wasteful.
easrng 5y ago
> citation needed. why do slack and discord - communication applications - need a web view component? YouTube/SoundCloud/Spotify/etc embeds would need a webview component if Discord was a native desktop app.
- foxhill 5y ago
  so we can lose local browse history, have to maintain two separate login session to each respective service (repeat for slack too, where appropriate), all just to have the video or song play in the same window..? well, fine, if that’s what’s required. all of the platforms have webview components, i believe.

qorrect 5y ago

> it’s a huge attack vector. I'm confused by this phrase. Wouldn't it have a 'huge attack vector space' ? I never really understood that phrase.

nurettin 5y ago
vector is like an angle and a magnitude, perhaps you mean attack surface, which is the integral of known attack vectors.
otterley 5y ago
Vector is being used here in the epidemiological sense, not the mathematical sense.

klabb3 5y ago

> the native window environment? I'd rather build an app that doesn't require me to start with the question "which OS and window environment are you using?" followed by "sorry, we couldn't afford to build for that". The idea that app developers have resources, skills and manpower to build ~3-7 UIs using ~2-3 different stacks – for exactly the same app – is imo more preposterous imo than assuming most users have enough ram to run a chrome+node instance. The failure of standardizing UI has led to this. Electron is a stop-gap, a good one. As a Linux user, I am very happy that Electron exists, otherwise I would have far fewer apps. Yes, Electron hogs resources. I am personally using Tauri, which has a much lower footprint. Importantly, I can write my app once.

foxhill 5y ago
> I'd rather build an app that doesn't require me to start with the question "which OS and window environment are you using?" followed by "sorry, we couldn't afford to build for that". i can’t help but feel your catastrophising a bit here. in any case, you have options that would greatly ease pains of this sort, wx, QT, SDL, etc. there are many. the point is that the problem with electron isn’t UI abstraction in general, just this particular implementation of it. > [it’s safer to assume] most users have enough ram to run a chrome+node instance. so in an effort to avoid saying that you “couldn’t afford some feature”, you’re presuming that users can afford the resources for another multi-gigabyte ram hog, which is most likely, for all intents and purposes, a pretty wrapper around JSON getters and setters? > The failure of standardizing UI has led to this. Electron is a stop-gap, a good one. As a Linux user, I am very happy that Electron exists, otherwise I would have far fewer apps. strong disagree here. i’d bet that electron and it’s ecosystem exists strictly only because of the abundance of engineers proficient in javascript. electron absolutely did not standardise UI. sorry if that’s come across as inflammatory, it’s not intentional. i guess i get a bit irrationally upset when i see i can trigger a full page refresh of what should be a native application when i hit CTRL+shift+R.
- porcoda 5y ago
  > i’d bet that electron and it’s ecosystem exists strictly only because of the abundance of engineers proficient in javascript. electron absolutely did not standardise UI. Bingo. We have a glut of developers who only really know web tech, and when they decide they want to do something for the desktop they just go with what they know instead of learning something different. The argument about portability that people make in support of Electron-based stuff doesn't hold up when you see that there exist cross-platform tools for other languages. At the end of the day, the tech world is crawling with JS developers who appear to be unmotivated to learn something other than JS (or one of its transpiled cousins).
  - klabb3 5y ago
    > they decide they want to do something for the desktop they just go with what they know instead of learning something different Shouldn't the burden of proof be reversed? If the stack works, why relearn in a different stack? The HN crowd loves to shit on web developers for not being good enough even at their own domain, yet at the same time encourage them to learn new tech. Proficiency takes time. As for the environment itself, web has the best inspect/debugging experience by far, an extremely capable and flexible layout engine and accessibility built in. It's also not controlled by a company, and has ubiquitous platform support. Obviously there's a network effect, which to a large extent led to this situation. But it also makes sense to learn today. If I was advising a junior it'd be criminally myopic to suggest learning Qt instead of web.

zarzavat 5y ago

> the native window environment? This means you’ll be limited to the intersection of features of each platform native rendering engine. On the other hand you get the union of all bugs and performance issues over each native rendering engine on each platform. Text will be a particular nightmare, what browsers do in terms of pixel consistent yet native-feeling text rendering and input is a miracle. > citation needed. why do slack and discord - communication applications - need a web view component? Perhaps those apps specifically don’t use it, but it is a standard component and all modern UI toolkits are expected to have one because many apps do need this functionality.

foxhill 5y ago
> This means you’ll be limited to the intersection of features of each platform native rendering engine. > On the other hand [...] we already live in this world. electron utilises the same APIs you would use. it doesn’t have a back way around these, and is subject to the same bugs and issues from the windowing system would be. it might be tempting to suggest here that electron devs can mitigate issues themselves and remove the need for that work on your part, but now you need to update your app: shared libraries aren’t exactly in fashion right now, so every electron based app needs updated. that in itself has a bunch of issues/consequences. if nothing else, it’s incredibly wasteful.

easrng 5y ago

> citation needed. why do slack and discord - communication applications - need a web view component? YouTube/SoundCloud/Spotify/etc embeds would need a webview component if Discord was a native desktop app.

foxhill 5y ago
so we can lose local browse history, have to maintain two separate login session to each respective service (repeat for slack too, where appropriate), all just to have the video or song play in the same window..? well, fine, if that’s what’s required. all of the platforms have webview components, i believe.