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

421–430 of 444 posts

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

#421

Post by nobleach »

joshribakoff wrote: post #341
nobleach wrote: post #304

Earlier quoted context omitted.

>"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,…

Read the hooks FAQ, the linter is not wrong, you are :) https://reactjs.org/docs/hooks-faq.html#is-it-safe-to-omit-f...

Did you see my comment about "yes I could rearch my code but..." The fact that I'm writing in some very specific way to please a linter IS the problem... regardless of whether we tell someone beforehand.

If I know I have a dependency I want to ignore, to achieve a certain result. Then I have a way to achieve a particular data flow. One can _say_, that's wrong but it's a deterministic way to achieve that result. Calling it "wrong" delves into the weirdness of hooks. Love them or hate them, they create patterns which must be learned and mastered. And even then... they can still be confusing. Except for on the internet obviously, here we find people who never have problems with them :)

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

#422

Post by rezonant »

llamataboot wrote: post #399
rezonant wrote: post #55

Earlier quoted context omitted.

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

I'm not saying there are no use cases for a JS framework, and I have a few I like, just that the switch to rails api only/separate react app has in almost every case I've seen added tons of complexity without a clear win

Imagine you have a Rails controller with a form template and you want to have a section of the form show or hide based on the setting of other form elements, obviously without reloading. Can you do it? Yes. Does Hotwire/Stimulus make this possible? Yes. Can it be done in a nice easy to use way? Yes. If you stretch beyond what Hotwire/Stimulus can let you do, do you have to completely switch over to the "frontend engineering" path of single page applications (React/Angular/Vue/Svelte/etc)? Also yes. Are the primitives you use in Hotwire/Stimulus in any way connected to the ones you'd use if the use case got even a little more complex? Absolutely not. Why not just have one set of primitives that work for all applications?

It's not like having some frontend templating logic or reactive forms or whatever is going to actually be harder than just doing it in Rails if you are familiar and comfortable with both. If you aren't comfortable with both, then that's fine.

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

#423

Post by apatheticonion »

chrisweekly wrote: post #259
apatheticonion wrote: post #226

Earlier quoted context omitted.

After working with React for years it is something I would not recommend and can only think of limited use cases to use. You can write really performant software in React, but ergonomic (beyond stockholm syndrome) I would not call it. It's also difficult to implement quality software engineering principles in a React application such that an application is maintainable, glacable and easy for someone new to a project…

> "glacable"?

Opps, "glanceable"

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

#424

Post by rezonant »

mst wrote: post #388
rezonant wrote: post #55

Earlier quoted context omitted.

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.

For forms-over-data business applications, sure it's fine. It's tradeoffs around the system use cases, potential/realized functionality, and team.

But I think that serving to public users with server-driven MVC for an application that goes beyond a pure content app has immediate and obvious limits in terms of what can practically done, and the more you try to overcome those limits the more you simply rebuild what is already available in the SPA side of things.

It's also inherently monolithic, meaning that if you want or need to support a mobile/native app for your public-facing app, you'll now need to develop a new "interface" (an API), when you should have already done that to enable the web app in the first place. Is it really worth skipping API/UI separation on day 1 when you know it's going to be needed on week 2?

You might say, it's fine, we're going to just make API calls for the Javascript, but then you've got an inconsistent availability of the functionality, and the second you hand that to another team to consume you will have wished you had simply built out all of the needed functionality directly in the API anyway.

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

#425

Post by pjmlp »

stickfigure wrote: post #383
pjmlp wrote: post #216

Earlier quoted context omitted.

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

Given the WebAssembly adoption rate of frameworks like Blazor, plenty of people miss JSF and WebForms today.

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

#426

Post by sakarisson »

littlecranky67 wrote: post #169
oaxacaoaxaca wrote: post #93

Earlier quoted context omitted.

I have the same complaint about hooks. Most people seem to ignore that tidbit, but to me it's really frustrating. Plus I recently hit more hook issues when putting a setInterval inside a useEffect. There's no way to do a normal didMount/willUnmount workflow without other hacks (i.e. useRef) just to set up a simple timer. Maddening! Edit: after writing this I went and read the article. Same scenario I was bitching abo…

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…

> The real footgun is people not reading the documentation for the framework they use

I would argue that the real footgun with hooks is the case where a `useEffect` call inadvertently gets triggered on each render because one of its dependencies, passed through another hook, changes identity on each render. It can get quite maddening, and in many cases you don't notice it until someone points out the resulting performance issue with your app. The solution, of course, is `useMemo` and `useCallback`, but it's not intuitive and it can be easy to miss from time to time in a large project.

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

#427

Post by _0w8t »

neoberg wrote: post #267
_0w8t wrote: post #191

Earlier quoted context omitted.

React hooks is another attempt to gain ergonomics. The idea is to try to spread the virtual DOM into native effects. In theory the code specifies or declared the effects once and the framework takes care about subscribing/unsubscribing as necessary. But in practice this became so messy that in any complex cases one better stick to classes and explicit subscribe/unsubscribe. The right way to do that exists in Elm. But…

I agree that hooks "can" be messy but in my experience they are quite useful and nice to maintain. That is if the code is written with maintainability in mind - which applies to any code really. I've been working on a quite complex React codebase for 5 years now - it's not the biggest but still not so small. I was there on day 1. The team that works on it now full time is ~15 devs + 10-15 doing some minor stuff from…

For us the problem with hooks is that we have a lot of complex state that can be shown in different components. So global stores are a must. But then bugs in the hooks can be hard to debug. Also lack of forceUpdate for hooks causes to use artificial state counters complicating the code. Basically with external state class components are more straightforward to write and easier to maintenance .

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

#428

Post by bayesian_horse »

code_runner wrote: post #303
bayesian_horse wrote: post #255

Earlier quoted context omitted.

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

So far not. But I can imagine things. For example imagine a Game of life component with two actions, "evolve" and "set_cell". Basically any time when it is awkward to have exactly one mutation function (setter) for a piece of state. Other examples are a minesweeper game. Basically any time it is too awkward to compose different mutations on top of a single setter.

The other big benefit is that you can test the reducer without the component. And compared to redux, it still has a smaller footprint. So it doesn't have the dependencies, you don't need to setup a store etc.

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

#429

Post by coxmichael »

ryansolid wrote: post #131
alephnan wrote: post #128

As part of my annual routine, I'm exploring the "latest and greatest" JavaScript UI library. Solid.js's performance seemed compelling. 15 minutes into documentation and this is what I encountered. Can you guess which one of the ChildComponent* updates when the text input on the parent component is updated, and the props passed to the child? export default function ParentComponent() { const [value, setValue] = createS…

Or Vue either to be fair. Similar rules in the Vue's setup function. It's how reactivity works in JavaScript. Basically don't destructure or access values out of of primitives or JSX. That's basically the gotcha. Unfortunately it's the price you pay for portability thus far. You can build your own language around this like Svelte but then composability is limited (need to rely on other mechanisms). You can make the u…

Out of interest, what language features do you see JavaScript needing to support these kinds of fine-grained reactive updates, and to allow destructuring?

I'd assume something like es6 proxies for primitive values would be needed, but that, nor built-in reactive primitives, are being discussed currently as far as I know.

Personally, I'd love to see reactive `[].map` equivalents (no need to use components), but that's possible today with a reactive wrapper or (god forbid) patching the prototype.

Post reply on HN