Live data from Hacker News

Solid – A declarative JavaScript library for building user interfaces

github.com

161–170 of 178 posts

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

#161
post #136

Earlier quoted context omitted.

why do you consider Hooks a "workaround around [React's] initial concepts"?

I think Hooks are genius truthfully. But they are definitely shoehorning something into a place that didn't expect it. You are calling these render functions with the purpose of creating new transformations every cycle, and the injection mechanism has to include the initialization the first time. So you basically have these slotted things that allocate memory every time to just use what's cached most of the time. Now…

thanks for the explanation! though i have to say i only have a vague idea of "fine-grained reactivity", any pointers for reading about this or systems that work this way?

in particular, i don't quite get this bit:

> By comparison the mechanism they ape (fine grained reactivity) works exactly the opposite way. You just need to be aware the stuff outside doesn't update.

inside/outside of what?

PS. my yet undeveloped pet theory is that hooks are (somehow) something like half a monad/algebraic-effect-thingy... though they're probably too tied up with the render cycle to analyze them this way

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

#162
post #161

Earlier quoted context omitted.

I think Hooks are genius truthfully. But they are definitely shoehorning something into a place that didn't expect it. You are calling these render functions with the purpose of creating new transformations every cycle, and the injection mechanism has to include the initialization the first time. So you basically have these slotted things that allocate memory every time to just use what's cached most of the time. Now…

thanks for the explanation! though i have to say i only have a vague idea of "fine-grained reactivity", any pointers for reading about this or systems that work this way? in particular, i don't quite get this bit: > By comparison the mechanism they ape (fine grained reactivity) works exactly the opposite way. You just need to be aware the stuff outside doesn't update. inside/outside of what? PS. my yet undeveloped pe…

I have the article for you: https://indepth.dev/finding-fine-grained-reactive-programmin... It's a bit dense at times but I try my best to cover the whole spectrum and how it relates to familiar libraries.

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

#163
post #41

Earlier quoted context omitted.

People loved React because it solved a problem. They just happened to solve it using virtual DOM. but theses next generation frameworks are showing that there's a better way to solve the same problem.

VirtualDOM allowed you to update the dom with better performance than before. Is there now a better technique? Why is it better than VirtualDOM?

[deleted]

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

#164
post #121

I've been playing around with your library for the last hour and so far it's excellent, pretty what I had hoped for after working with React for a while. The performance of individual renders is one area of improvement but I think the main contribution is the clarity the update model provides. React works well until you try to avoid re-rendering and then it really falls appart. For example, updating a context re-rend…

I do return a proxy. It's just readonly. I really like the unidirectional data flow and explicit read write segregation of react. This adds so much control without having to add Framework like control mechanisms. I know it isn't easy, but it something that makes the solution elegant in the end. I think that passing data should also mean the choice of passing the ability to update it. That is a problem I have with alm…

The ability to update a value from the child, Swift UI does this... I really like that

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

#165
post #112

Earlier quoted context omitted.

My 2c of insight: I found Svelte's docs & examples greatly sweetened the on-boarding. While I presume writing specs is a boring collateral, a friendly / bitesized / WISYWYG documentation would make a world of difference for the enthusiastic but less-than-ninjas of us. The smarter kids can catch up faster, and some might not bother, already do react/vue. I personally found with Svelte a way tamer learning curve.

I agree. I would love to do more. The truth is there is just so much to do. It's hard to find a balance between writing cleaner docs and say solving Async Hydration with Suspended Components. I had the luxury early on to prioritize the latter which is why Solid is so feature rich given how much of it needed to be researched and built from scratch. I always knew it would catch up with me. But that's a good problem to…

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'!

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

#166
post #20

Earlier quoted context omitted.

Dude, just let him have his fun and stop with the needless negativity. You don't know what the future holds and being rude for the sake of being rude, says quite a bit about you as a person.

I don't think I was being rude in any way. I agree that it is fun. But then its a slim chance that its going to be widely adopted. how come bringing that up is rude?

> If your library/framework/etc's goal is to make life slightly better, just don't do it.

> is fun and beneficial for the individual. YOu just have higher chances of staring a unicorn co, than creating a js library that is widely adopted.

