Hacker News Reader

I think the point is that frameworks ' magic isn't 100% there yet. You eventually HAVE to dive deep and understand things about the implementation to understand how to use it.

Ryan builds out Solid's reactivity system (createSignal) from scratch in about 20 minutes, live, in this video https://youtu.be/N-Y32BqhoYQ?t=1100

I haven't bothered fully grokking it because I've never had to understand the impl details. Solid gives me literal dom elements, and that's low-level enough for me.

I’ve never seen a framework or even languages into which I don’t need to dig deep from time to time. It seems to me an unachievable high bar.

I'll try to give an example of "bad magic".

Did you know React renders twice in developer mode to try to expose bugs with side effects?

If this doesn't raise an eyebrow, I don't know what will.

That seems like a pragmatic solution. The point of having a dev mode is to help development and catch mistakes. if(devMode) { rerender() } doesn't seem like magic. Though in general I really dislike the term magic for what is just code doing something.

Humans have limited cognitive capacity (and time).

To me magic code is code that requires a significant level of cognitive investment to understand and keep in your brain RAM. That threshold varies between people but it's always there.

In React's case, the chosen solution is not the issue here. It's a symptom of bad architecture. The library should be doing more than rendering twice to protect developers from side effects, to a point that rendering twice wouldn't be required.

That feels as bad as rebooting JBOSS servers once a day to "fix" OOM crashes. It's a hack at best and doesn't fix the real issue.

> The library should be doing more than rendering twice to protect developers from side effects

Like what?

probably the parent poster does not use React so it would seem a heavy demand on a human to make, given the already stated limited cognitive energy and time.

I suppose I would think not rendering twice and some sort of warning about side effects would be beneficial, rendering twice means that you get a misleading view of what your application behavior is, I can see how people would - from an architectural perspective - consider it bad without necessarily using the framework.

> some sort of warning about side effects would be beneficial

Rendering twice is exactly what allows you to detect that. How would you detect a side effect if not by calling the function twice?

React's contract is that your component should be allowed to render twice without any changes so this is just upholding the invariant in dev mode.

You can use a language / compiler / static analyzer that restricts side-effects.

Funny you mention that https://react.dev/learn/react-compiler

I do also use React, unfortunately.

my mistake, I feel your pain.

If you have to ask.

Learn Elm and you'll see React's shortcomings clearer. They don't render twice but that is just the tip of the iceberg.

Be warned though, exiting the cave is painful.

I've used elm. It's not that great. In many ways it has the same shortcomings as react but far worse. That is you find yourself wanting to do something as yet unsupported (which we often do because otherwise why write new software in the first place) you have to break out of it's abstraction. Except doing so is 10x harder with elm, and the community around it is so much smaller you can't find the answers. Also, after I personally had moved on, there was something of a tension between the community and the authors. Maybe that's resolved, although I'd suspect for some the resolution was to no longer be part of it.

Things like validating or limiting possible React code you can write such that these effects are impossible, in the same manner that abstract data types in programming languages attempt to define data structures that are correct by construction, or the same way that reactive programming enforces a programming paradigm that attempts to minimize unwanted interaction glitches.

I disagree. React is saying that you need to pass it a function for rendering a component and it does not guarantee how many times that function will be called. There are documented, well defined ways to call side effects based on component lifecycles.

However, how can react know what a side effect is? Hook into well known ones by hijacking the browser API? That sounds like a bad idea. Provide their own linter/compiler. That seems on the radar but I'm not sure I like the idea.

Also react doesn't stop you from doing it. You can say nah it's fine I want my side effect. It just runs the render explicitly twice in development, something that could happen in production for various reasons, so you can see what will happen.

Your proposed solution isn't very practical. A better solution would be a guarantee that render will only run once. But that's not how react has ever worked. There are other frameworks that do that. As with anything, there'll be a trade-off.

It's because the fundamental model of React's render cycle is unintuitive when combined with state. It's easy to make mistakes of this class specifically with React.

> That seems like a pragmatic solution.

That's not a contradiction to it being bad magic.

In fact, this being a pragmatic solution is a strong, though not conclusive, indicator that the underlying abstractions are not fit for purpose.

And the fact that lots of pragmatic choices led to those abstractions that are not fit for purpose also is an indicator that something about the starting point or the road is not right. Or both.

> abstractions that are not fit for purpose

You say that, but react is very successful, indicating that it's abstractions are working just fine for many people. Maybe we'd say they're not perfect but they fit it's purpose. It might not be my favourite frontend library to work with, but it's the one I'd be most likely to choose for commercial work because it does work well, and high use means that people have explored many solutions to problems with it.

You missed "underlying" from "underlying" abstractions.

React is an implementation, not the underlying abstraction. With react it's not even clear what the underlying abstraction is.

https://github.com/reactjs/react-basic/pull/12

Why do you care? Or are you just against the general idea of a framework having constaints that are a bit unusual for their language, like "components must be pure"?

It doesn't though. StrictMode does, and that's optional.

Why would that be bad magic? It’s a very clever way to expose stuff that is accidentally side effecting.

I think he was pretty clear that the "magic" in frameworks is not something you can easily understand, therefore have to guess how it really works. He doesn't like that.

You don't need to guess. You can actually read the code! Not saying that you should straight away when learning, but later, when you're familiar with your framework, I think reading through the codebase and understanding it is good practice.

You can read the code, but it’s complex and convoluted.

He referenced Backbone as a comparison point. If you compare Backbone’s source code to React’s source code, you’ll get what he means.

Basically, libraries like Backbone are small and simple enough that you can literally read the source code and fully understand how it works. Compare that to React, where the source code is an order of magnitude larger and very difficult to fully grasp the inner workings.

The simplicity and ability to easily understand the source code obviously comes with tradeoffs (e.g. with Backbone, to use it to build a reasonably complex app, you basically have to build your own framework on top of it, compared to React which has more abstractions and therefore is more plug and play.

It's complex but not that convoluted.

IIRC reading the React source code became quite a feat around the time fibers were introduced.

I've found the Vue community to be a little better at managing complexity than the react community has mainly because Vue was originally touted as a solution to some of react's problems. People are more conscious of the tradeoffs.

> Do you want to learn a framework at all, or have one that is so magical that it feels like it doesn't need to be learned?

My view is that the problem domain is not complex enough to warrant the complexity of our "solutions".

Is it really "Complex"? Or did we just make it "Complicated"?