16 ms·

What you call "trade-offs" appears to me to be developers externalizing their costs onto users. There are costs to developing desktop applications and developer

by Veen 10y ago

What you call "trade-offs" appears to me to be developers externalizing their costs onto users. There are costs to developing desktop applications and developers don't want to pay them, so they make users pay for them in wasted hardware dollars, bandwidth, RAM, battery life, and poor integration.

wickedlogic 10y ago
Yes. You just described modern computing.
- sametmax 10y ago
  Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. The world is asking for more and more software, and the resources to provide it are not following so people are taking shortcuts. Want something better ? Someone has to pay for it.
  - cableshaft 10y ago
    Yeah, but Python still doesn't seem to have a great cross-platform desktop GUI, as far as I can find. I'd prefer to code entirely in Python if I could, but I haven't liked a single GUI library I've tried for Python. Although to be fair I haven't really tried PyQT out still, but I don't like the idea of having to buy a commercial license for it.
    - sametmax 10y ago
      PyQT is alright. Kivy as well. Or anything in any other language. But none of them are close enough to the benefit of being able to use the tone of experience from the Web UI into the desktop. Eventually all GUI app toolkit ends up with a custom MVC framework, a client/server architecture, some kind of db for persistence, their own implementation of asynchronous event and communication models and a declarative layer to create the UI without code. For the most advanced this layer separate structure and layout. Well guess what, this is what the Web has natively being doing for ever. Since the web is now the most popular platform, with millions of libs and tutorials on it, people just reused that. It just makes sense. The problem is not the concept. The problem is we should have driven this effort with a standard to sanely close the gap between the desktop and the web so that you don't have to spawn a freaking browser-engine-os for every one of your app. But no, the web is the only platform with a standard. And it flourished while all the big players created closes gardens with proprietary shitty API. And this is the result. Have you not seen Jurassic Park for god sake ? Life finds a way.
      - cableshaft 10y ago
        Yep, completely agree with everything you said. I'd love for their to be a standard on the desktop side, but until then, I'll keep using a hodge-podge of technologies depending on the project, I guess.
      - Arizhel 10y ago
        They should have adopted Qt; it makes it easy to write native C++ code that compiles on different platforms, so you get the performance and RAM usage of C++ but still most of the benefits that web coding offers, without so many drawbacks. (It's also quite nice to work with IMO.) It's too bad it wasn't more universally adopted, by any of the 3 major platforms (including Linux, where the all-C Gtk+ has become the standard for the most part). Instead, it seems to have found its greatest success in, ironically, small embedded devices. Devices like this simply cannot take the performance hit of something like Electron.
      - ornitorrincos 10y ago
        I do strongly disagree with the web having the only strong standard, specially since it switched to a living standard I admit that for someone from the web electron is a godsend, but to be honest, responsiveness of the applications leave something to be desired
      - wott 10y ago
        > But none of them are close enough to the benefit of being able to use the tone of experience from the Web UI into the desktop. Web UI is a gazillion shades of shit, please don't dump that rubbish on the desktop. Thank you. Seriously, how can one take Web UIs, the most cumbersome, unreliable, inconsistent, unreactive UIs, as examples to be followed? That's beyond me.
        brokenmachine 10y ago
        Haha, "a gazillion shades of shit". So true.
      - tigershark 10y ago
        It's completely false. The web at the beginning was a huge mess of static pages, hacked CGI scripts and no interactivity at all with the need to submit a form to trigger a full reload of the page. Everything was absolutely synchronous and a lot of times the database was accessible directly from the public interface and some pages did actually have the connection string directly in the HTML for everyone to see. I'm really not sure in which alternate reality you have seen web apps doing all that forever.
    - skuzye 10y ago
      If you really want to use PyQT you may try PySide which is LGPL licensed. I'm not sure whether it restricts commercial use.
      - deleted 10y ago
        [deleted]
    - lmm 10y ago
      > Python still doesn't seem to have a great cross-platform desktop GUI, as far as I can find. PyQt is literally the best cross-platform desktop GUI going, in any language.
      - tigershark 10y ago
        Last time that I tried QT was a huge pain compared to WPF or other solutions, admittedly something like 5-6 years ago. And it was proprietary and it needed a licence. With all my good will I find quite difficult to believe that now PyQT is the silver bullet to write all UIs. For sure it's not for me given that I find python a pretty average language with the huge handicap of duck typing (and before someone starts, yes, I'm aware of the 'type annotations')
        lmm 10y ago
        > Last time that I tried QT was a huge pain compared to WPF or other solutions, admittedly something like 5-6 years ago. Shrug, I found it much nicer than anything else I'd used, but I've never used WPF (which is single-platform in any case). > And it was proprietary and it needed a licence. Neither Qt nor PyQt is proprietary in the usal sense of the word (nor were they 5-6 years ago). If you're using a non-standard definition it would probably be more productive to use a different word. > For sure it's not for me given that I find python a pretty average language with the huge handicap of duck typing (and before someone starts, yes, I'm aware of the 'type annotations') I'm a huge fan of type systems. I wish I could find a UI framework that's anywhere near as nice as PyQt for an ML-family language.
    - kofejnik 10y ago
      take a look at https://github.com/dddomodossola/remi https://github.com/dddomodossola/remi, which transpiles python into html (kind of)
  - user5994461 10y ago
    We use Java because Python proved to be too slow.
    - reitanqild 10y ago
      And because the IDE support (refactoring etc etc), compile time error checking and ease of use more than compensates for Java being a little bit verbose.
      - sametmax 10y ago
        Yeah, and they used C because the compilator could optimized stuff the JVM couldn't but now it can. And now Python get type hints so you can have the IDE tools you have with Java like with PyCharm. It's the circle of life.
        user5994461 10y ago
        Not quite correct about type hint. They are only in python 3. Everyone who adopted python 2 on sizeable codebase is likely stuck there forever, with zero annotations and none of the new tools available, and they'll never be ported back.
        sametmax 10y ago
        You can use type hints with Python 2 in the form of special comments (http://mypy.readthedocs.io/en/latest/python2.html#type-checking-python-2-code http://mypy.readthedocs.io/en/latest/python2.html#type-check...). Guido has been working on the type hint project for dropbox specifically to help them to migrate 2.7 code to 3. But let's be fair, type related tooling in Python are not close to the ones you have in Java yet. It's just that eventually, everything comes around. Java got faster. C++ easier. Python ...toolier ? Etc.
        user5994461 10y ago
        Java got faster and got some functional features. Python broke all retro compatibility and put all existing sizeable software in a miserable deprecated state with the breaking of python 3. I don't recall C++ getting easier. The few tools and IDE still fail at decent refactoring and code completion. The C++11 movement is adding few stuff more or less useful, piling on top of the vast amount of already existing complexity.
  - pducks32 10y ago
    We use some hipster language and act like we're doing it just to be ironic when actually it's a super cool language.
  - wvenable 10y ago
    I can't help but think there's a different flavor to this than with higher-level languages. This is adding a platform on top of another platform. The same objections existed years ago with Java when Swing was released. Java is a cross-platform high-level language but Swing is basically an entirely new platform. It's this platform on top of a platform that is objectionable from a performance, memory, storage, and integration perspective.
    - sametmax 10y ago
      We see the same thing with containers. Docker, flatpak, snap... It's just the right time for it. Languages have evolve to change the way we handle constraints like memory, speed, readability, expressivity etc. We are arriving at the pick of what languages can bring on the table. Sure we can improve things here and there, but the huge challenges now are integration, packaging, distribution, updates, communications, multi-tiers architectures and all that. So we now tweak platforms to help us with that. But because we didn't see that coming, it's not done in any structured way. It's done exactly the way we did everything since the beginning of computing, by stitching together stuff then hitting hard on it with a hammer until the job is done. This is not new. IT is a joke of an engineering field. We hack everything, don't think about the future, and then end up using the status quote. It's always has been like that.
      - wvenable 10y ago
        I agree. Containers should be unnecessary -- all that they could provide could be done at the process level with an operating system designed to isolate computing resources appropriately. But operating systems were not historically designed for that so another (somewhat ridiculous) layer is added on top.
        AlphaSite 10y ago
        Thats all containers are? They are an abstraction over OS level isolation.
        apexalpha 10y ago
  - coldtea 10y ago
    >Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. Yeah, but until Electron and they like, we seldom shipped desktop apps in anything than C, C++, Delphi etc even after all those decades. Which are all as close to the metal as can be. And in fact C/C++ can be as fast, or even faster than hand-rolled assembly most of the time (with few exception), so the whole premise is moot. The few Java desktop apps that were around, people used to hate as memory hogs.
    - sametmax 10y ago
      You bet ? I have 3 software opened right now using Python for their GUI: my rss reader, my torrent downloader and dropbox. And I got many more installed on my machine. But the thing is, even when I write something for myself, I first write a command line app, then a web service. Never a GUI, because it's such pain.
      - weberc2 10y ago
        To be fair, your "Python GUI apps" are a very thin wrapper around C/C++ libraries.
        sametmax 10y ago
        Of course. Electron is just a layer around the chrome compiled engined as well. If you want anything to display a matrix of pixels changing rapidly, you need low level performances eventually.
        weberc2 10y ago
        Of course, but in your case, the C/C++ libraries you're calling into aren't doing any heavy lifting, they're just making calls to an X server (or equivalent) or perhaps to a graphics card. There's no reason GTK (or the GUI portion of Qt) couldn't be implemented in Python, it's just a huge undertaking and it was started in C (or C++ as the case may be).
    - 10y ago
  - vbezhenar 10y ago
    C is generally faster, than hand-written assembly, so it doesn't make sense to write software in assembler. For macOS desktop applications are written with Objective C, which is C with fast message-passing, and doesn't trade much to speed. Swift is modern alternative, but it doesn't trade anything for speed either. For Linux applications are traditionally written with C and Gtk or with C++ and Qt. Those options are both very performant. For Windows main language for a long time was C++ and it remains supported language. There's movement to .NET, so Windows is an outlier here. But .NET is generally very performant language, it makes some tradeoffs for safety, but it has enough features to stay fast and its implementation is specifically tuned for desktop applications. The only terrible platform with slow language is Android and it's well known for its lags. There's very little desktop software written with Java and Python and usually those are specialized applications, when users don't really care about experience, but rather care about functionality. So JavaScript invasion here is unexpected and not wanted. I won't use any JavaScript desktop application, if I have choice. I don't like this technology. JavaScript and V8 made for browser with advanced sandbox capabilities. That's fine. But for desktop it's just not needed. And there's no other advantages. UI is terrible and does not conform to any standards. Performance is not good. Memory consumption is abysmal. Energy consumption is abysmal as well. If I'm about to buy application for macOS, I'm always carefully inspecting its bundle and trying to determine which technologies were used. Unless it's pure Objective C/Swift, I'm usually won't buy it. I hope, more users would do it.
    - omginternets 10y ago
      >C is generally faster, than hand-written assembly, so it doesn't make sense to write software in assembler. That's true now. It wasn't true then. The point still stands.
      - ornitorrincos 10y ago
        and not even true now for certain workloads, each tool for its job
  - faaq 10y ago
    hehe, you remember me, that crystal, nim and rust are invented to avoid write C ¯\_(ツ)_/¯
bobwaycott 10y ago
Everything in the world of web-stack development has turned externalizing costs onto users as a core first principle.
- rpastuszak 10y ago
  How about PWA, Service Workers, WebAssembly? Thousands of developers are working hard on improving the UX, reduce battery usage, wasted CPU cycles, network traffic, latency.
  - bobwaycott 10y ago
    All of this because they're externalizing costs onto users through SPAs and other go-to practices that force all the work onto users' devices.
- abiox 10y ago
  it's been that way since forever. if you're not employing expensive top-ranked brilliant engineers writing aggressively optimized, completely bespoke c applications tuned to every cpu model's feature set and performance characteristics... you just might be externalizing. insofar as it benefits the budget, you should probably externalize as much as possible. consumers will provide the fitness function through deciding what products they prefer.
  - panic 10y ago
    consumers will provide the fitness function through deciding what products they prefer. What about when your users don't have a choice?
    - abiox 10y ago
      hm... performance metrics, possibly? it may be hard to measure.
  - bobwaycott 10y ago
    We're not even discussing aggressively optimized C vs web stack. We're talking about a massive segment of today's software developers not even bothering to learn competent C (or Obj-C, Swift, Java, whatever) to build a native application. Hell, it's about the very practice of calling Electron apps native to begin with. The same thing continues to hold across web stack everywhere—reach only for those things that don't require you to learn a new language/paradigm, letting you keep churning out the same thing you build in a browser and call it native for platform X, and let it be on the user to pony up the resources to use it.
sametmax 10y ago
Well users/clients/bosses want everything, now, and for free so...
- tertius 10y ago
  Free things give continuous hassle. People on business don't want hassle. They pass on free except if they're very inexperienced.
pdabbadabba 10y ago
Well, to the extent that these costs degrade the user experience, I'm not sure they really are externalizing them. Presumably they pay this cost in the form of decreased user satisfaction. It's just that this is a cost they are willing to pay. There may be an interesting economic lesson here: it really is not that easy to externalize costs. It surely can be done (air pollution), but it requires some special circumstances for those costs not to be internalized in a different form. (These special circumstances might include information asymmetries, harm to a public good, enjoyed by people other than a firm's own customers, etc.--themselves classic risk factors for market failure.) By the same token, there probably are some truly externalized costs in this example, but I would expect them to be very minor and indirect. For example, most people probably do not pay the 'true' cost of their electricity. So to the extent electron wastes power, some of the cost will be internalized in the form of user dissatisfaction. But some will also be externalized either because the user doesn't know about the extra power consumption, or because the user herself doesn't fully internalize the costs of her power consumption and therefore doesn't care as much as she might if all costs were properly internalized.
- bhauer 10y ago
  > Well, to the extent that these costs degrade the user experience, I'm not sure they really are externalizing them. Presumably they pay this cost in the form of decreased user satisfaction. It's just that this is a cost they are willing to pay. Precisely. I don't use Slack in part because its desktop application is irrationally bloated for its use-case. Although I have other reasons as well, they are enduring a cost--a small one to be sure, but presumably non-trivial in aggregate--in people refusing to use their service in part because their desktop application is poor. But I do agree with the general emotion underlying the frustration of "externalities" here. As someone who advocates for high-performance and efficient web applications, I have toyed with the question of whether developers should confront the morality of wasting energy by having selected poor/low-performance platforms. Put in a somewhat comedic tone: low-performance software contributes to climate change.
  - nojvek 10y ago
    By walking just one day a year than taking my car, I can offset the electricity consumed by my laptop. You do have a point though. You make a difference where you can.
Tenhundfeld 10y ago
I don't disagree, but I'm hopeful that Electron will get better. When you choose an open source platform with a diverse group of major companies using it, part of what you are betting on is that the platform will a) survive for a reasonable amount of time and b) gradually improve. GitHub, Slack, Spotify, Microsoft, etc., are all using Electron. As their developers gain experience with the platform and as they experience problems with resource usage, I would expect to see the platform improve. Maybe I'm wrong.
- bluejekyll 10y ago
  On top of that, webassembly could see some improvements across the board.
  - douche 10y ago
    The future, where we write in native languages, that are compiled to Javascript, run in a webbrowser VM, and power desktop applications. Jesus wept.
    - m_fayer 10y ago
      In 2014 I laughed. No longer laughing. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
    - bluejekyll 10y ago
      It's not that they are native languages. They are languages with no overhead, GC is no longer necessary for example.
  - sethc2 10y ago
    I agree. I think it also has the potential to help motivate developers to write native UI rather than use electron. Currently if for your market, your primary target platform is the web, but other platforms are still important, going electron might make sense because you really don't want to write your business logic natively for each platform. Web assembly allows us to use the same native libraries for all our business logic and data models, which besides being more performant, means we only need to be willing to write the UI natively on top of those libraries. We've actually taken (very) old desktop C++ code, and compiled it to asm.js and ran it in our web app, and then rendered its outputs with webGL onto a canvas and have had surprisingly successful results. This makes the prospect of WASM becoming standard across the board very exciting. Now let's hope we don't decide to replace our native desktop app, that uses this old C++ library, with an electron app of our web app, running the asm.js compiled library :).
