7 ms·

> I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al

> I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al). I can't really parse this sentence. It seems to have a lot of ideas in it. 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? Do you want to read documentation or not? Do you think the problem with React is that its primitives are unsuited to the work you do in it? Or to the work anybody needs to do? I've spent most of my professional career in Vue, so I don't have a great perspective on the React ecosystem. But Vue feels like it must be included in your "complex framework" statement. I've definitely felt some pain from overuse of the framework, or poor understanding of various features, libraries, etc. The ecosystem around full-on SPAs is indeed complex. I'm just not sure what other systems would let me personally, and us broadly, manage a complex stateful client-side app. (This is entirely separate to overuse of SPAs for things that shouldn't be SPAs.)

szundi 2y ago
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.
- jemmyw 2y ago
  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.
  - cj 2y ago
    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.
    - jemmyw 2y ago
      It's complex but not that convoluted.
  - spion 2y ago
    IIRC reading the React source code became quite a feat around the time fibers were introduced.
eddd-ddde 2y ago
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.
- AlexErrant 2y ago
  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 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.
- ruszki 2y ago
  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.
hu3 2y ago
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.
- jemmyw 2y ago
  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.
  - hu3 2y ago
    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.
    - edflsafoiewq 2y ago
      > The library should be doing more than rendering twice to protect developers from side effects Like what?
      - bryanrasmussen 2y ago
        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.
mpweiher 2y ago
> 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". See also: https://www.youtube.com/watch?v=ubaX1Smg6pY https://www.youtube.com/watch?v=ubaX1Smg6pY Is it really "Complex"? Or did we just make it "Complicated"?
redman25 2y ago
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.

szundi 2y ago

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.

jemmyw 2y ago
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.
- cj 2y ago
  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.
  - jemmyw 2y ago
    It's complex but not that convoluted.
- spion 2y ago
  IIRC reading the React source code became quite a feat around the time fibers were introduced.

eddd-ddde 2y ago

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.

AlexErrant 2y ago
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 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.
ruszki 2y ago
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.

hu3 2y ago

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.

jemmyw 2y ago
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.
- hu3 2y ago
  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.
  - edflsafoiewq 2y ago
    > The library should be doing more than rendering twice to protect developers from side effects Like what?
    - bryanrasmussen 2y ago
      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.

mpweiher 2y ago

> 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". See also: https://www.youtube.com/watch?v=ubaX1Smg6pY https://www.youtube.com/watch?v=ubaX1Smg6pY Is it really "Complex"? Or did we just make it "Complicated"?

redman25 2y ago

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.