5 ms·

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 featu

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.

ivan_gammel 3y ago
>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.
twiss 3y ago
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.
- Phillippe 3y ago
  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
bastawhiz 3y ago
> 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.
- ivanjermakov 3y ago
  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.
  - bastawhiz 3y ago
    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.
- imbnwa 3y ago
  > 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.
  - ivanjermakov 3y ago
    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/757746a915d186a909540814100982ba6905437a/src/jsx.d.ts#L69 https://github.com/preactjs/preact/blob/757746a915d186a90954...
  - bastawhiz 3y ago
    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.
    - imbnwa 3y ago
      Perhaps Svelte, Solid, React, et al should form a working group and hammer out an interopt standard

ivan_gammel 3y ago

>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.

twiss 3y ago

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.

Phillippe 3y ago
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

bastawhiz 3y ago

> 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.

ivanjermakov 3y ago
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.
- bastawhiz 3y ago
  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.
imbnwa 3y ago
> 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.
- ivanjermakov 3y ago
  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/757746a915d186a909540814100982ba6905437a/src/jsx.d.ts#L69 https://github.com/preactjs/preact/blob/757746a915d186a90954...
- bastawhiz 3y ago
  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.
  - imbnwa 3y ago
    Perhaps Svelte, Solid, React, et al should form a working group and hammer out an interopt standard