justin_murray

This behavior is not very surprising to me, and I think the conclusion is a bit off. Here is an analogous study:

Participants are asked to drive 20 nails into a plank of wood. Group A is given a hammer and an unripe banana. Group B is given only a banana. Halfway through the experiment, the hammers are taken away.

Hammers erode your ability to persist at hard things…

My point being that AI is a new tool that allows us to work on harder things at a higher level. It’s like having a team of 100 skilled workers with nail guns (and all manner of other tools) that never tire, and you get to direct them. Once you experience that, it’s a bit disheartening to go back to building alone with your bare hands… even if you lament the decline in your hand-eye coordination.

Honest question: why don’t you think it is fair use?

I can see how it pushes the boundary, but I can’t lay out logic that it’s not. The code has been publish for the public to see. I’m always allowed to read it, remember it, tell my friends about it. Certainly, this is what the author hoped I would do. Otherwise, wouldn’t they have kept it to themselves?

These agents are just doing a more sophisticated, faster version of that same act.

This is at least murky, since a lot of pirated material is “publicly available”. Certainly some has ended up in the training data.

Seeing the need for polling the job status is off putting, especially for a js api that already is using async. If you _need_ to use polling, at least provide a convenience method I can just await. Better yet, add some signaling to the http api via eventsource or something.

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.

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.

Can you elaborate? What’s the economic way to do this?

This is very exciting!

I recently paid $12/ft for the drilling plus a bit more for excavation to connect them together and run to the house.

Temp is 52f from our loops. Supposedly very consistent once below the frost line (6ft or so). All depends on the region you are in.

Likely September 7th?