1. 2

    The worst thing to happen to the Mac is Steve Jobs dying (okay, it’s also the worst thing to happen to Apple). He was the only one with enough clout and confidence to say “we aren’t shipping this until it’s fixed.”

    1. 18

      Unfortunately if you count unfinished things that they shipped on his watch, you find a different story: the cracking-case G4 cube, Mac OS X 10.0, the iWork rewrite that removed features from existing documents, Apple Maps, iAd (we’re not an advertising company), the iPhone 4, and MobileMe are the ones I can think of now.

      I’m not arguing that quality is better now (I think it isn’t), but I will argue that Steve Jobs is not the patron saint of problem-free technology products. Apple has, like all other technology companies, shipped things that they thought (or maybe hoped) were good enough, under all of their CEOs.

      1. 1

        Didn’t they charge for the updates to fix their broken software on top of it while Windows did them for free? I could be misremembering but I think Mac folks told me that.

        1. 4

          All I can recall is charging for a patch to enable 802.11n wireless (as opposed to draft) but the explanation was that sarbanes oxley prohibited delivering a “new” product because they already booked the revenue for it, but then the law was clarified and software updates are ok now.

      2. 2

        It’s not so much about Steve Jobs, but about people that were behind products and development process, which of course were brought and held together by Steve Jobs. I would say that departure of Bob Mansfield is one of the mayor impacts on Apple’s final products.

      1. 13

        but Electron is without question a scourge

        Well, how about a big F* you?

        Sorry for the swear words, but while I agree that in general Electron is not great, calling it a scourge is incredibly offensive towards those who chose to develop with Electron, and have good reasons for it. Sometimes writing native apps is cost-prohibitive, and you’re better off with an Electron app that looks a bit out of place, than have no app at all. It’s cool for you to be smug and elitist and complain about stuff not following the HIG on every single platform the app is developed for, but have you ever thought about the cost of doing so? Yeah, big companies may be able to shell out enough money and pay developers to create native apps and follow the platform’s HIG, but not everyone’s a big business. I dare say the vast majority of app developers aren’t. By hating on Electron and anyone who doesn’t polish their app perfectly, you’re alienating a whole lot of developers.

        Learn to see the other side of the coin already.

        (I ranted about this on my blog recently, also explaining why Electron was chosen over developing native apps.)

        1. 36

          complain about stuff not following the HIG on every single platform the app is developed for

          Do you know why human interface guidelines exist? They exist because humanity is imperfect and accessibility is really important.

          Electron apps are not accessible. They’re often completely opaque to a screen reader, they’re often completely opaque to assistive speech recognition software, they often don’t respond properly to keyboard navigation and if they do, they don’t behave as expected. They don’t often respond properly to text scaling, they don’t understand system-wide options like increased contrast or reduce motion.

          To whole classes of users, your Electron app is worthless and unusable. What are we supposed to do? Congratulate you on your accomplishment? You need to shrink your ego and take some time to understand real world users, rather than throwing words around like “smug” and “elitist”.

          Also your blog post doesn’t even mention the word “accessibility” once. How disappointing.

          By hating on Electron and anyone who doesn’t polish their app perfectly, you’re alienating a whole lot of developers.

          At the risk of sounding controversial, what does it matter if we alienate some developers? Developers should do better. They need to do better. I’m fine with alienating developers for good reasons.

          Electron is not the answer. It’s a shortcut at best and a bandaid at worst. This isn’t a secret, so there’s really no point in acting surprised that people don’t agree with your choices.

          1. 10

            I think that we who care about accessibility need to avoid taking a condemning, vitriolic tone, and meet developers where they are. That way, we’ll be more likely to get results, rather than just alienating a large and growing group of people. It’s true that Electron apps often have accessibility problems. But I believe we can improve that situation without calling for people to throw out Electron entirely. Frankly, we need access to these apps more than these developers need us. So we have to work with what we’ve got.

            No, I haven’t always lived up to this ideal when communicating with mainstream developers, and I’m sorry about that.

            1. 14

              I think that we who care about accessibility need to avoid taking a condemning, vitriolic tone, and meet developers where they are.

              The problem is that these developers don’t want to meet anywhere else - that’s how we arrived at Electron apps in the first place. It’s the easy way out.

              1. 4

                Most trends in IT are driven by herd mentality, familiarity, leveraging ecosystems, and marketing by companies. All of these seem to contribute to Electron use just like they contributed to Java and .NET getting big. They sucked, too, compared to some prior languages. So, it’s best to identify what they’re using within what ecosystems to find an alternative that’s better while still being familiar.

                Then, see how many move to it or don’t for whatever reasons. Iterate from there.

                1. 1

                  Developers don’t want to listen because by the time they start publishing something (based on Electron, for a number of reasons), what they meet with is pure, unconditional hate towards the technology (and not just the tech! towards developers using said tech, too!) that enabled them. It is not surprising they don’t want to listen to the haters anymore.

                  You’re alienating new developers with this kind of mentality too, who would be willing to listen to your concerns. You’re alienating them, because of the sins of their fathers, so to say. I’m not surprised noone cares about accessibility, to be honest. When we’re told the world would be better off without developers like us, we’re not going to be interested in working towards better accessibility.

              2. 5

                Do you know why human interface guidelines exist? They exist because humanity is imperfect and accessibility is really important.

                I’m aware, thank you. I’m very much aware that Electron is not… great, for many reasons. That’s still not a reason to unconditionally call it a scourge.

                To whole classes of users, your Electron app is worthless and unusable. What are we supposed to do? Congratulate you on your accomplishment? You need to shrink your ego and take some time to understand real world users, rather than throwing words around like “smug” and “elitist”.

                You, like the article author, ignore circumstances, and generalize. Yes, my electron app is going to be useless for anyone using a screen reader. It will be useless for a whole lot of people. However, it will exist, and hundreds of people will be able to use it. Without Electron, it wouldn’t exist. So ask yourself this, which is better: an application that is not usable by some people, but makes the life of the vast majority of its intended audience easier; or an application that does not exist?

                Here’s the situation: there’s a keyboard with open source firmware. Right now, to change the layout, you need to edit the firmware source, compile a new one, and upload it to your keyboard. While we tried to make the process easy, it’s… not very friendly, and never going to be. So I’m building an application that lets you do this from a GUI, with no need for a compiler or anything else but the app itself. I develop on Linux, because that’s what I have most experience with. Our customers are usually on Windows or Mac, though. With Electron, I was able to create a useful application, that helps users. Without it, if I had to go native, I wouldn’t even start, because I lack the time and resources to go that route. For people that can’t use the Electron app, there are other ways to tweak their keyboard. The protocol the GUI talks can be implemented by any other app too (I have an Emacs package that talks to it, too). So people who can’t use the Electron app, have other choices.

                So, thank you, I do understand real world users. That is why I chose Electron. Because I made my due diligence, and concluded that despite all its shortcomings, Electron is still my best bet. Stop smugly throwing around Electron hate when you haven’t considered the circumstances.

                At the risk of sounding controversial, what does it matter if we alienate some developers? Developers should do better. They need to do better. I’m fine with alienating developers for good reasons.

                Well, for one, a lot of our customers would be deeply disappointed if they weren’t able to use the GUI configurator I built on Electron. “Developers should do better”. Well, come here and do my job then. Get the same functionality into the hands of customers without using Electron. I’ll wait (they won’t).

                Electron is not the answer. It’s a shortcut at best and a bandaid at worst. This isn’t a secret, so there’s really no point in acting surprised that people don’t agree with your choices.

                I agree it is not the best, and I’m not surprised people disagree with my use of it. I can even respect that, and have no problems with it. What I have problems with, is people calling Electron a scourge, and asserting that native is always best, and that anyone who doesn’t follow the HIG of a given platform “should do better”. I have a problem with people ignoring any and all circumstances, the reason why Electron was chosen for a particular product, and unconditionally proclaiming that the developers “should do better”. I have a problem with people who assert that alienating developers because they don’t (or can’t) write apps that match their idealistic desires is acceptable.

                Before writing off something completely, consider the circumstances, the whys. You may be surprised. You see, life is full of compromises, and so is software development. Sometimes you have to sacrifice accessibility, or native feel, or what have you, in order to ship something to the majority of your customers. I’d love to be able to support everyone, and write lighter, better apps, but I do not have the resources. People calling the technology that enables what I do a scourge, hurts. People asserting that I should do better, hurts.

                Until people stop ignoring these, I will call them elitist and smug. Because they assume others that chose Electron have the privilege of being able to chose something else, the resources to “do better”. Most often, they do not.

                1. 1

                  Electron apps are not accessible. They’re often completely opaque to a screen reader, they’re often completely opaque to assistive speech recognition software, they often don’t respond properly to keyboard navigation and if they do, they don’t behave as expected.

                  I haven’t written an electron app, but I’ve done a fair share of web UI programming with accessibility in mind. You communicate with platform accessibility APIs through web APIs. It’s not technically complicated, but it does require some domain expertise.

                  Does it work the same way on electron?

                  1. 8

                    Electron embeds chromium, which doesn’t connect to the native a11y APIs (MS are working to fix this on windows).

                    As a result electron apps are as inaccessible as chrome (screenreader users tend to use IE, safari or firefox).

                    1. 2

                      Huh, this is a real surprise if true.. i tested our web UI with screen readers across macOS and windows in chrome, FF, and IE, and the only problems that occurred were due to bad markup or the occasional platform bug. Reaching the accessibility API was not a problem i ran into with chrome

                      1. 1

                        Chrome is definitely accessible to screen readers. I’ve spent more time that I’d like getting JAWS to read consistently across IE, FF and Chrome. From memory, Chrome was generally the most well behaved.

                  2. 7

                    When Apple was first developing the Mac, they did a lot of research into human/computer interaction and one of the results was to apply a consistent interface on the system as a whole. This lead to every app having the same menu structure (for the most part, the system menu (the Apple logo) was first, “File” next, then “Edit”) and under these standard menus, the actions were largly the same and in the same order. This would lower training costs and if a user found themselves in a new app, they could at least expect some consistency in actions.

                    I’ve been using Linux as a desktop since the mid-90s (and Unix in general since 1989) and to say there’s a lack of consistency in UI is an understatement. Some apps have a menu bar at the top of the window (Macs menu bars are always at the top of the screen per Fitt’s Law), some you have to hold Ctrl down and press the mouse button, some the right mouse button will cause a pop-up menu. I’ve been able to navigate these inconsistencies, but I’m still annoyed by them.

                    Further more, I’m used to the CLI, and yet even there, the general UI (the command set, the options to each command) still surprises me. I wrote about the consistency of GUIs and the inconsistencies I found on the Unix CLI over the years and while I still prefer the CLI over the GUI [1], I can see where the consistency of the Mac GUI makes for a much better experience for many.

                    As I’ve stated, I think it’s wonderful that PHP has enabled people to create the dynamic websites they envision, but I wouldn’t want to use the resulting code personally.

                    [1] One can program the CLI to do repetitive tasks much easier than one can do the same for any of today’s GUIs. There have been some attempts over the years to script the GUI (Rexx, AppleTalk) but it still takes more deliberate action than just writing a for loop at the command prompt for a one-off type of job.

                    1. 5

                      I think the case where it makes sense to go Electron is not the point of Gruber’s rant. The point was that many, many developers today are easier with writing Electron app and using it on all platforms instead of putting time and effort into polished Cocoa apps.

                      The core of this blog post is how Mac really was different in terms of UI/UX. During the time I started using Mac (10.5) it was really differentiating itself by having “different”, “better looking and feeling” apps. Electron definitely made Mac feel less unique. Critics were pointed towards macOS app developers. Don’t get so offended by simple blogpost. Your reasons are fine, but that simply isn’t the case most of the time. Most people decide to go with electron because of plethora of mediocre JS devs, that can chunk out a lot of code that does something, and then you get slow junk like UX. In minds of 2000s Apple fans that is a big no.

                      Have a nice day, and move on.

                      1. 7

                        I think the case where it makes sense to go Electron is not the point of Gruber’s rant.

                        Correct.

                        The point was that many, many developers today are easier with writing Electron app

                        Incorrect.

                        Please just read the article.

                        His point is what he says: it is bad news for the Mac platform that un-Mac-like apps far worse than those that were roundly rejected 15 years ago are now tolerated by today’s Mac users.

                        It happens to be the case that Electron is the technology of choice for multiple prominent sub-par apps; that’s a simple statement of fact. (It also isn’t purely coincidental, which is why I agree with his characterisation of Electron as a scourge. If someone like @algernon who builds apps for Electron is bent on interpreting those statements as a judgement of their own personal merit, well… be my guest?) But Electron is not singled out: Marzipan gets a mention in the same vein. On top of that, Gruber also points out the new Mac App Store app, which uses neither. The particular technologies or their individual merits are not his point.

                        His point is, again, that a Mac userbase which doesn’t care about consistency spells trouble for the Mac platform.

                        1. 2

                          Marzipan gets a mention in the same vein.

                          Electron is the only one that gets called a scourge, and is singled out in the very beginning. It’s even in the title. It’s even the first sentence, which then continues: “because the Mac is the platform that attracts people who care”

                          If that’s not an elitist smug, I haven’t seen any.

                          1. 6

                            Once upon a time, Mac users were a ridiculed minority. In those days, Microsoft-powered PCs were better in just about every way. They were much faster, they had a more technically advanced OS (even crappy Win95 was far ahead of MacOS Classic), they had more applications, they had boatloads of games… just about every reason to pick one computer over another pointed in the direction of a Microsoft PC. You had to be special kind of kook to want a Mac regardless. It was inferior to a PC in basically every dimension. The one reason to pick a Mac over the PC was the depth of consistency and care in the UI design of its software. Only users who cared about that enough to accept the mile-long list of tradeoffs went for the Mac.

                            1.  

                              Elitism is often a good thing. It’s how we get from the mundane to the truly excellent.

                          2. 3

                            The point was that many, many developers today are easier with writing Electron app and using it on all platforms instead of putting time and effort into polished Cocoa apps.

                            My beef is not with the author wishing for apps that would look more native - I share the same wish. My beef is with him calling Electron “without a question a scourge”. How about I said MacOS is without a question a scourge, for it jails you in its walled garden? You’d be rightly upset.

                            There’s a big difference between wishing apps would be more polished on a particular platform, and between calling a technology (and by extension, developers who chose to use it) a scourge. It reeks from privileged elitism, and failure to understand why people go with Electron.

                            Most people decide to go with electron because of plethora of mediocre JS devs, that can chunk out a lot of code that does something

                            No. Most people decide to go with Electron because it provides a much better cross-platform environment than anything else. Please don’t call a whole bunch of people “mediocre JS devs”, unless you have solid data to back that up. Just because it is JS and “web stuff” doesn’t mean the people who develop it are any less smarter than native app developers. Can we stop this “only mediocre people write JS/PHP/whatever” bullshit?

                            1. 13

                              There are more bad developers writing webshit because there are more devs writing webshit period.

                              Native apps tend to outperform Electron apps and use less memory, because to do the same things that don’t bring in a browser and language runtime.

                              Elitism is, in this case, warranted. The only really performant app (usually) in Electron I’ve seen is VSCode, because MS really does have sharp people working in a domain they’ve been leaders in for decades.

                              1. 7

                                There seems to be a shift towards less attention paid, and value given, to the experience of the user. This makes me very sad.

                                When people talk about why they use Electron, they always phrase it in terms of “developer productivity”, and that’s where I find the most elitist bullshit to be. Developers talk about using Electron so they didn’t have to learn a new platform, or so they only had to test it in one place, or it was faster. They talk about lower development costs (which they wildly overstate, in my experience).

                                But the questions I’d like use to start asking: what are the costs of the shit user experience? What are the costs of people having to learn new tools that don’t behave quite like the others? When we save money and time on development that money and time is saved once, but when we save time for our users, it’s saved repeatedly.

                                Maybe calling Electron shit is elitist bullshit. But I’ll take that over having contempt for one’s users.

                                1. 3

                                  Contempt is a strong word. Would all these people be users in the first place if the app doesn’t exist for their platform? Go ahead and write a native Cocoa app for OSX, but that sure feels like contempt for Windows or Linux users. “Buy a new machine to use my stuff” vs. “deal with menus in the wrong order”?

                                  1. 1

                                    I never said “buy a new machine to use my stuff.”

                                    From extensive experience: for most small applications, I can develop them natively on Mac, Windows, and Linux* faster than someone can develop the same thing with similar quality using a cross platform thing.

                                    (*) “native” on Linux is less of a sticky thing that on Mac and Windows.

                                    1. 2

                                      Here’s a challenge for you: https://github.com/keyboardio/chrysalis-bundle-keyboardio (demo here).

                                      Go do something like that natively for Mac and Windows. It’s a small app, some 3700 lines of JS code with comments. You do that, and I promise I’ll never write an Electron app ever again. You can make the world a better place!

                                      1. 1

                                        Thank you for your interest in my consulting services.

                                        1. 3

                                          Thought so.

                                          FWIW, the app, like many Electron apps, were originally built in my unpaid free time. Complain about Electron apps once you built the same stuff under the same conditions.

                              2. 9

                                How about I said MacOS is without a question a scourge, for it jails you in its walled garden? You’d be rightly upset.

                                I wouldn’t. I might point out that you absolutely can bypass their walled garden, on MacOS, but those objections for iOS are not only valid, but are honestly concerning.

                                Electron is a scourge. iOS is a scourge. Facebook is a scourge. The feature creep within the browser is absolutely a scourge. There are loads of scourges. This is not an exhaustive list. I pray daily for a solar flare which delivers enough of an EMP that it utterly destroys the entire technology landscape, and gives us an opportunity to rebuild it from the invention of fire onwards, because we’ve fucked up, and our technology is bad.

                                And I say this because I want technology to be better. The Web is an awfully complicated way to render a UI. Our systems are overly dependent on a few corporations who don’t have our best interests at heart. Our computers are slower to do less work than they did two decades ago. Pretty much the only way anybody makes money in tech anymore is by abusing their users (see: Google, Facebook, etc). Or their employees (see: Uber). Or both (see: Amazon).

                                1.  

                                  In the EMP scenario we’d be too busy trying to get essentials back up to care about doing it right

                                2. 7

                                  You’d be rightly upset.

                                  No, I wouldn’t be rightly upset. I am not the technologies I use, and neither is that true for you.

                                  Electron is the technology used in multiple highly prominent applications that are written with little or no regard to platform conventions. Their success is bad for the native platforms. Those are statements of fact. If you have good reasons to use Electron, then there is no need for you to relate those facts to yourself and take them as a statement of your merits as an individual.

                                  1. 7

                                    Agree. The notion that your identity is somehow linked with the tools you use is toxic. It is fine to like your tools, but once you get comfy with them you should be pushing beyond them to expand your taste.

                                    1. 5

                                      your identity is somehow linked with the tools you use

                                      I used QBasic, Visual Basic 6, and later FreeBASIC. If my tools define me, I feel like such a shallow person with no depth or skill. Such a sinking feeling. I think I’m going to re-install SPARK Ada and buy Matlab to feel like a mathematician. Yeah, that will be better… ;)

                              3. 4

                                Thanks for sharing the blog post.

                                I think your case is quite different from, say, Slack. I have worked on major cross-platform apps at a company, and it’s not a huge deal, when you have a few people working on it, whose collective knowledge covers those platforms. All apps used the same core libraries for the non-UI parts, and each app added native UI on top. A company with tens, or even hundreds of well-paid developers should be able to do that, if they care at all about accessibility, performance (which is a different kind of accessibility issue,) resource usage, and all those things.

                                1. 2

                                  It is still a big deal, even for a larger company, because there’s a huge difference between employing N developers to develop a single cross-platform application (with some of them specializing in one platform or the other), and between employing a set of developers to create native applications, and a set for the core libraries. There may be overlap between them, but chances are that someone who’s good at developing for Windows or OSX would not be happy with developing for Linux. So you end up employing more people, paying more, diverging UIs, for what? Paying customers will use the Electron app just as well, so what’s the point of going native and increasing costs?

                                  Yeah, they should be able to do that, yes, it would improve the user experience, yes, it would be better in almost every possible way. Yet, the benefits for the company are miniscule, most of the time. In the case of Slack, for example, or twitter, a uniform experience across devices is much more important than native feel. It’s easier to document, easier to troubleshoot, and easier for people who hop between devices: it’s the same everywhere. That’s quite a big benefit, but goes very much against making the apps feel native. And if you forego native feel, but still develop a native application that looks and behaves like on any other platform (good luck with that, by the way), then the benefits of native boil down to being less resource hungry. In the vast majority of cases, that is simply not worth the cost of the development and maintenance burden.

                                  In the age of mobile devices, I do not feel that apps looking “native” is any benefit at all, but that’s a different topic.

                                  1. 5

                                    I built them in the past myself. I’ve read write-ups about what it takes for others. If designing program right, most of the code is shared between the different platforms. The things that are different are mostly in the front-end that calls the common code. A lot of that can be automated to a degree, too, after design is laid out. For main three platforms, it basically took a max of three people two of whom only worked on UI stuff here and there mostly focused on shared code. That isn’t the minimum either: it can be lower if you have 1-2 developers that are experts in more than one platform. In mobile, many people probably know both iOS and Android.

                                    The cross-platform part will be a small part of the app’s overall cost in most cases. It will mostly be in design/UI, too. That’s worth investing in anyway, though. :)

                                    1. 5

                                      Our experience clearly differ then. I worked for companies that made native apps for the major platforms (mobile included), and each team was 10+ people at a minimum, with little code shared (the common code was behind an API, so there’s that, but the apps itself had virtually no code in common). Not to mention that the UIs differed a lot, because they were made to feel native. Different UIs, different designs, different bugs, different things to document and support. A whole lot of time was wasted on bridging the gaps.

                                      If they made the apps feel less native, and have a common look across platforms, then indeed, it could have been done with fewer people. You’d have to fight the native widgets then, though. Or use a cross-platform widget library. Or write your own. And the writer of the article would then complain loudly, and proclaim that multi-platform apps are the worst that could happen to the Mac (paraphrasing), because they don’t follow the HIG, and developers nowadays just don’t care.

                                      1. 3

                                        each team was 10+ people at a minimum, with little code shared (the common code was behind an API, so there’s that, but the apps itself had virtually no code in common).

                                        “If they made the apps feel less native, and have a common look across platforms, then indeed, it could have been done with fewer people. “

                                        I said native look on multiple platforms minimizing cost. You example sounds like something about the company rather than an inherent property of cross-platform. You usually need at least one person per platform, esp UI and style experts, but most of the code can be reused. The UI’s just call into it. They’ll have some of their own code, too, for functions specific to that platform. Mostly portable. Just sounds like the company didn’t want to do it that way, didn’t know how, or maybe couldn’t due to constraints from legacy decisions.

                                        1. 1

                                          My experience mirrors yours almost exactly.

                                  2. 3

                                    What about sciter? Companies doing stuff like anti-virus have been using it for a long time with way, way, less, resource use. It’s licensing scheme looks like something other vendors should copy. Here’s a comparison claiming a simple editor is 2MB in sciter vs 100+ in Electron just because it brings in less baggage.

                                    How many people using Electron could use the free, binary version of sciter? And how many companies using Electron could afford $310 per year? I mean, that’s within reach of startups and micro-businesses, yeah? I’m asking because you said it’s use Electron or not cross-platform at all cuz too costly/difficult. I’m making it easy by using a comparable offering rather than, say, Lazarus w/ Free Pascal or otherwise non-mainstream languages. :)

                                    Note: I also have a feeling lots of people just don’t know about this product, too.

                                    1. 4

                                      I actually evaluated sciter when I got frustrated with developing in JS, and wanted to go native. For my use, it wasn’t an option, because the app I write is free software, and therefore so much be its dependencies. For closed-source use, it’s probably fine. Though, you’d still have to write plenty of platform-specific code. AV companies already do that, but companies that start off with a web-based service, and develop an application later do not have that platform-specific code already built. What they have, is plenty of JavaScript and web stuff. Putting that into Electron is considerably easier, and you end up with very similar UX, with little effort, because you’re targeting a browser still.

                                      Oh, and:

                                      With Sciter, changing the front end of your application involves just altering the styles (CSS), and probably a couple of scripts that do animations.

                                      Yeaah… no. That’s not how changing the UX works. It’s a tad more involved than that. Not sure I’d be willing to trust my UI on an offering that basically tells me that changing between, say, Metro and Material UI is a matter of CSS and animations. (Hint: it’s much more involved than that.)

                                      Since we’ve already decided we’re not going to follow any platform HIGs (and thus, have the article author proclaim we’re a scurge), what’s the point of going native? Less resource use? Why is that worth it for the company? People use the app as it is, otherwise they wouldn’t be writing an app. Writing native, and making it look and behave the same has non-negligible cost, but little to no benefits. Faster and lighter is in many cases not a goal worth pursuing, because customers buy the thing anyway. (I’d love if that wouldn’t be the case, but in many cases, it is.)

                                      1. 1

                                        I appreciate the balanced review of sciter. That makes sense.

                                  1. 20

                                    My sense now is that Alan Kay’s insight, that we can use the lessons of biology (objects are like cells that pass messages to each other), was on target but it was just applied incompletely. To fully embrace his model you need asynchrony. You can get that by seeing the processes of Erlang as objects or by doing what we now call micro-services. That’s where OO ideas best apply. The insides can be functional.

                                    1. 17

                                      “If you want to deeply understand OOP, you need to spend significant time with SmallTalk” is something I’ve heard over and over throughout my career.

                                      1. 5

                                        It’s also a relatively simple language with educational variants like Squeak to help learners.

                                        1. 7

                                          I have literally taken to carrying around a Squeak environment on USB to show to people. even experienced engineers tend to get lost in it for a few hours and come out the other side looking at software in a different way, given a quick schpiel about message passing.

                                        2. 4

                                          If you don’t have any Smalltalk handy, Erlang will do in a pinch.

                                          1. 2

                                            And if you don’t have Erlang handy, you can try Amber in your browser!

                                          2. 1

                                            I went through the Amber intro that /u/apg shared. I’d love to dive deeper. If anyone has any resources for exploring SmallTalk/Squeak/Etc further, I’d love to see them. Especially resources that explore what sets the OO system apart.

                                            1. 2

                                              I’m told that this is “required” reading. It’s pretty short, and good.

                                          3. 16

                                            I even wrote a book on that statement. My impression is that “the insides can be functional” could even be “the insides should be functional”; many objects should end up converting incoming messages into outgoing messages. Very few objects need to be edge nodes that turn incoming messages into storage.

                                            But most OOP code that I’ve seen has been designed as procedural code where the modules are called “class”. Storage and behaviour are intertwingled, complexity is not reduced, and people say “don’t do OOP because it intertwingles behaviour and storage”. It doesn’t.

                                            1. 2

                                              This.

                                              Whether the implementation is “functional” or not, the internals of any opaque object boundary should at least be modellable as collection of [newState, worldActions] = f(old state, message) behaviours.

                                              We also need a unified and clearer method for namespacing and module separation, so that people aren’t forced to make classes (or closures-via-invocation) simply to split the universe into public and private realms.

                                              To say that the concept of objects should be abandoned simply because existing successful languages have forced users to mis-apply classes for namespacing is as silly as the idea that we should throw out lexical closures because people have been misusing them to implement objects (I’m looking at you, React team).

                                            2. 5

                                              If there’s one lesson I’ve learned from software verification, it’s that concurrency is bad and we should avoid it as much as possible.

                                              1. 8

                                                I’m not entirely sure this is correct. I’ve been using Haskell/Idris/Rust/TLA+ for a while now and I’m now of the opinion that concurrency is just being tackled at the wrong conceptual level. In that most OOP/imperative strategies mix state+action when they shouldn’t.

                                                Also can you qualify what you mean by concurrency? I’m not sure if you’re conflating concurrency with parallelism here.

                                                I’m using the definitions offered by Simon Marlow of Haskell fame, from Parallel and Concurrent Programming in Haskell:

                                                In many fields, the words parallel and concurrent are synonyms; not so in programming, where they are used to describe fundamentally different concepts.

                                                A parallel program is one that uses a multiplicity of computational hardware (e.g., several processor cores) to perform a computation more quickly. The aim is to arrive at the answer earlier, by delegating different parts of the computation to different processors that execute at the same time.

                                                By contrast, concurrency is a program-structuring technique in which there are multiple threads of control. Conceptually, the threads of control execute “at the same time”; that is, the user sees their effects interleaved. Whether they actually execute at the same time or not is an implementation detail; a concurrent program can execute on a single processor through interleaved execution or on multiple physical processors.

                                                While parallel programming is concerned only with efficiency, concurrent programming is concerned with structuring a program that needs to interact with multiple independent external agents (for example, the user, a database server, and some external clients). Concurrency allows such programs to be modular; the thread that interacts with the user is distinct from the thread that talks to the database. In the absence of concurrency, such programs have to be written with event loops and callbacks, which are typically more cumbersome and lack the modularity that threads offer.

                                                1. 5

                                                  Also can you qualify what you mean by concurrency?

                                                  Concurrency is the property that your system cannot be described by a single global clock, as there exist multiple independent agents such that the behavior the system depends on their order of execution. Concurrency is bad because it means you have multiple possible behaviors for any starting state, which complicates analysis.

                                                  Using haskell/rust/Eiffel here helps but doesn’t eliminate the core problem, as your system may be larger than an individual program.

                                                  1. 10

                                                    All programs run in systems bigger than the program

                                                    1. 1

                                                      But that’s not an issue if the interaction between the program and the system is effectively consecutive (not concurrent), I think is the point that was being made. A multi-threaded program, even if you can guarantee is free of data races etc, may still have multiple possible behaviors, with no guarantee that all are correct within the context of the system in which operates. Analysis is more complex because of the concurrency. A non-internally-concurrent program can on the other be tested against a certain input sequence and have a deterministic output, so that we can know it is always correct for that input sequence. Reducing the overall level of concurrency in the system eases analysis.

                                                      1. 2

                                                        You can, and probably should, think of OS scheduling decisions as a form of input. I agree that concurrency can make the state space larger, but I don’t believe it is correct to treat concurrency/parallelism as mysterious or qualitative.

                                                    2. 3

                                                      Using haskell/rust/Eiffel here helps but doesn’t eliminate the core problem, as your system may be larger than an individual program.

                                                      They help in reducing the scope into the i/o layer interacting with each other. I think an example would be helpful here as there isn’t anything to argue for your stated position so far.

                                                      But lets ignore language for the moment and give an example from my work. We have a network filesystem that has to behave generally like a POSIX filesystem across systems. This is all c and in kernel, so mutexes and semaphores are the overall abstractions in use for good or ill.

                                                      I’ve been using TLA+ both as a learning aide in validating my understanding of the existing code, and to try to find logic bugs in general for things like flock() needing to behave across systems.

                                                      Generally what I find is that these primitives are insufficient for handling the interactions in i/o across system boundaries. Aka lets take a call to flock() or even fsync(), you need to ensure all client systems behave in a certain way when one (or more) systems make a call. What I find is that the behavior as programmed works in general cases, but when you setup TLA+ to mimic the mutex/semaphores in use and their calling behavior, they are riddled with logic holes.

                                                      This is where I’m trying to argue that the abstraction layers in use are insufficient. If we were to presume we used rust in this case, primarily as its about the only one that could fit a kernel module use case, there are a number of in node concurrent races across kernel worker threads that can just “go away”. Thus freeing us to validate our internode concurrent behavior logic via TLA+ and then ensuring our written code conforms to that specification.

                                                      As such, I do not agree that concurrent programming should be avoided whenever possible. I only argue that OOP encourages by default bad practices that one would want to use when programming in a concurrent style (mixing state+code in an abstraction that is ill suited for it). It doesn’t mean OOP is inherently bad, just a poor fit for the domain.

                                                      1. 1

                                                        I feel that each public/private boundary should have its own singular clock, and use this to sequence interactions within its encapsulated parts, but there can never really be a single global clock to a useful system, and most of our problems come from taking the illusion of said clock further than we should have.

                                                    3. 4

                                                      I would go exactly tangential and say that the best software treats concurrency as the basis of all computation. in particular, agnostic concurrency. if objects are modeled to have the right scope of visibility and influence, they should be able to handle messages in a perfectly concurrent and idempotent manner, regardless of cardinality.

                                                      1. 2

                                                        Take Clojure for example, and I think concurrency is not that bad, and there is no reason to avoid it. Mutability and intertwining of abstractions is what leads to problematic situations. Functional programming solves that by its nature.

                                                        1. 4

                                                          Even if the program is immutable, you ultimately want the program to have some effect on the outside world, and functional programming doesn’t magically fix the race conditions there. Consider having a bunch of immutable, unentwined workers all making HTTP requests the same server. Even if there are no data races, you can still exceed the rate limit due to concurrency.

                                                    1. 9

                                                      Not a single mention of DTrace? Why? For me personally that would be the biggest selling point, yeah it comes even before ZFS for me. It totally changed the way how I perceived operating systems and monitoring.

                                                      1. 1

                                                        Looks amazing, I am giving it a shot in a VM.

                                                        1. 4

                                                          Lack of medium posts… It pops up from now and then, especially those with custom domains that are actually on Medium. Reddit is full of those, they are often on HN, here not so much. And I like it’s OpenBSD community based. I am not so much in OpenBSD as much as in FreeBSD and illumos, but I am glad it’s not Linux-centrict community, it feels it’s UNIX community instead which I appreciate a lot more.

                                                          1. 3
                                                            1. Getting Clojure by Russ Olsen
                                                            2. The Rust Programming Book by Steve Klabnik

                                                            (3.) Finished William Gibson’s Neuromancer few days ago.

                                                            1. 1

                                                              How are you finding Getting Clojure? I’m looking for a Clojure book that doesn’t start with “functional x imperative” and assumes I already know some stuff. Learning a new language is hard because there’s few books that meet you there, but I’ve found that to be even more so with Clojure.

                                                              1. 3

                                                                I have to say that this could be the best book I’ve read on Clojure (in aspects of learning it). It really has that Clojure vibe, concise, expressive, to the point! I really like it, because I often felt overwhelmed by possibilities of writing simple things. This book explained many aspects of Clojure and functional programming in Clojure (not in general, that’s important) very well, where I had that “ahaa!” moment. Plus it has examples from real world code (open source Clojure projects). If you ask me, go for it, you won’t regret it! This is the book to get to untangle your mind about clj.

                                                            1. 2

                                                              Interesting answers, but still no mentions of Clojure’s Spec. i really wonder why?

                                                              1. 2

                                                                Things OP has listed look reasonable and needed, in fact illumos needs the distribution that is described in here, but I don’t know how to achieve that. As @apg said this is just another fragmentation of already small and fragmented community.

                                                                SmartOS being the biggest fish in the tank, being backed and developed by Joyent is probably the best option, but it is not kind of general-purpose-developer Operating System. I have played with illumos, looked at it source code, and no doubt it is the best operating system I have seen (yes I am very young, millennial, and I don’t like linux), but as of now I see FreeBSD to be the best option.

                                                                I would really like small, efficient and nifty operating system, that goes somewhere in between FreeBSD and OpenBSD but in illumos land. :)

                                                                edit: typos

                                                                1. 2

                                                                  I would really like small, efficient and nifty operating system, that goes somewhere in between FreeBSD and OpenBSD but in illumos land. :)

                                                                  That’s kind of the goal. I personally lean toward FreeBSD on that spectrum, but one of the other Unleashed devs is a big fan of OpenBSD so he brings that point of view to the project.

                                                                1. 2

                                                                  I am in exact sam situation. Posting more when i come home from uni.

                                                                  1. -2

                                                                    I find this hilarious. As Steve Lord has mentioned, Gary Bernhardt was right!

                                                                    1. 5

                                                                      I do these things once a week at least… >_<

                                                                      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

                                                                        1. 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. 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.

                                                                                            1. 2

                                                                                              Almost every talk from Bryan Cantrill, Stuart Halloway and Gary Bernhardt.

                                                                                              1. 4

                                                                                                Cantrill recently posted a list of all his talks. Don’t know if you saw that post.

                                                                                                http://dtrace.org/blogs/bmc/2018/02/03/talks/

                                                                                                1. 2

                                                                                                  I did indeed, but thanks anyway! Only thing missing over there is BSDNow podcast appearances, which I think are pretty good, especially first one, “Ubuntu slaughters kittens”.

                                                                                              1. 4

                                                                                                I have no specific questions but I wanted to say how much I enjoyed the talk, and how much I look forward to the time when I can brew cask install xi and act as your alpha tester.

                                                                                                1. 2

                                                                                                  If you’re interested in playing around with Xi on a mac, you should check out xi-mac. It doesn’t have much complex tooling but it does use CoreText which is pretty interesting, and in general is a very smooth feeling editor (compared to say, Atom).

                                                                                                  1. 1

                                                                                                    Yeah, I looked at it! But I couldn’t build it, because I only have the commandline tools, and it requires full Xcode.

                                                                                                  2. 1

                                                                                                    Pretty much I am in the same boat as Peter, both for Xi and Alacritty! Since I am no Rust dev (yet ;)) I feel like it’s too early for me to use it, but I check both projects on Github once in a while.

                                                                                                  1. 2

                                                                                                    Nice. So it’s mostly for web developers or really as mentioned power users. A matter of time until we see “how do I quit nEXT” posts :) The navigation experience reminds me of Chrome’s Vimium ext. https://chrome.google.com/webstore/detail/vimium/dbepggeogbaibhgnhhndojpepiihcmeb?hl=en

                                                                                                    1. 2

                                                                                                      It has Emacs keybindings, so I think that wouldn’t be a problem. ;)

                                                                                                    1. 3

                                                                                                      This is a fair response. Thank you.

                                                                                                      1. 57

                                                                                                        Yeah, “moderating” with a don't make "hate posts" isn’t gonna cut it. There was glossed over reason for not liking electron followed by good discussion pointing to the actual reasons. This looked a lot more like a “frustrated and with good reason” post to me!

                                                                                                        If absolutely nothing else - there needs to be an explanation from @pushcx on what the specifics of hate are!

                                                                                                        I sincerely hope that this type of moderation doesn’t become the norm!

                                                                                                        1. 16

                                                                                                          It’s really boring whenever an app made with Electron comes up that someone has to bring up that they don’t like Electron. It adds nothing to the conversation. I hope this kind of moderation becomes the norm.

                                                                                                          1. 45

                                                                                                            And I personally find many discussions on this site boring, but I’d hope that my discussion preferences don’t get baked into moderation policy.

                                                                                                            We’ve already got downvotes.

                                                                                                            1. 10

                                                                                                              So… sarcastic remarks are now a no-no?

                                                                                                              I find Electron to be a little too much bloated for my taste. I would not recommend it as a go-to solution for desktop applications, since not everyone really needs bundled web browser and ffmpeg. That out of the way, feel free to talk about it’s advantages.

                                                                                                              Is this really better?

                                                                                                              1. 5

                                                                                                                I assume you mean moderating of the comment.. not the removal of the entire thread.. hopefully you mean that :P.

                                                                                                                1. 6

                                                                                                                  Exactly this! Much nicer way to resolve this situation was to say in comments like “Hey, we consider this type of comments harmful because of etc etc etc… but no, they had to remove it. And the comment was not as problematic as they present it here. I don’t want to leave this place after 3 years of reading other people’s (well moderated) opinions. I kinda felt this is going to happen after JCS announced that he’s stepping out.

                                                                                                                2. 0

                                                                                                                  Its really boring when a “lightweight” app comes up that has been written in Electron, when it is far from lightweight. It adds nothing to the site. I hope this kind of content doesn’t become the norm.

                                                                                                                3. 5

                                                                                                                  Given the effects of rants on conversation (especially rants many of us have read many times), it would be nice to enforce stricter requirements on the writer of the rants to offer “constructive feedback”.

                                                                                                                  “I’m really tired of having to install Electron’s 200 megs” yeah we all are… “would be nice to have some shared libs/for people to rely more on OS-specific containers” OK now we have something that adds to the conversation.

                                                                                                                  And if we’ve all had this conversation before…. well… we can just not make the post (This one might apply to my own post but I don’t read it that often).

                                                                                                                  EDIT: I don’t necessarily think this requires deletion in most cases. Downvotes should work so long as people aren’t rage-upvoting….

                                                                                                                1. 5

                                                                                                                  I don’t like the look of this. Okay, I get it, new management, different people -> different moderation! But I find this specific case to be more strict kind of moderation, and I think this already moderated community (by invites only access) doesn’t need that! Especially because the comment couldn’t be related to “hate post”. It was sarcastic yes, but in the end what OP said about electron was true, many people agreed and thus the upvotes.

                                                                                                                  I will start to feel much more claustrophobic here after this, and it’s a pita, since lobste.rs was my way to go to place to read people’s opinions and have a friendly constructive discussion. Now my opinion might not align with moderator’s and will be declared as “hate post”… bollocks.

                                                                                                                  1. 5

                                                                                                                    The post called itself a “hate post”, pushcx’s mod message was a snarky quote of that. Not the best choice of words, but moderators are humans too.