Hacker News Reader

As someone who has been using rx since 2014 (with a heavy heart) I must agree with you here. 9 out of 10 times there’s a simple, more boring way of solving the problem. I want boring in my life. Boring is good.

The idea that reading code is harder than writing it can take an extreme form with this style of coding imho.

(My other issue is that for me FRP style code, esp. with rx, is just so much fun to write.)

> It’s just that they produce some of the least intuitive code imaginable. The three horsemen of JavaScript have always been generators, RxJS, and Redux.

It took the author of RxJava months to understand the concepts. And he had the author of Rx.Net to explain them to him [1]

It's also strange is that what we realy want is Excel-like reativity. But instead we're always getting Rx-like reactivity.

[1] From his book: https://pbs.twimg.com/media/C0M-U1DXcAADTS3?format=jpg&name=...

A time ago I had a project where we had an intense tree-like data structure where at any given level there may be a finite async-stream. Basically recursively needed to await streams until they finished.

I was using for RxDB based on RxJS, so after a couple nights of banging my head I went into the RxJS chat and asked for help. One of the maintainers of the library who worked at MS said it was a perfect problem and I think I nerd-baited him into helping out...

... we ended up spending like a week on it going back and forth, and neither of us could figure it out. The code we ended up with was frightening.

I'm guessing Jafar is Jafar Husain, the original evangelist of Observables in JavaScript?

https://www.youtube.com/watch?v=lil4YCCXRYc

I don't think that the problem is that JavaScript may or may not have this feature, it's not even that the language is large and all-encompassing; it's that mixing and matching features is highly appealing and very rarely works out well in practice.

JavaScript is not really a single language built around a single specific style or set of needs any more. In this day and age it's an amalgamation of different techniques and styles. You've got classic inheritance and composition for your OOP crowd; you've got your map and reduce for your functional crowd; you've even got your observables for your reactive crowd.

This is all well and good, but I've found that it's hard to write some practical code that blends styles. At some point it's tempting to start adding types, generics and dependency management into a functional project, but it's my experience that this blending ends up getting in the way of itself. Similar story for wanting to do things like having a service that listens to queues in an async way with sync rest APIs. It seems like having a common set of middleware would make it easy to support both layers; however this is easier said than done. These things sort of work but it feels deeply unsatisfying, requiring constant switching between observable and async/await styles with error handling being a constant concern.

I tend to agree. Observables are incredibly powerful, so they seem like they _might_ be a good fit for some use cases where you're dealing with streams of events. And even then, you have to be really determined to not make a mess. For day-to-day event handling, they usually feel like overkill and become really difficult to understand. Like, I don't _want_ to use map, filter, etc to handle non-iterable stuff. It feels clever and cool on the surface but weird and brain-knot-inducing once you look more deeply at it.

The way they show off observables here is solves a lot of problems, but despite offering up Svelte as an example of observables, it doesn't seem to aim to solve the problem that Svelte stores do.

What I really want is a trivial way to say "fire this callback whenever this variable changes."

Mobx actually enables this w/o too much work, and Svelte stores are a really nice syntaxical wrapper around the concept.

Heck just give me what C# had back in 2002 and I'd be happy.

> fire this callback whenever this variable changes

