4 ms·

But on the whole, I don’t think the armchair critics truly appreciate how Electron reduces the cost by at least an order of magnitude. Compared to what? Java?

But on the whole, I don’t think the armchair critics truly appreciate how Electron reduces the cost by at least an order of magnitude. Compared to what? Java? Have you used c#.net, or for that matter Delphi or VB6 in their heydays? To me, I look at electron and I would put it roughly on par with QT. Although, like the vb vs delphi argument, i think electron gives you a good initial boostrap and makes you feel productive, but then when you start to hit problems they are very difficult to solve. Vs QT which is harder to get started in, but once you have the core up an running its possible to bolt things on fairly rapidly. I've not written anything in lazurus other than toys, but many of the problems I had with it just a couple years ago seems to be mostly fixed. AKA, its been quietly getting more robust everytime I install a new version.. So, I would be interested in a fair electron vs lazurus comparison from someone who has spent significant time in both.

nooorofe 5y ago
What about running those apps on Android and iPhones?
sofixa 5y ago
There's still a huge advantage for Electron - it's still fundamentally the same tech underneath - HTML, CSS, JS. Any semi-competent web developer can use Electron and ship cross-platform apps with it, and heck, lots of code can be shared between Electron apps and the web "app". None of the other options provide these facilities.
- anthk 5y ago
  QT is much faster than Electron.
  - sofixa 5y ago
    Thanks for the information, however that isn't really relevant to the points I'm making.
    - CRConrad 5y ago
      > that isn't really relevant to the points I'm making. But maybe it should be.
- StillBored 5y ago
  But, you then have all the problems with JS/HTML/CSS that web developers have. Like for example being able to support scroll bars and the like in a reasonable way. We accept certain poor behaviors from web apps because they are bound by a technology stack that is in many way sub optimal for the needs of the user. I was employed doing what we called client server development in the 1990's, where we wrote the frontends the users interacted with in vb and later delphi. I would put the visual and operational complexity of some of those applications far beyond any slack/etc type application (one actually had a chat function built in). They were also distributed, but instead used proprietary protocols over proprietary wireless networks (until later when we were some of the first customers for cellular data). And I say it not to brag, but there were two of us working on the front end, both part time over the span of maybe 5 years. And we could do large logs/chat histories where the scrollbar reflected where in the data set the user was viewing and they could smoothly scroll or jump to any arbitrary location. I can't remember the last web application that could do something even that basic. Slack definitely cant. I'm pretty sure there are more developers working more hours on the slack front-end than we worked on those applications. So, I'm not sure where the claims of developer efficiency comes from. People make a lot of claims about developer efficiency, but just about none of them are backed up by more than their gut instincts, which I would claim from the end user/3rd party viewpoint seem to be completely invalid. The apps are overwhelmingly poor on any number of fronts, and apparently have a lot of man hours poured into them.
ihateolives 5y ago
Last time I looked at Lazarus its autocomplete/suggestion was not on par that I've become to expect from VSC/Intellij and modern languages. Also, who wants to write things in FP nowadays? I was toying with the idea, but I don't want to end up abandoning my project midway just because FP happens to miss an important library or db driver or something else.
- StillBored 5y ago
  The pascal thing has its own advantages/disadvantages. Finding people with pascal experience is going to be difficult, but i'm not sure this is really any worse than some of the web/framework wars. Pick a framework and likely in 5 years your going to have problems finding people who are experts in it because they have all moved to something else (although maybe that is settling down angular/react are still around). OTOH, Pascal is a far simpler language than JS, for sure it has fewer gochas than JS does at this point, and it supports proper threading if you happen to need that among other things. Its definitely stagnated, but that's probably a good thing if you plan on building a long term business around it. I'm not sure I would consider editor features like auto completion very high on my technology selection, particularly since you can 1. fix it, 2. use a different editor. I would worry about hidpi support with Lazarus, and how well the android/ios/mac bindings actually work. Maybe a few other things too, basically things that are going to be so large a work item that fixing them is going to outweigh any advantages of picking the tool. I think electron has at least a dozen of these, and that would push me away from it. From where I stand, electron is closer to java in the long term results.
  - ihateolives 5y ago
    Autocomplete was one example, but I wouldn't underestimate the importance of tooling when you want to onboard people new to the language. Does fp even have package/dependency manager? How good are linters? I wrote my first pieces of shitty Turbo C code before autocomplete was a thing, in a DOS editor. There was no discovery of language syntax or features, you had to have a paper manual open on your desk. So I got frustrated, didn't stick around (dumb decision in retrospective), turned to webdev, at least the turnaround from code to result was quicker. For some time I thought it couldn't get any better than syntax highlighting, but it did. And now I just don't want to work with languages that don't have good lsp support. Been there, done that, nope, not going back.
