3 ms·

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

> 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

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