1. 2
  1.  

  2. 7

    I’m anxious of the day we all look back and think “Oh no, that was a huge mistake.”

    Little late on that in JS, now aren’t we?

    ~

    The thing that made promises “click” for me was to realize that, to the end user, it really doesn’t matter in many cases why the page didn’t render when a promise failed. DB on fire? Unable to reach microservice? Type error? Doesn’t matter.

    The promise code got so much simpler when I a) started programming the happy path and b) made functions that were easily composable. Writing code for the preferred case and stopping caring about the specifics of why something failed and just making sure it could be undone did wonders. Writing functions that took like one or two params and did the needful so I could .then them in a clear data transform pipeline was amazing.

    So, basically, when I started trying to write Erlang/Elixir in JS.

    And then I remembered that JS was fucking stupid and I should try to stick to languages that wouldn’t cause brain cancer.

    1. 4

      You probably care about the difference between a service failure and code errors when your server gets put into an unknowable state, and remains up.

      The thing is, with a different implementation like righto, you CAN only code the happy path, AND you get the the distinction, AND you can use err-back APIs, AND you can use promises. There are very few downsides.

      “Little late on that in JS, now aren’t we?” - lol