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

301–310 of 444 posts

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

#301

Post by unfocussed_mike »

orra wrote: post #127
unfocussed_mike wrote: post #75

> That’s a lot of code to write for an auto-incrementing counter. Is it though? I mean I happily write more code for a single-page Vue component for something like this. Terseness is not always a virtue.

> Terseness is not always a virtue. This is a subjective thing, right? Personally, I hate boilerplate: either it's a distraction because it's boring and superfluous, or worse it's long and it's wrong. Regardless, it adds to the cognitive load when maintaining code.

Yeah, definitely, hence the "not always" in this case.

There are several terse syntaxes I really like. I'm just not convinced it's a virtue in this context.

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

#302

Post by unfocussed_mike »

strangeattractr wrote: post #241
unfocussed_mike wrote: post #75

> That’s a lot of code to write for an auto-incrementing counter. Is it though? I mean I happily write more code for a single-page Vue component for something like this. Terseness is not always a virtue.

The vue code for this is pretty terse anyway to be honest. A single variable in data, a call to setInterval in the created hook and a few lines of html with template formatting. It's extremely clear what's going on too.

I agree. I think the single-page .vue model is also really amenable to whitespace and consistent formatting.

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

#303

Post by code_runner »

bayesian_horse wrote: post #255
code_runner wrote: post #244

I just dove back into react after a while in vue and deep in some backend systems. I love the new ergonomics (hooks, useEffect, redux tools) but I definitely hit the exact issue OP mentions almost immediately. I don’t feel that the solution react provides is too out there, but agree it could be better. The react ecosystem still makes it worth the one or two “could be betters” for me.

You may need to think about how you implement asynchronous side effects. Declaring them with useEffect quickly gets annoying. Look for things like thunks or saga. Or when not using Redux, at least think about using async functions. In general I want to keep async logic out of my components as much as possible. I also don't want the component rendering to drive the async logic.

have you had any success using the useReducer hook totally outside of redux? I feel like its bulky for certain operations but I still haven't found that "perfect" use-case for it yet that makes it click for me

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

#304

Post by nobleach »

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…

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

I do not want this handled at the framework level though. There are plenty of times in my day-to-day where that linter is wrong. If I were to add one of the dependencies (it's sure I should add) my component would re-render over and over. Sure, one could argue, "well, then you've poorly architected your code"... but THAT is where I feel like the failure occurs. Having to do write my code to please a paradigm. What that means is I only "sorta agree" with the design trade-offs. And much like Ruby on Rails, you either go all in, or spend your days hating the framework.

I do worry that Solid also has these "If you know, you know" edges though. So I'm trading looking at a function and assuming it'll run over and over with, looking at a function and thinking, "how can I make this thing run again when it needs to?" I'm not saying it's wrong, it's just another piece of tacit knowledge one has to learn when adopting a new framework.

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

#305

Post by phailhaus »

StevePerkins wrote: post #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 crysta…

The OO pattern is far worse, and it's easy to show why: there is only one lifecycle method of a type for each class. This means that when you have a set of related behaviors, you have to split them up across several lifecycle methods and keep them in sync. Sure, that's fine if you just have "one-liners", but software grows, and over time your class will become difficult to maintain as each of those lifecycle methods start managing several different behaviors, all interrelated. With hooks, this isn't a problem: each set of behaviors can be encapsulated by a single hook that handles all lifecycle events together. This can be further abstracted into its own function, which allows them to be trivially reused in any other component. It's simply not feasible in OO patterns.

I think if you actually used hooks, you'll notice this immediately. It's not a matter of "looking cooler", a lot of language theory went into making UI development functional and less stateful, which in turn makes it far easier to manage complex applications. A small team can maintain a pretty huge beast if using hooks effectively.

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

#306

Post by christophilus »

StevePerkins wrote: post #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 crysta…

I've been in the industry since the days of VB6 (which I loved). I've never been more productive than I was with VB6 and WinForms. That said, UI has always been a mess, even then. The more feature-rich you want your UI, the gnarlier and messier it gets.

Everyone always likes to blame the front-end engineers for being slovenly, but my experience is that; UI is just messy. It's just hard to program cleanly.

Not to mention, modern UIs are generally more complex than the old VB days (at least, my programs are): they have to adjust to various screen sizes. They are almost always client/server apps and need to account for more failure modes. They are built on top of a mess of a document layer that was never intended to be an application layer.

This last point is the reason the front-end space has so much churn. It's still an unsolved problem, and may never be well-solved, but I'm glad folks are trying to solve it. React was a step-change for me in terms of building better UIs. I'm looking forward to the next step-change.

Lastly, before someone makes the argument: no; we aren't going to stop building applications on top of the DOM + CSS. Not until someone comes up with an alternative that gives us the same ease of distribution and broad base adoption.

Edit: I should note, I'm a full-stack dev, and have been more back-end than front-end for most of the early part of my career. The backend is always easier for me at least, but I don't think it's because front-end devs are hipsters.

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

#307

Post by toqy »

zero_shift wrote: post #272
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…

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

I wouldn't call in Solid a custom DSL anymore than any given React component. And Solid looks to have good TS support.

https://www.solidjs.com/docs/latest/api#%3Cfor%3E

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

#309

Post by frolicker »

StevePerkins wrote: post #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 crysta…

No post body was provided.

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

#310

Post by marcellus23 »

christophilus wrote: post #306
StevePerkins wrote: post #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 crysta…

I've been in the industry since the days of VB6 (which I loved). I've never been more productive than I was with VB6 and WinForms. That said, UI has always been a mess, even then. The more feature-rich you want your UI, the gnarlier and messier it gets. Everyone always likes to blame the front-end engineers for being slovenly, but my experience is that; UI is just messy. It's just hard to program cleanly. Not to ment…

> UI is just messy. It's just hard to program cleanly.

I'm an almost entirely frontend dev (iOS + macOS now, web development in the past) and this is what I've come to believe. It's easy to program UI cleanly if it's extremely basic or not very usable — but the second you want an animated transition between states, or to remember what the user checked on the last page so that you can keep it checked on this page, or any number of other things that you need to do if you actually want people to _enjoy using your software_, it gets much harder.

My take is it's because building UI is building software for humans, and humans often want behavior that doesn't allow for clean abstraction. Backend dev is more about building for other software -- not that it's easier, just a different set of problems.

Post reply on HN