jrochkind1 10y ago
Well, why would any developer or organization doing development "want" to pay those costs, as you suggest they should?
- Arizhel 10y ago
  To make a quality product and offer a better user experience? Users may not notice the slowness right away, but if they run a bunch of applications at once they probably will, and they're more likely to notice it while running on battery.
- TeMPOraL 10y ago
  Because those costs grow orders of magnitude as they're externalized. $1000 spent during development can offset $1M in energy wasted by a million users. So they should want to pay those costs as responsible members of civilized society. And if they don't want to, they should be forced to by said society.
pluma 10y ago
I've switched from Sublime Text 3 (native) to VSCode (Electron) and I couldn't be happier. If I didn't know it's electron based I wouldn't have been able to tell as a user. YMMV so don't generalise.
- kungtotte 10y ago
  When did you switch? Atom was damned near unusable around 1.0, and VSCode was only a little better. The difference to now is night and day.
  - infogulch 10y ago
    Atom and VSCode are in different leagues with respect to performance, and the difference is growing with time. If you think the reason that Atom is slow is because of Electron, VSCode is the counterexample.
    - ori_b 10y ago
      If VSCode isn't slow because of electron, what's the reason it's slow?
      - pluma 10y ago
        VSCode isn't slow. Atom is slow. Since both are written with electron the difference must obviously be the actual implementation, not the platform itself. Keep in mind VSCode was written by Microsoft who have decades of experience writing IDEs and text editors, whereas Atom was written by GitHub who are mostly working on the GitHub product.
        ori_b 10y ago
        > VSCode isn't slow. Atom is slow. Could have fooled me.
        iterateandgit 10y ago
