Live data from Hacker News

Solid – A declarative JavaScript library for building user interfaces

github.com

171–178 of 178 posts

Re: Solid – A declarative JavaScript library for building user interfaces

#171
post #165

Earlier quoted context omitted.

Clear Docs is important because they say we spend 1x developing a product and 10x marketing it. In the developer experience world, docs are marketing. Also, polished product and polished code deserve a polished set of docs. Just sayin'!

Volunteering?

Ahahaha I know it sounds like that. But I realize what a massive task that would be. Am I volunteering? No. I appreciate your invite.. I'll email you if I change my mind.

I think a cool thing would be if the docs site was made in it. Self documenting.

Re: Solid – A declarative JavaScript library for building user interfaces

#172

Earlier quoted context omitted.

It's a dumb example, animated lists transition are kind of a good go to... https://svelte.dev/tutorial/animate as is https://dev.to/buhrmi/svelte-component-transitions-5ie

Yeah I guess I mean more I don't understand what it takes mechanically to support those types of transitions. It makes sense to me but I also feel like there would be a lot of details in a generalizable solution. Super interesting though.

I think that's exactly right. it ends up being a LOT of super specific, fragile code --- so kind of interersting thought to see if you can make them elegant/easy/emergent in the library/framework itself.

Re: Solid – A declarative JavaScript library for building user interfaces

#173

Solid looks like Surplus.js mix react.js

Yep more or less. I was working with Adam, Surplus' author, for a bit before he didn't have time to work on the project further. I've take a different tact now with the reactive system and improved the rendering technique a bit. But he definitely deserves the credit for pioneering the JSX approach 4 years ago now. My initial JSX work was generalizing it for other reactive libraries and then it just grew to this.

I see Solid uses proxy to 'get' and 'notice update' the state. This seems providing a better DX than s-js. However, Solid require developer to explicitly use 'react style/hook' to update the state.

Why not also use proxy to 'set' and 'notice update' on the state?

Re: Solid – A declarative JavaScript library for building user interfaces

#176
post #174

@ryansolid What minimum browser versions does the library support

As is probably evergreen browsers to use all features. I use proxies which are notoriously hard to polyfill. It is possible to avoid them but I was not taking IE in mind after that. So while possible to support older browsers with Babel unclear what all the polyfills that would be necessary.

Re: Solid – A declarative JavaScript library for building user interfaces

#177

Earlier quoted context omitted.

Yep more or less. I was working with Adam, Surplus' author, for a bit before he didn't have time to work on the project further. I've take a different tact now with the reactive system and improved the rendering technique a bit. But he definitely deserves the credit for pioneering the JSX approach 4 years ago now. My initial JSX work was generalizing it for other reactive libraries and then it just grew to this.

I see Solid uses proxy to 'get' and 'notice update' the state. This seems providing a better DX than s-js. However, Solid require developer to explicitly use 'react style/hook' to update the state. Why not also use proxy to 'set' and 'notice update' on the state?

I'm big on read/write segregation and explicit mutation. With simple signals you have this naturally. Once you move to a nested tree you can lose this. Keeping this control allows us to adopt immutability patterns and enforce unidirectional flow. To me this is the most sane way to deal complex reactivity.

Re: Solid – A declarative JavaScript library for building user interfaces

#178

Earlier quoted context omitted.

I see Solid uses proxy to 'get' and 'notice update' the state. This seems providing a better DX than s-js. However, Solid require developer to explicitly use 'react style/hook' to update the state. Why not also use proxy to 'set' and 'notice update' on the state?

I'm big on read/write segregation and explicit mutation. With simple signals you have this naturally. Once you move to a nested tree you can lose this. Keeping this control allows us to adopt immutability patterns and enforce unidirectional flow. To me this is the most sane way to deal complex reactivity.

I agree, then the way to read and update state with dependency tracing in solid seems meeting the sweet spot of the s-js and elm/react style.
Post reply on HN