efreak 5y ago
It's not that I don't appreciate it. It's that I _don't care_. I've only got 16gb of ram, and much of that is used by things I actually care about, like airsonic, a Linux VM, fb2k, etc (yes, my PC is my home sever). Even if I were to dump all this, there's a limited number of electron apps I'm willing to use, and none of them are things I leave open all the time. Authy particularly annoys me, since I have no choice if I wish to use their authenticator (humble bundle doesn't support totp, only Authy 2fa)

nooorofe 5y ago

What about running those apps on Android and iPhones?

sofixa 5y ago

There's still a huge advantage for Electron - it's still fundamentally the same tech underneath - HTML, CSS, JS. Any semi-competent web developer can use Electron and ship cross-platform apps with it, and heck, lots of code can be shared between Electron apps and the web "app". None of the other options provide these facilities.

anthk 5y ago
QT is much faster than Electron.
- sofixa 5y ago
  Thanks for the information, however that isn't really relevant to the points I'm making.
  - CRConrad 5y ago
    > that isn't really relevant to the points I'm making. But maybe it should be.
StillBored 5y ago
But, you then have all the problems with JS/HTML/CSS that web developers have. Like for example being able to support scroll bars and the like in a reasonable way. We accept certain poor behaviors from web apps because they are bound by a technology stack that is in many way sub optimal for the needs of the user. I was employed doing what we called client server development in the 1990's, where we wrote the frontends the users interacted with in vb and later delphi. I would put the visual and operational complexity of some of those applications far beyond any slack/etc type application (one actually had a chat function built in). They were also distributed, but instead used proprietary protocols over proprietary wireless networks (until later when we were some of the first customers for cellular data). And I say it not to brag, but there were two of us working on the front end, both part time over the span of maybe 5 years. And we could do large logs/chat histories where the scrollbar reflected where in the data set the user was viewing and they could smoothly scroll or jump to any arbitrary location. I can't remember the last web application that could do something even that basic. Slack definitely cant. I'm pretty sure there are more developers working more hours on the slack front-end than we worked on those applications. So, I'm not sure where the claims of developer efficiency comes from. People make a lot of claims about developer efficiency, but just about none of them are backed up by more than their gut instincts, which I would claim from the end user/3rd party viewpoint seem to be completely invalid. The apps are overwhelmingly poor on any number of fronts, and apparently have a lot of man hours poured into them.

ihateolives 5y ago

Last time I looked at Lazarus its autocomplete/suggestion was not on par that I've become to expect from VSC/Intellij and modern languages. Also, who wants to write things in FP nowadays? I was toying with the idea, but I don't want to end up abandoning my project midway just because FP happens to miss an important library or db driver or something else.

StillBored 5y ago
The pascal thing has its own advantages/disadvantages. Finding people with pascal experience is going to be difficult, but i'm not sure this is really any worse than some of the web/framework wars. Pick a framework and likely in 5 years your going to have problems finding people who are experts in it because they have all moved to something else (although maybe that is settling down angular/react are still around). OTOH, Pascal is a far simpler language than JS, for sure it has fewer gochas than JS does at this point, and it supports proper threading if you happen to need that among other things. Its definitely stagnated, but that's probably a good thing if you plan on building a long term business around it. I'm not sure I would consider editor features like auto completion very high on my technology selection, particularly since you can 1. fix it, 2. use a different editor. I would worry about hidpi support with Lazarus, and how well the android/ios/mac bindings actually work. Maybe a few other things too, basically things that are going to be so large a work item that fixing them is going to outweigh any advantages of picking the tool. I think electron has at least a dozen of these, and that would push me away from it. From where I stand, electron is closer to java in the long term results.
- ihateolives 5y ago
  Autocomplete was one example, but I wouldn't underestimate the importance of tooling when you want to onboard people new to the language. Does fp even have package/dependency manager? How good are linters? I wrote my first pieces of shitty Turbo C code before autocomplete was a thing, in a DOS editor. There was no discovery of language syntax or features, you had to have a paper manual open on your desk. So I got frustrated, didn't stick around (dumb decision in retrospective), turned to webdev, at least the turnaround from code to result was quicker. For some time I thought it couldn't get any better than syntax highlighting, but it did. And now I just don't want to work with languages that don't have good lsp support. Been there, done that, nope, not going back.

efreak 5y ago

It's not that I don't appreciate it. It's that I _don't care_. I've only got 16gb of ram, and much of that is used by things I actually care about, like airsonic, a Linux VM, fb2k, etc (yes, my PC is my home sever). Even if I were to dump all this, there's a limited number of electron apps I'm willing to use, and none of them are things I leave open all the time. Authy particularly annoys me, since I have no choice if I wish to use their authenticator (humble bundle doesn't support totp, only Authy 2fa)