I hope it's improved now.
499 karma · joined September 6, 2016
I hope it's improved now.
"<the human brain> cannot think, reason, comprehend anything it has not seen before. If you're getting answers, it has seen it elsewhere, or it is literally dumb, statistical luck."
https://www.youtube.com/@pilot-debrief/videos https://www.youtube.com/@AirSafetyInstitute/videos
At a certain point you won’t have to read and understand every line of code it writes, you can trust that a “module” you ask it to build works exactly like you’d think it would, with a clearly defined interface to the rest of your handwritten code.
I'm not sure this is the right conclusion here. I think zod v4 is being included within v3 so consumers can migrate over incrementally. I.e refactor all usages, one by one to `import ... from 'zod/v4'`, and once that's done, upgrade to v4 entirely.
> "Well, Steve… I think it’s more like we both had this rich neighbour named Xerox and I broke into his house to steal the TV set and found out that you had already stolen it."
> I'm losing my job right in front of my eyes. Thank you, Father.
Do you have sources on this?
Yeah I don't know where the parent comment got this from. Every few weeks I seem to see these low effort posts that basically boil down to "javascript bad", but gets a lot of upvotes. And when you read into it, you see the author often has a poor grasp of js, or its ecosystem, and has set up some unholy abstraction, assuming that's how everyone does it.
Use the right tool for the job lol.
That sounds a little reductive and gate-keepy. Maybe an advanced type system allowing for complex types to be expressed easily actually allows you to write simpler, more effective code.
Curious if you have any specific examples though.
I've been researching 'local first' solutions like electric recently and tried out powersync, triplit and instant for now. All three of these solve for both reading and writing to databases, with offline support.
Wondering if you have plans to support writes too.
I agree with this. Luckily there's some work being done on this - check out the new React Compiler[1]
> what's in dependency arrays, what should go in useCallbacks and useEffect
This lint plugin[2] from the react team helps quite a bit with this
[1] https://react.dev/learn/react-compiler [2] https://github.com/facebook/react/tree/main/packages/eslint-...
I think the root cause of this is react not really being a framework, rather just a library that allows you to write declarative code involving state that in the end, outputs a DOM tree. IMO it does that quite well.
It doesn't have very many opinions on how you should structure your code, how you should organize your state, how your routing logic should work etc. I think that's where frameworks come in. React was quite popular long before frameworks like nextjs, meteor, remix, ... became 'mainstream', causing lots of developers to invent their own (poorly maintained) frameworks.
React's goal isn't to make you a better developer though. It's goal is to make it easier to build non trivial, stateful applications