Ouch, welcome to callback hell :(

Futures would be slightly better. The least painful approach to things like that. to my mind, is an explicit event loop, and posting events on a change.

Been there, helped design an entire embedded runtime based[1] around it, didn't mind it.

FWIW Eventing systems are not the same as callback hell. "Tell me when this variable changes" is the heart of a lot of really well engineered systems, including high performance hardware IO. (Fill this buffer w/o bothering the CPU, when the buffer is full, call this function to process its contents).

Eventing systems are nice.

> The least painful approach to things like that. to my mind, is an explicit event loop, and posting events on a change.

That is how Windows works under the covers.

Events are just syntactic sugar on top if that, in replacement of a giant switch/case statement.

[1]https://meanderingthoughts.hashnode.dev/cooperative-multitas...

My experience has been a total opposite. I've been able to deliver quite complex features in a couple of lines of vert readable code thanks Observables. Of course, you can write terrible code with it, but the same goes for every technology.

I think that this presentation from Netflix engineering team is still the best demonstration of how productive you can be wit RxJS: https://youtu.be/FAZJsxcykPs

Maybe it's because I work on embedded system where I only have to worry about a single process, but I find observables really ergonomic.

"If/else" are a core construct in programming languages. Observables add "when", which I think is just as essential. Whenever someone describes an autonomous system, they will use "when X, do Y". So it makes sense to me that code follows that.

A lot of the time I just want to write a piece of code that and plug it into the system without having to worry about coupling or its effect on other parts of the code. Most of the time I don't have clear requirements, and need to stay flexible.

For example, new requirement to turn off the LCD after X minutes of inactivity, and turn it back on when the user presses a button? I just create a new component (instanced based on a configuration flag), plug it into the event bus reacting to ButtonPress events, and call it a day, without having to worry about something else breaking, often without even having to read existing code (except how to get notified of the event).

Even when modifying existing code, it's easier to replace an event, easy to find which components are depending on that event, etc.

I dont think this should be considered controversial. This sounds like a well balanced opinion, and is for sure one I share.

JavaScript has many missing features. This is not one of them.

> It’s just that they produce some of the least intuitive code imaginable.

I agree because I have seen this a lot.

> JavaScript has many missing features. This is not one of them.

While I do agree that abusing Observable might leads to messy code, it's very valuable in highly interactive apps. It provides proper abstraction/algebra which letting you tackle problems like tripple click, which might be extremely tedious to solve otherwise.

And interactivity is one of the natrual thing modern browser should empower developer to achieve (at least for non-die-hard no-JS person).

> But we already have them via the ReadableStream and TransformStream APIs.

I do appreciate that you appreciate simplicity and this sentiment in general. But I feel similar sentiments that led JavaScript to stagnent for a long time (ES6 is just ES4 but more than a decade later).

People like Douglas Crockford found the parity in JavaScript and Lisp, and summarized the beauty in his works. While his book is one of my favorite programming book, the sentiment (JavaScript don't need features because of closure, Lisp-like and all that) was so popular at time, which probably contributes to the stagnant.

(Microsoft and friends was probably happy about this that the web wasn't taking over so fast and they can shit everybody with IE6 for years, and then the mobile and their walled gardens were taking over. In other word, the web had even greater potential in between IE6 and mobile era)

People could really try re-implement their React apps without modern tooling to feel the pain: No ES6 module and abuse closure then cat the all files into one giant ball, only to mess up the order and dependencies. Or without reactivity, updating states everywhere which leads to confusing bugs that making apps out of sync., etc

> The three horsemen of unmaintainable JavaScript have always been generators, RxJS, and Redux.

Redux produces the easiest to follow code when following best practices. It’s boring and works extremely well for its purpose.

Generators may get a bad wrap but async/await are just generators with a different syntax — at least in js land. Would you argue the same for async/await?

I’ve seen this comparison to async/await a few times and I’m not sure how accurate it actually is. It’s true that async functions can be polyfilled via generators, but from what I understand that’s more of a conceptual transpilation by tools like Babel, rather than a runtime implementation.

IMO the `await` keyword is clever abstraction that can make asynchronous code easier to understand in a synchronous way. And unlike the collection-oriented ceremony of generators, calling await on an expression doesn’t imply anything more than the presence of a `then` method on an object.

Anything with a `then` method can be awaited, and so native Promises aren’t actually all the special or sacred. Invoking await on an expression involves no extra machinery, only that a Promise-like object is returned.

And the `async` keyword is even better. It’s completely optional! This keyword only has two effects: allowing the `await` keyword in a function scope, and implicitly returning a promise.

There’s a secret pleasure in all this too. A series of awaited Promises can be wrapped into a single async function. And there’s no need for multiple error checking steps either. All async functions return a promise, so we can wrap the function single try/catch block, or even daisy-chain another promise on the `catch` method. All the pieces fit into each other, and most of them are optional.

Meanwhile in generator land, we’ve got cognitive overload in spades. Yield can only be called from inside a generator, yes that little asterisk next to the function name you might at first glance mistake for an errant multiplication symbol. Sorry, there’s these things called Symbols too. Any object can be made yieldable…or was it iterable…by placing the special symbol on an object class as an interpolated method which returns an iterable. I’m not making this up.

Imagine teaching this to a junior developer who’s spent over a year programming asynchronous code and never once needing a generator. The tide-level for problems solved with generators is always waist-deep, always introduced as a secondary step to achieving another goal.

Generators are almost always hints of a design-flaw introduced much earlier in development, usually by an engineer with enough experience to write code, but not nearly enough to understand how it works.

I agree with your point. On

> Anything with a `then` method can be awaited, and so native Promises aren’t actually all the special or sacred. Invoking await on an expression involves no extra machinery, only that a Promise-like object is returned.

note that _anything_ can be awaited in JS.

``` const x = await null; console.log(x) ```

Huh wow! I did not know that! I think TypeScript always kept this hidden from me, but it makes sense. Another perk of `await` is that it collapses all promises into their final value, regardless of how many nested pending promises are expressed:

  const foo = await Promise.resolve(Promise.resolve("abc"))

  console.log(foo.length) // 3

It's not `await` which is doing that; it's the Promises themselves. For example:

   Promise.resolve(Promise.resolve("abc")).then(console.log)

This will print `"abc"`, not `Promise.resolve("abc")`.

What’s wrong with generators?

Nothing other than they're one of the more esoteric and misunderstood features of the language.

It’s a great question, and for the folks who knows the answer of why generators misunderstood, they surely discovered this feature in the most unpleasant circumstances.

Generators were introduced during JavaScript’s awkward adolescence, where the cutting edge of ES6 was only possible through Babel (which was then called 6to5). They’re fantastic for turning array like classes into iterable collections. But that’s not what makes them bad.

For a time you had a perfect storm of JavaScript Hell. Promises were polyfilled and rewritten as generators to take advantage of the `yield` keyword. You’ll most likely find out about this trick at the least opportune time: while debugging an async redux action. Now every single stack trace is a high-stakes game of “detangle the Christmas lights!

This was truly a horrible time to be a front end developer. Not only did you have to transpile your code, you had to debug it through a source map wrung through Webpack’s module system. And while you’re picking through this mud ball of a web app, there’s a Super Senior Software Engineer giving a talk on the virtues of observable data management!

I’ve always suspected that these galaxy brain engineers are more like window washers on an ivory tower. And as for the rest of us, we’re just the code gnomes who are shrug when given triangular bricks until told how round bricks are actually better.

I know this is all hyperbole but the emotion is real. For every productive hour of work gained through a new and necessary features, engineers have lost 10-fold on the lesser well-thought out JavaScript. I’m not so sure that native observables will be any different.

I get asked this question a lot — I help maintain redux-saga.

I recently gave a talk where this question came up: https://youtu.be/uRbqLGj_6mI?t=2166

I’ve also imposed generators on a lot of colleagues.

I think they are mostly misunderstood and potentially in the realm of being “magical” — at least on the surface.

The reality is they are syntactic sugar on top of functions with recursive switch statements where each case is a yield point.

They aren’t that hard to grok — the syntax is mind bending. Having code that looks synchronous but behaves asynchronous is “magical.”

I think it does come down to that because everyone loves async/await even tho that’s just sugar on generators where each yield must be a promise.

And then there's async generators...

Personally, I love redux-saga. It took me a little while to wrap my head around it (but 1/10th the amount of time as RxJS), but it is _really_ nice to be able to write complex async logic in synchronous-looking code that's also readable. (At least it was readable for me and the people on my team.) Whenever I had some weird async coordination problem that I needed to solve, I was _always_ able to solve it with redux-saga. I wish more people would use it.

I feel the same way which is why I decided to help maintain the project. Async flow control is very tricky even in js–land. Having watchers live inside of a while-loop is a powerful construct that lends itself to interest flow control patterns.

I'm also in the process of rebuilding redux-saga but without the redux part: https://github.com/neurosnap/starfx

It's still in alpha stage, but it is very reminiscent of redux-saga.

Is this an issue with observables or an issue with RxJS allowing you to shoot yourself in the foot?

A saner API (as shown in the proposal) has some obvious benefits in handling certain use cases without necessarily devolving into the crazy streams one sees with RxJS.

I've never understood why redux gets implemented so badly... I feel that the folks who build wacky redux implementations would still write spaghetti managing state without redux.

The biggest issue is that for the first few years there was no single standardized way to write Redux code. Everyone came up with their own patterns, and wrote their own helper libraries. It also required a lot of "boilerplate" code for things like defining action type strings, action creator functions, and hand-written immutable updates.

That's why we published our official Redux Toolkit package in 2019. It standardizes Redux usage, and includes methods that build in our recommended approaches for things like store setup, writing reducers, simpler immutable updates with Immer, and even a complete server data fetching and caching solution called RTK Query:

- https://redux.js.org/introduction/why-rtk-is-redux-today

- https://redux.js.org/tutorials/essentials/part-2-app-structu...

We routinely get highly positive feedback from folks who hated writing old-style Redux, but love using RTK.

Related, we also have a "Style Guide" docs page that provides guidance on what approaches we recommend using when writing Redux code:

- https://redux.js.org/style-guide/

Having used RTK and RTKQ, I cannot believe they come from the same authors. RTK is mostly serviceable, though for most projects, not using Redux is better. I’ve never seen a case when RTKQ was an improvement over fetch().

Obviously, deleting Redux from the internet to prevent incompetent engineering leads / managers from forcing it on people would be preferable.

If you can't understand the benefits of using RTK Query over fetch I'm not sure you're credible.

They're not even substitutes; RTK Query by default wraps fetch or can be configured to use your preferred http client. So it's an entirely additional layer of cacheing and refetching logic with a standardized interface around common loading and error states.

It is considerably easier to write performant web applications with a library like RTK Query or TanStack Query than to just use fetch and try to roll your own cacheing solution. I say this as someone who has done all of the above professionally.

In my experience it was due to backend devs (like myself) being asked to or volunteering for some front end projects. At least that is how our current frontend turned into a redux mess and is currently being rewritten.

It is a completely different skillset and I think more often than not people assume that they can write front end code just because they know Javascript.

Redux is very straightforward until you start adding middleware, then the complexities start piling up.

I am a nuts and bolts Python programmer. What the heck even is this?