Live data from Hacker News

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

typeofnan.dev

231–240 of 444 posts

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

#231
post #209

Earlier quoted context omitted.

People always use the setInterval() issue as a footgun. The real footgun is people not reading the documentation for the framework they use, because the exact example is handled in the official react docs [0]. I always advice aspiring react devs to understand why this exact setInterval() doesn't work (and why there is the need for the rule-of-hooks), because it will automatically create an understanding how hooks and…

When I started with classes, I hardly had to read the docs, few hours and was good to go. For many developers I worked with at the time this was the case. React was easy coming from jQuery, Backbone other frameworks at the time. With effects, i've read the docs many times. I still don't fully understand how it's supposed to work. I don't seem to get the feeling / abstract concept behind it and it still surprises me a…

Well if you do not want to read the docs, go with vanilla JS ;) Seriously, no matter what you use, read the docs. Arguing that a library should not require you to read the docs is just nonsense - cause any library makes decisions about abstractions for a reason. If you do not want/need those abstractions, do not use the library blindly. It is always the case that you should now and agree with those, that is why you use the library in the first place. So, read the docs, please.

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

#233
I love solidjs, but the similarities to React are the hardest part for me. The semantics are so similar, but the mechanics are the polar opposite.

In react, everything is a function and all your code runs on every render unless you specifically tell it not to. This really encourages a certain style of writing code and provides a lot of guarantees about safety and scope.

Solid is literally the polar opposite, your code runs once, and only the parts that you specifically make reactive are reactive. This allows for much finer-grained updates and performance.

The mental models are so different because they are optimized for different things. React allows for developer sanity (cue all the people who worked on one lousy react app telling me that it doesn't) and Solid optimizes for speed and simplicity.

Solid is very well designed though. One of the features I loved is that Ryan specifically built it to work as possible to vanilla html/js so you can copy old stack overflow answers.

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

#234

I love solidjs, but the similarities to React are the hardest part for me. The semantics are so similar, but the mechanics are the polar opposite. In react, everything is a function and all your code runs on every render unless you specifically tell it not to. This really encourages a certain style of writing code and provides a lot of guarantees about safety and scope. Solid is literally the polar opposite, your cod…

and Solid JS runs very close native JS speed! Any one making a Reactive Native Connector for solidjs? Vue Native was already using that connector. with that, Solid JS will be ultimate isomorphic lib to use.

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

#236

I wonder if there's an immediate mode framework for Js, in the vein of IMGUI for C. If people are wondering what that is, it's basically this: function renderGui() { label('hello') if(button('click me')) { console.log('I have been clicked') } }

This seems like a huge step back from declarative UIs, any reason why you would say it’s preferable?

Performance, for one. This method can easily avoid allocating an object for every div (since it turns into a method call, not something that needs to return an object), compared to React's render() method.

Another scenario outlined in the article of rendering a row of buttons, each with it's own click handler, that needs to allocate a lambda for each button every render. Alternatively, using map() and filter() also allocates lambdas and temporary arrays.

All this can be replaced with a simple for loop like:

  for (item of items) {
     if(!item.isClickable)
         continue;
     if(button(item.name)){
         console.log(item.name)
     }
  }
Compare this to the React-ish pseudocode:

  items.filter(item=>item.isClickable).map(item=>console.log(item.name)} >{item.name})

Readibility-wise, it's sort of an acquired taste, I'm not saying it looks better than JSX (but it's a hell of a lot readable than React.createElement, so some syntactic sugar might be put on top of it).

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

#237
post #14

What was wrong with the class component? It was very understandable and predictable.

Class components are fine for the simplest examples, but the moment they start increasing in complexity, they become a bit of a mess. Sharing functionality across multiple components becomes tricky with class components (with the only real option being HoCs / render props). You necessarily have to spread logic across different lifecycle methods. Hooks allow you to bundle code together by functionality, and consequent…

I think in the class world this is normally done by writing a service and injecting it on the constructor of the parent class. Since, React doesn't have DI built-in, it becomes problematic with the injection. hooks are essentially classes imo.

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

#238

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

They literally don't. For some reason the developers think that storing state in hidden global variables (linked list indexed by hook call order) is a good idea. You know, they could have at least defined useReducer inside the class. Of course that would sort of break the pretentious ability to define hooks as global functions that access component state. After all, you would have to pass the current component as the first parameter, imagine the horror!

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

#239
post #183

Earlier quoted context omitted.

https://svelte.dev/blog/virtual-dom-is-pure-overhead It is a huge performance issue. I tried to do a pokedex in react, you have to use a virtual list, because react/virtual dom is too slow, doing any operation on a plain list with 1k element, like filtering lead to multiples seconds freeze. This also lead to a lot of issues, like not being able to ctrl+f text being out of screen in a virtual list.

Great article. The fact that Angular, the framework built by the company who also builds the world's most popular browser, does not have a virtual DOM, is very telling.

I wouldn't acclaim angular for the performance either.

Building apps on it show consistent subpar performance.

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

#240
Almost every criticism of React that I've read, goes away when you drive it from Clojurescript. If you haven't had the pleasure I suggest you take it out for a spin.

Example of a full blown React component in Clojurescript:

  (defn counter
    []
    (let [state (r/atom 0)]
      (fn []
        [:div {:onClick #(swap! state inc)}
         "The count is: " @state])))
Post reply on HN