Live data from Hacker News

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

typeofnan.dev

381–390 of 444 posts

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

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

Hrm.

"React as Schelling Point" ?

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

#382
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 think for progress you need to look outside the js world. Fundamentally, people keep repeating the same mistakes there. I'm having a lot of fun lately using Kotlin-js for example. We use the Fritz2 framework, koin for dependency injection (popular on Android as well for good reasons), and fritz2 relies on kotlin's co-routines and StateFlow for state management. It makes for a surprisingly concise code base. For exa…

The way mobx-state-tree uses generators as a coroutine-like affordance is worthy of study.

I would not at all be surprised or troubled if, having studied it, you still dislike it, but there are definitely ideas in there that I consider to be at worst -interesting-.

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

#383
post #216

Earlier quoted context omitted.

That isn't a solution. Everybody moved away from this approach for web applications for good reasons.

The craziness of SPA frameworks running headless browsers, rediscovering SSR as if they are inventing something that no one else thought about, proves otherwise.

Having been on this ride since before HTML was a thing... I'm going to make a prediction: JS SSR will be a brief flash in the pan. In another ten years, we're going to look at it the same way we look at JSF today. "What were we thinking?"

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

#384

I've been using React since around 2016 and when Hooks were introduced I played around with it but didn't like it at all exactly because of the reasons mentioned in this article. Sure it reduced quite a bit of boilerplate code that came with class based components and enabled better code re-usability outside of class inheritance or mixins but the disadvantages were too big for me personally to really consider using H…

Pure function components in React with MobX for state management rather than the hooks system has worked out quite well for me.

I do, however, keep finding myself wondering about jumping to Vue and VueX instead.

Ask me in five years, I guess.

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

#385
post #2

This is interesting because it's a bit like Svelte, but it doesn't use the Svelte "language" (which looks like JS and HTML but, in some crucial ways, sometimes isn't ). It's a little disheartening to see that it's 3+ years old and has only had a single significant contributor though[1]. It's impossible to avoid single-contributor projects in the JS world, especially with Node, but the alternatives (React, Vue, Angula…

I'd also look at other repos. Admittedly for the core code it has been mostly me. I think there is an intimidation factor. When you create a library this performance oriented it is hard to get people comfortable working on the core. But things like the site, docs etc.. are much more contributors making more substantial submissions: https://github.com/solidjs/solid-site/graphs/contributors https://github.com/solidjs/s…

There are projects of mine where I'm the only relevant core contributor but the ecosystem is developed by many other people and it's largely worked out fine.

I would hope that if either of us got hit by the proverbial bus that people involved in the ecosystem would pour themselves a strong drink and dig in to the necessary maintenance anyway.

Projects I've ended up moving on from have regularly worked out that way, and I think that while solid might not be as popular as some people would want for something to bet their production code on, it does seem to me that it's popular -enough- that I don't believe you're a truly dangerous single point of failure here.

(if this comment read as negative rather than an attempt at a clear eyed analysis, I apologise for phrasing it wrong)

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

#386

We've used React with Mobx in commercial apps for 5+ years now. React has been good for us BUT Solid is so much cleaner (and leaner). Porting most React code to Solid is pretty easy - mostly involves deleting things that are no longer required (useCallback, useRef, etc) and moving prop access into the JSX to enable just those specific attributes to be updated when state changes. It has come to the point where I reall…

As somebody who's quite enjoyed mobx I would encourage you to write up your experiences.

I would hope that while -me- reading any such blog post is almost certainly going to be irrelevant, it might pay off enough in recruiting/marketing/pure nerdery to be worth the effort to write it up.

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

#387
post #282
post #276

Earlier quoted context omitted.

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.

I don’t like the separation between template and code, I don’t like the developer experience (slow and often malfunctioning VS Code extensions and slow builds, bad in-browser debug helpers), I don’t like how creating “ad-hoc” components is basically impossible. I think Zone.js is insane. I know Angular very well. That’s why I’m confident I can create high-performance applications using Angular. I firmly believe Angul…

If you can't hate on your major dependencies confidently and at length, you probably haven't used them long enough yet.

I generally spend much of my day writing perl. It absolutely works for me, but every time I encounter somebody who wants to -attack- perl I find myself disappointed by how short their list of reasons to hate it is compared to my own.

(one of the most complicated JS codebases I work with on a regular basis is in angular, and the learning curve is a fucking cliff but yeah, once you get to the top, I agree with everything you've said about it)

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

#388

Honestly my hope (and I admit as a full-stack but leaning back-end developer to be biased against JS) is that the future is in things like turbo-stream, stimulus reflex, phoenix liveview etc - or in things like all_futures (essentially an ActiveRecord wrapper around kredis) - that we move towards building reactive-apps by firing off events from the back-end and figuring out how to subscribe to them on the front-end t…

What about apps that have no backend? What about apps that should work both online and offline?

Those are very different applications and the trade-offs involved are completely different.

In the -common- case OP seems to me to have a valid point.

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

#389
post #334

I'm surprised to see so many negative opinions about React. Surely, I can't be the only one that truly likes React and finds myself being extremely productive and making impressive apps with it.

You're definitely not the only one. But I find it refreshing to hear some people voicing many of the complaints I've had about React for years. Up until very recently, criticizing react seemed to be nearly unheard of.

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

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

I don't understand your issues here. I built a community app for a hockey league that manages around 120,000 players in the DB. I do tons of loading, sorting and various algorithms on the data. I've never once had React be my bottleneck. Rendering a page server-side and delivering it to users is about as inefficient a process as you can get unless you have massive resources dedicated to an optimization almost no one…

I have hit a point where I've moved my browser from running locally on my laptop to running on a hetzner dedicated server over VNC because it performs ridiculously better so "readily available" is apparently an unfortunately variable claim.

I would note however that my laptop is not entirely recent and I'm using firefox and my big pain point has been React Native Web apps like web twitter. So you're likely still mostly right, and the question inevitably becomes "how much mostly is enough for any given application".

Post reply on HN