shaan7 10y ago
THIS ^
jliptzin 10y ago
The vast majority of users (like >99%) don't have a clue why their computer isn't performing up to par. They literally have no idea how any of it works. They might just assume that it's slow because they haven't deleted spam emails in a while (even while they use gmail) or didn't pay extra to get that 3.2Ghz machine instead of the 3Ghz. They certainly don't have any idea how to open up top stats and check what resources a particular app is using, so until that happens and users punish developers for this kind of stuff, expect it to continue.
- wott 10y ago
  > The vast majority of users (like >99%) don't have a clue why their computer isn't performing up to par. They literally have no idea how any of it works. Same thing for Web developers.
- flukus 10y ago
  Yes, you'll often hear things like "I think I have a virus" or "I think I need a new computer". They're computer is fine, they're just running slow apps.
  - brokenmachine 10y ago
    They need a new computer because they don't know how to make their old one work properly. Getting a new computer will fix the problem though. :-)
greenhatman 10y ago
>There are costs to developing desktop applications and developers don't want to pay them, so they make users pay for them That is definitely not the whole story. Costs are shared between developers and users. If it's more expensive to develop an app, you can bet it's going to cost users more too.

by Veen 10y ago

wickedlogic 10y ago

Yes. You just described modern computing.

sametmax 10y ago
Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. The world is asking for more and more software, and the resources to provide it are not following so people are taking shortcuts. Want something better ? Someone has to pay for it.
- cableshaft 10y ago
  Yeah, but Python still doesn't seem to have a great cross-platform desktop GUI, as far as I can find. I'd prefer to code entirely in Python if I could, but I haven't liked a single GUI library I've tried for Python. Although to be fair I haven't really tried PyQT out still, but I don't like the idea of having to buy a commercial license for it.
  - sametmax 10y ago
    PyQT is alright. Kivy as well. Or anything in any other language. But none of them are close enough to the benefit of being able to use the tone of experience from the Web UI into the desktop. Eventually all GUI app toolkit ends up with a custom MVC framework, a client/server architecture, some kind of db for persistence, their own implementation of asynchronous event and communication models and a declarative layer to create the UI without code. For the most advanced this layer separate structure and layout. Well guess what, this is what the Web has natively being doing for ever. Since the web is now the most popular platform, with millions of libs and tutorials on it, people just reused that. It just makes sense. The problem is not the concept. The problem is we should have driven this effort with a standard to sanely close the gap between the desktop and the web so that you don't have to spawn a freaking browser-engine-os for every one of your app. But no, the web is the only platform with a standard. And it flourished while all the big players created closes gardens with proprietary shitty API. And this is the result. Have you not seen Jurassic Park for god sake ? Life finds a way.
    - cableshaft 10y ago
      Yep, completely agree with everything you said. I'd love for their to be a standard on the desktop side, but until then, I'll keep using a hodge-podge of technologies depending on the project, I guess.
    - Arizhel 10y ago
      They should have adopted Qt; it makes it easy to write native C++ code that compiles on different platforms, so you get the performance and RAM usage of C++ but still most of the benefits that web coding offers, without so many drawbacks. (It's also quite nice to work with IMO.) It's too bad it wasn't more universally adopted, by any of the 3 major platforms (including Linux, where the all-C Gtk+ has become the standard for the most part). Instead, it seems to have found its greatest success in, ironically, small embedded devices. Devices like this simply cannot take the performance hit of something like Electron.
    - ornitorrincos 10y ago
      I do strongly disagree with the web having the only strong standard, specially since it switched to a living standard I admit that for someone from the web electron is a godsend, but to be honest, responsiveness of the applications leave something to be desired
    - wott 10y ago
      > But none of them are close enough to the benefit of being able to use the tone of experience from the Web UI into the desktop. Web UI is a gazillion shades of shit, please don't dump that rubbish on the desktop. Thank you. Seriously, how can one take Web UIs, the most cumbersome, unreliable, inconsistent, unreactive UIs, as examples to be followed? That's beyond me.
      - brokenmachine 10y ago
        Haha, "a gazillion shades of shit". So true.
    - tigershark 10y ago
      It's completely false. The web at the beginning was a huge mess of static pages, hacked CGI scripts and no interactivity at all with the need to submit a form to trigger a full reload of the page. Everything was absolutely synchronous and a lot of times the database was accessible directly from the public interface and some pages did actually have the connection string directly in the HTML for everyone to see. I'm really not sure in which alternate reality you have seen web apps doing all that forever.
  - skuzye 10y ago
    If you really want to use PyQT you may try PySide which is LGPL licensed. I'm not sure whether it restricts commercial use.
    - deleted 10y ago
      [deleted]
  - lmm 10y ago
    > Python still doesn't seem to have a great cross-platform desktop GUI, as far as I can find. PyQt is literally the best cross-platform desktop GUI going, in any language.
    - tigershark 10y ago
      Last time that I tried QT was a huge pain compared to WPF or other solutions, admittedly something like 5-6 years ago. And it was proprietary and it needed a licence. With all my good will I find quite difficult to believe that now PyQT is the silver bullet to write all UIs. For sure it's not for me given that I find python a pretty average language with the huge handicap of duck typing (and before someone starts, yes, I'm aware of the 'type annotations')
      - lmm 10y ago
        > Last time that I tried QT was a huge pain compared to WPF or other solutions, admittedly something like 5-6 years ago. Shrug, I found it much nicer than anything else I'd used, but I've never used WPF (which is single-platform in any case). > And it was proprietary and it needed a licence. Neither Qt nor PyQt is proprietary in the usal sense of the word (nor were they 5-6 years ago). If you're using a non-standard definition it would probably be more productive to use a different word. > For sure it's not for me given that I find python a pretty average language with the huge handicap of duck typing (and before someone starts, yes, I'm aware of the 'type annotations') I'm a huge fan of type systems. I wish I could find a UI framework that's anywhere near as nice as PyQt for an ML-family language.
  - kofejnik 10y ago
    take a look at https://github.com/dddomodossola/remi https://github.com/dddomodossola/remi, which transpiles python into html (kind of)
- user5994461 10y ago
  We use Java because Python proved to be too slow.
  - reitanqild 10y ago
    And because the IDE support (refactoring etc etc), compile time error checking and ease of use more than compensates for Java being a little bit verbose.
    - sametmax 10y ago
      Yeah, and they used C because the compilator could optimized stuff the JVM couldn't but now it can. And now Python get type hints so you can have the IDE tools you have with Java like with PyCharm. It's the circle of life.
      - user5994461 10y ago
        Not quite correct about type hint. They are only in python 3. Everyone who adopted python 2 on sizeable codebase is likely stuck there forever, with zero annotations and none of the new tools available, and they'll never be ported back.
        sametmax 10y ago
        You can use type hints with Python 2 in the form of special comments (http://mypy.readthedocs.io/en/latest/python2.html#type-checking-python-2-code http://mypy.readthedocs.io/en/latest/python2.html#type-check...). Guido has been working on the type hint project for dropbox specifically to help them to migrate 2.7 code to 3. But let's be fair, type related tooling in Python are not close to the ones you have in Java yet. It's just that eventually, everything comes around. Java got faster. C++ easier. Python ...toolier ? Etc.
        user5994461 10y ago
        Java got faster and got some functional features. Python broke all retro compatibility and put all existing sizeable software in a miserable deprecated state with the breaking of python 3. I don't recall C++ getting easier. The few tools and IDE still fail at decent refactoring and code completion. The C++11 movement is adding few stuff more or less useful, piling on top of the vast amount of already existing complexity.
- pducks32 10y ago
  We use some hipster language and act like we're doing it just to be ironic when actually it's a super cool language.
- wvenable 10y ago
  I can't help but think there's a different flavor to this than with higher-level languages. This is adding a platform on top of another platform. The same objections existed years ago with Java when Swing was released. Java is a cross-platform high-level language but Swing is basically an entirely new platform. It's this platform on top of a platform that is objectionable from a performance, memory, storage, and integration perspective.
  - sametmax 10y ago
    We see the same thing with containers. Docker, flatpak, snap... It's just the right time for it. Languages have evolve to change the way we handle constraints like memory, speed, readability, expressivity etc. We are arriving at the pick of what languages can bring on the table. Sure we can improve things here and there, but the huge challenges now are integration, packaging, distribution, updates, communications, multi-tiers architectures and all that. So we now tweak platforms to help us with that. But because we didn't see that coming, it's not done in any structured way. It's done exactly the way we did everything since the beginning of computing, by stitching together stuff then hitting hard on it with a hammer until the job is done. This is not new. IT is a joke of an engineering field. We hack everything, don't think about the future, and then end up using the status quote. It's always has been like that.
    - wvenable 10y ago
      I agree. Containers should be unnecessary -- all that they could provide could be done at the process level with an operating system designed to isolate computing resources appropriately. But operating systems were not historically designed for that so another (somewhat ridiculous) layer is added on top.
      - AlphaSite 10y ago
        Thats all containers are? They are an abstraction over OS level isolation.
      - apexalpha 10y ago
- coldtea 10y ago
  >Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. Yeah, but until Electron and they like, we seldom shipped desktop apps in anything than C, C++, Delphi etc even after all those decades. Which are all as close to the metal as can be. And in fact C/C++ can be as fast, or even faster than hand-rolled assembly most of the time (with few exception), so the whole premise is moot. The few Java desktop apps that were around, people used to hate as memory hogs.
  - sametmax 10y ago
    You bet ? I have 3 software opened right now using Python for their GUI: my rss reader, my torrent downloader and dropbox. And I got many more installed on my machine. But the thing is, even when I write something for myself, I first write a command line app, then a web service. Never a GUI, because it's such pain.
    - weberc2 10y ago
      To be fair, your "Python GUI apps" are a very thin wrapper around C/C++ libraries.
      - sametmax 10y ago
        Of course. Electron is just a layer around the chrome compiled engined as well. If you want anything to display a matrix of pixels changing rapidly, you need low level performances eventually.
        weberc2 10y ago
        Of course, but in your case, the C/C++ libraries you're calling into aren't doing any heavy lifting, they're just making calls to an X server (or equivalent) or perhaps to a graphics card. There's no reason GTK (or the GUI portion of Qt) couldn't be implemented in Python, it's just a huge undertaking and it was started in C (or C++ as the case may be).
  - 10y ago
- vbezhenar 10y ago
  C is generally faster, than hand-written assembly, so it doesn't make sense to write software in assembler. For macOS desktop applications are written with Objective C, which is C with fast message-passing, and doesn't trade much to speed. Swift is modern alternative, but it doesn't trade anything for speed either. For Linux applications are traditionally written with C and Gtk or with C++ and Qt. Those options are both very performant. For Windows main language for a long time was C++ and it remains supported language. There's movement to .NET, so Windows is an outlier here. But .NET is generally very performant language, it makes some tradeoffs for safety, but it has enough features to stay fast and its implementation is specifically tuned for desktop applications. The only terrible platform with slow language is Android and it's well known for its lags. There's very little desktop software written with Java and Python and usually those are specialized applications, when users don't really care about experience, but rather care about functionality. So JavaScript invasion here is unexpected and not wanted. I won't use any JavaScript desktop application, if I have choice. I don't like this technology. JavaScript and V8 made for browser with advanced sandbox capabilities. That's fine. But for desktop it's just not needed. And there's no other advantages. UI is terrible and does not conform to any standards. Performance is not good. Memory consumption is abysmal. Energy consumption is abysmal as well. If I'm about to buy application for macOS, I'm always carefully inspecting its bundle and trying to determine which technologies were used. Unless it's pure Objective C/Swift, I'm usually won't buy it. I hope, more users would do it.
  - omginternets 10y ago
    >C is generally faster, than hand-written assembly, so it doesn't make sense to write software in assembler. That's true now. It wasn't true then. The point still stands.
    - ornitorrincos 10y ago
      and not even true now for certain workloads, each tool for its job
- faaq 10y ago
  hehe, you remember me, that crystal, nim and rust are invented to avoid write C ¯\_(ツ)_/¯

bobwaycott 10y ago

Everything in the world of web-stack development has turned externalizing costs onto users as a core first principle.

rpastuszak 10y ago
How about PWA, Service Workers, WebAssembly? Thousands of developers are working hard on improving the UX, reduce battery usage, wasted CPU cycles, network traffic, latency.
- bobwaycott 10y ago
  All of this because they're externalizing costs onto users through SPAs and other go-to practices that force all the work onto users' devices.
abiox 10y ago
it's been that way since forever. if you're not employing expensive top-ranked brilliant engineers writing aggressively optimized, completely bespoke c applications tuned to every cpu model's feature set and performance characteristics... you just might be externalizing. insofar as it benefits the budget, you should probably externalize as much as possible. consumers will provide the fitness function through deciding what products they prefer.
- panic 10y ago
  consumers will provide the fitness function through deciding what products they prefer. What about when your users don't have a choice?
  - abiox 10y ago
    hm... performance metrics, possibly? it may be hard to measure.
- bobwaycott 10y ago
  We're not even discussing aggressively optimized C vs web stack. We're talking about a massive segment of today's software developers not even bothering to learn competent C (or Obj-C, Swift, Java, whatever) to build a native application. Hell, it's about the very practice of calling Electron apps native to begin with. The same thing continues to hold across web stack everywhere—reach only for those things that don't require you to learn a new language/paradigm, letting you keep churning out the same thing you build in a browser and call it native for platform X, and let it be on the user to pony up the resources to use it.

sametmax 10y ago

Well users/clients/bosses want everything, now, and for free so...

tertius 10y ago
Free things give continuous hassle. People on business don't want hassle. They pass on free except if they're very inexperienced.

pdabbadabba 10y ago

Well, to the extent that these costs degrade the user experience, I'm not sure they really are externalizing them. Presumably they pay this cost in the form of decreased user satisfaction. It's just that this is a cost they are willing to pay. There may be an interesting economic lesson here: it really is not that easy to externalize costs. It surely can be done (air pollution), but it requires some special circumstances for those costs not to be internalized in a different form. (These special circumstances might include information asymmetries, harm to a public good, enjoyed by people other than a firm's own customers, etc.--themselves classic risk factors for market failure.) By the same token, there probably are some truly externalized costs in this example, but I would expect them to be very minor and indirect. For example, most people probably do not pay the 'true' cost of their electricity. So to the extent electron wastes power, some of the cost will be internalized in the form of user dissatisfaction. But some will also be externalized either because the user doesn't know about the extra power consumption, or because the user herself doesn't fully internalize the costs of her power consumption and therefore doesn't care as much as she might if all costs were properly internalized.

bhauer 10y ago
> Well, to the extent that these costs degrade the user experience, I'm not sure they really are externalizing them. Presumably they pay this cost in the form of decreased user satisfaction. It's just that this is a cost they are willing to pay. Precisely. I don't use Slack in part because its desktop application is irrationally bloated for its use-case. Although I have other reasons as well, they are enduring a cost--a small one to be sure, but presumably non-trivial in aggregate--in people refusing to use their service in part because their desktop application is poor. But I do agree with the general emotion underlying the frustration of "externalities" here. As someone who advocates for high-performance and efficient web applications, I have toyed with the question of whether developers should confront the morality of wasting energy by having selected poor/low-performance platforms. Put in a somewhat comedic tone: low-performance software contributes to climate change.
- nojvek 10y ago
  By walking just one day a year than taking my car, I can offset the electricity consumed by my laptop. You do have a point though. You make a difference where you can.

Tenhundfeld 10y ago

I don't disagree, but I'm hopeful that Electron will get better. When you choose an open source platform with a diverse group of major companies using it, part of what you are betting on is that the platform will a) survive for a reasonable amount of time and b) gradually improve. GitHub, Slack, Spotify, Microsoft, etc., are all using Electron. As their developers gain experience with the platform and as they experience problems with resource usage, I would expect to see the platform improve. Maybe I'm wrong.

bluejekyll 10y ago
On top of that, webassembly could see some improvements across the board.
- douche 10y ago
  The future, where we write in native languages, that are compiled to Javascript, run in a webbrowser VM, and power desktop applications. Jesus wept.
  - m_fayer 10y ago
    In 2014 I laughed. No longer laughing. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  - bluejekyll 10y ago
    It's not that they are native languages. They are languages with no overhead, GC is no longer necessary for example.
- sethc2 10y ago
  I agree. I think it also has the potential to help motivate developers to write native UI rather than use electron. Currently if for your market, your primary target platform is the web, but other platforms are still important, going electron might make sense because you really don't want to write your business logic natively for each platform. Web assembly allows us to use the same native libraries for all our business logic and data models, which besides being more performant, means we only need to be willing to write the UI natively on top of those libraries. We've actually taken (very) old desktop C++ code, and compiled it to asm.js and ran it in our web app, and then rendered its outputs with webGL onto a canvas and have had surprisingly successful results. This makes the prospect of WASM becoming standard across the board very exciting. Now let's hope we don't decide to replace our native desktop app, that uses this old C++ library, with an electron app of our web app, running the asm.js compiled library :).

