11–20 of 55 posts
That's the worst idea for framework I've seen recently
For example you could remind the author of the perils of imperative programming such as needing to mentally simulate application state at every line to understand the program vs functional programming where you have referential transparency
React, the good parts
That's the worst idea for framework I've seen recently
While I do agree, it would be nice to see something more than just “I hate this” in a comment. For example you could remind the author of the perils of imperative programming such as needing to mentally simulate application state at every line to understand the program vs functional programming where you have referential transparency
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.
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 th…
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".
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 th…
When I see code like
count++;
setContent(The count is {count});
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.
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 th…
Just a few more thoughts to add: When I see code like count++; setContent( The count is {count} ); 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 wit…
This reminds me of google’s incremental dom ( https://google.github.io/incremental-dom/ ) it surely made some things (like making sure an element has focus) a lot easier to do and in general felt a bit more like something that works with the browser instead of against it.