1. 16

Warning: contains Electron advocacy.

  1.  

  2. 23

    I’m sure Electron’s memory requirements and CPU hunger will eventually get fixed, but I’ve been waiting for that to happen for either Chrome and Firefox for … gods, has it been a decade already? I still have to kill off Firefox periodically because it ends up being a black hole of memory.

    If I have to force my own eyes to look at this from a positive standpoint, maybe more Electron apps is good, because it will inevitably make the issues more acute, and maybe eventually the fix bleeds back to browserland quicker than if there was less Electron apps.

    For the record, my unedited reaction was: “NOOOOOOOOOOOOOOOOOO” and then “It’s fine I don’t use that client anyway” and then “I need to write a potent CLI for the Github PR workflows that force me through the UI” and then “oh don’t I have some of that lying around already?”

    1. 24

      I’m sure Electron’s memory requirements and CPU hunger will eventually get fixed

      I’m not optimistic. You can’t stop the zeitgeist, it just shouts over you until you get tired and leave. The app industry has never cared about resource usage. It’s always about more features/gaudier UIs. The joke used to be that all apps eventually integrate an email client, now it seems like the new metric of progress is GIFs/emoji. What bothers me most is not the resource usage, but the general lackadaisical attitude toward engineering. Consumer software feels wholly extractive in nature.

      Personally, I just want to know how apps like Slack end up using over one hundred threads between all processes for a…chat client?

      1. 15

        Personally, I just want to know how apps like Slack end up using over one hundred threads between all processes for a…chat client?

        Maybe they read an article on Erlang talking about how it handles all kinds of throughput with a thread for everything. Decided to do a thread for every chat room, user, and comment. They figured multicore CPU’s would just get more concurrency. Multimoore’s Law.

        Edit: Good suggestion. Corrected.

        1. 4

          Erlang uses an erlang process for everything, not really a thread.

        2. 10

          I see what you mean, and I know how you feel; I’ve had several discussions in the recent past with colleagues about this. From a development standpoint, both for product guys and devs, it’s a nice thing to be able to take a webthing that you already have, and make it a desktopthing that is crossplatform, all the while minimizing the amount of knowledge required in order to make this happen. In this sense, I’d say that Electron is generally a good thing for the industry, as it is oriented now.

          That being said, it’s a horrible horrible craptastic shitfest for users. At least, in the humble opinion of this here dude.

          1. 4

            I sometimes think that the problem is one of incentive misalignment, and that as consumers don’t pay for software any longer, there’s no market pressure on developers to produce better output, but I’m old enough to remember when you had to pay for your software and I can’t say that it was really any better then.

          2. 12

            Here’s a thought though - such applications simply aren’t for us. They’re for people who could give a crap about memory footprint and native UI bling.

            They just want a bridge to allow therm to use what would otherwise be an app with a pretty steep learning curve, and Electron does that quite nicely.

            1. -5

              Maybe if they can’t care about memory and using native UI’s they’re too fucking noobish to be needing a real-people VCS, and they should stick to Dropbox. :|

              1. 4

                Way to welcome new people into the fold! Have you considered a career in PR? :)

                1. 6

                  I know you’re being facetious here, but let’s seriously unpack it for a second.

                  If we want better apps, better usage of resources, and better engineering, in what universe would ignoring those things in search of “new people” lead to a better outcome for us?

                  Similarly, are we leaving out new people, or just people too lazy to care about their tools?

                  It’s really popular today to sacrifice everything at the altar of “but but but MAH NEW PEOPLE” and then somehow people act surprised and confused when our runtimes bloat and our languages become overcomplicated pieces of shit and our applications turn into shiny toys with two Duplo buttons, neither of which do what we want.

                  1. 7

                    There are varying levels of acumen appropriate to different levels of contribution.

                    Sure, I wouldn’t want a UNIX kernel engineer to not be super cozy with the Git command line, but what about a young person who hears about this open source thing and wants to try to make a contribution?

                    Why do we confuse barriers to entry with sloppiness and laziness in people who should do better?

                    Given the above, I emphatically disagree. I think there is a purpose for such things as a friendly GUI client, and I reject the idea that everyone should be forced to ascend a steep learning curve in the name of “good engineering”.

                    1. 2

                      I’ve answered this in a root posting above, but look, CLI stuff is not a “barrier to entry”, especially for Git.

                      People need to get better at teaching how to use git, sure. But the tool itself (and I speak from having taught this to multiple groups of people with all ranges of experience) is quite amenable to the beginner.

                      There’s a myth that somehow learning command-line tools is harder than GUI tools, and I don’t know if that’s:

                      • because hackers are too lazy to try and teach their craft to other people
                      • because hackers and neckbeards don’t want new people devaluing the market
                      • because hackers secretly know that CLI stuff isn’t too bad and they need to feel accomplished
                      • because folks believe that any damn fool should be able to use powerful tools without learning them

                      I suspect it’s some combination of the above, and I know that it’s bullshit.

                      1. 5

                        I don’t deny that if teaching resources were better, people might have an easier time with CLI tools like Git, but where we part ways is the idea that GUIs are fundamentally inferior to the CLI. Hell, I’m a CLI person myself, I don’t use GUIs at all if I can help it. Being partially blind, I’m allergic to mice :)

                        however - I have known a great many people in my 25 years in the biz, and some are CLI people and some are not. Trying to tell someone who just HATES that command line that they should suck it up and learn is simply not productive. Tools have different expressions because different people’s brains are different, we learn differently, and even interact with the world differently. This is not a bug, it’s a feature.

                        1. 1

                          When you go to a restaurant and you want to order, do you tell the waiter what you want with words, or do you point at pictures on the wall? Language is what enables humans to communicate effectively. CLI is language. GUI can be something like direct manipulation of physical objects, in which case it makes sense, but as soon as you start dealing with abstractions, which demand language, instead of physical things, GUI becomes the equivalent of pointing and grunting.

                          1. 5

                            As a matter of fact, let’s play this game :)

                            When I go to a restaurant where the menus are in English, sure! I say what I want.

                            When the menus are in Cantonese however, that doesn’t work so well.

                            In those cases, I do in fact politely point and/or gesticulate in some other way, and so would you. Newcomers are in precisely this position.

                            1. 4

                              1.e4 e5 2.Nf3 f6 3.Nxe5 fxe5 4.Qh5+ Ke7 5.Qxe5+ Kf7 6.Bc4+ d5 7.Bxd5+ Kg6 8.h4 h5 9.Bxb7 Bxb7 10.Qf5+ Kh6 11.d4+ g5 12.Qf7 Qe7 13.hxg5+ Qxg5. How should White move?

                              Here’s the exact same thing, but visually. How should White move?

                              CLI is simple parser, because simple parsers are easier to build than simple GUIs. GUIs are higher level abstractions. They both have their place, and preferring one doesn’t automatically make you a pointer-and-grunter.

                      2. 5

                        Similarly, are we leaving out new people, or just people too lazy to care about their tools?

                        Everyone has to start somewhere. Throwing someone into the deep end of having to learn Emacs, Git, a database, and a programming language all at the same time means the only people who will make it thru are self-selected for a high pain threshold. That’s how you get tools with such a rubbish inconsistent interface like git in the first place.

                        There’s nothing wrong with letting people get a handle on their fundamental programming skills before forcing them to learn the inanities of git. There are legitimate reasons to delay learning tools which can’t be written off as laziness.

                        1. 4

                          “Buy a new computer because the one you have, even though it’s only a year old, is grossly inadequate to run all of the required tooling” is also an impediment to learning programming. 4GB computers are still being sold, and at 1GB each for chrome, atom, slack, and git, there’s literally no room left to run your program.

                          1. 0

                            These new falgned operating systems have this thing called Virtual Memory? You may have heard of it :)

                          2. 1

                            What inanities? Nothing they need to be concerned with for daily work.

                            Look, you tell them:

                            “Are you trying to start with git?”

                            $ git init .
                            

                            “Are you trying to save your work?”

                            $ git add .
                            $ <do stuff for a bit>
                            $ git commit -m "Saving progress"
                            

                            “Oh, you need to go back and undo your work?”

                            $ git log
                            $ git reset --hard <hash of commit>
                            

                            “Oh, you want to experiment?”

                            $ git checkout -b hold-my-beer
                            $ <do stuff for a bit>
                            

                            “Did it work?”

                            $ git checkout master
                            $ git merge hold-my-beer
                            

                            “Did it not work?”

                            $ git checkout master
                            $ git branch -D hold-my-beer
                            

                            Not rocket science.

                            1. 5

                              Except that this is a huge oversimplification. How many people reading this ACTUALLY just use plain old git merge? Best practice says you do git pull –rebase first , or else this imaginary newbie will be treated to the error message you get when you try to git push and your local copy is out of date.

                              Also, even if the Git CLI is easy - some people just prefer GUI interfaces to things - why must we shove everyone into the same box?

                              1. 0

                                Of course it’s an oversimplification! They’re noobs. They don’t need to get distracted with best practices and all that other good rot–they have simple problems, they need simple solutions. It’s very difficult to have it both ways. Also, I’ll note that claiming “best practices” and then later saying “why must we shove everyone into the same box” is kinda rich. :)

                                Look, with noobs, you keep it simple. Take a cue from Uncle Sam and treat your students like conscripts with a fifth-grade reading level and prioritize their being able to accomplish a task over their understanding it and potentially fucking it up.

                                1. 1

                                  What inanities?

                                  Then:

                                  Of course it’s an oversimplification!

                                  Errrrrrr.

                                  1. 1

                                    Your point? Remember, the full line (that you didn’t quote) limited the context to daily work.

                                    1. 1

                                      Sorry; trying to point out here that understanding the daily work necessities involves rote memorisation of some fairly inane commands. As @feoh mentioned, if you don’t pull/rebase first your noob’s going to hit an error, fast — they don’t need to get distracted with “best practices”, they do need to actually be able to get their work done, and CLI git will often surprise you.

                                      1. 1

                                        I might be a bit controversial in this regard, but I think that actually collaborating with other people and doing multiple things at the same time are beyond the ken of beginners.

                                        Most of the folks I see at the workshops that are beginners are either:

                                        • People who hope Github will help them build websites (no kidding here).
                                        • People who want a way of tracking their own work on their own projects.

                                        For either of those groups, simple “do this and don’t try that unless you want to learn more” directions are more than sufficient.

                                        1. 2

                                          I think I agree in general, but you have to start somewhere, right? As a beginner, say you’re starting to learn HTML5 whatever apps, and everyone and every guide says you need to use version control. You’ve never heard of it, but you do a little reading and it makes intuitive sense.

                                          Now, you can:

                                          • memorise the commands you’ve listed above;
                                          • use a GUI for Git which more-or-less is a way to do exactly those same things except the error messages are friendlier and you can neither accidentally get stuck in a pager when looking at the log (it happens ¯\_(ツ)_/¯) nor typo a command and place yourself in an unrecoverable position;
                                          • spend 4 weeks getting side-tracked learning DVCS fundamentals; or,
                                          • give up.

                                          I think it’s a fine way to avoid getting distracted. Why force “do this and don’t try that” on someone when you could just hand them something that actually makes sense to them?

                  2. 1

                    You have to kill Firefox? Ouch. I suspect an add-on is behind this and suggest looking at about:memory and about:performance for more.

                    1. 1

                      I say “kill” in the “SIGINT” sense of the term, not “SIGKILL”

                  3. 4

                    (slight bitching below)

                    I’ve taught more than a few introduction to Git courses for intermediate and total noob devs (and non-devs!) alike, and the first thing I do is have them ignore the GUI.

                    It is so much easier to point to a list of commands (say, on a cheatsheet or side whiteboard) and say “Use these, if you get lost, use this, if all hope is lost, use that.”

                    Git, for better or worse, really really really wants to be a CLI tool. Shoving it into a GUI makes it really hard to debug what a user has done (compared with backscroll) when helping them, and every GUI (looking at you, TortoiseGit and Github) feels the need to dress up common patterns with a bunch of weird phrasing and bullshit to the point where you end up running incorrect commands and eventually tripping over yourself.

                    Just teach (and use) the damned CLI tool. It’s easier for everybody involved.

                    1. 8

                      I strongly disagree–I have used Magit (the Emacs GUI for git) since 2007 and the thought of going back to the CLI for everything just makes me cringe. If I didn’t have alternate tools I would have given up on git and switched to hg years ago.

                      This is not to say that all git GUIs or even most git GUIs are any good; I suspect most of them are rubbish. But the problem is absolutely not inherent in the idea of putting a GUI in front of git.

                      1. 2

                        I think magit is the exception to the “Shoving it into a GUI makes it really hard to debug” issue, it’s easily my fave UI for git. That said, I think one can’t actually appreciate its quality without spending heaps of time using the CLI!

                        1. 3

                          Maybe… I think it’s proof that there’s nothing inherent in the nature of GUIs that leads to the difficult-to-debug-ness; it’s just that historically our patterns and paradigms surrounding how we construct GUIs happen to lead to obscuring problems.

                          1. 1

                            What are your thoughts on how GitKraken handles git? I’ve not had to use Git in very many arcane ways, but I’ve had little trouble with GitKraken in the past.

                      2. 3

                        I know Git inside and out and I still prefer Github Desktop. Basic things like separating the title and the extended comments of a commit and being able to see the entire tree in front of you make the whole process more pleasant.

                        I feel like I’m in the 80’s arguing about GUI vs. CLI. All of these arguments have already been made.

                        1. 2

                          Basic things like separating the title and the extended comments of a commit and being able to see the entire tree in front of you make the whole process more pleasant.

                          Could you clarify this a bit further?

                          separating the title and the extended comments of a commit

                          You can do this in the CLI when editing the commit message, no? I.e. not using -m flag.

                          being able to see the entire tree in front of you

                          This is possible with -v flag on commit, no? Or do you mean having it in different columns so you can do both at once?

                          1. 3

                            I’m talking about all of this in a visual sense. Absolutely, all of this is possible on the CLI, but it’s simpler and more streamlined in a GUI. When I talk about separating the commit, I mean to say that there is an obvious visual separation.

                            When I open a git project on Github Desktop, I can see the entire tree, everything that needs to be committed, and what changes were just made. I didn’t have to type anything to do that.

                            You could write some script to immediately show this information inside the prompt and in various windows in a terminal window group, but then you’d just be recreating the GUI.

                        2. 1

                          I mostly agree, except that some of the critical core Git operations are not very good on the command line. This would be staging files, particularly hunks (one of Git’s best features IMO) and viewing and manipulating the commit log. Both are possible to do on the command line, but massively clunky, and benefit from having an actual GUI.

                          The thing is, most of the commands do work better on the command line, so the problem IMO is that it’s harder to find Git GUI tools that do only the things that GUIs are good for, and don’t try to do everything under the sun.