OK, but this thing scored like 600 extra stars in 1 day. And already has over 2K stars. I get you're discounting that. But people like it and are using it. Some dude worked years on it. And you try to trivialize all of that positivity by saying well it's just fun for an individual, as if it's nothing more than fun, as if all the other people who like it don't matter. Which is a lie. He's made something that's more than just him. Something people like. And you're giving the advice, "Oh, all that you did, just don't." as if you're so much smarter than this guy who has created this amazing thing. And, yeah, I get you're dismissing that because it's not "as big as" whatever.

Sure, you're right from your perspective. But how useful is your perspective? And...holding that perspective, how can you really appreciate this work?

You dream of building something better than what is. In some area. Eng dreams. We can all relate.

In the framework space, does any tool really have all the answers? No. Improvements can be made. So make them. Totally good thing to do.

Seems you think you don't have a useful comment to offer, so you just land mean criticism. You know it's mean. That's your point. You feel low, then on HN and see this library written by this dude, get angry and unleash on here. Sure, you feel better for a time, but you hurt other people.

Yeah, I get that putting yourself above this work, and this guy, and dismissing and trivializing the guy and the work, makes you feel better, by comparison. But that's just about what you need to believe, in the moment, to feel good, as a result of whatever situation you're in. It's not about this guy, and it's not about the reality for people using it.

I don't know Ryan, but I've faced this sort of comments from the internet before. It hurts. It gets in the way. It makes you, the commenter, come across as...some sort of inhuman troll. Which of course, you're not!

I'm not trying to change your mind. I get the pain you're feeling to want to say stuff like that. Just trying to point out that what you're doing is bad. For you, and others. Yeah, I guess that's your point, but people can choose different things.

The way I see it, apart from being bad for trying to hurt others, being cruel like this is a huge disservice to you. That's my appeal to you.

I'm trying to read beyond the meanness in your comments to see your actual thoughts on this. And I think they're valid. Actually I want to know about your criticism of the eng landscape and what you think. But when you land this cruel hit, but leave off explaining how you actually think, you let everyone down. Including yourself. Because you do have something interesting to say. what you offer is not just meanness. I genuinely believe that. Don't care if you don't.

What you did this time, is not great. Plus it's bad karma for you. Hopefully next time you only comment on someone's work if you make kind comments and share your true perspective. That would be valuable! Hope you have a good one :)

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

#167
post #127

Is it possible to use Solid with just plain JavaScript/TypeScript (like using createElement with React)? I generally find those far more readable than JSX (and is one of the reasons I think SwiftUI and Flutter code looks nicer than React).

It sounds to me that you are looking for Webscript: https://mudgen.github.io/webscript/docs/ Webscript does work with SolidJS nicely.

Probably should have specified, but a big ting I'm looking for is sull TypeScript support in this regard.

Webscript looks really cool, but it doesn't look very TypeScript-friendly.

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

#168

Is there dedicated DevTools support for Solid like there is for React, Vue, Svelte, and co.? If not, is there a convenient way to inspect state, props, and the component hierarchy?

This seems like a silly issue. At one time there was no DevTool support for any of those other tools you mentioned.

This is not a silly issue.

Lack of devtools is expected for a new framework, however, it is worth asking for, especially if you are considering it for production

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

#169
post #165

Earlier quoted context omitted.

I agree. I would love to do more. The truth is there is just so much to do. It's hard to find a balance between writing cleaner docs and say solving Async Hydration with Suspended Components. I had the luxury early on to prioritize the latter which is why Solid is so feature rich given how much of it needed to be researched and built from scratch. I always knew it would catch up with me. But that's a good problem to…

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?

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

#170

Is it possible to use Solid with just plain JavaScript/TypeScript (like using createElement with React)? I generally find those far more readable than JSX (and is one of the reasons I think SwiftUI and Flutter code looks nicer than React).

You can use HyperScript(createElement) version. You just forgo the advantages of compilation - better dx(less need for explicit wrapping), better performance(optimized code path), and smaller bundle size (more directed code).

Solid's JSX does not compile to HyperScript like React. HyperScript is a different slightly de-optimized experience.

Post reply on HN