6 ms·

It's cool to see a novel idea like this get prototyped and then opened up for discussion. As others have hinted at, this feels like jQuery with different synta

It's cool to see a novel idea like this get prototyped and then opened up for discussion. As others have hinted at, this feels like jQuery with different syntax and more limitations. In its current form, I can't imagine choosing this over jQuery (in part because I already know jQuery, and in part because the limited reach of your selectors feels like it would be a roadblock very quickly). Perhaps you could reshape this to be an extension of jQuery, where this alternative jsx syntax is available if you want it, but the full power of jQuery's selectors is also available (without having to mix two libraries with overlapping purpose)? That aside, I can't imagine abandoning React for this. That would feel like a step backwards to me. IMO, the most valuable thing React brought to the ecosystem is a simple way to make reusable components. Much of React's convenience is because of its functional nature: each component instance has an isolated scope/context, making it easy to reason over the behavior of a small widget without worrying about external effects from the larger application. From what I can see in your examples, you're relying on things like global identifiers/keys, which I think leads to a mess in a large application. Take your counter example: what if my application needs 5 such counters? Can I do this without significant code duplication? I could probably wrap it in a function, but I'd likely need to pass in some unique id to distinguish between the 5 usages. This is a huge part of what React does for you, just keeping track of which component instances go where in the DOM (without needing DOM `id`s everywhere). It could be that I'm missing something. It'd be great to see some larger examples of a more complex application with widget reuse, to see how that feels.

danielvaughn 2y ago
Yeah I opted for quick, simple demonstrations of the basic ideas. In a real application, at least one of any significant complexity, I wouldn't be writing the code you see in those demos. I'm experimenting with how it might integrate with state management libraries, currently with mobx. I haven't done any work on this front yet, but I'm especially excited to see how this might fit into an SSR/MPA app. I have some ideas though; my goal is to implement ISR/streaming/etc without the need for weird little conventions like "use server".
justin_murray 2y ago
Just a few more thoughts to add: When I see code like count++; setContent(<p key="counter">The count is {count}</p>); I immediately think about how someone, at some point, will introduce bugs/weirdness where they update some state (`count`), but then forget to make the `setContent` call to update the DOM. That's a very useful thing that React's `useState` does; a single way to update the state that is guaranteed to always be synced with the DOM. Of course, I could make a `setCount` function to help abstract this, but that's more boilerplate and just more opportunity for someone to screw it up. Another point related to scoped components: one thing that I saw happen in jQuery codebases (and I think the same would happen here) is that it's too easy to mistakenly write a rogue selector that affects some part of the DOM that is far away from what was intended. It's one of those great power = great responsibility things... but I think this power more often leads to complex and confusing code that is hard for someone to understand and maintain. React can be frustrating at times, when it seems like it would be easiest for a parent component to directly manipulate some nested child (or vice versa), but I think this friction often just leads to code that is easier to reason over.
- danielvaughn 2y ago
  "greater power & greater responsibility" is definitely the tradeoff I'm making. One of the tradeoffs I list in the readme is that you really need to think about the UI in a way that you don't with React. It's certainly more expedient to use React and let it handle the platform itself. On the other hand, you pay for that in a multitude of other ways - it's more than just a few frustrations here and there.
Justsignedup 2y ago
I have to strongly agree with this. The entire point of react was to avoid all the challenges of old imperative coding of syncing up state with render state. The Dom digging was an absolutely genius idea to stop that nonsense and just render the correct state and let the framework handle the rest. I wrote a ton of backbone code, and was a major fan of jquery before Dom querying was even a feature of browsers. And once I went react I really fell in love with frontend dev. Frontend is so simple now because of it, while it used to be dare I say more complex than backend back in the day.
- danielvaughn 2y ago
  Same, used jQuery for years and had a love/hate relationship with it. You're correct that React solved the imperative problems from before, but that's not the only factor to consider. You have to weigh the problems it solves against the problems that it causes.
  - Justsignedup 2y ago
    Eh. For me, it was vastly worth it. Yes there are drawbacks to react. But I feel like the gains far far far outweigh them.
    - danielvaughn 2y ago
      totally fair

danielvaughn 2y ago

Yeah I opted for quick, simple demonstrations of the basic ideas. In a real application, at least one of any significant complexity, I wouldn't be writing the code you see in those demos. I'm experimenting with how it might integrate with state management libraries, currently with mobx. I haven't done any work on this front yet, but I'm especially excited to see how this might fit into an SSR/MPA app. I have some ideas though; my goal is to implement ISR/streaming/etc without the need for weird little conventions like "use server".

justin_murray 2y ago

Just a few more thoughts to add: When I see code like count++; setContent(<p key="counter">The count is {count}</p>); I immediately think about how someone, at some point, will introduce bugs/weirdness where they update some state (`count`), but then forget to make the `setContent` call to update the DOM. That's a very useful thing that React's `useState` does; a single way to update the state that is guaranteed to always be synced with the DOM. Of course, I could make a `setCount` function to help abstract this, but that's more boilerplate and just more opportunity for someone to screw it up. Another point related to scoped components: one thing that I saw happen in jQuery codebases (and I think the same would happen here) is that it's too easy to mistakenly write a rogue selector that affects some part of the DOM that is far away from what was intended. It's one of those great power = great responsibility things... but I think this power more often leads to complex and confusing code that is hard for someone to understand and maintain. React can be frustrating at times, when it seems like it would be easiest for a parent component to directly manipulate some nested child (or vice versa), but I think this friction often just leads to code that is easier to reason over.

danielvaughn 2y ago
"greater power & greater responsibility" is definitely the tradeoff I'm making. One of the tradeoffs I list in the readme is that you really need to think about the UI in a way that you don't with React. It's certainly more expedient to use React and let it handle the platform itself. On the other hand, you pay for that in a multitude of other ways - it's more than just a few frustrations here and there.

Justsignedup 2y ago

I have to strongly agree with this. The entire point of react was to avoid all the challenges of old imperative coding of syncing up state with render state. The Dom digging was an absolutely genius idea to stop that nonsense and just render the correct state and let the framework handle the rest. I wrote a ton of backbone code, and was a major fan of jquery before Dom querying was even a feature of browsers. And once I went react I really fell in love with frontend dev. Frontend is so simple now because of it, while it used to be dare I say more complex than backend back in the day.

danielvaughn 2y ago
Same, used jQuery for years and had a love/hate relationship with it. You're correct that React solved the imperative problems from before, but that's not the only factor to consider. You have to weigh the problems it solves against the problems that it causes.
- Justsignedup 2y ago
  Eh. For me, it was vastly worth it. Yes there are drawbacks to react. But I feel like the gains far far far outweigh them.
  - danielvaughn 2y ago
    totally fair