7 ms·
The answer: Electron and this new breed of lazy "developers" who can't be bothered to actually make decent native apps.
by Rjevski 9y ago
The answer: Electron and this new breed of lazy "developers" who can't be bothered to actually make decent native apps.
- johnflan 9y agonailed it
- rco8786 9y agoI know right. Real "developers" only write in assembly with a completely separate codebase for each target platform. No code review or source control either, because they're not lazy. Actual issues aside (yes slack takes up way too much memory and it's due to the platform they chose which is hugely bloaty but will undoubtedly get smaller/faster over time just as everything does) why would you choose to attack the developers for building a tool that millions of people use with great success? They're not lazy. They used the best tools available to them to deliver their product and they're reaching the limits of said tools. Now they have to address those limits. This is exactly how software is supposed to work.
- Rjevski 9y agoI choose to attack those developers because they're taking an easy path knowing that it will end up in a bad product, yet they still do it. At the end of the day I don't care which technology is used as long as the end product is good, however a chat client that uses 1,5GB of memory is the total opposite of good. Come on, it's a f'ing chat client - a solved problem and existing implementations (look at any IRC client) take like 100MB's max. I would have no problems with Electron if they somehow managed to get the resource usage similar to a native app.
- deleted 9y ago[deleted]
- npizzolato 9y agoPerhaps the attitude of measuring the good-ness of a chat client solely on how much memory it uses is one of the main contributors to the rise in popularity of Slack and the decline in popularity of IRC. I personally don't care if my chat client uses more ram than its competitors if it's easier to use. Judging by the amount of people using Slack, I don't think I'm alone.
- kelnage 9y agoIf its a "solved problem" then why aren't users flocking to IRC over Slack? The answer is likely multifaceted, but part of it is undoubtedly the usability of the client - which may be resource intensive, but that was likely a trade off for speed/ease of development.
- frgtpsswrdlame 9y agoMarketing? IRC's not sexy like Slack is. Realistically, it's going to take what, 10 extra minutes for a dev to get IRC down versus Slack?
- rhizome 9y agoNIH Syndrome. You can't make a walled garden out of IRC.
- cuckcuckspruce 9y agoWhy can't you? You just don't connect your IRC server to any other server.
- rhizome 9y agoTrue, so maybe they're also hoping for patents or other ancillary NIH benefit.
- omaranto 9y agoWhy would people flock from Slack to IRC? IRC is much older, it's probably more like people sticking with IRC and not trying Slack. Which presumably is happening in large numbers.
- deleted 9y ago[deleted]
- dman 9y agoCan you give me some examples of platforms whose memory usage has meaningfully gone down over time?
- Rjevski 9y agoNope, but memory usage has increased in sync with how technology evolved - software that used to take X MB of memory now takes X*2 but at the same time your laptop now comes with 2x or 4x the memory it used to. However Electron takes this to a new extreme - the memory usage of an Electron app is like 15x of that of a native app, and yet I can't buy a Macbook with 100GB of RAM.
- dman 9y agoIts not even the RAM that annoys me the most about Electron - its the hit to the battery life.
- vintagedave 9y agoThere's an important realisation as a developer, or in fact as anyone whose work affects other people. Consider a bug or badly created feature that costs users ten seconds of their time. Let's assume a hundred thousand users, encountering that once a day, for a year. That's 4200 man-hours lost per year. Is it user-focused to allow that bug to remain? How do you judge the importance of your users' time? Slack - often Electron-based apps in general - are fast for the developers to create, but cause problems for the users. There are many more users than developers, and a good question is, is the value of users' time and money less than the developers, or the user's resources (such as memory) the developers' to freely use? Developers can't write their whole app in assembly, but at what point do the problems their choice of technology cause for users overbalance a reasonable standard of consideration for their users and user experience? An app with the problems Slack has is one that has largely prioritised the developer's time and resources over their users. So your "real developers" comment is a straw man ;) But you're close, I think: better is to consider the balance of value developers ascribe to themselves vs their users and what use of Electron, and app behaviour like this, says.
- pspeter3 9y agoShouldn't this trade off be born by the market? If Electron is such a problem for Slack, users should be switching away to better engineered alternatives.
- vintagedave 9y agoJust because Slack is useful enough people use it, doesn't meant the tradeoff they've made when developing indicates a high regard for their users' machines or experience.
- pspeter3 9y agoThat's fair. I wonder if users actually care in practice.
- vintagedave 9y ago
- carlosrg 9y agoExactly. It's just bad engineering. Taking shortcuts to save money and not paying attention to important non-functional requirements.
- iheart2code 9y agoI wouldn't blame this on engineers -- they aren't necessarily the ones making the (albeit very attractive) business decision to use one codebase for multiple platforms.
- skinnymuch 9y agoHe didn't really blame the engineers. He blamed the engineering. Unless you were just saying your statement and not implying he blamed engineers.
- FieryTransition 9y agopersonally I never had problems with discord (also made with electron), seems to me that you can make good and bad design decisions regardless of the stack you use. Don't think electron is alone on this. Choosing a stack makes some things easier and other things harder to accomplish though.
- Mithaldu 9y agoDiscord performs pretty badly to be honest. I have it idling with no chats open and using as much resources as other chat clients with 50+ chats open.
- outworlder 9y agoThis is a very short-sighted comment. Electron or not, you need a web browser to display content. Unless you want to replicate a browser's layout engine, poorly. History and the rich interface are the main appeals of Slack. I guess you could create a QT app or something and embed a web widget inside. Not sure how much that would help.
- zakk 9y agoSince when you need a web browser to display content? Slack could easily use native widgets, without embedding any HTML.
- outworlder 9y agoHave you used Slack? The rich interface is one of the main reasons people use it. It's not IRC.
- Rjevski 9y agoI feel like I've made a mistake mentioning IRC - that was just an example to say that a client that receives and sends messages over the network was a solved problem. Rich interface doesn't mean HTML and CSS. Have you seen good iOS apps? Their interface is just as rich and yet it's pure Swift/Objective-C compiled down to native code.
- zakk 9y agoYes I have, and I have used interfaces which were as rich, or even richer, for decades, without the need of embedding web content. For instance GTK apps in the earlies 2000s were easily displaying content as rich.
- outworlder 9y agoI understand that. But we also have apps like Adium displaying their chat messages using HTML with no issues, just because they want to easily customize the themes. Point is, native or not native, this should not matter for a well optimized code. We are not talking about a AAA game here, it's just a chat app. It should not be burning cycles when inactive.
- findjashua 9y agoGiven that Visual Studio Code is also built on Electron but poses none of the resource issues (in spite of being a much more complex application - ide v/s chat client), makes me think the problem lies with the application and not the platform
- quickthrower2 9y agoYes but they probably worked their arses off and spent big bucks to get it to perform. And it's kind of a marketing product: one of Microsoft's catch-up-with-whats-hip initiatives. For the average shop just code native and get that performance for free.
- StevePerkins 9y agoI like VS Code. However, people think it's "light" and "snappy" only because they're comparing it to Atom. IntelliJ feels pretty fast-loading and snappy when you put it head to head against Atom. The reality is that Code takes multiple seconds to launch on my machine (a MacBook Pro with 16GB RAM), while GVim or Sublime or any native editor is subsecond. Granted, it does perform well enough once it's up and running. But startup time is probably an order of magnitude worse, and ongoing resource consumption even far less competitive. Code shows that it's possible for a good Electron app to be better than a bad Electron app. But that's not a proof statement that Electron is in the same league is native.
- abritinthebay 9y ago> people think it's "light" and "snappy" only because they're comparing it to Atom There's some truth to this, but I also prefer it to (my previous workhorse) Sublime. Which is a 100% native app, unlike Atom. > The reality is that Code takes multiple seconds to launch on my machine (a MacBook Pro with 16GB RAM) Something is wrong there, it really shouldn't. 1 second, maybe, if you're loading a large complex folder or something but unless you've got a crap ton of extensions I've never seen it be that slow.
- reificator 9y ago
- seretogis 9y agoPlease don't blame Electron. VS Code is an Electron-based application and it runs beautifully, with much less RAM/CPU hoarding than Slack. I only run Slack in a Chrome tab now.
- tomc1985 9y agoNot really... it's still considerably slower than Sublime, Gedit/Pluma (or anything gtksourceview), vim, and others, and VS Code got to where it is today due to much gnashing of teeth I would love to see Electron abandoned...
- pspeter3 9y agoWhat alternative would you propose?
- tomc1985 9y agoI haven't played with QT's JS backend but that looks nice. (It's C++ native) pyGTK is a good toolkit. On the JVM side of things there's JavaFX Almost anything is better than bundling webkit really... even WinForms. And the above list is mostly new stuff for new devs. For the real programmers amongst us there's QT, GTK, JVM's Swing...
- pspeter3 9y agoDo you have an example app in production that cross compiles to all platforms? Also, what constitutes a real programmer?
- tomc1985 9y ago> Also, what constitutes a real programmer? People that aren't afraid of the hard stuff, and don't need software to wipe their ass? As for software... IntelliJ IDEA (Swing), we use internal pyGTK stuff that runs on Win/Mac/Lin, Wireshark (QT), Mozilla Firefox (XUL ... another brilliant UI markup language which died for no good reason), pgAdmin III (wxWidgets) On the music plugin side of things there is a lot of VSTs written in JUCE framework, another good cross-platform UI kit which focused on audio software.
- pspeter3 9y agoThis seems like an ad hominem attack based on developers making trade offs. Electron essentially seems to be born out of the trade off of engineering a web product and satisfying customer demands for a desktop app. Edit: Removed commentary about most desktop apps based on https://news.ycombinator.com/item?id=14869864 https://news.ycombinator.com/item?id=14869864
- dkersten 9y ago> reliable cross platform experience In my own personal experience, these applications have almost never provided me with a more pleasant experience than eg a Qt application. Plus I've had Slack's CSS mess up giving me a weird messed up UI. This has NEVER happened with an actually native application. I've also had Slack consume 4 gigs of RAM, which is ridiculous for something that is never the main thing I use my computer for. Quicker time to market perhaps, but "reliable cross platform experience".. not in my opinion, at least, unless you mean that its reliably equally bad on all platforms ;-) EDIT: Cross platform is easy when you don't need a platform-native look and feel, which web-as-native often doesn't do anyway (or not perfectly at least)
- pspeter3 9y agoYeah, that makes a lot of sense. Do you feel the same way about rich web apps?
- dkersten 9y agoYeah, in comparison to native apps anyway. At least they don't pretend to be native. But really, I think it depends on use case: most web apps I use aren't things that I need to leave open all day, while Slack is.
- jpttsn 9y agoMost? That sounds wrong to me, but I don't even know how you're counting. Most by number of apps? Consider all little enterprise things built in Java or whatever. Most by time spent? Browsers, AAA games and file managers aren't web apps, surely? Most by HN hype and VC funding?
- uniformlyrandom 9y agoThat is just silly, blaming the instrument rather than implementation. Electron is an excellent instrument, and you can leak memory and abuse CPU in any language.
- mahyarm 9y agoSome instruments are more prone on average to do so than others. Why are most flash games horrible on CPU usage but something made in pygame not nearly as much?
- chillee 9y agoAh yes, all those great games made in pygame like...?
- mahyarm 9y agoIt can be actually pretty subtle since they tend to present themselves as standalone executable games and don't advertise the fact they used pygame, and this was the time before unity was much of anything. Nowadays everyone just uses unity. One game I remember was a 2D space game that had pretty good graphics, digging into it's folders and being surprised at seeing pygame and python everywhere. But it's probably been 10 years since I've played it so I can't remember the name. The rest is google.