1. 3

    I’m a big fan of Pop!_OS, and set up recurring donations to the project a while ago. Their UI design chops are stellar, to the point that (IMO) the new Windows 11 UI actually looks and feels more like a Pop clone than anything else… Even window tiling made it over!

    1. 7

      This is an article I’m been trying to write for awhile and failing. The reason is, I can’t come up with the clear-cut “use x not y” scenario here. Monoliths are easier from an infrastructure perspective, but in my experience working on large monoliths at a certain scale becomes extremely difficult. You need a lot of practical experience with the monolith before you can start contributing meaningful improvements and overall feature velocity drops.

      I suspect that’s why microservices took off, in part due to CTOs losing interest in the amount of time it took to ship a new feature. Suddenly you could leave the cruft behind and embrace the specific language and framework best suited to the problem at hand, not “the tool you were forced to use because that’s how the monolith works”. However it does add a ton of operational cost in terms of management. Tracing, a nice to have in a monolith becomes a real requirement, because you need to see where the request is failing and why. Your metrics and logging platform becomes really a core production system, but at any time one of your services can crush it.

      I think if I were starting a company today I would likely start with a monolith, only because it would keep my application complexity down. Then as I grew I would break off services into microservices, but I don’t know if this is “best practice” or simply the pattern I’ve seen work ok.

      1. 10

        You need a lot of practical experience with the monolith before you can start contributing meaningful improvements and overall feature velocity drops.

        I keep seeing people make that argument, but I never really understand it. I can’t imagine what architectural benefit is gained by having the network boundary between the components of your system? How is an HTTP request better than a function call? In what world do you get better IDE, debugging etc. support for making an HTTP request compared to making a simple function call? How is it helpful that whenever you make an HTTP request instead of a function call there’s the possibility that that there might be network delays or version differences between the two components talking?

        And before anyone replies with “but with HTTP requests you get better logging, you have tracing frameworks etc. etc.”, what stops you from logging and tracing the same things through function calls? And before anyone replies with “but with microservices, the requests need to be self-contained, so they result in better decoupling”, what stops you from designing the internal structure of a monolith the same way? (I.e. passing around immutable data, instead of turning your codebase into OOP spaghetti?) I think microservices force teams to write more pure and functional code and that’s why people perceive architectural benefits in them, but the only thing stopping you from writing your entire application in a functional style is your habits IMO…

        So, I think microservices are only about performance and scaling (the performance kind, not the complexity kind).

        1. 7

          I keep seeing people make that argument, but I never really understand it. I can’t imagine what architectural benefit is gained by having the network boundary between the components of your system? How is an HTTP request better than a function call? In what world do you get better IDE, debugging etc. support for making an HTTP request compared to making a simple function call? How is it helpful that whenever you make an HTTP request instead of a function call there’s the possibility that that there might be network delays or version differences between the two components talking?

          You’re looking at microservices through the technical lens, and through that lens you are correct: they’ll almost always fail. But your analysis doesn’t consider people.

          In my experiences with large development teams, microservices shine when you need to scale people. When you have an application that becomes so large that the test suite is irreducibly slow, QA takes a week to complete regression, release engineering means coordinating hundreds of simultaneous changes in diverging areas of the system, that one developer can’t keep the features of the product in their brain at one time, and you’re still working on dozens & dozens of new features and the requests aren’t slowing down…

          @maduggan mentioned “feature velocity” – they’re spot on. When the 10+ year old monolith I am working on decomposing was a baby, you could launch new functionality in minutes to hours. Now, two weeks is the lower bound… and it’s not just a procedural lower bound anymore.

          Microservices let you get back to better velocity and better fault tolerance – if you build for it! – but you pay for it in exchange for more difficult debugging, slower performance, etc etc. IME, those are the worst tradeoffs to take when just starting a product, so always start with a monolith. Worry about the problems you’ll face when you’re a big success if/when you become that big success!

          1. 4

            In my experiences with large development teams, microservices shine when you need to scale people. When you have an application that becomes so large that the test suite is irreducibly slow, QA takes a week to complete regression, release engineering means coordinating hundreds of simultaneous changes in diverging areas of the system, that one developer can’t keep the features of the product in their brain at one time, and you’re still working on dozens & dozens of new features and the requests aren’t slowing down…

            Couldn’t all of these issues be solved more efficiently by splitting the monolith up into packages? (Ie instead of moving something to a separate service, distribute it as a package and consume it just like you would any other 3rd party software.)

            The only overhead I can think of is that you may need to host your own repo mirror (in the worst case). You may also need to handle sunsetting of older, incompatible package versions, but this release synchronization problem already exists in micro services, so it’s not really a strong argument against packaging.

            1. 4

              In some cases I’ve found that pattern to work really well. One of my current monsters is a Ruby application, and partitioning functionality into individually versioned Rubygems hosted in the same repo that holds our vendored dependencies have let introduce a hub & spoke model. You can isolate development in those gems, they can have their own test/deployment/release cadences, and the core application can pull them in as they are ready.

              But it’s not a silver bullet. As an example, we’ve had to introduce new software and infrastructure to change how our core search process works. We decided to cleave that as a microservice: the technology stack is necessarily different from the core application, and hanging it as a sidecar let us make use of an existing OLTP -> reporting stream. No new infrastructure to the core application, no changes to tap into the data, and a nicely defined failure domain we can take advantage of: the search microservice lives behind a circuit breaker and we always have the ability to fall back to the existing (horrifically slow and expensive) search.

              Another place where I’ve felt pain is with acquisitions. Your nice homogeneous company can become a sprawling polyglot with very different infrastructure and deployments. Exposing an API / RPC endpoint is often the least common denominator you have.

              1. 1

                We decided to cleave that as a microservice: the technology stack is necessarily different from the core application.

                I think this is a solid argument for extracting a service, at least under certain circumstances, but I wouldn’t call it a microservice architecture just because you support your monolith with a few tiny suppporting services with well defined purposes.

                BTW, having to use a different stack doesn’t always have to mean extracting a separate service. Whenever I need to cross the language/ecosystem barrier, I first evaluate whether FFI is an option, if not, then I consider writing that “service” as a one-shot CLI application and spawning it as a child process from my service every time I’d otherwise make a network request (making sure that the executable is reproducibly built and injected into your path is very easy with nix, for instance). I know these are painful options compared to just writing a new function or a new package, but I think they’re still less painful than writing a new service.

                Another place where I’ve felt pain is with acquisitions.

                Yeah, that does sound hairy…

              2. 4

                If we split a monolith into distinct packages and those packages can only interact with each other through strict interfaces, then I’d argue you’ve implemented micro-services that run inside of a single execution environment. The organisational benefits are the same in both models.

                1. 3

                  I strongly favor monoliths where possible, but this isn’t true. Teams releasing bugs in their packages can stall a release of the monolith if they cause a rollback. The packages approach definitely scales better than an entangled monolith if you’re doing it right, but at some level of scale those packages will need to be broken out into services with their own ops teams. As a hyperbolic example, suppose all of Google was a monolith—barring obvious technical limitations. It wouldn’t work.

                  In my eyes, the real problem is people dramatically underestimate the development scalability of a well designed monolith. Or have problems with a poorly designed monolith and jump to microservices right away rather than refactoring their code.

                  1. 1

                    I’m not sure I totally agree. If you: a) allow your software to be released continuously as opposed to large staged releases then an individual change is a small rollback, not an entire feature; or b) use feature flags to enable new features (and expose bugs) then a rollback of a release might be as simple as unflagging instead of doing a new deploy; or c) you release each package independently as opposed to all at once, then you can rollback a single package instead of the whole application (consider say hot reloading a single module with erlang/elixir)

                    That’s not to say you should do these things, but more calling out that proper scalable package based development is much more similar to microservices than we normally acknowledge and that it’s easy to conflate monorepo problems with monolith problems with deployment practice problems with release strategy problems and so on, but that they’re actually different problems and certain things aren’t necessarily incompatible?

                    1. 1

                      I think I was unclear. I meant they aren’t completely equivalent. Yes the benefits are similar, but at some level of scale you will need to split up into services. To express it mathematically: suppose each team causes a rollback every 1000 years, but you have infinity teams. Your monolith rollback rate is now 100%.

                      1. 2

                        But why does a package rollback have to mean a system rollback? Imagine you have organized your system into n packages, each of which (or their subsets) are somehow versioned independently. Then you have a topmost layer where you bind these together, specifying which versions come from where and builds the monolith. If one of the packages turn out to have a bug, you just revert that package by configuring the topmost layer to pull its previous version and rebuild -> deploy.

                        1. 1

                          That’s a rollback with more steps. You’re waiting on a full rebuild, and by reverting one package and not the others you’d be pushing an untested configuration into production. People roll back to the last known-good build for a reason, whack-a-mole in prod is not a fun game.

                          If you have perfectly clean interfaces exactly as a discrete service would have, it could work, but you’d still be waiting on a rebuild, instead of rolling back the 1-10% of canary instances immediately. And if you have enough packages getting individually rolled back you’d be constantly rebuilding and redeploying one binary to a huge fleet.

                          @rslabbert’s point about hot code reloading could solve these issues, but in practice few people use languages with that capability. The Erlang VM is enough of an “operating system” that you could argue code reloading modules isn’t that different than redeploying containers on k8s, and message passing isn’t that different than connecting services with RPCs. In other words, the hot code reloading solution also demonstrates the desirable properties of having discrete services.

                          1. 2

                            by reverting one package and not the others you’d be pushing an untested configuration into production … whack-a-mole in prod is not a fun game.

                            How is that different than rolling back one microservice and not the others?

                            I think the rest of your argument is primarily about performance and I readily admit that microservices will eventually win in any performance-related direction you pull the scale to infinity.

                            1. 1

                              Like I said, it’s the same if you assume that your packages are equally as isolated as the equivalent microservices. Except the ergonomics of releases and rollbacks become more complicated for ops teams. It’s not really about performance, it’s about the ability to respond to incidents quickly. There are myriads of performance issues—mostly related to locality—that I’ve chosen to ignore for this discussion. One of the biggest advantages of monoliths is operational simplicity, take that away and they’re a lot less compelling.

                              1. 2

                                I don’t think there are fundamental reasons why the ergonomics have to be worse. If you’re fine with having a network interface between the two sides of a function call, than that means you can introduce enough dynamic dispatch that at the layer where you aggregate your “micropackages”, the rebuild only involves rebuilding the packages you’re rolling back.

                                That said, I acknowledge the status quo when it comes to the availability of tools for the ops teams. Microservices are at one end of an architectural spectrum, and there’s a natural tendency for people to meet at the ends of spectrums and then the network effects kick in.

                            2. 1

                              untested configuration

                              Yeah, but that’s the point! :) Opting in to a service architecture necessarily means losing the concept of a single testable configuration, in this sense. This is a good thing! It acts as a forcing function toward improved observability and automation, which ultimately yield more robust and reliable systems than QA-style testing regimens.

                  2. 2

                    Packages are worse than monoliths and worse than services IME. Teams pin to package versions, requiring massive coordination when rolling out changes — and you don’t understand what client code calls you, and so understanding impact on perf, IO, etc is much harder. And if pinning is banned, rolling out changes is even harder: the engineer making the change has to understand every callsite from every team and is inevitably responsible for anything that goes wrong.

                    Services make understanding the full lifecycle of your code basically trivial: you know latency of your API endpoints, you know how much IO it’s doing, you know every bottleneck in your own code. Making a small improvement is easy, and easy to roll out. Not so with packages.

                    Services are one approach to scaling teams. Monoliths are another, although people vastly underestimate how hard they are to scale to large numbers of engineers. I worked at Airbnb, which went the service route, and FB, which went the monolith route: both worked, and IMO FB worked better — but FB invested far, far, far more resources into scaling the monolith, including staffing teams to create new programming languages (Hack), VMs (HHVM), and IDEs (Nuclide). Airbnb largely used off-the-shelf components. It’s def a tradeoff.

                    For small teams it’s no comparison though: monoliths are easy, services are a pain.

                    1. 1

                      Teams pin to package versions, requiring massive coordination when rolling out changes

                      True - I guess this is both a blessing and a curse since teams can keep on using older versions if they need to - the flip side is you also risk having an unknown amount of old versions floating around at any given time. I can definitely see scenarios where this could become a problem (ie you quickly need to address a CVE)

                      the engineer making the change has to understand every callsite from every team and is inevitably responsible for anything that goes wrong.

                      Don’t microservices also suffer from this problem? (Except now you don’t have the benefit of static analysis)

                      1. 1

                        Don’t microservices also suffer from this problem? (Except now you don’t have the benefit of static analysis)

                        Not really. With a service, your team knows roughly every codepath that might hit disk, open a DB connection (or attempt to reserve a thread in the DB connection threadpool), etc — because only your own team’s code can do that, since the machines are partitioned away from clients. Basic monitoring + a staged rollout is pretty safe, and if something goes wrong, the expertise for understanding how to fix it lies on your direct team. Every caller is logged via however you’re logging your API requests, so as long as those graphs look good, you’re good.

                        With a “modular monolith,” IME a lot more human complexity happens, because you’re more likely to need to work cross-team when you make changes: any client could be hitting disk, opening connections, etc, because your code for doing that is shipped directly to them. And working cross-team is slow.

                        1. 1

                          Sorry, maybe I was unclear - in a microservices setup you still have to be aware of all the calls made in to your system so as not to accidentally introduce breaking changes to the protocol.

                          If you ship your code as a library the other teams probably have a test suite and / or static analysis tools that exercises the integration between your code and theirs, which they can run as part of an upgrade.

                          With microservices this isn’t possible, so you usually have to resort to having a CI environment that’s a poor man’s version of the prod environment. In my experience the QoS of the CI environment is way worse than its prod equivalent, which usually causes slow and brittle tests.

                          Also, intentionally breaking changes to your microservice have to be carefully coordinated between all teams that use it, and is usually precluded by a period in which a backwards compatible version has to be maintained in parallel.

                          Contrast this to the library approach where teams can opt in to new versions on demand, so there’s no need for a “compatibility layer”. Of course this has problems as well (eg what if your team’s library uses log4j?) but I would say it’s a viable alternative to microservices if your primary concern is code splitting.

                          1. 2

                            If by “opt in to new versions on demand” you mean that teams can pin to old versions of your library… That’s true! But, it’s not the unpinned “modular monolith” others were describing. Pinning carries its own issues with it:

                            • Fixing important bugs? Time to patch the universe, because no one is on the latest version, and you’ll need to upgrade all of them. Or, you’ll need to update many old versions of your own code.
                            • Fixing non-critical, but noticeable bugs? Whatever support channel you have open with clients will get pinged forever about the bug in the old version.

                            Services have many technical downsides, but they’re nice at removing human communication bottlenecks. At a small company those don’t exist, at a big one they dominate almost all other work. There are other ways to skin the cat, but they usually require at least as much effort as services — I haven’t seen a perfect solution yet.

                      2. 1

                        That depends on how the packages are structured. I’ve done the modular monolith approach using a monorepo that did not use package versioning, and this structure works much better than a regular monolith.

                        The true purpose of decomposing into modules, IMO, is not versioning but isolation. You can ensure that there is no implicit coupling between modules by running the test suite without any undeclared dependencies. Shopify has taken this even further with their static analysis tooling.

                        1. 1

                          Shopify has taken this even further with their static analysis tooling.

                          The Shopify tooling was mostly a play to keep the engineers working on it from leaving AFAICT. The monolith there has been so stalled for years that teams actively build things as services that actually would have to do in to the monolith to work right, just to get anything done at all.

                          1. 1

                            source for this?

                            1. 1

                              My 5 years of employment at Shopify :)

                    2. 1

                      In our case, while we started out with a microservice for political reasons, it actually turned out to be the right call. We started out receiving requests to our service via SS7 (the telephony network), which required linking to a commercial SS7 network stack that only has support for specific versions of Solaris. Over time, it became a requirement to support SIP (over the Internet). Since we started with a microservice (an SS7 interface and the business logic), it was easy to add the SIP interface without having to support two separate versions of the code had it been a monolith.

                      Velocity is not a concern here, since our customers are the Oligarchic Cell Phone Companies (it took us five years to get them to add some additional information in the requests they send us). Performance is a concern, since our requests are in real time (they’re part of the call flow on the telephone network).

                    3. 2

                      I keep seeing people make that argument, but I never really understand it. I can’t imagine what architectural benefit is gained by having the network boundary between the components of your system? How is an HTTP request better than a function call? In what world do you get better IDE, debugging etc. support for making an HTTP request compared to making a simple function call? How is it helpful that whenever you make an HTTP request instead of a function call there’s the possibility that that there might be network delays or version differences between the two components talking?

                      The main benefit of a service-oriented architecture (or microservices, I guess, but that’s a semantic distinction I’m not really interested in exploring right now) is that services can be deployed and updated independently of one another. Folks who make this choice are often choosing to trade social coordination problems for distributed systems problems, and a certain point, it’s the right call. People who chose this architecture often don’t make raw HTTP calls to other services—the service contract is defined through things like gRPC, Thrift, or Smithy, which allows for the automatic generation of client/server stubs. I’ve found it to be a very pleasant development experience.

                      The other benefit of a service-oriented architecture is the blast radius reduction of an outage, but that’s a bit more rare.

                      1. 1

                        … services can be deployed and updated independently of one another. Folks who make this choice are often choosing to trade social coordination problems for distributed systems problems …

                        In {my-language-of-choice}, I use a lot of packages written by people that I have never met and never talk to. They don’t ask me when they want to release new versions of their packages. Though I guess there’s an important point to make here that not many languages support having multiple versions of the same package in the same process, so if different teams want to depend on different versions of the same package, that forces them to separate processes. Depending on the technology choices, that could indeed inevitably shatter the monolith, but a shattered monolith still doesn’t have to mean “every team develops a microservice”. In my experience, people reach out to creating new services too fast, while they could just as well be maintaining a package that a few “macroservices” could pull in and update at their leisure.

                      2. 2

                        Operationally we have a lot of tools that let us look at HTTP requests, and run things on different machines.

                        You have a web app that has a 3D rendering feature. Having two processes instead of function calls lets you properly provision resources instead of doing “our web app requires GPUs because 1% of requests spin up blender”

                        Similarly while you can have instrumentation for function calls, having stuff broken up at the process level means your operations teams will have more visibility into what’s going on. By making that layer exist they could independently do things like move processes to different machines or add debugging only to certain parts.

                        It seems like it’s futzing around but if you are bought into kubernetes and the like this stuff isn’t actually as hard (security is tricky tho)

                        1. 1

                          Operationally we have a lot of tools that let us look at HTTP requests

                          How are they better than wrapping your function with a decorator (or whatever your language supports) that logs the arguments and the stack trace at that point along with the time it took to execute etc.?

                          You have a web app that has a 3D rendering feature.

                          That’s certainly a use case that justifies spinning up a new service! But I find it unlikely that those people that boast having 2500 distinct microservices in production actually have 2500 genuinely unique hardware requirements, like I can only simulate this flux capacitor on that quantum FPGA we’ve bought for $100M. If you have a few services lying around supporting narrowly defined needs of a central monolith, I wouldn’t call that a microservice architecture.

                          having stuff broken up at the process level means your operations teams will have more visibility into what’s going on… move processes to different machines or add debugging only to certain parts.

                          This is a little fuzzy, because: a) It assumes that your operations teams can understand the workings of a web of microservices, but they can’t understand the web of function calls in your monolith, or how a bunch of packages work together. Imagine if you composed your application out of “micropackages” to make an analogy, along with a topmost layer that pulls together those micropackages, what stops your operations teams (capable of understanding the microservice mesh) from isolating, modifying and deploying your micropackages? b) I can’t tell how much of the benefit is actually performance-related (like “it seems like this functionality is consuming more CPU than is available to the rest of the application”), in which case, it goes back to my original argument that microservices are about performance.

                        2. 1

                          For one, you can mock HTTP “calls” in basically any language. The difficulty (or even, possiblility) of mocking functions in other languages varies greatly.

                          1. 1

                            How is it possible that you can turn a piece of functionality into an HTTP endpoint, register it somewhere so that its consumers can find it, and have that registration point be flexible that you can redirect the consumer or the producer to a mock version of the other side, but you can’t do the same without leaving your process? In the worst case (not a real suggestion, but a lower bound) why can’t you just register your function to a global “myServices” dictionary that is a key-value store that binds names to functions (classes, objects, function pointers, etc. etc.), then whenever you want to call it, just grab your function from the dictionary and call it. I know this is less practical than just importing a module and calling its functions, but certainly not more so than turning the whole thing into an HTTP workflow.

                            1. 2

                              Everything you’re asking about in this thread is entirely possible. Here is an example of an architecture that can be deployed as independent services or as a single monolith. Same code, different wire-ups.

                              The reasons to prefer multiple services are almost all organizational rather than technical; service-oriented architectures are almost always technically worse than alternatives. But most organizations of nontrivial size are not constrained by technical bottlenecks, they’re constrained by logistical ones.

                        3. 3

                          at a certain scale becomes extremely difficult.

                          Yes, but most places aren’t at a certain scale.

                          1. 2

                            Then as I grew I would break off services into microservices…

                            Agreed. I’d add that splitting off services that are non-essential is a good way to start. That way you can figure out how you want to “do” microservices (and your team can get up to speed) without being overly concerned about downtime. You also get the resiliency benefits since the microservice can, in fact, go down without taking the entire app with it. My personal view is that a core monolith (macroservice?) that contains everything that is absolutely essential to the product with a bunch of non-essential microservices supporting it is often the sweet spot.

                            1. 1

                              Microservices as a tool for scaling organizations. When done well, the contract between services is clearer — it’s just the surface-level API + SLAs. Whereas multi-team monoliths need a TPM to coordinate work.

                              On a purely technical level, microservices are worse than monoliths in almost every way. But they’re incredible for scaling out organizations.

                            1. 6

                              I’m on a Linux system at the moment, so I can’t speak to “feel”. But in terms of “look” it doesn’t look any more native than electron does to me, just from these particular screenshots. I might even say it looks less “native” than wxWidgets, to me.

                              Is the flutter runtime stuff a lot lighter than electron? Or is dart at least nicer to use than javascript, typescript or c++? I feel like I’m missing some piece of why this is an improvement that might make me say “a ha!” if I looked from the right angle.

                              1. 5

                                Flutter is extremely lightweight compared to Electron, and Dart is much nicer than vanilla JS. But the best part about it is not dealing with the DOM, which is absolutely terrible for UI development.

                                1. 3

                                  They look pretty native to me? What looks non-native? It’s certainly more native-looking than most Electron apps I’ve seen… Those tend to take the web approach of inventing their own standards for buttons/modals/etc rather than respecting the platform’s. (Not that that’s always bad! But it usually feels non-native.)

                                  My relatively meager Dart experience is that it’s nicer to use than C++ and JS, but less nice than TypeScript. YMMV depending on your preferences.

                                  1. 4

                                    The source list on the Mac version really stands out like a sore thumb to me. I’d have been almost certain it was electron had I seen the shot out of context.

                                    Getting the native utility dialogs (file chooser, color picker, etc.) is probably worth it alone if Flutter does that, to be fair, if the cross platform build story is good and Dart is nice to use.

                                1. 2

                                  I’m a pretty big fan of the Razer Basilisk Ultimate. It’s wireless — either using Bluetooth or the provided USB dongle that uses a lower-latency custom protocol (and the dongle stores itself inside the mouse for travel!) — but crucially, the mouse comes with a charging dock. When I’m done using it for the day, I put the mouse on the dock, so I never have to worry about it dying at inconvenient times. The dock also can have the dongle plugged into it neatly, so you only need one USB port: the single cable from the port to the dock:

                                  • powers the dock
                                  • connects the wireless dongle
                                  • and charges the mouse when you dock it.

                                  The mouse also works in wired mode, unlike Apple’s wireless mice — and it uses the same USB cable as the dock, so in a pinch, you can simply unplug the cable from the dock, plug it into the mouse directly, and use it as a regular wired mouse.

                                  It has fancy lighting and programmable buttons, etc, but I don’t really care about that — I just think they’ve basically entirely solved wireless mouse UX. When I last looked it seemed like no one else offered similar setups, although Logitech had something close if you were willing to use a special wireless charging mousepad they make (I preferred not to, for vain aesthetic reasons).

                                  1. 4

                                    The most successful pattern I’ve seen for this kind of thing is a local copy of the traffic routing data, that is periodically refreshed from a central store. When the central store goes down you best guess based on the stale local data, and when the central store is up you get slightly better traffic management.

                                    1. 13

                                      I need to learn to read the actual article before freaking out over the title.

                                      EDIT: @hwayne would recommend editing the title slightly to prevent misunderstandings, as apparently I’m not the only one. Maybe something like “Design with Judaism in mind”.

                                      1. 13

                                        EDIT: @hwayne would recommend editing the title slightly to prevent misunderstandings, as apparently I’m not the only one. Maybe something like “Design with Judaism in mind”.

                                        I think it’s a great title exactly because of this. Far too many people comment without actually reading the damn article. I’ve been (re)watching Babylon 5 and I’m reminded by this scene. “I always leave a little room for someone to disappoint me”.

                                        1. 12

                                          Obvious trolling is obvious, and frankly a pleasant surprise in the current climate. I appreciate it. Not jewish myself, but Grandma’s name was Solomon and I’ve got some uncles who look like cartoon propaganda art.

                                          1. 5

                                            I think that’s a better title. “Jewmain” is a novel coinage, and while it’s easy enough to figure out that this article is about Jews, it took me a second reading to realize the pun on “domain-driven”, which is a bit of a stretch.

                                            1. 2

                                              Yes I was confused at first sight as well, but reading the article brought up some points I didn’t know about, like with the oven or how in Israel, Passover is 7 days as opposed to 8. I guess it’s a good thought exercise in how you add logic to your programming to support cases like these.

                                              1. 5

                                                The oven isn’t the only appliance with Sabbath mode. I believe there are also elevators that stop at every floor so you don’t have to operate the elevator.

                                                1. 1

                                                  There’s a Sabbath elevator at Johns Hopkins. I would expect them in any major US city with a large Jewish population.

                                                  1. 1

                                                    I’ve only ever seen them at Johns Hopkins hospital and in New York City personally. I’m sure there are more of them, but I’ve never seen one in Chicago, for instance. Nor in Atlanta. Nor in DC, Nor in Miami. Nor in Los Angeles. Nor in San Francisco. Nor in Boston. Nor in Minneapolis. Those are just the specific major US where I’ve spent more than a few weeks without observing one. What other locations do you see them in?

                                                    Also, is there any reason (other than familiarity) that you confined your expectation to US cities? I’ve never seen one in Paris or London, for instance, but I’d have had no specific reason to expect (or not expect) to.

                                                    1. 7

                                                      The number of Jews living in the US is vastly higher than abroad, by orders of magnitude. Accommodations I’m used to here are literally unheard of in Europe, even in the big cities. I’d guess that where @carlmjohnson was coming from.

                                                      Edit: and it hits me that things like the French concept of laïcité actively work to discourage accommodations.

                                                      1. 6

                                                        To buttress this point with some data, over half of all living Jews today live in America. Another 30% live in Israel. The next highest country by population, France, accounts for a mere 3% of the world’s Jewish population — where they make up 0.7% of the country’s population; less than half of their prevalence in America, which is 1.5%, and so not explainable simply by virtue of France being a smaller country than America.

                                                        And it’s even more concentrated than that data might appear to show: 1.5 million of America’s 7.6 million Jews live in the NYC metro area, which is greater than the Jewish population of Chicago, Philadelphia, San Francisco, and D.C. combined. To put that in perspective, over 10% of all Jews alive today live specifically in the NYC metro area — and even in NYC they are nonetheless a small minority of city residents. There just aren’t that many Jews living in the world. Most places have almost none.

                                                        And not to put too fine a point on it, but that isn’t by accident. Europe, including France when it was under German occupation, genocided nearly all of its Jews: successfully murdering two out of every three European Jews, and most of the one-third remaining survivors fled to America, where they arrived at Ellis Island in the NYC area. The Middle East and North Africa unsuccessfully tried to do the same, albeit in a less organized fashion: those native Middle Eastern and North African Jews were largely saved by fleeing to Israel, where they make up 61% of the Israeli Jewish population, contrary to many Americans’ assumptions that Israeli Jews are mainly white descendants of Europeans.

                                                        1. 1

                                                          In my experience, synagogues in Europe always have guys with machine guns standing around out front. It is very different than the US.

                                                          I wouldn’t say though that the US as a whole has very high numbers of Jewish people. NYC specifically and then a few other Northeast cities do. Baltimore, for instance, has a large number of Orthodox Jews who caught measles pre-pandemic. I’m not as familiar with the rest of the country but I think there are a couple of enclaves in various cities throughout the midwest and whatnot.

                                                          An interesting comparison is the number of Native Americans, which IIRC is approximately same at a national level (around 1% of US population), but the distribution is completely different, so there are very few Native Americans in NYC, Baltimore, etc. and a lot in the West, Southwest, etc.

                                                        2. 1

                                                          Oh, there’s at least one in LA (Cedars-Sinai). Placards on the door too.

                                                          1. 1

                                                            Plenty of them in Toronto hospitals.

                                                            1. 2

                                                              It makes perfect sense that they’d be more common at hospitals. I was scratching my head at how I’d not noticed them most places, even ones I’d visited quite a lot. Especially since it’s the kind of thing I find interesting and would take notice of.

                                                              I (thankfully!) rarely visit the hospital.

                                                              1. 2

                                                                You’ll only find Shabbat elevators in places Jews would conceivably be on Shabbat. So, no office buildings or the like; just apartments and doctors’ offices. (And a few other things I’m glossing for expediency.)

                                                                You’d also have to know to look for them. In one of my NYC apartments, a freight elevator was a Shabbos elevator, but, since tenants wouldn’t normally be using the freight elevator, most didn’t know about it.

                                                                1. 1

                                                                  Both my daughters were born at Mount Sinai, which, I guess it shouldn’t be remarkable lol

                                                          2. 1

                                                            Don’t forget the Sabbath light switch!

                                                        3. 2

                                                          I’m curious, what was your initial response?

                                                          1. 12

                                                            Mine was “Oh fsck me, how did antisemitism make it this high on Lobste.rs!”

                                                            1. 1

                                                              That was also my instant reaction, which lasted until I noticed the author’s name in the URL.

                                                        1. 26

                                                          Let’s look at an example: I make software for hair salons. Our main product is based on Electron and runs in many hair salons in The Netherlands. Over 95% of our users have PC’s that run Windows. So, we have a choice: Use Electron to support both macOS and Windows. Or don’t support macOS at all.

                                                          […]

                                                          I’ve never gotten the feedback during the last ten years: “It’s a nice app, but it would be better if it were a native app”. Not once. Users only care that it works, not how it works.

                                                          Sounds like you’re looking for the wrong feedback. If your clientele isn’t technical, they don’t know there’s a difference between electron and native apps. Even if they can tell there’s a difference, they don’t know how to express it. Maybe they would be happier with a native app. Maybe they’d be happier if the app was more responsive, and the app would be more responsive if it used less memory. You can’t take what the customer says as gospel, because they don’t know how to communicate at your level.

                                                          1. 11

                                                            Right, the salon doesn’t care about the stack, but they do care about its effects; if it’s slow, they’ll feel it (even if it’s not enough to make it worth communicating). If it doesn’t take the same shortcuts as the other apps, they’ll complain, etc.

                                                            1. 6

                                                              Honestly a salon app can probably be done entirely with a local web app and a shortcut on the desktop which opens the default browser to the salon app location. I’ve seen lots of apps for kiosks and such distributed this way. Usually written in Java but not always. When I’ve done non-profit work in the past, it’s what I’ve done.

                                                              1. 3

                                                                Why is this better than an Electron app? It’s using potentially more RAM — a full browser and a JVM, rather than just a stripped-down browser — with a more confusing UI (why is there an address bar?). It’s just as “slow” and most likely actually slower, since every interaction needs the entire UI and any data updates serialized to and from strings and sent over a local socket, rather than happening entirely in-process with shared memory. Electron for consumer apps has some known downsides (e.g. RAM, since most users will be running a browser in addition to the app at most times), but for point-of-sale or registration management apps, it’s not like someone’s trying to browse Reddit and stream Netflix on the same machine at the same time. A local webserver with a desktop shortcut to open a browser seems… significantly worse than a single Electron app.

                                                                1. 3

                                                                  It’s using potentially more RAM

                                                                  This is a kiosk app. There’s nothing running on this box other than the operating system and the application. I struggle to think of a box made in the last 10 years that couldn’t run a single browser tab and a JVM to run a CRUD web app. Some of these boxes are even airgapped. Why prematurely optimize?

                                                                  with a more confusing UI (why is there an address bar?)

                                                                  Kiosk mode apps usually hide the address bar. Okay that’s not exactly what I said when I said “shortcut on the desktop which opens the default browser to the salon app location” but please use good faith and permit me to say I am capable of hiding the address bar.

                                                                  since every interaction needs the entire UI and any data updates serialized to and from strings and sent over a local socket

                                                                  And a multiprocessing environment is running background processes and handling devices that I couldn’t care less about in a kiosk environment. Why even go with an Electron or native app here if you could grab a microcontroller and a VGA display and implement the entire thing from scratch in C or Forth or something? The answer is, it’s easy and quick for me to write, it’s easy and quick to deploy, it’s easy for the non-profit to find other people who can work on the app, and it’s cheap for the non-profit to hire somebody to fix the app if they need to. A non-profit isn’t looking for the leanest/meanest application, they just need to have something to quickly run (e.g. fast development) and make a difference to their organization, be easy/cheap to maintain, and easy/cheap to fix. That’s the whole calculus here. I presume @Sophistifunk’s work on airline kiosks probably had very similar requirements.

                                                                  1. 6

                                                                    Right, but in a thread dumping on Electron for this exact use case — a salon kiosk app is exactly the app the blog post author was talking about — I’m confused why Electron is viewed as bad but a locally-running JVM webserver + custom webview for a browser is viewed as good.

                                                                    I agree wholeheartedly that nobody should care about less-than-gigabyte RAM overhead for a kiosk app: nothing else is running on the machine, so it doesn’t matter. And I agree that “it works” and “it has the features I need” and are the most important parts. Just… Why the Electron hate? It has generally similar upsides in terms of easy to maintain + easy to hire for + easy cross platform support, and the downsides are as meaningless as you mention for the local webserver+browser version. It’s also probably easier for the average team to deploy: you don’t need a custom webview, you don’t need multiple build targets, you need to support one fewer language’s tooling, it’s easier to manage since there aren’t hidden-to-the-end-user processes running separately from the application and binding ports, that can crash or hang or get into buggy states that simply closing the app window won’t fix… I’m not saying “don’t do a local webserver + browser/custom webview” — if your company has mostly JVM people already, then it could make sense — I’m just confused why people would think Electron is inferior or poorly suited for kiosk apps by comparison.

                                                                    Edit: maybe I misunderstood, and you agree with the blog post author that Electron is fine for this use case?

                                                                    1. 1

                                                                      quick to write and deploy is definitely not my experience with webapps! i have found that desktop apps have a far simpler architecture, in general.

                                                                    2. 3

                                                                      It’s not better in those metrics you point out. It is that exact mindset that led to electron success and before that, it’s existence.

                                                                      It is a possibility. A web developer can develop a desktop app. They could already before electron as pointed out by GP. Electron just streamlined that way of working. It works, that is enough for many people, but not always. I think the position on the article is silly because it essentially justify everything by “it works”. I’m pretty sure the author doesn’t have that mindset when he buys a car, a computer or a pair of jeans. It is not so difficult to grasp that people want quality products that work well.

                                                                      Two aspects that don’t usually get discussed: 1.UI libraries are usually horrible to work with, poorly documented and the communities are generally full of entitled people that are not too interested in sharing their knowledge. The same doesn’t apply to web technologies, which have been more open and welcoming from day one. 2. People used to value a UI that had the same style as the rest of their os chrome, nowdays they value individually designed aestetics. Pretty much the opposite. Webtech, being a document formatting solution, excels here.

                                                                      Chromium apps dont get enough love, and I think half of the people would use them instead of electron. Slack is one such case.n I cannot understand how people reason about having a desktop app that is literally just showing webpage you can open.

                                                                      1. 1

                                                                        I think the position on the article is silly because it essentially justify everything by “it works”. I’m pretty sure the author doesn’t have that mindset when he buys a car, a computer or a pair of jeans. It is not so difficult to grasp that people want quality products that work well.

                                                                        That is what most people want out of a car, a computer, or a pair of jeans. Almost everyone in my life that drives has opted for a simple Japanese car with high reliability, often slightly used, not because they love their CVT engines (lol) or they find the styling of the Corolla to be beautiful, but because it gets them from point A to point B with minimal fuss and breaks down seldom. In another life I used to do cabinetry. The number of people willing to pay for solid woodwork when they can get a rickety Ikea table is vanishingly few. I, and most other folks with an eye for woodwork, would love to sit on a Morton Chair but most people have never heard of it nor even care about it. They want a chair that’s decently aesthetic that’s comfortable enough. That’s all. This doesn’t excuse slow apps or apps that are unresponsive, but as TFA says, that’s a matter of how you write an app, not an indictment of Electron itself. A slow app is slow and disrespecting of its users regardless of the technology it uses underneath. Much like people wouldn’t sit in a chair that wobbles excessively.

                                                                        It’s not better in those metrics you point out. It is that exact mindset that led to electron success and before that, it’s existence.

                                                                        At one end of a spectrum is a bespoke solution from a bespoke FPGA and a bespoke display. On the other is some plug-and-play Electron monstrosity. Given the requirements you have at hand which point along this spectrum would you pick and why?

                                                                        1. 3

                                                                          From an engineering perspective, the Corolla is the native app in the analogy. Compared to european and american cars, it has less superfluous resources thrown at it. Less unecessairy features, no luxury factor, better fuel economy, great durability. etc. In essence is makes better usage of resources.

                                                                          But I agree with you that from the user perspective, things might be switched around. The fact is that making an electron app is cheaper because there is a much larger pool of [cheap] developers availlable. At that point, even if the user would prefer a native app, the electron app is good enough, or to be fair, often does exactly what the user wants. Resource usage being unimportant in many cases.

                                                                          At one end of a spectrum is a bespoke solution from a bespoke FPGA and a bespoke display. On the other is some plug-and-play Electron monstrosity. Given the requirements you have at hand which point along this spectrum would you pick and why?

                                                                          95-99% of the time an electron app. The 1-5% being left for more critical missions. Or for cases where resources are limited or scarce for whatever reason.

                                                                    3. 1

                                                                      Yes, many years ago now I was behind the curtain at “airline you’ve heard of” and all their airport kiosks were a Java web app with a web front-end.

                                                                      1. 3

                                                                        Surprised it wasn’t a 3270/5250 application.

                                                                        1. 1

                                                                          These were public-facing touch screens.

                                                                          1. 1

                                                                            United States based carrier? With a popular bag check system that exhibits many 9s of user facing uptime?

                                                                    4. 1

                                                                      You assume working feedback chains between users and owners, and then developers.

                                                                      Most of the time you need to be a coworker to know what people hate.

                                                                    5. 6

                                                                      Also: these are computers that do one thing and one thing only. In a more typical desktop example you will have several apps open, including perhaps multiple Electron apps, and I bet the general expectation is also a bit higher than a point of sale system.

                                                                      Anecdotally, I’ve certainly noticed quite a few Electron apps have issues in terms of performance and UX, which I usually noticed before I knew it was Electron. This is a biased sample of course since I never noticed apps using Electron when it worked well, but all of this seems a bit too hand-wavy to me.

                                                                      1. 5

                                                                        There are plenty of apps that are fine delivered via Electron. In every case other than VSCode (which is basically a miracle), they’re things that should just be web-apps in the first place.

                                                                        1. 1

                                                                          Maybe they’d be happier if the app was more responsive, and the app would be more responsive if it used less memory.

                                                                          Though this raises the question, what if the author of the app used Electron and they made sure to optimize it to make it as responsive as possible? VSCode is an example but VSCode actually does a lot. A salon app, like the author of this site is talking about, is probably a lot easier to optimize than something like VSCode.

                                                                          (FWIW I’m not saying the author did or did not make their app responsive/low-latency. I’m just raising the point that there’s a middle ground that can be acceptable.)

                                                                          1. 4

                                                                            VSCode often gets touted as an example, but also realize that there is a huge team at a well funded company that makes this app, and clearly put a lot of work into it! I’d say VSCode is more an exception than anything, and an example of how much work it takes to make an Electron app that performs reasonably.
                                                                            Slack is a counter example of a large team at a well funded company that ships a poorly performing electron app.

                                                                            1. 4

                                                                              If you want an example of a poorly-performing Electron app from the same company that made VSCode, let me point you at MS Teams.

                                                                              1. 1

                                                                                I think there’s a lot more variables here than team size and funding and as such using these as predictive features is misguided. Just like trying to use those two features to determine the success of any software project.

                                                                                1. 2

                                                                                  Nah, not sure how you got that take.

                                                                                  I’m more saying that even with lots of advantages, Electron apps still end up like crap most of the time. VSCode should be considered an anomaly, or at best an example of what is possible by as an unlikely/amazing result, not a good predictor of what end users most often end up with.

                                                                                  1. 4

                                                                                    I’m more saying that even with lots of advantages, Electron apps still end up like crap most of the time. VSCode should be considered an anomaly, or at best an example of what is possible by as an unlikely/amazing result, not a good predictor of what end users most often end up with.

                                                                                    I mean I disagree but there’s no substance to disagree over. It’s just your word against mine. That’s literally what TFA is about. The author of TFA thinks good and bad apps are independent of Electron and I agree. You don’t. Without anything more to bring to this we’re just voicing our unfounded opinions.

                                                                          1. 14

                                                                            The choice is between an Electron app or no macOS app.

                                                                            Really? Were there no other cross-platform GUI toolkits you could have used?

                                                                            1. 15

                                                                              I wrote and maintain an Electron application. If I weren’t using Electron, if the application would exist at all, it would be Linux-only. There’s a very simple reason why: we use interactive SVGs a lot throughout the application, because we need an image that resembles a keyboard, and SVGs make that easy. GTK can’t do that, QT can’t do that. They can display SVGs, sure, but they don’t support interactive SVGs, only via a webview. Since about 90% of the stuff the app does is tied to interacting with that SVG, there’s no point in using a native toolkit, when most of it will be spent in the same WebKit anyway.

                                                                              We could, of course, build our own widgets instead of using SVGs, but that’s way more time investment than we can afford. We - well, I - explored the native options. None of them would’ve allowed me to build the app as it is today. Electron did.

                                                                              Sometimes there are good reasons for using Electron.

                                                                              1. 1

                                                                                not svgs, but the tk vector canvas is surprisingly capable and nice to use.

                                                                              2. 12

                                                                                Honestly, I have a dim view of cross-platform toolkits having used them and developed on them. UX-wise, they’re about as bad mouthfeel-wise as Electron. I had to do quite a bit of work to get Qt to have not awful mouthfeel on Mac OS. I find most of the advocates of cross-platform UI toolkits tend to be on Linux, which was historically a pretty low bar UX-wise and clamouring for any application. You’d get better performance, but it’s not a strong argument from the UX side.

                                                                                1. 6

                                                                                  Honestly, in my experience they’re worse than Electron apps. At least standard text input shortcuts work in Electron! The “cross-platform” toolkits tend to look non-native, just like an Electron app (although often more dated), and have very… weird shortcut support, e.g. macOS Emacs-style keyboard input.

                                                                                2. 7

                                                                                  What would you recommend? I don’t mean this adversarially, it’s just that every time I’ve looked for a good cross-platform GUI toolkit, I’ve come back disappointed. I hate working with Qt because Qt bindings vary in quality across languages and I’d rather not use Qt’s stdlib over the C++ stdlib when writing C++ because I have much more experience with the C++ stdlib. Gtk similarly has some pretty poor bindings in certain languages. Tk is probably the toolkit I’ve enjoyed using the most, but it’s rapidly losing mindshare from what I can tell.

                                                                                  1. 2

                                                                                    I agree with you that the state of cross-platform GUI toolkits is bad. I love GTK on Linux, and as far as I can tell, its language bindings are consistently good, even when they’re third-party. But GTK support on Windows is second-class, and on MacOS has historically been terrible (but is maybe getting better?).

                                                                                    When I was looking at a toolkit to use for a cross-platform graphical Common Lisp app, the best I could find was Tk, despite its limitations.

                                                                                  2. 4

                                                                                    I think so? There are options you can use, but there are no really good options. https://blog.royalsloth.eu/posts/sad-state-of-cross-platform-gui-frameworks/ is a nice survey.

                                                                                    1. 2

                                                                                      They missed some third-party XAML implementations like https://avaloniaui.net/ It’s going to be closer to javafx, but with a great RAD environment (visual studio)

                                                                                      I hope MAUI will get a community Linux back-end. That would make it a good alternative too.

                                                                                    2. 4

                                                                                      i mean you have to buy into the react paradigm but react native can compile to windows and mac in addition to ios and android

                                                                                      https://microsoft.github.io/react-native-windows/

                                                                                      1. 2

                                                                                        I guess people really haven’t tried how fast you can get stuff running with QT. Yeah it’s not completely native (and it can also be used the electron way since some version), but that’s not something you get with electron either. To be fair, you have to use c++ (with QT additions) or python for it..

                                                                                        1. 2

                                                                                          I inherited a Qt project once. It was awful. I’ve never used Electron, but I know enough about it to pick it over Qt in most circumstances.

                                                                                          Not sure there are many other options if you’re targeting desktop. Proton looks promising. Microsoft’s React Native for Windows and Mac does as well. Both are similar concepts with ostensibly less overhead than Electron. Anyone here try those?

                                                                                        1. 20

                                                                                          I’ve been using JS since the late 90s and I haven’t even seen alert/confirm/prompt outside of toy tutorials or horrendous code since roughly 2005. I don’t find the arguments in this blog very convincing.

                                                                                          It’s also incredibly clickbait/alarmist, which is an immediate eye roll.

                                                                                          1. 37

                                                                                            I use confirm for actions that cannot be undone and are potentially dangerous. Why wouldn’t I? The alternative is to write a lot of code to throw up a modal div that does the same thing. Might as well do it natively.

                                                                                            1. 32

                                                                                              Wait until you meet enterprise software!

                                                                                              1. 28

                                                                                                In the relevant bug tracker discussion someone says this broke ERP software with hundreds of thousands of users.

                                                                                                1. 18

                                                                                                  Half the argument of the blog post though is that “toy tutorials” are important and valuable in a way that isn’t captured by how often the feature is used in production. And most of the rest is about how actually, it’s valuable that code from 2005 still works. I think you are missing the forest for the trees.

                                                                                                  1. 8

                                                                                                    The article considerably overstates what the Chrome team is actually intending to ship: it’s disabling cross-origin alert inside iframes, not alert entirely. Most of the article seems to be an extremely uncharitable reading of Dominic hoping that “one day”, “in the far future”, “maybe” (literally these are direct quotes!) they can remove blocking APIs like alert — not that they have any plans to do so now or any time soon.

                                                                                                    I don’t think the GP is missing the forest for the trees; I think the author is making a mountain out of a molehill.

                                                                                                    1. 7

                                                                                                      Few things:

                                                                                                      • “Some day” tends to come a lot sooner than we’d expect.
                                                                                                      • This is the sort of thing people use to justify further encroachment down the line (“Well we already disable it for iframe stuff…”).
                                                                                                      • This directly reduces the utility of using iframes–and some folks still use those on occasion, and it is exceedingly tacky to unilaterally decide to break their workflows.
                                                                                                    2. 1

                                                                                                      You can still do your little toy tutorials with alert/confirm/prompt, just don’t do them in an iframe?

                                                                                                      1. 2

                                                                                                        If you’re making a codepad-like site, you kind of have to put all the user-submitted JS in an alert so it’s not on your own domain.

                                                                                                        1. 1

                                                                                                          If you’re making a codepad-like site, you can also inject a polyfill for alert() etc in the user-controlled iframe to keep things working. Until you’re done locking down the codepad for arbitrary user scripts to run without problems, this is probably one of the smaller tasks.

                                                                                                          1. 2

                                                                                                            Can you make the polyfill block?

                                                                                                    3. 11

                                                                                                      I use alert() and confirm(). It’s easy, simple, works, and doesn’t even look so bad since Firefox 89. I don’t think my code is “horrendous”; it’s just the obvious solution without throwing a bunch of JS at it.

                                                                                                      I agree this blog post isn’t especially great though.

                                                                                                      1. 1

                                                                                                        Do you use it in a cross-origin iframe?

                                                                                                        1. 3

                                                                                                          No, but your comment made no mention of that:

                                                                                                          I haven’t even seen alert/confirm/prompt outside of toy tutorials or horrendous code since roughly 2005.

                                                                                                          1. 1

                                                                                                            Sorry, I read your reply in the context of the blog post (i.e. your code is going to break).

                                                                                                            My line about horrendous code is hyperbolic, but the fact is that alert/confirm/prompt don’t offer customizability to make for a consistent, well-made UX. Maybe it’s not a problem for certain audiences (usually things like internal tools for devs end up having them), but most customer-facing solutions require more to their experience.

                                                                                                            I’m not saying they should remove them right now, but a day in the future where they go away (presumably deprecated due to a better option) is not something we should be dreading. Who knows if that day will even come.

                                                                                                      2. 8

                                                                                                        At $JOB we have used prompt for some simple scenarios where it solves the problem of getting user input in a scenario in some sync-y code, and was no fuss.

                                                                                                        We integrate with Salesforce through an iframe. This change caused us to have to like redo a whole tiny thing to get stuff working again (using a much heavier modal thing instead of, well, a call to prompt). It wasn’t the end of the world, but it was annoying and a real unforced error.

                                                                                                        We would love a scenario where browsers offered more rich input in a clean way (modals have been in basically every native GUI since the beginning of time!). I’m sure people would be way less frustrated if Chrome offered easy alternatives that don’t rely (for example) on z-index-overlays (that can break for a billion reasons) or stuff like that.

                                                                                                        Sometimes you just want input from somebody in a prompt-y way

                                                                                                        1. 5

                                                                                                          You haven’t seen a lot of business to business software then.

                                                                                                          1. 1

                                                                                                            That is still no reason to remove a perfectly functional feature that has worked reliability for decades and requir a orders of magnitude less resources than the alternative. Both human and computational resources.

                                                                                                            I use it all the time on simple UIs I write for my own usage or for restricted groups of users.

                                                                                                            The amount of resources that could be saved if we favoured well known, tried and true technology rather than the new aesthetically shiny thing, is astonishing.

                                                                                                            1. 2

                                                                                                              It’s not about “shiny things” but about use experience. Linux has suffered for decades due to the approach you’re talking about.

                                                                                                              1. 2

                                                                                                                No, Linux has suffered precisely because it does not offer a native GUI, or UI at all, forcing everyone to reinvent basic functionality like on the web.

                                                                                                          1. 16

                                                                                                            Quoting the W3C prioritization guidelines is both entirely on the nose, and missing the point: the W3C no longer is in the driver’s seat, because it insisted on ignoring browser vendors. So the vendors made WHATWG, and W3C is mostly a rubber stamp operator now. If W3C disagrees with WHATWG, guess what ships: it’s what the vendors in WHATWG want, not what the W3C demands.

                                                                                                            I generally appreciate “don’t break the web,” but I also don’t think it’s useful to be dogmatic about it. There are plenty of counterexamples of ecosystems that work just fine — or are even improved by — breaking changes. The iOS ecosystem immediately comes to mind, for example. I like that old websites mostly still work and that the web is more stable than iOS, but I also don’t think every minute detail needs to be frozen in time to be true to a philosophical vision of the web. If something is generally bad for the ecosystem, and rarely used, removing it doesn’t seem like a sin. In my experience 99% of the time an old website is broken, it’s broken from link rot; cross-origin iframe alert being disabled hardly seems to rate in comparison to that.

                                                                                                            And cross-origin alert inside an iframe frankly doesn’t seem that useful. The majority of the use cases the author brings up won’t break at all: if you’re working on your own website and using it as a printf-debug, it seems very unlikely you’d be using it cross-origin. The same is true for students: cross-origin iframe anything is a pain; most students are not starting from there and teachers are doing them a disservice if they are. Codepen will likely have to do something special to handle the fact that alert won’t work when embedded in other sites, but TBH a polyfill, or just popping up a modal explaining why it doesn’t work, doesn’t seem unreasonably difficult.

                                                                                                            The author makes a very strong claim to broaden this essay by claiming that Chrome is intending to deprecate alert and other blocking APIs entirely, without any replacements or considering any of their use cases. This is a fairly uncharitable reading of a comment Dominic made in the thread about removing cross-origin alert inside an iframe, which I’ll reproduce here:

                                                                                                            One day (far in the future), maybe we can remove alert/confirm/prompt/beforeunload entirely. Incremental steps like this one are exciting.

                                                                                                            This is not a comment that warrants outrage, in my opinion. “Far in the future” and “maybe” are pretty important parts of the sentence. Yes, Chrome would like them to be eventually gone, but assuming the worst and that there will be no consideration of usage or reasonable migration paths or replacements, way in advance, seems a little unreasonable.

                                                                                                            1. -1

                                                                                                              3:2 aspect ratio display? Great, I look forward to every game I own being distorted or letterbox’ed on it. I didn’t know they even made displays with that aspect ratio.

                                                                                                              1. 19

                                                                                                                People often complains about the lack of vertical space. Why would games be distorted? Only video will be problematic on this ratio.

                                                                                                                1. 16

                                                                                                                  The screen was specifically what put me over the top to buy one. I’ve been dreaming about a taller aspect screen since they made everything “wide” ten years ago.

                                                                                                                  1. 2

                                                                                                                    I would prefer a “normal” 4:3. The pixel density of the 13.5” 2256x1504 display is too low for 2x scaling. Something like 2400x1600 should be the lowest option.

                                                                                                                    1. 2

                                                                                                                      Obviously it’s all subjective, but I’d say 4:3 feels “dated” while 3:2 feels “super cool”.

                                                                                                                  2. 8

                                                                                                                    It is a lot more pleasant for coding, reading, and writing in my experience. 3:2 is great for that and I prefer it, but I don’t play many videogames anymore.

                                                                                                                    Work forced me to used a 16:9 display for a while. I use a ultra-widescreen now because that breaks into 3 reasonable panes, but 2 vertical 16:9s was ok. For me, xrandr is linux’s killer-app.

                                                                                                                    1. 5

                                                                                                                      3:2 is great. My old Surface Book has 3:2; I’d much rather get a few inches of vertical space for coding and reading than avoid letterboxing for movies.

                                                                                                                      In my experience PC games work just fine with 3:2 as well typically.

                                                                                                                      1. 4

                                                                                                                        I used one of the original Chromebooks, the Chromebook Pixel, for several months in 2015 and adored the 3:2 aspect ratio for everything except media consumption. It was a little awkward for fullscreen 16:9 videos but fine for 4:3. I recognize that not much content is 4:3 anymore, though.

                                                                                                                        I’m a little concerned about the pixel density of the Framework screen being too low for HiDPI but I’m unlikely to buy one anytime soon having just bought a Lenovo Flex 5 CB earlier this year for my main mobile computing device.

                                                                                                                        1. 2

                                                                                                                          Yeah, I have one of those Chromebooks too. The aspect ratio is definitely the best thing about the whole machine by a long shot. If it weren’t for the glossy display I would have been tempted to use it as my daily driver (after wiping the OS of course).

                                                                                                                      1. 6

                                                                                                                        Okay, that’s a few less keystrokes, but a harder mental load. I’d rather press F3 to go to the next result (or even, re-hit ctrl+f and enter) than remember if I’m in the “search” mode and hit some random button that has a different meaning in a different context.

                                                                                                                        When programming, you already have to juggle so many different things in your mind - why complicate it further? I feel like all those vim/emacs articles are just written to justify the time spent learning all those keystrokes and quirks, and all the time setting up the plugins.

                                                                                                                        1. 10

                                                                                                                          I get that concern, but the truth is that after a couple weeks of using vim all the commands and things you use daily become second nature. I’ve had times where I couldn’t tell someone how to do something in vim without having my fingers on the keys so I see what my movements were. It’s pretty amazing how many shortcuts you can keep in your head.

                                                                                                                          1. 2

                                                                                                                            I’m able to mostly do that by playing the air-qwerty- keyboard. Definitely keeping most of my vim knowledge in my muscles, leaving my brain free for how I want the text to change.

                                                                                                                          2. 6

                                                                                                                            You’re actually looking at it the wrong way around. F3 is the random key here. Nobody would ever figure out that key without help. On the other hand, in VI most keys are part of a logical pattern, even though some of those are historical. For example: n is the key you’d press to get to the next search result.

                                                                                                                            So while most shortcuts in modern day GUI have to be memorized without much context to help*, Vim commands are a language built out of related patterns.

                                                                                                                            *) That’s of course not the full story. All those shortcuts have a history as well and some are an abbreviation for the action as in ctrl+f(ind) or ctrl+c(opy). But there’s no “copy a word and paste it to the next line” or anything similar one could express with those.

                                                                                                                            1. 5

                                                                                                                              People figure out the F3 key by seeing it in the IDE’s menus - which vim doesn’t have. With vim, you have to put in the effort and actively learn the shortcuts. But even then, I said you can just hit Ctrl+F and enter again to get the same behavior, which is obvious because most software has the same shortcuts, and work the same way.

                                                                                                                              But there’s no “copy a word and paste it to the next line” or anything similar one could express with those.

                                                                                                                              Ctrl+Shift+Right to select the word, then Ctrl+C, Down arrow, Ctrl+V, am I missing something?

                                                                                                                              1. 2

                                                                                                                                Yes, if you use GVim you get those little helpers in menus as well. That’s a different interface. But the topic should be about concepts. VIM commands are a concept, a language, rather than a list of unrelated commands.

                                                                                                                                Of course you can do everything that you can do in VIM in any other editor as well. I’m referring to concepts and I might not be very good in conveying that. Sorry.

                                                                                                                                1. 1

                                                                                                                                  In the end you can express pretty much anything in any editor with enough keystrokes: the arrow keys exist, after all.

                                                                                                                                  Modal editing tends to be a lot more efficient than non-modal though, and the keystrokes don’t require you to move your hands much e.g. to the arrow keys (way off the home row) or to use modifiers like Ctrl that require stretching your hands. Modal editors allow you to use the keys that are the easiest to reach: the letter keys, since the modal editor knows whether you’re intending to write vs intending to issue commands. These days I mostly use VSCode, rather than Vim, but I always have Vim emulation turned on because it’s much faster than non-modal editing once you’re familiar with it. Vim is particularly nice because it has a mini language for expressing edits; for example, w means “word,” and can be combined with deletion to delete a word (dw), selection to select a word (vw), “yank” to copy a word (yw), etc — or it can be used alone without a prefacing action, in which case it simply jumps to the next word after the cursor position. And there are many other “motion” nouns like w, and those can also be combined with the action verbs in the same manner — to copy letters, paragraphs, etc, or even more complex ideas such as letter search terms. Command sequences are first-class and your last command can be replayed with a single keystroke, and there’s even a built-in macro definition verb q, which stores up indexable lists of command sequences you issue and can replay the entire lists for executing complex but tedious refactors.

                                                                                                                                  Sure — the bottleneck in programming is typically not between your hands and the keyboard; it’s typically thought. But once you know what you want to express, it’s a very pleasant experience to be able to do it with such efficiency of motion. And since we do ultimately spend quite a while typing, it’s not irrational to spend some time learning a new system to have that time feel nicer.

                                                                                                                                  1. 2

                                                                                                                                    Modal editing tends to be a lot more efficient than non-modal though, and the keystrokes don’t require you to move your hands much

                                                                                                                                    Real gain is in reduced load on one’s muscles and tendons. Moving to vim bindings has helped me overcome pain in my wrists.

                                                                                                                                    1. 2

                                                                                                                                      I don’t see it as much for programming, but for writing prose a modal editor is great for forcing me to separate writing from editing. When I write an article / book chapter in vim, I try to write the first draft and then go back end edit. At worst, I try to write entire paragraphs or sections and then edit. I find this produces much better output than if I use an editor that makes it easy to edit while I’m writing.

                                                                                                                              2. 5

                                                                                                                                This is something that the article comes close to saying, but doesn’t actually say: Vim doesn’t just provide a bunch of shortcuts and keybindings for arbitrary operations, instead it provides a fairly well thought out programming language for dealing with text, that happens to also be bound to convenient keys. Crucially, operations in this language can be composed such as in the examples that the article gives, so you can build up your own vocabulary of operations even if the developers didn’t account for them. Does this take longer to learn than looking up the? Yes, probably. But I suspect that for most vim fans, there comes a “aha moment” where the power of this approach becomes apparent, and once you get used to it, you can’t live with it.

                                                                                                                                1. 2

                                                                                                                                  I’m not sure “n” for next is “some random key”? And “N” (shift-n[ext]) for previous.

                                                                                                                                  And slash/question mark for search might be a bit arbitrary, but slash sorta-kinda “means” pattern/regex (as in /^something/).

                                                                                                                                  Ed: ok, I’m not sure why op is exited about “find” - I generally “search”.. . Or move by word (w) beginning/end of line (| and $). See also: https://stackoverflow.com/questions/12495442/what-do-the-f-and-t-commands-do-in-vim#12495564

                                                                                                                                  1. 1

                                                                                                                                    Move by word - hold ctrl, works in any textarea in any operating system.

                                                                                                                                    Move to beginning/end of line - press “home” or “end” keys, works in any textarea in any operating system.

                                                                                                                                    n is “some random key” on every other software with a text box on your computer. Vim is inferior in that aspect, not superior.

                                                                                                                                    1. 1

                                                                                                                                      ) moves by sentence and } moves by paragraph. I miss that all the time while writing prose outside of vim.

                                                                                                                                      Since they’re motions, you can combine them with delete/yank/replace/whatever. So di) deletes the whole sentence.

                                                                                                                                      1. 1

                                                                                                                                        Option up/down moves by paragraph.

                                                                                                                                        1. 1

                                                                                                                                          I’m on Windows

                                                                                                                                  2. 2

                                                                                                                                    The mental load goes away after a while and it just becomes muscle memory. Each saving by itself is small, but they all add up over time. One I used recently was %g/^State \d/norm! f:lD: “On every line that starts with State followed by a number, delete everything after the first colon. Would have taken several minutes without that, with it it’s just a couple of seconds. When I’m constantly getting savings like that, it’s worth it.

                                                                                                                                  1. 5

                                                                                                                                    Responded to this on the orange site as well, but git has both the ability to view a “clean” squash-and-rebase style history, as well as a chronological history of when commits entered the main branch, as well as a “true” history of when commits were authored (IMO least useful history, despite it being the default of git log)… Assuming you use regular merges with --no-ff, which is the default on Github.

                                                                                                                                    • To view the history of PR merges: git log --merges

                                                                                                                                    • To view the history of when commits entered the main branch (i.e. view all commits, but group them by PR rather than interspersing based on commit timestamp): git log --topo-order. Some people don’t like viewing the “useless” merge commits in this view, so you can also pass --no-merges if you want to skip those (IMO it’s useful to see them, but if you disagree, you can filter them out).

                                                                                                                                    • To view the fairly useless history of when commits were authored, of course, you just use git log. This probably shouldn’t have been the default; I can’t think of a time I ever wanted this view. I think much of the handwringing around merge/rebase strategies is due to git choosing this as the default log view, and thus Github choosing it as the only log view in its GUI.

                                                                                                                                    Since Github doesn’t support any of these views other than the fairly useless default one, unfortunately, many people aren’t aware of them. But git already supports “commit groups” — that is, branches — with rich ways of viewing the history of a repo! You don’t need to destroy commit history in order to get the views you want.

                                                                                                                                    1. 9

                                                                                                                                      I had a similar experience: Android to iPhone, recently used a new Android and was pleasantly surprised. Even the low end Androids work way better than flagship phones from 2015 when I switched. But there’s a killer app in the Apple ecosystem for me: applications. Mail, Photos, Music, Notes, Calendar, Contacts, Files: all apps on iOS and applications on MacOS.

                                                                                                                                      Google’s SPAs don’t cut if for me. I don’t necessarily use offline access, but I need to open an application without enormous first load times and more load times after backgrounding for a few minutes. Apple Photos in particular demolishes the Google Photos experience purely by having the photos stored locally, especially if I’m away from my gigabit home internet.

                                                                                                                                      1. 4

                                                                                                                                        Yeah, the Apple built in apps are just so good. The notes app alone is such an amazing information capture system. It just sucks that it’s such a pain to develop for it unless you pay. Also apparently my Flutter development efforts are futile on iOS because I use an M1 macbook and cocoapods apparently doesn’t work on M1.

                                                                                                                                        1. 3

                                                                                                                                          I switched off iOS a long time ago, so I may not be up to date on the Notes app — when I last used it, it was fairly bare-bones. What makes it better than say, Google Keep?

                                                                                                                                          1. 4

                                                                                                                                            They’ve added a lot to it in the meantime, it’s basically a full OneNote competitor now. I have several years of daily notes in it. The real killer feature is how it integrates into iMessage and the like so you can share notes with people.

                                                                                                                                            1. 1

                                                                                                                                              And even more improvements are coming this fall in iOS/iPadOS 15 and Monterey - hashtags for note tagging support, ability to tag/mention people in notes and the new omnipresent quick note interface, all of those are amazing additions that are well worth the upgrade. Can’t wait for the stable versions to ship in September.

                                                                                                                                              1. 1

                                                                                                                                                Can you read/edit those notes via a non-macOS computer? I noticed that if I can only use it on the phone it’s 100% useless to me.

                                                                                                                                                1. 2

                                                                                                                                                  You can use iCloud web yeah, but it’s kinda crap. I only really use the web version to read things.

                                                                                                                                          2. 4

                                                                                                                                            Apple Photos in particular demolishes the Google Photos experience purely by having the photos stored locally, especially if I’m away from my gigabit home internet.

                                                                                                                                            If you use iCloud, Photos on iOS will offload older pictures to it and fetch them only when needed. That’s a killer feature too imho has you never need to care if this is local or not, or to manage your space.

                                                                                                                                            1. 2

                                                                                                                                              I too moved from Android to iPhone. But google photos is one of the apps I kept. A lot of fun features in it, and I can share photos with friends and family regardless of their platform.

                                                                                                                                              1. 1

                                                                                                                                                The killer feature of Google Photos for me is the expansive timeline stretching back multiple devices. First load isn’t a major concern for me because I’m just going to use the scroll bar to scrub back to 2011, anyway.

                                                                                                                                              1. 3

                                                                                                                                                If you’re considering switching to Android to try it out, I’d highly recommend the Pixel line of phones — if you want a second or “burner” phone, or one for dev testing before commiting to the ecosystem, the cheaper “A” line of Pixels are great ($350 unlocked, or potentially free if you get it from a carrier with a contract). Great camera quality, they get OS updates as soon as they come out, and Google does a good job of detecting spam calls and not even ringing your phone when it’s a spammer. When they’re not sure, you have the option to let Google Assistant pick up and real-time transcribe the conversation for you, and you can hop in and take over the call if it’s someone real.

                                                                                                                                                As an Android user the main thing I wish I could use from the Apple ecosystem is the watch. But there are decent smartwatch options out there if you’re not committed to square-screen-on-your-wrist — I wear a Garmin smartwatch that most people mistake for a non-smartwatch, and get notifications on my wrist and some health tracking.

                                                                                                                                                1. 4

                                                                                                                                                  Is there anything like this from Apple? Lack of software management tooling was part of what pushed me away from macOS.

                                                                                                                                                  1. 5

                                                                                                                                                    macOS operates a completely different model for apps. Each one is packaged completely in a .app file, so you can have 400 diff. versions if you are so inclined and can park them basically anywhere and they still run. They are even platform agnostic.

                                                                                                                                                    It’s just different, though I guess with flatpack and whatever, maybe Linux is trying to go that direction also?

                                                                                                                                                    You could use nix or pkgsrc or brew if you wanted something more “traditional”.

                                                                                                                                                    Also the App Store exists.

                                                                                                                                                    MS has never had a good story for apps and delivery, and it’s nice that they are finally working on it after a few decades with mostly a terrible story.

                                                                                                                                                    1. 2

                                                                                                                                                      macOS operates a completely different model for apps. Each one is packaged completely in a .app file, so you can have 400 diff. versions if you are so inclined and can park them basically anywhere and they still run. They are even platform agnostic.

                                                                                                                                                      That solves the packaging problem, but not the update part. Most macOS apps are either distributed via the app store or come with their own updater. The custom updaters are annoying because the individual apps typically don’t have permission to write to /Applications and so you need privilege elevation during the update process.

                                                                                                                                                      Homebrew works pretty well for this, but it’s not an Apple-supported thing (I guess now it’s technically a Microsoft product, since it’s maintained by GitHub).

                                                                                                                                                      1. 2

                                                                                                                                                        Yeah, pretty much every software engineer I know who uses macOS uses Homebrew. This is like Homebrew, but maintained by Microsoft instead of a third party. Previously there were third-party programs that did this on Windows like Chocolatey and scoop, very similar to Fink/MacPorts/Homebrew for macOS (which were all inspired by *nix package managers).

                                                                                                                                                        Apple doesn’t seem very focused on command line use cases, so I doubt they’ll ship something like this any time soon. MS has been increasingly focused on these kinds of use cases, probably in part because command line users are often also likely to use AWS/Azure/GCP, and I’ve been pleasantly surprised with all the tools they’ve been releasing lately.

                                                                                                                                                        1. 1

                                                                                                                                                          I agree with everything you said, but when Apple sanctioned the .app story as the way to do it, upgrades were not expected every day like they are now. The issue has gotten worse, though Apple’s made it clear the App Store is THE WAY to do this, but obviously not everyone agrees.

                                                                                                                                                          Homebrew, pkgsrc, nix, etc all handle this fine on macOS though.

                                                                                                                                                          1. 2

                                                                                                                                                            I agree with everything you said, but when Apple sanctioned the .app story as the way to do it, upgrades were not expected every day like they are now

                                                                                                                                                            Apple inherited .app bundles from NeXT. The model was very different there: they were expected to be stored on an NFS or AFS server and updated centrally for everyone. With AFS, you’d generally have a local cache, so it ended up very similar to the app-store model: a central server updates, you grab the latest version and run it.

                                                                                                                                                            Part of the problem with the macOS model comes from the fact that it tried to merge a user-managed desktop metaphor with a centrally managed workstation system.

                                                                                                                                                            1. 1

                                                                                                                                                              I must have missed this reply somehow.. anyways.. :)

                                                                                                                                                              I 100% agree, I didn’t mean to imply Apple invented their system themselves. Thanks for the trip down memory lane :)

                                                                                                                                                      2. 2

                                                                                                                                                        There was at one point an effort to add support for rpm. I don’t think it ever escaped the lab.

                                                                                                                                                      1. 10

                                                                                                                                                        AOSP’s Linux days appear numbered, progress on Fuchsia has been fast.

                                                                                                                                                        1. 1

                                                                                                                                                          Maybe, but possibly only for the android ecosystem. I doubt that the server world will move away from that. And any company that wants to have a collaboration is better of using linux than some google OS which allows them to have an edge over many functions (by simply keeping them private, so everyone has their own extensions).

                                                                                                                                                          1. 10

                                                                                                                                                            AOSP is the Android Open Source Project. https://source.android.com/

                                                                                                                                                            1. 2

                                                                                                                                                              AOSP doesn’t include anything required to run something you’d call android for normal users

                                                                                                                                                              • location
                                                                                                                                                              • sync
                                                                                                                                                              • playstore
                                                                                                                                                              • playstore APIs required for many apps (see location,sync..)
                                                                                                                                                              • google camera (no it won’t run unless modified to do so on approved hardware/os variations)

                                                                                                                                                              This is why people are using things like microG or opengapps on their custom ROMs.

                                                                                                                                                              Google explicitly got sued under anti-trust because they dictate the “kind” of android you can use when you want a real android and not some useless thing that’s running as much apps as ubuntu phone.

                                                                                                                                                              And let’s not talk about their driver stack, where every vendor ships their own crippled variation of android with their own binary blobs you have to use - if you can even download them by yourself and not have to compile their own version of android.

                                                                                                                                                              1. 5

                                                                                                                                                                I think the person you originally replied to was referring to the usage of the Linux kernel in the Android project and suggesting that the days that Linux will continue to be used as the base for the Android operating system are numbered.

                                                                                                                                                                I’m aware of the things you’ve mentioned here, but I’m not sure how they are related to the original point.

                                                                                                                                                                1. 2

                                                                                                                                                                  Yeah you’re right, totally missed that

                                                                                                                                                            2. 8

                                                                                                                                                              is better of using linux than some google OS

                                                                                                                                                              But what if… Fuchsia was actually much less work to write and maintain drivers for, due to drivers running in userspace and hitting stable APIs and ABIs?

                                                                                                                                                              1. 5

                                                                                                                                                                That might be a nice side effect (I know little about Fuschia internals other than some former Be people were working on it), but my suspicion is Google is in it primarily for the non-copyleft.

                                                                                                                                                                1. 12

                                                                                                                                                                  I think you have it exactly backwards. Getting rid of copyleft is a nice bonus, but the thing that seems to be causing actual problems is HW vendors refusing to forward-port their drivers to new kernel versions, whether or not they throw some source code over the wall. With a stable driver/kernel interface, this would not be a problem.

                                                                                                                                                                  1. 3

                                                                                                                                                                    I think you under-estimate the ability of vendors to produce crap. Kernel-land vs user-land and APIs are very secondary. As soon as they can write crap, they’ll write crap. Sure the crap will be more isolated but it won’t work better and with less incentive to produce working stuff, it might even end up worse. I don’t know how things would turn out but “works well in practice, not only in demos” doesn’t seem to have been the goal of vendors so far.

                                                                                                                                                                    1. 3

                                                                                                                                                                      Sure the crap will be more isolated but it won’t work better and with less incentive to produce working stuff

                                                                                                                                                                      That’s the purpose of isolation though, isn’t it? To allow folks to write crap and not have it mess up the entire kernel. It’s accepting the human nature of writing bad code and trying to contain the damage.

                                                                                                                                                                      1. 3

                                                                                                                                                                        To play devil’s advocate: reducing penalties for writing crap incentivizes developers to write crap, so more crap will appear.

                                                                                                                                                                        To be clear, I’m entirely in favor of better OSes - but usually, when you incentivize something, people will do it. Ideally, we’d have developers trying hard to write good software and OSes that compensate for their mistakes - but in order to do that, we’ll need to incentivize them properly.

                                                                                                                                                                        1. 1

                                                                                                                                                                          Yup, that’s the purpose. But if that’s the camera driver and it’s crap, you’re going to have troubles taking pictures and that will cripple more than one app. I’m wary they’ll manage to make things worse. Not that the OS would make that more prevalent, but that these vendors are really really terrible.

                                                                                                                                                                          1. 3

                                                                                                                                                                            It sounds like the problem for Google is that the vendor makes it work once and then abandons it, so upgrading the kernel becomes hard.

                                                                                                                                                                            If it never worked in the first place, it wouldn’t matter whether the kernel upgrade broke it, because it never worked in the first place. The problem Google seems to be facing is that it did work at one point, but keeping it working is a PITA due to the lack of encapsulation/isolation.

                                                                                                                                                                        2. 2

                                                                                                                                                                          When running in unprivileged mode, drivers are this much easier to both debug and reverse engineer. This is on top of all other advantages.

                                                                                                                                                                          It’s a win-win situation.

                                                                                                                                                                      2. 4

                                                                                                                                                                        I believe Fuchsia is MIT licensed. https://fuchsia.googlesource.com/fuchsia/

                                                                                                                                                                        1. 7

                                                                                                                                                                          Yeah, not copyleft like GPLv2 is.

                                                                                                                                                                          1. 2

                                                                                                                                                                            Sorry, my brain read non-copyleft as proprietary for some reason.

                                                                                                                                                                          2. 3

                                                                                                                                                                            looks like 2-clause BSD (aka “Simplified BSD License” or “FreeBSD License”): https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/LICENSE

                                                                                                                                                                            EDIT: With a litigation revoking patent grant! https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/PATENTS
                                                                                                                                                                            Not sure why they didn’t just use apache-2 license?

                                                                                                                                                                          3. 4

                                                                                                                                                                            but my suspicion is Google is in it primarily for the non-copyleft.

                                                                                                                                                                            You would be correct.

                                                                                                                                                                          4. 3

                                                                                                                                                                            It’s ultimately up to Google whether Fuchsia has stable ABI. I do think the biggest liability is the fact that this is after all a Google project - and they choose to kill it regardless of how good or beloved it is (eg: Reader)

                                                                                                                                                                      1. 14

                                                                                                                                                                        Can someone explain me the point of the rant? I don’t really understand what it’s trying to say.

                                                                                                                                                                        1. 84

                                                                                                                                                                          Every language has some core idea that inspired its creators to make it, instead of putting up with the other perfectly good languages that already existed. Sometimes, that idea is simple (“everything is an object” for Smalltalk, “everything is a cons cell” for LISP), and sometimes that idea is more complex (the way that Java is designed to scale to huge teams, or the way that Perl is “the Cliff’s Notes of Unix”).

                                                                                                                                                                          The author’s idea is that the core idea of Ruby is (waves hands) for making domain-specific languages. It’s not the universal syntax for expressing all algorithms, but if you have an idea for how a particular algorithm should be expressed, you can probably bend Ruby into that shape, at least within a particular class or project.

                                                                                                                                                                          The author’s lament is that Ruby’s core idea was never really named, and thus never advertised, and thus never formed part of Ruby’s reputation. As a result, it didn’t build up the audience of tinkerers and experimenters who could form a long-lived supportive community around it.

                                                                                                                                                                          Instead, what it got was Rails, which was the opposite of that core idea: instead of bending Rails into a domain-specific language for the application you want to create, the idea is to bend your application to fit within the framework Rails provides. And since Rails became hugely popular, the vast majority of the Ruby community valued that framework-style approach and Ruby just became the incidental-complexity runtime for Rails instead of an interesting thing in its own right.

                                                                                                                                                                          1. 11

                                                                                                                                                                            Brilliant summary. Well done.

                                                                                                                                                                            1. 4

                                                                                                                                                                              The Ruby-on-Rails revolution and its consequences have been a disaster for the Ruby race.

                                                                                                                                                                              1. 2

                                                                                                                                                                                Can you expand a bit on the idea that Ruby is for DSLs? I feel like I’ve heard that here and there and it always seemed like a bit of a stretch. Ruby just doesn’t have things that I would think would be critical for truly writing DSLs, such as lazy evaluation and macros.

                                                                                                                                                                                The vagrant config, for example, is a bunch of ruby code that calls itself a DSL but it really just feels like… writing ruby. Python, for instance, could do it just as well (see: SCons).

                                                                                                                                                                                1. 5

                                                                                                                                                                                  The instance_exec method allows for succinct DSLs whose syntax couldn’t be easily copied in other languages like Python. Basically, it allows you to evaluate blocks as if they were running in the scope of an arbitrary object’s methods — or to put it in Rubyist terms, it allows you to execute blocks with an arbitrary receiver. For (a completely contrived) example, in Python you might write:

                                                                                                                                                                                  conf = Library.config_object()
                                                                                                                                                                                  conf.config_file("foo.txt")
                                                                                                                                                                                  conf.worker_processes(2)
                                                                                                                                                                                  worker = Library.worker(conf)
                                                                                                                                                                                  

                                                                                                                                                                                  Whereas a Ruby library might read:

                                                                                                                                                                                  worker = Library.worker do
                                                                                                                                                                                    config_file "foo.txt"
                                                                                                                                                                                    worker_processes 2
                                                                                                                                                                                  end
                                                                                                                                                                                  

                                                                                                                                                                                  The interior of the Ruby block defining the worker feels in a certain sense like a DSL; these methods are not in global scope: they’re special methods that are accessible inside the block, running on an anonymous object. It’s sort of like having a domain-specific language with new keywords — config_file and worker_processes — that elegantly composes with standard Ruby.

                                                                                                                                                                                  Of course, really all it means is you can leave out repeated references to conf, since Library.worker makes everything run as if it’s in the scope of some method on conf (and Ruby has implicit self inside method calls, so you can write config_file instead of self.config_file). But ergonomically it can feel nice. It’s the same number of lines, but much less significant text.

                                                                                                                                                                                  1. 1

                                                                                                                                                                                    To your point: until I read this comment, I had no idea that the Vagrant config was even supposed to be any kind of DSL. It just looked like ordinary Ruby to me.

                                                                                                                                                                                  2. 1

                                                                                                                                                                                    Thank you… Didn’t even bother reading the post - love your writing style too!

                                                                                                                                                                                    1. 1

                                                                                                                                                                                      Thanks for that. I never learned that about ruby because the first and only place I tried it was (gross) codecademy, before I’d started learning how to code.

                                                                                                                                                                                      1. 1

                                                                                                                                                                                        The author’s lament is that Ruby’s core idea was never really named, and thus never advertised

                                                                                                                                                                                        I know this is not your point, but I have a bunch of populer old books from ruby 1.9 times such as “metaprogramming ruby” and “rspec” which disagree.

                                                                                                                                                                                      2. 5

                                                                                                                                                                                        That Ruby never gained traction for the face value of its expressiveness. I feel that this rant imply that the mix of semantic approach of Perl and the meta-approach of Lisp meeting in the right balance in Ruby have not been recognized and exploited fully to show what Ruby really is.

                                                                                                                                                                                        The way the author speaks about “phrase-based” reminds me of Perl, Raku, APL, dense language where you can express yourself in short understandable phrase. The author pushes the idea that this is the meaning of the mantra “Desifned for developer’s happiness”. To be happy, you have to be able to express yourself without convolution and Ruby provided that solid base and rich vocabulary to be expressive and precise.

                                                                                                                                                                                        1. 3

                                                                                                                                                                                          Me neither. Wondering if I should flag this as off-topic.

                                                                                                                                                                                        1. 2

                                                                                                                                                                                          Personally, it varies.

                                                                                                                                                                                          If it’s automating a small set of commands, I’ll use bash. That’s what a bash script is: it executes the bash commands you’d run manually in your terminal. Common examples for me would be:

                                                                                                                                                                                          • Running a specific Docker container with certain arguments.
                                                                                                                                                                                          • Starting a development database and/or running migrations.
                                                                                                                                                                                          • Bootstrapping some other, more complicated piece of code without needing any dependencies on the system.

                                                                                                                                                                                          Using a non-bash programming language to just run some bash commands ends up feeling like overkill when it’s small.

                                                                                                                                                                                          But, bash sucks at tasks with much complexity, like if you need error handling beyond the process just failing with whatever error message the subprocess failed with, or even basic math. Importing other bash scripts is also a slight amount of pain every time you do it, because without some ceremony, the import path will be dependent on the directory of the user, rather than the path of the script being run; breaking up bash scripts into multiple files is obviously possible, but doing it a bunch is death by a thousand papercuts. If it’s more than a few dozen lines I’ll usually switch to a more standard programming language.

                                                                                                                                                                                          If the script mostly interacts with other processes, I’ll use Ruby. Node is… painful when it comes to spawning and waiting for output from processes. child_process is filled with callbacks and EventEmitters, when typically I just want to spawn a process synchronously and block until it gives me output. Usually when I’m writing scripting / automation tasks I’m trying to get something done reasonably quickly and don’t want to set up an entire environment, install dependencies, etc; I just want a script that’s reasonably-portable to other machines without doing much of anything to set it up, and so what’s in the standard library is important. For subprocesses, Node’s standard lib is pretty painful; Ruby’s is decent (mainly the open3 module).

                                                                                                                                                                                          If it’s mostly not about interacting with subprocesses and instead is about reading + transforming + outputting data, I’ll use Node. JS is a fairly comfortable language for me, it’s quite fast for an interpreted language, and I like its simple support for functional-style programming.

                                                                                                                                                                                          But really, it all depends on the project. For home use, all of the above is true; if it’s something I’m working on with other people, or at a job, I’ll use whatever is simplest for the project. If it’s a few lines I’ll still use bash, and anything larger I’ll probably use whatever language the project is written in. Most tasks can be accomplished in most programming languages, and making, for example, a Python team deal with a Ruby script is silly compared to just writing the script in Python; same goes for even compiled languages like Rust or Go.

                                                                                                                                                                                          Plus, in an existing project you’ve probably already paid the price of setting up some kind of environment and managing dependencies — so there’s no extra cost for using them. Whereas if you switch languages from the primary project’s, you’re back to either being dependent on stdlib, or asking people to set up and manage yet another environment to run your script.

                                                                                                                                                                                          1. 10

                                                                                                                                                                                            Want to call an async function blockingly from a sync function? -> Throw it on an executor!

                                                                                                                                                                                            This is colored, no? If it wasn’t you would just call the async function without needing an executor. Cannot you do something like this in every language that has futures-based async?

                                                                                                                                                                                            1. 6

                                                                                                                                                                                              The key part is blockingly.

                                                                                                                                                                                              You can fire-and-forget async functions in any language with “colors”, but you can’t block synchronously until they finish.

                                                                                                                                                                                              In JS there’s no way to get a result of a Promise without unwinding your stack first (microtasks are processed only after the entire call stack unwinds, so no return, no results).

                                                                                                                                                                                              In Rust you can block a thread waiting for anything async that you want. That’s not even a feature of async executors, but merely the fact that you’re in full control OS threads, so you can always build on top of that.

                                                                                                                                                                                              1. 4

                                                                                                                                                                                                No, it’s typed. Rust, like C# and others, avoid the color mess by just unifying it with the type system. It has special syntax but under the hood it’s all the same. It’s simpler (no separate color checker needed) and more powerful (eg sync manipulation of async functions).

                                                                                                                                                                                                1. 4

                                                                                                                                                                                                  Just because Rust and C# hardcodedasync/await into the language doesn’t mean their functions aren’t colored anymore.

                                                                                                                                                                                                2. 2

                                                                                                                                                                                                  Calling async functions from sync code in javascript is no easy feat

                                                                                                                                                                                                  1. 4

                                                                                                                                                                                                    Wait, what? It’s much easier than Rust:

                                                                                                                                                                                                    // "async" color
                                                                                                                                                                                                    async function a() {
                                                                                                                                                                                                      return "hello";
                                                                                                                                                                                                    }
                                                                                                                                                                                                    
                                                                                                                                                                                                    // not "async" color, but calls an async-color function
                                                                                                                                                                                                    function b() {
                                                                                                                                                                                                      a().then(greeting => console.log(`${greeting} world`));
                                                                                                                                                                                                    }
                                                                                                                                                                                                    

                                                                                                                                                                                                    You can also easily return values calculated in sync functions that depend on data from async functions, because an async function is just syntax sugar for returning a Promise, and so your non-async function can just return a Promise as well:

                                                                                                                                                                                                    // "async" color
                                                                                                                                                                                                    async function a() {
                                                                                                                                                                                                      return 1;
                                                                                                                                                                                                    }
                                                                                                                                                                                                    
                                                                                                                                                                                                    // not "async" color
                                                                                                                                                                                                    function b() {
                                                                                                                                                                                                      return a().then(x => x + 1);
                                                                                                                                                                                                    }
                                                                                                                                                                                                    
                                                                                                                                                                                                    // not "async" color
                                                                                                                                                                                                    function c() {
                                                                                                                                                                                                      b().then(val => console.log(val));
                                                                                                                                                                                                    }
                                                                                                                                                                                                    
                                                                                                                                                                                                    c();
                                                                                                                                                                                                    // prints 2
                                                                                                                                                                                                    

                                                                                                                                                                                                    Or, since await is just syntax sugar for waiting for a Promise, you could even mix and match, e.g. c could be rewritten as:

                                                                                                                                                                                                    async function c() {
                                                                                                                                                                                                      const val  = await b();
                                                                                                                                                                                                      console.log(val);
                                                                                                                                                                                                    }
                                                                                                                                                                                                    

                                                                                                                                                                                                    Even though b was never explicitly tagged with the async color marker.

                                                                                                                                                                                                    1. 11

                                                                                                                                                                                                      If you’re using promises (via then, etc) the function is async, not sync, no matter which syntax you’re using…

                                                                                                                                                                                                      1. 2

                                                                                                                                                                                                        Well, it really depends what you mean by “async”, and I think precision matters, as this topic is trickier in JS than some give it credit for. This might be pedantic on my part, but just to be super clear here, a function “is async” in JS when it uses the “async” keyword – that’s it. The only thing that the async keyword does is:

                                                                                                                                                                                                        1. It makes the function return a promise
                                                                                                                                                                                                        2. It enables the use of await and try/catch/finally as syntactic sugar for .then/.catch/.finally.

                                                                                                                                                                                                        As a result, when an async function is desugared, it decomposes into an outer function which chains together a number of callbacks. This is what makes the async function feel async; any one statement within the async function body could belong to a number of different callbacks after desugaring.

                                                                                                                                                                                                        If you’re using promises (via then, etc) the function is async, not sync, no matter which syntax you’re using…

                                                                                                                                                                                                        I don’t think “the function” is precise enough to be meaningful because it could mean two things:

                                                                                                                                                                                                        • this function composes and returns a promise chain, and the process by which that chain runs to completion is asynchronous with respect to other work happening in the event loop
                                                                                                                                                                                                        • this function constructs a value, calls a method on it, and then returns that value; the value may be a promise but that’s neither here nor there when it comes to each statement in the outer function body getting executed synchronously
                                                                                                                                                                                                        1. 4

                                                                                                                                                                                                          Pedantry noted. I should have said if your function returns a promise it is async.

                                                                                                                                                                                                      2. 2

                                                                                                                                                                                                        To get a Promise in JS, not returning it and neither handling any rejection of it is dangerous, as that will swallow any exceptions thrown within that Promise chain.

                                                                                                                                                                                                        It also won’t execute the content of the Promise chain synchronously, so any code depending on that execution won’t be able to wait for it to be done.

                                                                                                                                                                                                        This is a real issue in JS that’s been discussed in the context of eg CLI tools, where a sync execution can be preferable from a simplicity view point.