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

131–140 of 444 posts

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

#131

Post by ryansolid »

alephnan wrote: post #128

As part of my annual routine, I'm exploring the "latest and greatest" JavaScript UI library. Solid.js's performance seemed compelling. 15 minutes into documentation and this is what I encountered. Can you guess which one of the ChildComponent* updates when the text input on the parent component is updated, and the props passed to the child? export default function ParentComponent() { const [value, setValue] = createS…

Or Vue either to be fair. Similar rules in the Vue's setup function. It's how reactivity works in JavaScript. Basically don't destructure or access values out of of primitives or JSX. That's basically the gotcha.

Unfortunately it's the price you pay for portability thus far. You can build your own language around this like Svelte but then composability is limited (need to rely on other mechanisms). You can make the updates coarser grained like React but then you need a different mechanism(like VDOM diffing) to apply updates granularly. I imagine this situation improves in the future but we haven't gotten there yet.

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

#132

Post by ihateolives »

benatkin wrote: post #105
riwsky wrote: post #37

Earlier quoted context omitted.

React lets you build DOM with normal JavaScript loops and .map; solid requires its own For element. How do you define “does not fight against js”? Because the above feels likes solid fighting against js.

Don't forget about having to pass key to each element in React. The simplicity of using map() is an illusion. SolidJS splits it between and . is equivalent to passing the object as the key and is equivalent to passing the index as the key. https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_index

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

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

#133

Post by fuzzy2 »

Slightly OT: I’m always amused coming to discussions like this one, where people are (basically) complaining about the Virtual DOM and its implications. It’s bad for performance at scale, updates aren’t minimal. And other stuff: SFC are hard to wrap your head around, I don’t want to write explicitly reactive code and so on. Some framework solves this by looking (somewhat) like React but in the end doing something entirely different.

May I interest you in Angular? It certainly isn’t cool and I really do hate it. But especially since the AoT compiler has been implemented, performance is quite good. There’s templates, which some folks seem to love. Angular keeps in-memory references to all dynamic elements in a template so they can be updated with high efficiency. It has class components. It has a lifecycle method that is called OnInit. So maybe give it a whirl.

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

#134

Post by [deleted] »

preommr wrote: post #10

I swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale. react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sug…

[deleted]

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

#135

Post by yulaow »

TekMol wrote: post #68

What feels like complete insanity when it comes to React is that it needs compilation to work: render() { return The count is: {this.state.count} ; } This is not Javascript and it will need to be compiled into Javascript before it gets executed. But you can do the same in Javascript: render() { return ` The count is: ${this.state.count} `; } Using regular Javascript makes my life a thousand times easier than having t…

Doesn't that make an hard life for the linter that now has to decide which template string represents a (complete) element and which is just text/whatever? I prefer the first solution because it's much simpler to parse

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

#136

Post by ryansolid »

alskdjflaskjdhf wrote: post #124
ryansolid wrote: post #89

Earlier quoted context omitted.

What does a reusable (ie import from another file) `useAutoCounter` look like in Svelte?

Probably the equivalent would be a custom store, something like this: import { writable } from "svelte/store"; function autoCounter(interval, initialValue = 0) { let { subscribe, update } = writable(initialValue); setInterval(() => update((n) => n + 1), interval); return { subscribe } } let counter = autoCounter(1000); The count is: {$counter}

Yep. Looks sort of like the Solid example in the article. It's basically my auto-response to Svelte syntax. Once you do anything in Svelte it is more or less the same thing.

Just different priorities. In Solid you can take that code as is in the component and hoist it out to a function above and presto.. store. It's all the same thing everywhere. Same patterns, same usage, same building blocks. No new APIs, no new syntax.

It is nice when first learning not to worry about Svelte Stores and use the convenient syntax. It is also nice to learn something once and use it everywhere.

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

#137

Post by peferron »

riwsky wrote: post #37
rk06 wrote: post #20

Earlier quoted context omitted.

The thing is that While react is against side effects, javascript is not. Which result in these impedance mismatch where what devs want is against react itself. Vue/svelte/solid do not fight against js, hence they do not end up in similar situation

React lets you build DOM with normal JavaScript loops and .map; solid requires its own For element. How do you define “does not fight against js”? Because the above feels likes solid fighting against js.

Fully agree.

With React, "plain JS" works just like I expect it to. If I have an event handler that does `x = foo` then I don't expect my component to re-render. Why should it? I'm just changing the value of a local variable. If I want to re-render, there's no way to express that in plain JS, so I'll use React's API and write `setX(foo)` instead. Now it's clear that it's not just changing the value of a local variable, but using React's API to do something else.

With Svelte, writing `x = foo` doesn't just change the value of a local variable. Maybe it's going to run a bunch of magic to update a piece of the DOM instead. Or maybe I need to prefix it with `$: ` which in plain JS is a label for a continue or break statement, but here doesn't mean that at all and means reactivity instead.

Oh, and to conditionally render an element, instead of writing idiomatic JS like `condition && `, I now have to write `{#if condition} {/if}`.

WTF. What looks like plain JS is now magic, and what should look like plain JS such as conditional rendering and lists are now some contrived templating constructs.

And almost everyone here is telling me that I should find that simpler somehow.

It makes zero sense.

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

#138

Post by benatkin »

rk06 wrote: post #126
benatkin wrote: post #122

Earlier quoted context omitted.

> View = F(data) That's just how templates are meant to work. Underscore.js templates don't allow making an AJAX call before calling render() either. https://underscorejs.org/#template

Consider following scenario: User is entering an account register form. When the user has entered a value in nickname, your app must check if it is in use and display error message if the nickname is already in use. Sounds good, and ubiquitous right? Well, that also require an ajax call to server for validation, so it breaks the pure function assumption right there. Now, you what do you do?

The template's render function doesn't make the AJAX call - not in React, and not in Underscore templates.

When you display the error message, yes, React provides a way to do that without re-rendering the input box and while keeping the contents, but many react devs are skipping the traditional React way of doing that and using react-hook-form instead.

I get what you're saying about the component's data updating the state of the DOM in a way that resembles pure functions, but I think AngularJS did it before React, and that Backbone was not far from this vision. Certainly there are a zillion JavaScript frameworks that do this now, and only React has you jumping through silly hoops like "className" and "htmlFor". https://preactjs.com/guide/v10/differences-to-react/#raw-htm... https://www.solidjs.com/tutorial/bindings_classlist

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

#139

Post by norman784 »

pjmlp wrote: post #98
preommr wrote: post #10

I swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale. react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sug…

I keep my sanity by ignoring all of them, focusing on mastering pure Web standards only, and delving into such frameworks only when I am required to collaborate with Web FE devs.

I recently started to look at native web components (custom elements), at first I thought I could replace {insert your framework here} with it, but it seems that it doesn't solve the issue, you still need some kind of framework built on top of it to achieve the same goal.

If you have some recommendations or want to share your experience with working only with web standards I want to read them :)

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

#140

Post by ricardobeat »

preommr wrote: post #10

I swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale. react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sug…

That's not completely correct. React is, and has been from the start, a UI rendering library. Its fundamentals are component abstractions, the component tree, lifecycle, the virtual DOM. We had other declarative frameworks before React (Ractive.js, svelte's spiritual grandfather, being the most popular one).

The 'inputs changed, render this' paradigm (and by this I mean reactivity, not the declarative model) has been around for much longer and is exactly what this post is about - React doesn't really do that, since it relies on you to explicitly tell it, via dependency arrays or setState calls, when to re-render. It is not fundamentally different from `.on('change', this.render)` code we were writing back in 2010, just a lot of syntax sugar on top.

That React managed to sell itself so well, while not actually delivering on the reactivity or performance promises, is the surprising part. I'm excited for the future as we finally move on from this era.

Post reply on HN