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

171–180 of 444 posts

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

#171

Post by nicoburns »

alskdjflaskjdhf wrote: post #111
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…

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

I've not used Svelte, but when I've used such DSLs the problem tends to be that they're not very flexible, and as soon as you step outside of the provided helpers you're stuck and you just can't do the thing.

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

#173

Post by sbergot »

alskdjflaskjdhf wrote: post #111
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…

>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 error messages, more surprising issues, etc. You need to understand the scoping mecanisms and if things go wrong hope there is a debug tool available.

And in the end those templating languages do not prevent you from mixing UI responsibilities from the rest of your code.

If you want a reactive model you can have one. I personally prefer explicit messages like calling setState.

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

#174

Post by bryanrasmussen »

onion2k wrote: post #130
bryanrasmussen wrote: post #45

Earlier quoted context omitted.

In my personal opinion when there is a lot of complicated state in a component and there is no real benefit to splitting it up into smaller components then hooks are inferior to the older lifecycle methods (in creating understandable, maintainable code), however in my experience whenever I come to place nowadays this would be considered heresy and everything needs to be in hooks even if you have 10+ and growing numbe…

hooks are inferior to the older lifecycle methods (in creating understandable, maintainable code) If the lifecycle methods you're referring to are things like componentWillReceiveProps or getDerivedStateFromProps then the React blog covers why they were problematic https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d... . It was very common for developers to make things that would repeatedly rerender when oth…

that a particular way of doing things was problematic for the community as a whole when measured across all usages does not invalidate the observation that there were some usages in which that particular way seemed better.

when, as I often encounter, organizations mandate all hooks all the time they are not throwing the baby out with the bathwater, but they are maybe throwing out the baby's rubber duckie without considering that might be useful to have around at times.

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

#175

Post by LAC-Tech »

stocknoob wrote: post #67
valtism wrote: post #63

I've used React for ~3 years, primarily with function components and hooks. I think that hooks were a wonderful addition and I think the framework has made smart choices with checking object equality to decided if components re-render. That said, I think that easily the most difficult aspects of react revolve around how re-renders are triggered. Maintaining referential equality to stop unnecessary renders gets tricky…

For the other Americans, “used xyz in anger” means “used xyz in production”. https://english.stackexchange.com/questions/30939/is-used-in...

Weird. I'm not British by I say "used xyz in anger" because I read lots of other programmers saying it. Had no idea it was regional, thought it was hacker lingo like "grok".

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

#176

Post by chrismorgan »

suction wrote: post #151
chrismorgan wrote: post #30

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. Once you deal with larger amounts of data and need virtualised rather than fully-materialised lists, you start using different things in React as well. The fact of…

What JS framework would you choose to work with big datasets like, e.g. a data grid with half a million rows that should have a "filter as you type" functionality?

Most of the work for this is essentially database tech rather than UI tech. From the UI perspective, you just need to be able to say things like “current query is ‘foo’, and based on my current scroll position I want to render records 32–86” (since 42–76 will be visible on screen, and then we add a few more for good measure to give a small time buffer for retrieving more when you start scrolling), ask the database layer for the required records, and render them as a perfectly normal virtualised/only-partially-materialised list. It’s then up to your database layer to perform the filtering; whether that database runs on the frontend or backend makes no difference, and whether it’s sqlite.js or records.filter(…).slice(…) makes no difference (though their performance characteristics will certainly vary). This can be integrated with the UI framework fairly tightly, but there’s no need for it to be.

For the UI part of it: what I would use would depend on my requirements (is it a list, is it a grid, how is it to be interacted with, &c.) and what was already in use (React, Svelte, plain JavaScript, other). I personally would often be inclined to implement it from scratch, because I’m typically not impressed with most library options (they have a tendency to be heavy, limited, and slower than they need to be) and am familiar with exactly what needs to go into it to make it as perfect as is possible (it’s not a particularly large amount of work, but it is fiddly in places and must be done correctly or it’ll be awful), but that’s not a course of action I would recommend for most developers.

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

#177

Post by leonardopainter »

This article points out how ridiculous React is. This is just a simple timer, yet there are so many things you can get wrong. This article doesn't seem to even clear the interval so it runs forever. Solid solves some problems, but I don't know why everything has to be reactive. I have never understood it, I just noticed that from knockoutjs onwards, every front-end framework was based on automatically updating views based on state.

I create a library at github.com/thebinarysearchtree/artwork. To be honest, I don't know if it is going to work or not. It is just javascript with no reactivity. When I rewrote a fairly typical large application that you would find at most corporations (not a giant tech company application), every component ended up being about 50% of the code of react, with excellent performance.

The problem I have with it that makes me uneasy is that ultimately you are creating content in JavaScript, which I don't think is ideal. The lack of HTML structure isn't a problem as devtools and so on show that. The problem is things like:

  const label = label('Email:');
I want the HTMLLabelElement variable to be called label... but that is the name of the function that creates it. Then there is the setText example on the github page... I just didn't want to write label.innerText.. h3.innerText... etc etc .innerText. Variadic arguments are not ideal though, and when you have lots of elements with lots of attributes, eg:

  const content = div({
    className: 'content',
    title: 'whatever',
    innerText: 'something'
  });
it doesn't look like art, which is the point of the library. It is just hard to create content with JavaScript and not really the tool for the job. If I could solve that, I would be very happy with the library. It kind of needs JSX, but then it is back to having the JSX variable auto-update the state and well.. I guess that is why knockout and so on do it. Maybe I could do just plain HTML without state.

So yeah, I don't know. I mean, it does end up being half the code. If you look at the todo example on my github page, and compare it to the one on React's homepage or solid's homepage, it is literally half the amount of code with native hand-written performance. This continues on to real-world components, it is just that.. I am a perfectionist I guess, and I want it to be elegant always.

anyway.. I haven't even finished writing the documentation.

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

#178

Post by LAC-Tech »

rk06 wrote: post #120
intrnl wrote: post #96

Earlier quoted context omitted.

i'm finding a hard time articulating what you said, if React is against side effects then useEffect wouldn't have existed and we wouldn't have data fetching. React is unique in that everything in the component is within the render path, while the rest of the frameworks (that you've mentioned) doesn't. you might be mistaking "side effects during render is bad" for "side effects is bad", the two statements are not the…

I mean side effects from a functional point of view. Let me explain in more details React’s philosophy is View = F(data) I.e. view is a pure function of data. By “pure”, we mean F() does not do console.log, ajax calls, date time and other stuff which is not consistent every where. This assumption is ingrained in React. You see it when you are told that react can overrender and your code should handle overrendering. A…

> React’s philosophy is View = F(data)

Yeah internal component state throws all of that out the window.

That's lit-htmls philosophy, not react. React is all about bundling the view and state and then marathon profiling sessions to figure out why everything is re-rendering all the time.

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

#179

Post by sbergot »

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…

Yes hooks are not great. They violate too many functional programming rules that the react team pretend to care about.

I still like using them however. I had a few issues when trying to do more abstract code.

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

#180

Post by sbergot »

t_tsonev wrote: post #99
AgentME wrote: post #73

Earlier quoted context omitted.

JSX doesn't have loops. When using React, you use regular not-React-specific Javascript tools to do loops and create lists of React elements.

If this is true, why do you need unique item keys? React cares about loops a lot more than it may seem at a first look.

keys are not specific to loops. They are needed whenever you are returning a react document with a dynamic structure. They allow for more fine grain dom updates.
Post reply on HN