Live data from Hacker News

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

typeofnan.dev

271–280 of 444 posts

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

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

Same, I just use classes for anything that needs more than a few lines of business logic.

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

#272

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…

> It does not make code any harder to understand or to write,

Well, what can you tell me about TypeScript type inference for this custom DSL?

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

#273
post #133

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

I've been using Angular in production for 5+ years. There was a year where things were confusing, state updating all over the place, and general frustration. But once I grokked pure components, and embraced "data down, actions up", it all clicked and just made sense [0]. I find React obtuse in comparison.

Angular front-end, Nestjs backend has fast become my stack of choice. It greatly minimises context switching by having such similar paradigms across frontend and backend.

[0] - blog series I wrote detailing Angular best practices that I learnt along the way: https://link.medium.com/ncYgWgnK2nb

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

#274

Earlier quoted context omitted.

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

Well you've obviously completely missed the point of JSX then. The "whole markup language" that they invented is literally a line for line transform. Optimisation aside, there's no reason why line 58 of a file with JSX in it won't be line 58 of the transpiled JS file, and read exactly the same. All JSX is is a custom function call syntax. It's about as pure as you can get while having any sort of html-ish 'templating…

Solid's doesn't rely on any build-time magic, other than the JSX custom function call syntax that is also present in React. If you want, you can even call it like an ordinary function:

    function MyComponent() {
        return For({
            each: [1,2,3,4],
            children: x => {x},
        })
    )
It's just a function call, and it doesn't even need `React.createElement`. What's more pure than that?

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

#275
post #239

Earlier quoted context omitted.

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.

generally speaking, Angular handles dom manipulation better than React and Vue. Angular has managed to simplify its enterprise/production applicability and performance is a first-order feature that's hard to f up. React -- you can f performance up before you're done writing your first component.

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

#276
post #133

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

The whole "I hate angular" is a bit old at this point. The latest versions are really quite simple/powerful. We act like it's still 2015 and we're jumping from angularjs 1.x to React. The jump was nice, yet turns out production-grade engineering in React was not so nice.

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

#277
The author lost me in the introduction.

> "Ohhh, an OO pattern with a couple of one-liner lifecycle methods is just WAY too much code! Higher likelihood for errors and worse developer experience."

...

> "So instead, I'm going to replace this with a functional pattern, that crams a couple of lifecycle functions into a closure, and is riddled with edge cases and common developer mistakes."

This article perfectly crystalizes why my career has tracked toward the backend over the past decade. All of the virtual ink in this article, and honestly most of the complexity in the field overall... and it seems to really all just boil down to, "I think this looks cooler."

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

#278

Earlier quoted context omitted.

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

The post you're replying to says they've read the docs many times.

In their defense, they said "read the docs" not "read the comments"... :D

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

#279

Earlier quoted context omitted.

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

Australian living in England as a dev for 5 years. Never heard of "used in anger" in any context. Weird.

Australian living in Australia for most of my life. I've heard "used in anger" lots of times. I can't remember when, or by whom. But its certainly a thing I've heard people say here.

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

#280
post #209

Earlier quoted context omitted.

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

Ok, but surely it’s a good thing when frameworks are intuitive?
Post reply on HN