jrochkind1 10y ago

Well, why would any developer or organization doing development "want" to pay those costs, as you suggest they should?

Arizhel 10y ago
To make a quality product and offer a better user experience? Users may not notice the slowness right away, but if they run a bunch of applications at once they probably will, and they're more likely to notice it while running on battery.
TeMPOraL 10y ago
Because those costs grow orders of magnitude as they're externalized. $1000 spent during development can offset $1M in energy wasted by a million users. So they should want to pay those costs as responsible members of civilized society. And if they don't want to, they should be forced to by said society.

pluma 10y ago

I've switched from Sublime Text 3 (native) to VSCode (Electron) and I couldn't be happier. If I didn't know it's electron based I wouldn't have been able to tell as a user. YMMV so don't generalise.

kungtotte 10y ago
When did you switch? Atom was damned near unusable around 1.0, and VSCode was only a little better. The difference to now is night and day.
- infogulch 10y ago
  Atom and VSCode are in different leagues with respect to performance, and the difference is growing with time. If you think the reason that Atom is slow is because of Electron, VSCode is the counterexample.
  - ori_b 10y ago
    If VSCode isn't slow because of electron, what's the reason it's slow?
    - pluma 10y ago
      VSCode isn't slow. Atom is slow. Since both are written with electron the difference must obviously be the actual implementation, not the platform itself. Keep in mind VSCode was written by Microsoft who have decades of experience writing IDEs and text editors, whereas Atom was written by GitHub who are mostly working on the GitHub product.
      - ori_b 10y ago
        > VSCode isn't slow. Atom is slow. Could have fooled me.
        iterateandgit 10y ago

shaan7 10y ago

THIS ^

jliptzin 10y ago

The vast majority of users (like >99%) don't have a clue why their computer isn't performing up to par. They literally have no idea how any of it works. They might just assume that it's slow because they haven't deleted spam emails in a while (even while they use gmail) or didn't pay extra to get that 3.2Ghz machine instead of the 3Ghz. They certainly don't have any idea how to open up top stats and check what resources a particular app is using, so until that happens and users punish developers for this kind of stuff, expect it to continue.

wott 10y ago
> The vast majority of users (like >99%) don't have a clue why their computer isn't performing up to par. They literally have no idea how any of it works. Same thing for Web developers.
flukus 10y ago
Yes, you'll often hear things like "I think I have a virus" or "I think I need a new computer". They're computer is fine, they're just running slow apps.
- brokenmachine 10y ago
  They need a new computer because they don't know how to make their old one work properly. Getting a new computer will fix the problem though. :-)

greenhatman 10y ago

>There are costs to developing desktop applications and developers don't want to pay them, so they make users pay for them That is definitely not the whole story. Costs are shared between developers and users. If it's more expensive to develop an app, you can bet it's going to cost users more too.