Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Solid.js feels like what I always wanted React to be

typeofnan.dev

Post reply on HN
Print view View original

221–230 of 444 posts

Re: Solid.js feels like what I always wanted React to be

#221

Post by leonardopainter »

leonardopainter wrote: post #198
pjmlp wrote: post #184

Earlier quoted context omitted.

Easy, Java and .NET SSR frameworks (which support components for two decades now), + vanilaJS for Ajax like behaviours. Loads fast, easy to debug without tons of layers in the middle. And yes, I also do manually make use of script and vendor JS libraries. Naturally it only works when doing side gigs on my own, on big Web projects where my role is mostly BE/DevSecOps, I go with the flow.

That isn't a solution. Everybody moved away from this approach for web applications for good reasons.

Well, I think when they moved away, they also increased the complexity of their applications as well.

Re: Solid.js feels like what I always wanted React to be

#222

Post by ihateolives »

wonnage wrote: post #150
ihateolives wrote: post #132

Earlier quoted context omitted.

> Don't forget about having to pass key to each element in React. The simplicity of using map() is an illusion. That's one of the design decisions I don't fully understand. It knows that there should be a key there so why just not put it there silently and let me override it when I need, instead of screaming at me when I omit it.

The purpose is well-documented here: https://reactjs.org/docs/reconciliation.html#recursing-on-ch... And it also goes into why index is a poor key (it's basically the same behavior as with no key). Using object identity to detect inserts doesn't work either, because the map function is returning new React element objects on each render. Practically speaking if you know your items won't change, then omitting the key o…

I know, I've read it. I'm still not convinced. React could just as well generate and insert missing key on build instead of asking me to do this:

... you can add a new ID property to your model or hash some parts of the content to generate a key.

It is just plain wrong to ask me to change my data model because of this. This is part of the housekeeping that I expect the framework -- pardon, library -- to take care of for me.

Re: Solid.js feels like what I always wanted React to be

#223

Post by jimmont »

JoeyJoJoJr wrote: post #190
jimmont wrote: post #157

Earlier quoted context omitted.

This is about "feels like" and me too--the little newsletter popup and lack of substance shows this. React became obsolete over the past few years as browsers increasingly adopted the mix of web components features (eg componentDidMount vs connectedCallback). Just using React, and the explanations for why a technology is and isn't used in an organization speaks to the level of practical knowledge and detritus in proj…

That is a big call regarding web components. I did some looking into web components for a recent project and React is just way ahead in many areas. You could use a framework like Lit to help smooth things over, but that just speaks to the underlying standard being somewhat cumbersome to use. I totally want web components to succeed and be the new way of doing things, but I get the feeling that is still a while away.

Big call? I suppose there's a point where having done enough work in projects affords some perspective. Whenever anyone gets the feeling to do something else the docs will probably be there, as they were the past few years.

Re: Solid.js feels like what I always wanted React to be

#225

Post by jillesvangurp »

ohgodplsno wrote: post #114
jillesvangurp wrote: post #80

Earlier quoted context omitted.

I think for progress you need to look outside the js world. Fundamentally, people keep repeating the same mistakes there. I'm having a lot of fun lately using Kotlin-js for example. We use the Fritz2 framework, koin for dependency injection (popular on Android as well for good reasons), and fritz2 relies on kotlin's co-routines and StateFlow for state management. It makes for a surprisingly concise code base. For exa…

>GlobalScope.launch { ... } I can't begin to express how sad that makes me. Your component should have its own scope that it destroys when it gets destroyed, otherwise your coroutine leaks to the outside world when your component is gone from view.

Sure, but I wasn't going to fit a whole lot of boiler plate in a comment on HN to do that. Using Globalscope in a demo is perfectly valid; a lot of co-routine presentations do that as well. Normally, I'd use some named scope and life cycles associated with e.g. koin modules or a web worker. This is just something that I quickly knocked out that actually works. Also, this is not Android. There are not a whole lot of life cycle events beyond "page loaded".

