Hacker News Reader

Comment by ivanjermakov | Hacker News Reader

Is dependency tracking problem statically solvable (without calling effect once and subscribing to all .get's)?

I don't think this needs to be a language feature, rather abstraction of existing features. In other words, can't this be a library?

I know that SolidJS is able to figure out dependent signals, but probably doing so on the first execution.

View on HN

I believe Svelte does figure it out at build time.

Which does make me question the mention of Svelte in the proposal, and makes me wonder what the Svelte developers think of it - because IIUC they indeed don't need this (at runtime), if I'm not mistaken.

The current Svelte version does it at build/compile time. The up and coming Svelte 5 is using signals and the reactivity is moved to runtime

> In other words, can't this be a library?

You answered your own question:

> I know that SolidJS is able to

It already is, obviously. But how is SolidJS supposed to work with other non-SolidJS code? It can't. Unless every library builds support for every other library, they can't possibly interoperate.

It's a shame that JS ecosystem is so sparse.

E.g. in Rust it's much more common to rely on existing "building blocks" like futures, tokio, syn, serde even just for basic bindings, favoring interoperability.

I think you've got it backwards. Fifteen years ago we had jQuery and not a whole lot else. Everyone just used the "building blocks" libraries of js. But then the community and the ecosystem grew exponentially, and we have innumerable choices. Python is similar: I can think of a half dozen ways off the top of my head to build a web app. At least Python was on top of standardizing things like WSGI, but even then you can see rough edges like the non-interoperable nature of concurrent code (twisted vs tornado vs greenlets vs threading vs multiprocessing vs asyncio etc).

Rust will have the same thing happen in another decade or so. It's prevalence will grow the community, which will grow the ecosystem, and the positive feedback loop will mean that there's a huge amount of choice. That's a good thing, but it will have downsides, like decreased interoperability (unless the language evolves). JavaScript was cursed for a very long time by leadership that was essentially asleep at the wheel.

> It already is, obviously. But how is SolidJS supposed to work with other non-SolidJS code?

Who actually writes code like this? People use some signal graph library for application code typically, I’ve never seen anyone mixing SolidJs with MobX in application code or as a consequence of a library dep.

Those who want to develop a library that can be used by any other reactive framework. I often see SignalLike<T> type that tries to subtype it.

https://github.com/preactjs/preact/blob/757746a915d186a90954...

Let me offer you a scenario: you want to build a UI web component that uses state, but you want it to be usable in both Svelte and React (with solidjs). The current situation is that it's a massive pain in the ass, because you have to move all of the state out of your code into a "driver" module that you can swap out for each of the frameworks you want to target. The entire architecture of your library is made worse (less readable/maintainable, probably less performant, harder to contribute to) in order to have a single set of UI code.

All of that goes away when the plumbing for handling state is standardized by the runtime.

Perhaps Svelte, Solid, React, et al should form a working group and hammer out an interopt standard

>In other words, can't this be a library?

It is explicitly mentioned in the proposal. The problem with 3rd party libraries is their interoperability and diversity of implementations, which might be unnecessary for this kind of things.

Reply on news.ycombinator.com