Observable API Proposal
github.com
github.com
I can’t quite find an accurate metaphor to describe my experience with these data design patterns, but the first that comes to mind is “Hollywood accounting.” It’s always the same hat trick. Take a straightforward task of single directional data flow and subdivide it up into a Haskellian map/reduce game of musical chairs.
Don’t get me wrong, I understand the importance of having observability in data streams. But we already have them via the ReadableStream and TransformStream APIs. Combined with native proxies and we’re just about covered on the use-cases described in the examples section.
I’m also suspect of the lack of insight in this explainer on why the two previous proposals were rejected. We need more concrete evidence of why an additional API should be the answer to the question of whether there are too many competing observable frameworks. This isn’t a jQuery or Bluebird Promises scenario where the observerable paradigm is so entrenched in contemporary engineering, or even that a sizable amount of software development would require a third-party library to fill in the gap.
JavaScript has many missing features. This is not one of them.
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=...
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.
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:
Obviously, deleting Redux from the internet to prevent incompetent engineering leads / managers from forcing it on people would be preferable.
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.
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.
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.
JavaScript has many missing features. This is not one of them.
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.)
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.
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 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.
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.
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
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?
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.
> 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) ```
const foo = await Promise.resolve(Promise.resolve("abc"))
console.log(foo.length) // 3 Promise.resolve(Promise.resolve("abc")).then(console.log)
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.
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.
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...
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
"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 also don't see why this needs to be part of Javascript when it can be adequately implemented in a library. Today's great idea is tomorrow's legacy.
a = 0, 1, 2, ...
b = a
c = a
d = b + c
Naive me would have d observe a and recalculate its value by recomputing b and c then.
Other naive but complexity indulging me would store a dependency graph and use this graph to determine when one should wait for a value to update.
Surely there must be an easier way?
I have a somewhat small implementation that transparently batches updates with queueMicrotask in this library (bruh): https://github.com/Technical-Source/bruh/blob/a829af9df9405b...
Another way to deal with it is explicitly not dealing with it, eg. saying it is only (inconsistent) UI and will go away in a millisec…
I believe WHATWG is being favored so Observables will have a "killer app" (events) and could hence be built into the platform. As I recall, there was friction in TC39 to the effect of "RxJS exists. Why bother specifying this in the language?"
And, honestly, that's a great point. It's even easy to wrap EventTargets: fromEvent(target, 'eventName').
For the record: I'm a big fan of RxJS and have used it in production client-side code for several years. But even I'm not hot on this proposal to build it into the language.