1. 29
  1.  

  2. 18

    Slightly off topic: I see people complaining a lot about Electron, with Slack being a prime example.

    I think the success of Visual Studio Code means that it is possible to build excellent apps using Electron. And that the performance of Slack app is not necessarily representative of all Electron based apps.

    1. 26

      I think it’s possible. But VSC is literally the only Electron app that doesn’t blatantly suck performance-wise. Is that because Microsoft just actually put in the effort to make something good? Or is it because Microsoft has built best-in-class IDEs that scale radically better than any alternative for a long long long time?

      Now no one get me wrong, I’m a UNIX guy through and through, but anyone who claims there’s anything better than Visual Studio for large scale C++ development has no clue what they’re talking about. C++ as a language is complete bullshit, the most hostile language you can write an IDE for. Building an IDE for any other language is child’s play in comparison, and Microsoft is proving it with VSC.

      I don’t think it’s currently possible for anyone besides Microsoft to make an excellent Electron app. They took a bunch of internal skill for building huge GUI applications that scale, and built their own language to translate that skill to a cross platform environment. I think they could have chosen whatever platform they felt like, and only chose to target Javascript because the web / cloud is good for business. We’ll start seeing good Electron apps when Typescript and the Microsoft way become the de facto standard for building Electron apps.

      But I also haven’t slept in 24 hours so maybe I’m crazy. I reckon I’ll go to bed now.

      1. 7

        but anyone who claims there’s anything better than Visual Studio for large scale C++ development has no clue what they’re talking about.

        JetBrains CLion might actually be a bit better – but they started building addons to improve development in VisualStudio (e.g. the amazing ReSharper) originally, and only expanded to build their own IDE later on.

        I fully agree on all other points.

        1. 5

          CLion definitely has a great feature set, but I’ve found a lot of it to be unusably slow, at least on our large codebase. Lots of us use Qt Creator even though it’s objectively worse and has some sketchy bugs, because it’s at least fast for the stuff it does do. I look forward to the day I can comfortably switch to CLion.

          1. 3

            CLion is fantastic, I came to it after a lot of use of PyCharm.

        2. [Comment from banned user removed]

          1. 5

            I don’t think I can agree on the hype thingy here.

            Background: I hate developing on Windows, been using Linux for god knows how many years, but I do have a Windows work(play)station at home where I sometimes do development and I don’t always want to ssh into some box to develop (or in the case of creating Windows applications, I can’t)

            I’ve been using eclipse for years (for the right combination of languges and available plugins, of course) and had been searching for a decent “general-purpose” replacements (e.g. supports a lot of languages in a decent way, is configurable enough so you can work, has more features than, say, an editor with only syntax highlighting). So ok, I never used Sublime Text (tried it out, didn’t like it for some reason) and VS Code was the first thing since like 10 years where it was just a joy having a nice, functioning and free IDE/text editor that didn’t look like it was written i the 90s (like, can’t configure the font, horrible Office 94-like MDI), doesn’t take 2mins to load (like eclipse with certain plugins) etc.pp

            It’s about frictionless onboarding, and yes, maybe I sound really nitpicky here - but it’s from the standpoint as a totally hobbyist programmer, as my overlap with any work projects or any serious open source work (where I usually have the tooling set up like at work, as it’s long-ongoing and worth the investmnt). That’s also the focus on free. Absolutely willing to pay for a good IDE (e.g. IntelliJ IDEA) but not if I’m firing it up once per month.

          2. 3

            Is there a chance that the ill reputation of Electron apps is that Electron itself offers ample opportunity for prime footgunmanship?

            I’d argue that yes, it’s quite possible to build a nice simple (moderately) lightweight thing in Electron; it’s just pretty hard in comparison to building, say, a nice simple (definitely) lightweight CLI. Or even a desktop app using a regular graphical toolkit?

            1. 10

              Visual Studio Code, Slack, Discord, WhatsApp, Spotify all are unfortunately not simple. And while they could be reduced to simpler apps, I kinda feel like we’re all using them exactly because they have all these advanced features. These features are not useless, and a simpler app would disappoint.

              It also seems like GUI and CLI toolkits are lagging behind the Web by maybe a decade, no joke. I’d love to see a native framework that implements the React+Redux flow. Doesn’t even have to be portable or JavaScript.

              1. 4

                I’m a huge fan of CLI software that eats text and outputs text. It’s easier to integrate into my flow, and the plethora of tools that are already available to manipulate the inputs and outputs.

                An example: I’ve written a CLI client to JIRA that I have plugged into the Acme editor. I just tweaked my output templates a bit to include commands that I’d want to run related to a given ticket as part of my regular output, and added a very simple plumber rule that fetches a ticket’s information if I right-click anything that looks like a JIRA ticket (TASK-1234, for example). It’s served me well as a means to not have to deal with the JIRA UI, which I find bloated and unintuitive, and it allows me to remain in the context of my work to deal with the annoyance of updating a ticket (or fetching info regarding a ticket (or listing tickets, or pretty much anything really)). It’s far from perfect, but it covers most, if not all, of my day-to-day interaction with JIRA, and it’s all just an integration of different programs that know how to deal with text.

                [edit: It’s far from perfect, but I find it better than the alternative]

                1. 1

                  Is either part of that open-source by chance? I’ve been trying acme as my editor and use JIRA at work. I have a hunch you’re largely describing four lines of plumb rules and a short shell script, but I’m still having trouble wrapping my head around the right way to do these things.

                  1. 3

                    Full disclosure, the JIRA thing has bugs that have not stopped me from using it in any meaningful way. https://github.com/otremblay/jkl

                    The acme plumbing rule is as follows:

                    type	is	text
                    data	matches	'([A-Za-z]+)-([0-9]+)'    
                    plumb	start	rc -c 'jkl '$1'-'$2' >[2=1] | nobs | plumb -i -d edit -a ''action=showdata filename=/jkl/'$1'-'$2''''
                    

                    It checks for a file called “.jklrc” in $HOME. Its shape is as follows:

                    JIRA_ROOT=https://your.jira.server/   
                    JIRA_USER=yourusername
                    JIRA_PASSWORD=yourpassword
                    JIRA_PROJECT=PROJECTKEY
                    #JKLNOCOLOR=true
                    RED_ISSUE_STATUSES=Open
                    BLUE_ISSUE_STATUSES=Ready for QA,In QA,Ready for Deploy
                    YELLOW_ISSUE_STATUSES=default
                    GREEN_ISSUE_STATUSES=Done,Closed
                    # The following is the template for a given issue. You don't need this, but mine contains commands that jkl can run using middleclick.
                    JKL_ISSUE_TMPL="{{$key := .Key}}{{$key}}	{{if .Fields.IssueType}}[{{.Fields.IssueType.Name}}]{{end}}	{{.Fields.Summary}}\n\nURL: {{.URL}}\n\n{{if .Fields.Status}}Status:	 {{.Fields.Status.Name}}\n{{end}}Transitions: {{range .Transitions}}\n	{{.Name}}	| jkl {{$key}} '{{.Name}}'{{end}}\n\n{{if .Fields.Assignee}}Assignee:	{{.Fields.Assignee.Name}}\n{{end}}jkl assign {{$key}} otremblay\n\nTime Remaining/Original Estimate:	{{.Fields.PrettyRemaining}} / {{.Fields.PrettyOriginalEstimate}}\n\n{{.PrintExtraFields}}\n\nDescription:   {{.Fields.Description}} \n\nIssue Links: \n{{range .Fields.IssueLinks}}	{{.}}\n{{end}}\n\nComments: jkl comment {{$key}}\n\n{{if .Fields.Comment }}{{$k := $key}}{{range .Fields.Comment.Comments}}{{.Author.DisplayName}} [~{{.Author.Name}}] (jkl edit {{$k}}~{{.Id}}):\n-----------------\n{{.Body}}\n-----------------\n\n{{end}}{{end}}"
                    
                    1. 1

                      Thank you so much! I’ll take a look shortly. It really helps to see real-world examples like this.

                      1. 2

                        If “jkl” blows up in your face, I totally accept PRs. If you decide to go down that path, I’m sorry about the state of the code. :P

                2. 1

                  It also seems like GUI and CLI toolkits are lagging behind the Web by maybe a decade, no joke. I’d love to see a native framework that implements the React+Redux flow. Doesn’t even have to be portable or JavaScript.

                  I couldn’t disagree more. Sure, maybe in “developer ergonomics” Web is ahead, but GUI trounces Web in terms of performance and consistency.

                  1. 1

                    I’d love to see a native framework that implements the React+Redux flow.

                    Maybe Flutter?

                    1. 1

                      Flutter is such a native framework, although only for mobile (i.e. Android & iOS).

                    2. 2

                      I belive one of the things that gave Electron apps a bad reputation (aside from the obvious technological issuses) were things like “new” web browsers, built with electron, offering nothing practically new, that most people would actually want, such as lower memory consumption, for example.

                      1. 2

                        Building UIs is hard in general - it seems like electron trades off ease of making UIs performant for ease of building them.

                        That being said, it seems like it’s not prohibitively difficult to build a fast UI in electron: https://keminglabs.com/blog/building-a-fast-electron-app-with-rust/

                        It seems like most people building electron apps just don’t think about performance until much later in the process of development.

                      2. 2

                        I think one of the few main selling points of Electron was accessibility. Anybody with solid knowledge of HTML, CSS and JS could find his way around and build the app that was running on multiple platforms. But it wasn’t performant and it was quite resource hog as it turned out. Now why is this not the case with Visual Studio Code? Because it is being written by really good developers, who are working for Microsoft, who worked on creating Typescript, in which is Visual Studio Code written, on top of Electron. Now you can get the sense of things why Visual Studio Code is different case than rest of the Electron apps, people behind it are the reason. And whole story defeats the point of Electron. If Electron as a platform could produce half as good results as VSC in terms of performance and resource efficiency than maybe it would be more viable option, as it is right now, I can see the pendulum swinging back to some other native way of implementing applications.

                        1. 2

                          I mean, I hate the web stack like few others, but I think the point that ultimately the people are more determinative than the technology stands.

                          I just really hate the web.

                        2. 1

                          I completely agree. I think that a lot of the frustrations with the quality of Electron apps is misplaced.

                        3. 9

                          I used to switch editor every couple months because I could not find my sweet spot. VS Code has conquered my heart 8 months ago and I love it, and it works blazing fast even on my old MBP!

                          1. 8

                            The one thing I really admire about Visual Studio Code is the support for language servers. I’m glad the days of every IDE/editor implement their own static analysis tools in the same language as the IDE are over, or on the way out at least.

                            1. 2

                              JetBrains various IDEs support those too but they are not as lightweight.

                            2. 6

                              Besides the negative points discussed above, Atom is effectively the same tool as Sublime Text except it runs slower.

                              I disagree with that statement. Sublime Text is great, I love its speed, but it has a bunch of tiny awkward details that Atom doesn’t have, and Atom has some cool features that Sublime Text doesn’t.

                              From ST one of the things that bothers me the most is that it assumes I want to drag text that I’ve selected, which is false, actually I basically never want to drag text. This assumption means that I can’t select something and then re-select something inside that selection, because it assumes a drag is a text drag, not a selection.

                              Another bit I find Atom does great is the splits, I love its approach. My favorite of any editor.

                              Not that I use it a lot, but the Git support from Atom is great.

                              I can’t figure out how to make ST’s subl command behave like I want. I want it to behave exactly like Atom’s:

                              • subl . opens current dir in a window and nothing more
                              • subl opens new window and nothing more
                              • If a window is opened without a file, it just opens an empty window with no working dir

                              Right now it also opens whatever old window I had open when I last closed ST, and I can’t find how to disable that.

                              Also, to be fair, Atom has Teletype now. I haven’t used it, but it looks cool.

                              I probably missed something, but I think I’ve done enough to show it’s not “the same”.

                              1. 2

                                The ‘drag selected text’ continually confounds me. I can’t imagine anyone finding that useful. The other thing is Eclipse and other IDEs dragging/dropping arbitrary objects in project/navigator views, “oops where’d that folder go?” It’s maddening.

                                1. 3

                                  One always cuts and pastes, right? Who drags around a block of text..

                                  1. 1

                                    Have you tried going to preferences -> settings and addding/changing "drag_text" to false?

                                  2. 2

                                    The dragging thing is probably OS-specific. I don’t see it on my Ubuntu.

                                    1. 1

                                      It looks like there’s an undocumented option remember_open_files in ST. That combined with alias subl="subl -n" in your shell should get pretty close to the behavior you’re looking for.

                                    2. 4

                                      Does anyone find it to be kind of sad that any time there’s even a whiff of anything related to Electron that the discussion devolves into the usual Less Filling/Tastes Great that we’ve come to know and expect?

                                      1. 4

                                        For the longest time, most tech choices around what’s really popular are mostly marketing or social even though the users tell themselves and others it was technical merit. Convenience also trumps most other factors. The Electron situation just seems like another instance of it to me. If Electron conversations bothered me, then most tech conversations would bother me. Not good for state of mind to let that happen. :)

                                        1. 4

                                          Oh, I’m not bothered, I just have to wonder if there are more interesting topics one might choose to discuss.

                                          And I couldn’t agree more - convenience / easy of adoption is a HUGE factor in tech adoption.

                                          Look at Go, one of the reasons that language is making such inroads at least in the ops/infrastructure arena is the fact that it’s damnably convenient in that it produces self contained binaries you can simply drop in and done.

                                          Electron strikes me as being entirely similar. Give Javascript devs the ability to write desktop apps? Of course it’s going to be a hit. People can moan all they like, but it’s here. Maybe let’s think through ways of using it well and guidelines for creating performant Electron apps rather than trying to tell everyone that they should be coding in ANSI C or assembler :)

                                          1. 2

                                            On your first point, it’s gotta be one of the least-productive topics. The only time I was glad this topic came up was an article talking about multiple attempts at a cross-platform, native version of a simple, graphical app with all the problems that came with it. That was great for showing exactly the kinds of problems the pro-native crowd needs to fix. Even the mismatch between those components might not be so bad if one takes a metaprogramming/generative/DSL approach to the problem: clean language describing the GUI mapped to primitive functions in native language, some OS-specific views for native look/feel (manual or generated), several libraries worth of integration and/or boilerplate just get generated from that, and build instructions are handed off to platform-specific tooling to turn it into several executables. The framework, even if generated through external tooling, is at least mocked up in some native language + IDE for easy development of the GUI part. That’s the kind of thing tumbling around in my mind as I read that or see these Electron threads.

                                            On your last point, yeah that would be more productive. Maybe the VS Code people have a write-up somewhere on how to build great Electron apps. They seem to be the champions at it based on comments I read. Alternatively, they’re the champions at efficient algorithms for IDE’s in C or C++ that they’re just compiling to efficient primitives of JS. In that case, the efficiency has nothing to do with it being Electron. That I used to run Visual Studio 6 on a 64MB RAM machine makes me think it’s possible. Whereas, installing Slack for first time on a 4GB machine I fixed last night was first time it had a run out of memory error in 8 years. That could be a coincidence, though. Maybe…

                                      2. 2

                                        I use both Sublime Text and Visual Studio Code, but I often noticed VSCode having some decent input lag (at least when using the Vim Mode), where Sublime, once it is started, rarely does to the same extent.

                                        That being said, there are a lot of things that VSCode does that can be quite useful, and somehow, it manages to have a terminal that is less laggy than ConEmu.

                                        1. 1

                                          VSCode’s vim emulation is really laggy.

                                          I was playing with throttling my CPU to 400MHz to see how slow certain things were, an unexpected consequence was it took substantial time (felt like about half a second, but I didn’t measure) for a keystroke in vscode to actually register. Turning of the vim extension fixed this entirely.

                                          1. 2

                                            So, minor update on this: I don’t think it’s just the Vim Emulation that’s laggy. I suspect there are other extensions that are similarly laggy (I didn’t test to figure out which ones, because I have other things to do at the moment). I actually switched from VS Code back to Sublime Text for Angular/Typescript development due to just getting fed up with the general lack of responsiveness I was getting. Given that Sublime Text has autocomplete for TypeScript, I’m not losing a great deal.

                                            1. 1

                                              That’s a shame. I like having my Vim keys. Maybe I’ll have to look into other Vim for VS extensions

                                          2. 2

                                            Wow. I was using Atom until I read this post. I had dismissed VSCode because Microsoft but WOW, this is zippy!

                                            1. 2

                                              I tried VSCode for two weeks, then went back to Sublime. I found the code intel better on Code, but it just was not snappy on a medium sized python project. It was taking half a second to switch between two open files, and jump to symbol was nowhere as fast as sublime. Maybe it sounds like nitpicking but it was driving me insane. So Sublime it is for me. I’ll reevaluate Code periodically though, because it’s very promising.

                                              1. 1

                                                FWIW I did the exact same thing recently - but skipped the inbetween steps. VS Code is (for now) the best of both worlds. Until it gets too bloated and heavy I guess…

                                                1. 1

                                                  Is VSCode open source? How do I know Microsoft isn’t sending every keystroke to headquarters? They’re known to do shady stuff like that, so unlike the closed source Sublime Text I don’t trust them.

                                                  1. 4

                                                    It’s MIT licensed see: https://github.com/Microsoft/vscode/blob/master/LICENSE.txt

                                                    That said, the default build you download from them, if you do not build it yourself has a different license and does include some usage stat gathering and telemetry information, but you can turn it off ( https://code.visualstudio.com/Docs/supporting/FAQ#_how-to-disable-telemetry-reporting ) .

                                                    Lots of details available about the licensing differences here: https://github.com/Microsoft/vscode/issues/60#issuecomment-161792005

                                                    1. 3

                                                      Wow, thanks for that link. From https://code.visualstudio.com/license#vscode :

                                                      You may not:

                                                      • work around any technical limitations in the software;
                                                      • reverse engineer, decompile or disassemble the software, or otherwise attempt to derive the source code for the software except, and solely to the extent: (i) permitted by applicable law, despite this limitation; or (ii) required to debug changes to any libraries licensed under the GNU Lesser General Public License which are included with and linked to by the software;
                                                      • remove, minimize, block or modify any notices of Microsoft or its suppliers in the software;
                                                      • use the software in any way that is against the law; or
                                                      • share, publish, or lend the software, or provide it as a hosted solution for others to use, or transfer the software or this agreement to any third party.

                                                      That’s some “MIT Licensed software”, lol.

                                                      From the linked comment:

                                                      When you build from the vscode repository, you can configure the resulting tool by customizing the product.json file. This file controls things like the Gallery endpoints, “Send-a-Smile” endpoints, telemetry endpoints, logos, names, and more.

                                                      Someone should setup a website to distribute debullshitified builds. Or at the very least clear instructions on how to create your own.

                                                      1. 4

                                                        The source code is MIT licensed, 100% completely. no bullshit.

                                                        The compiled version that Microsoft distributes does indeed have a very different license :)

                                                        I agree someone should publish the MIT licensed version built for the various platforms, that would be nice. I don’t have the resources to do that, but if you wanted to send me the $$‘s and/or resources I’d be happy to do it :)

                                                        Instructions on building yourself are fairly clear: https://github.com/Microsoft/vscode/wiki/How-to-Contribute#build-and-run-from-source

                                                        1. 1

                                                          Instructions on building yourself are fairly clear: https://github.com/Microsoft/vscode/wiki/How-to-Contribute#build-and-run-from-source

                                                          Thanks for that link!

                                                          I see gcc is required, perhaps that’s a clue as to why it’s faster than Atom? (Not-Actually-100%-Electron ?)

                                                          1. 2

                                                            It even builds Rust! https://www.npmjs.com/package/vscode-ripgrep well OK, it just downloads pre-compiled ripgrep binaries, to shove inside the vscode application.

                                                            It’s definitely not 100% electron, they are very pragmatic, it seems.

                                                  2. 1

                                                    Using the IntelliJ run configurations didn’t seem to fit well with my workflow

                                                    Many of the powerful IDEs require you to set up run configurations so that the tool can run your software for you.

                                                    But Intellij Idea does not require to set up run configurations. I rarely used this feature.

                                                    1. 1

                                                      Sublime isn’t free, so it’s natural for people to go and look somewhere else. Btw Sublime is my third favorite all time text editor (Emacs on first place, Vim second). It is probably one of my favorite modern applications, looks and works like a clock on every platform. But what people look for is accessibility. Integrated debugger and git support are one of few reasons why everybody went down that route. It is questionable if that is the area which text editor should cover, but if it is easy to setup and use then people roll with it.

                                                      Same principle could be applied to Electron. Surge of web technologies, JS and web devs led to logical step of creating customizable environment that would be programmed with HTML/CSS/JS. And it is fine. Look, why would someone who is front end developer, who haven’t written in any lower level language since college (or even ever) go through the process of learning lisp or vim. He goes and finds free editor, written with web technologies in mind and it looks pretty and has all the features he can possibly need.

                                                      Sublime on the other hand is really good and robust text editor, and that’s it. In it’s essence it is really to the point, getting the job done fast and without too much bells and whistles. Yeah maybe in 2010. Sublime’s extensions and plugins were something that no other editor had, but it got surpassed pretty fast by Atom and later on by VSCode. Atom and Code can dream of speed, code navigation and indexing that Sublime has. If I had to work on larger code base I can see myself coming back to Sublime. For now (and that’s few year for now) Emacs is still keeping me pretty satisfied. Vim is always there in CLI. And I stopped looking at anything that’s Electron quite some time ago.

                                                      edits: typos