Re: Solid.js feels like what I always wanted React to be

#226

Post by apatheticonion »

parentheses wrote: post #82

This article hits on something I've felt for a long time. The idea that "hooks are superior" to me is ridiculous. If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges! Solid is nice and _seems_ to fix the issues with hooks, but as another comment mentioned, the challenge is with building at scale…

After working with React for years it is something I would not recommend and can only think of limited use cases to use.

You can write really performant software in React, but ergonomic (beyond stockholm syndrome) I would not call it.

It's also difficult to implement quality software engineering principles in a React application such that an application is maintainable, glacable and easy for someone new to a project to pick up.

The flexibility in its toolchain is nice, however

Re: Solid.js feels like what I always wanted React to be

#227

Post by shrew »

sbergot wrote: post #173
alskdjflaskjdhf wrote: post #111

Earlier quoted context omitted.

>In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like that reinvents a concept that's already in the language. I find this a totally bizarre complaint. I've spent the past few months working on Svelte stuff and I've seen people on HN make this same complaint about Svelte's t…

Because you sometimes want to filter, sort or project your data. Then you have to handle this in viewmodels or invent more and more features for the templating language. Then you want to refactor into components. So you need facilities for invoking subcomponents. Maybe you want something recursive to display tree-like data. So you end up with a secondary full featured language usually with worse IDE support, worse er…

> Because you sometimes want to filter, sort or project your data.

The idea that this type of thing should be happening anywhere near the view rendering loop is the exact reason I've not had a great time picking up React codebases.

By the time you're rendering data into markup, the data should be in the exact state you need it. No further filtering or data mangling or sorting. That type of data manipulation should happen at the point of data change and then it shouldn't happen again until the data changes again.

The simplistic templating languages in Vue/Svelte/Alpine/whatever-comes-next force you to pull your data manipulation back to somewhere more appropriate, with Vue even throwing a warning if you try to filter within v-for construct.

Because React is JS, people are let loose to do wildly inefficient operations and do them over and over and over whenever _anything_ in that component changes.

Re: Solid.js feels like what I always wanted React to be

#228

Post by chriswarbo »

sbergot wrote: post #173
alskdjflaskjdhf wrote: post #111

Earlier quoted context omitted.

>In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like that reinvents a concept that's already in the language. I find this a totally bizarre complaint. I've spent the past few months working on Svelte stuff and I've seen people on HN make this same complaint about Svelte's t…

Because you sometimes want to filter, sort or project your data. Then you have to handle this in viewmodels or invent more and more features for the templating language. Then you want to refactor into components. So you need facilities for invoking subcomponents. Maybe you want something recursive to display tree-like data. So you end up with a secondary full featured language usually with worse IDE support, worse er…

> So you end up with a secondary full featured language usually with worse IDE support, worse error messages, more surprising issues, etc.

Gilad Bracha calls these "shadow worlds" https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.htm...

Re: Solid.js feels like what I always wanted React to be

#229

Post by tambourine_man »

lpghatguy wrote: post #13

New JS frameworks always make for compelling hello world examples. Can you branch on state or use loops over data in Solid.js? The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty! As an example of this point, check out the "Simple Todos" example for So…

>…much like traditional templating languages, we get a construct like that reinvents a concept that's already in the language.

I'm right there with you, but when React invents a whole markup language inside of JavaScript, it's not in much of a standing to make purity criticisms.

Re: Solid.js feels like what I always wanted React to be

#230

Post by prohobo »

I'm proficient with React hooks and functional components, but I will never bullshit anyone by pretending that they make any kind of intuitive sense.

Classes may have been more "code" but were clear to understand. I don't dispute that functional components are probably more efficient though.

Anyways, I've never had this problem with React hooks. I've been building complex dynamic UIs for years, and maybe I've grown to get around these kinds of things, but it seems like Solid.js is solving a niche problem at the cost of making hooks even less understandable?

Post reply on HN