3 ms·

> Electron apps all have orders of magnitude higher memory usage than comparable native apps I use across the board (10s of MB vs 100s of MB). This can be an i

> Electron apps all have orders of magnitude higher memory usage than comparable native apps I use across the board (10s of MB vs 100s of MB). This can be an issue, but it depends on the type of app you are making. If you are making a calculator app, you don't want it to consume 100 MB of memory and take 15 seconds to start. But if you are making a Business Intelligence app then if it takes 100 MB and 15 seconds to start your users will typically accept that. And as a developer you get to use awesome Web technologies, such as D3.js, that simply don't have an equivalent in native app development. In general, Web technologies are advancing at a much faster rate than native, and native tech will find it hard to keep up.

marpstar 10y ago
I agree that web-based libraries are being released at a more frequent rate and with greater adoption than desktop APIs, but to suggest that native app development offers no data visualization libraries seems a bit naive.
- interlocutor 10y ago
  I didn't say there are no data visualization libraries for native development. What I said is there is no equivalent to D3.js. I recommend taking a look at D3. It is not a charting library. There are charting libraries built on top of D3, but D3 is not your average charting package like MS chart control.
BoorishBears 10y ago
>This can be an issue, but it depends on the type of app you are making. It does, but the problem is Electron is the new hotness, so every chat client that could have been a 10MB native app is now coming out as a 100MB Electron app. Instead of looking at the problem being solved and choosing Electron, people work backwards and choose Electron because that's what looks good on a resume/is easy to hire for/is popular/etc., then try and fit their problems into it. "simply don't have an equivalent in native app development" Really? I mean I know D3.js is just an example, but between LiveCharts, OxPlot, MS Charts, and a decades worth of charting libs there's nothing like it? The thing is native has decades of legacy, which isn't always a bad thing as much as people tend to assume it is. Electron apps are not doing things that are extraordinarily new, I'd be shocked to find that there are popular libraries for frontend web dev that don't have alternatives on native (not to mention native has WebViews that get updated outside of your own release cadence, and offer performance that's at least good enough to embed in places where you really can't find anything as good as the Js equivalent). >In general, Web technologies are advancing at a much faster rate than native, and native tech will find it hard to keep up. I find that statement wonderfully ironic, I think with things like Electron, the Web just started getting to where native tech is. Web technologies "advance faster" in the sense that technology "churns faster". Look at what web apps were doing in 2006 and what web apps were doing in 2016 from a user's perspective. While from a web devs perspective React and co might have brought us forward (or sideways) lightyears, from a user perspective not that much changed. If WPF could do what that user needed in 2006, it can do what they need today, that's why there's so few "advancements". Now we're getting stuff like WASM so we can essentially utilize native stacks on web tech, I don't know how easily I can call that "advanced tech" over native.
- Asooka 10y ago
  On the bright side, these Electron apps work on Linux, whereas I'd be stuck running the ill-maintained web version (if one even existed) otherwise.
dx034 10y ago
I disagree with that. PgAdmin is a great example of how bad performance can be when you choose to build a non-native app. I admit it's not in Electron, but the idea behind it is similar. Performance is especially important for BI programmes. Start up time can be a bit longer, but users will heavily use the programme, so every delay to use it will be noticed much more than for a non-BI app. Navigation without using the mouse is also more important for BI apps, and typically worse in non-native apps (not that it couldn't be different). So while the pure start up time is itself not a huge problem, non-native apps will also take more resources and time performing tasks, which is a huge deal for BI apps.

marpstar 10y ago

I agree that web-based libraries are being released at a more frequent rate and with greater adoption than desktop APIs, but to suggest that native app development offers no data visualization libraries seems a bit naive.

interlocutor 10y ago
I didn't say there are no data visualization libraries for native development. What I said is there is no equivalent to D3.js. I recommend taking a look at D3. It is not a charting library. There are charting libraries built on top of D3, but D3 is not your average charting package like MS chart control.

BoorishBears 10y ago

>This can be an issue, but it depends on the type of app you are making. It does, but the problem is Electron is the new hotness, so every chat client that could have been a 10MB native app is now coming out as a 100MB Electron app. Instead of looking at the problem being solved and choosing Electron, people work backwards and choose Electron because that's what looks good on a resume/is easy to hire for/is popular/etc., then try and fit their problems into it. "simply don't have an equivalent in native app development" Really? I mean I know D3.js is just an example, but between LiveCharts, OxPlot, MS Charts, and a decades worth of charting libs there's nothing like it? The thing is native has decades of legacy, which isn't always a bad thing as much as people tend to assume it is. Electron apps are not doing things that are extraordinarily new, I'd be shocked to find that there are popular libraries for frontend web dev that don't have alternatives on native (not to mention native has WebViews that get updated outside of your own release cadence, and offer performance that's at least good enough to embed in places where you really can't find anything as good as the Js equivalent). >In general, Web technologies are advancing at a much faster rate than native, and native tech will find it hard to keep up. I find that statement wonderfully ironic, I think with things like Electron, the Web just started getting to where native tech is. Web technologies "advance faster" in the sense that technology "churns faster". Look at what web apps were doing in 2006 and what web apps were doing in 2016 from a user's perspective. While from a web devs perspective React and co might have brought us forward (or sideways) lightyears, from a user perspective not that much changed. If WPF could do what that user needed in 2006, it can do what they need today, that's why there's so few "advancements". Now we're getting stuff like WASM so we can essentially utilize native stacks on web tech, I don't know how easily I can call that "advanced tech" over native.

Asooka 10y ago
On the bright side, these Electron apps work on Linux, whereas I'd be stuck running the ill-maintained web version (if one even existed) otherwise.

dx034 10y ago

I disagree with that. PgAdmin is a great example of how bad performance can be when you choose to build a non-native app. I admit it's not in Electron, but the idea behind it is similar. Performance is especially important for BI programmes. Start up time can be a bit longer, but users will heavily use the programme, so every delay to use it will be noticed much more than for a non-BI app. Navigation without using the mouse is also more important for BI apps, and typically worse in non-native apps (not that it couldn't be different). So while the pure start up time is itself not a huge problem, non-native apps will also take more resources and time performing tasks, which is a huge deal for BI apps.