[HN Gopher] Observable API Proposal
___________________________________________________________________
Observable API Proposal
Author : tosh
Score : 84 points
Date : 2023-07-28 16:39 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| earthboundkid wrote:
| Shouldn't this just be like a two line utility function to turn a
| addEventListner call into an async iterable?
| noelwelsh wrote:
| I only skimmed the document but I didn't see any mention of
| glitches. If this hasn't been addressed I'm worried there hasn't
| been sufficient thought about the semantics of Observables.
| Glitches, and avoiding them in push systems, is addressed in
| Flapjax (2009): https://www.flapjax-lang.org/publications/
|
| 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.
| sippeangelo wrote:
| What are Glitches?
| noelwelsh wrote:
| Glitches are transient incorrect values due to delays in
| propagating values. Imagine a diamond pattern of reactive
| values like: a = 0, 1, 2, ... b = a
| c = a d = b + c
|
| d should be 0, 2, 4, ... but if, say, b updates and d sees
| this update before c updates then you can get incorrect
| values in d.
| aatd86 wrote:
| Quite interesting. How does one resolve this?
|
| Naive me would have d observe a and recalculate its value
| by rexomputing 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?
| mappu wrote:
| If b, c, and d were lazily evaluated (pull-based) you
| would also avoid this issue,
| _greim_ wrote:
| Why not have it return an async iterable, which has both push and
| pull semantics? Combined with the iterable helpers proposal you'd
| get a lot of things for free, including end-to-end backpressure.
| jwilber wrote:
| Would absolutely love this.
| pwdisswordfishc wrote:
| How does it differ from <https://github.com/tc39/proposal-
| observable/>?
| TeffenEllis wrote:
| Controversial but brave take: I think adding this to JavaScript
| is a bad idea. It's not that observables are inherently bad. It's
| just that they produce some of the least intuitive code
| imaginable. I've never seen a codebase with observables where I
| didn't question the engineering team's technical motivations. The
| three horsemen of unmaintainable JavaScript have always been
| generators, RxJS, and Redux.
|
| 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.
| valcron1000 wrote:
| 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
| andreidd wrote:
| What's wrong with generators?
| _greim_ wrote:
| Nothing other than they're one of the more esoteric and
| misunderstood features of the language.
| troupo wrote:
| > 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=...
| bsimpson wrote:
| I'm guessing Jafar is Jafar Husain, the original evangelist
| of Observables in JavaScript?
|
| https://www.youtube.com/watch?v=lil4YCCXRYc
| nwienert wrote:
| 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.
| rpastuszak wrote:
| 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.)
| qudat wrote:
| > 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?
| revel wrote:
| 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.
| nerdponx wrote:
| I am a nuts and bolts Python programmer. What the heck even is
| this?
| wesleytodd wrote:
| 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.
| dimal wrote:
| 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.
| nraf wrote:
| 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.
| nosefurhairdo wrote:
| 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.
| acemarke wrote:
| 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/
| tl wrote:
| 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.
| makestuff wrote:
| 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.
| _greim_ wrote:
| Redux is very straightforward until you start adding
| middleware, then the complexities start piling up.
| Alifatisk wrote:
| I like this!
| pictur wrote:
| What exactly will this benefit from?
| bpierre wrote:
| Some context about the current status:
| https://twitter.com/domfarolino/status/1684921351004430336
| Eduard wrote:
| which programming language and / or platform ? Is it too obvious
| to mention it?
| frankfrank13 wrote:
| ecmascript I have to assume
| bsimpson wrote:
| TC39 (the JS standards body) and WHATWG (the web standards
| body) have been ping-ponging this back and forth between one
| another.
|
| 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?"
| badlucklottery wrote:
| > "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.
___________________________________________________________________
(page generated 2023-07-28 23:01 UTC)