Live data from Hacker News

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

typeofnan.dev

321–330 of 444 posts

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

#321

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…

UI development seems determined to repeat every mistake we've made on the backend over the past thirty years, while adamantly refusing to ask us about any of those mistakes.

I don’t think there’s much overlap between the two, besides general programming best practices.

In my experience, backend development is often simpler because you can move any state out of your own code into dedicated external components, like databases and queues. With frontend code, you have to manage state; there’s nowhere else for it to go.

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

#322

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') } }

i think an immediate mode UI library would make sense if you want to render to a canvas or a similar "backend". maybe for things like games, or some interactive graphic things

but if you want to render to the DOM —and you want to use the DOM if you want to have decent accessibility, or not have to reimplement all the complex user interactions that the browsers take care of— then i think an immediate mode framework might have a great impedance mismatch with the DOM, as the latter is a retained mode GUI model

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

#323

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…

When you say it out loud, it all makes sense.

UI developers focus on user interface, and much of that has to do with looks, style, and personal ergonomics. In a way, it makes sense that the engineers steeped in this type of problem set would be oriented to thinking this way. Even if they aren't initially, the probably will be over time.

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

#324

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…

VB6 was great. I also really enjoyed RealBasic for desktop apps on the Mac. It just worked. Network programming with sockets was so simple. Now I open XCode and am completely overwhelmed.

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

#325
post #298

Earlier quoted context omitted.

> 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.' IMO there's significant complexity in building a feature-rich frontend client. The "thicker" the client, the worse it gets. There's definitely a lot of 'I think this looks cooler' going around, but also we shouldn't forget that the need to com…

> IMO there's significant complexity in building a feature-rich frontend client. Doing complex things is always complex, but when SIMPLE things are complex, then something is going very wrong. And this is exactly where we are with most JS frameworks these days. Layer upon Layer of abstraction, and instead of the complexity the dev has to deal with decreasing as a result of it being abstracted into frameworks offering…

> this is exactly where we are with most JS frameworks these days

Have you been saying the same thing since 2014? JS frameworks have never been simpler, never been more discoverable thanks to TS, and there are plenty of levels of abstraction a developer can put between themselves and vanilla JS. But even calling React too-far-abstracted-to-be-simple is comical; it's a simple system offering composition of components.

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

#326
post #293

Earlier quoted context omitted.

UI development seems determined to repeat every mistake we've made on the backend over the past thirty years, while adamantly refusing to ask us about any of those mistakes.

Care to elaborate? What mistakes are you referring to?

None in particular, it's just a classic jibe from those who dislike UI frameworks because they don't use and thus don't understand them

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

#327
post #227

Earlier quoted context omitted.

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

> Because you sometimes want to filter, sort or project your data. The idea that this type of thing should be happening anywhere near the view rendering loop is the exact reason I've not had a great time picking up React codebases. By the time you're rendering data into markup, the data should be in the exact state you need it. No further filtering or data mangling or sorting. That type of data manipulation should ha…

Exactly. The whole paradigm of reactive data binding is that data dictates what the UI should render. Don't solve your data needs when rendering ffs.

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

#328
I prefer the very explicit first React example. While I'm not a web dev, on a larger project with a larger team, implicit stuff generally makes things harder to understand and more error-prone. I don't see the boilerplate as a negative, I see it as documentation.

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

#329

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…

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.

It's true, but the counterpoint is that DSLs make your life much easier in 90% of the cases (if not more).

Personally I've never found a problem I wasn't able to solve in Svelte.

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

#330

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…

A factor of two reduction in LOC and an elimination of almost all boilerplate is justifiable in itself. I don't know where the author said "I think this looks cooler"
Post reply on HN