781–788 of 788 posts
Earlier quoted context omitted.
I only knew React until my current job, which uses Vue. I'd strongly recommend trying a framework other than React for your next project. After you're past the learning curve, it's much more intuitive.
I've tried many of them. They all suck.
Then try something like snabbdom or mithril.js.
Earlier quoted context omitted.
If there is anyone here who has time to explain to me (or link articles about) why functional components and hooks are considered to be better than class components, please enlighten me. Up until roughly 4-5 years ago I was doing small front-end React apps on the side (I'm a backend engineer) and was feeling very productive with class components. They made sense to me, concerns were nicely separated, and I felt I cou…
I'm glad I'm not alone in that sentiment. I haven't touched react since the move to hooks. People seem to like them though?
I think distributed locking is hard because it only offers certain properties and requires that the application work together to achieve consistency, just like what you said about DynamoDB:
> DynamoDB is a good database (IFF your workload lines up with what it's offering)
I have written a blog post about distributed locks: https://blog.damnever.com/en/2020/the-consistency-problem-of...
That was actually one of the first things I understood about programming 30 years ago. Accidental complexity is the root af all evil.
Earlier quoted context omitted.
I've been loving edgedb in my typescript side projects for a number of years now. I have always hated ORMs, mostly for performance and a little bit for elegance / ergonomics. Curious if you have thoughts on a solution like that?
I like EdgeDB. The only downside I see is the lock-in, that is less of an issue with SQL. While I have not used EdgeDB, I have used Hasura, which I really liked. Wrt the syntax of queries, I know of https://prql-lang.org which is kind of similar of EdgeQL. Funny that EdgeDB says on its page it tries to solve the ORM problem: I strongly believe ORMs do not solve any problem, they merely create problems (as I argue in…
Edgedb ends up being an extremely performant ORM if used that way. And since your database is fully aware of your object graph, it's just as or more type safe than graphql.
Earlier quoted context omitted.
If something can be configured, this opens up infinite possibilities for discussions on how it should be configured. The fact that you even ASK if you should use the tall style means that you are considering the POSSIBILITY of using it that way. Put it this way, if it is technically impossible to develop a car that have the color red, we would not be discussing or entertaining what color the next car should have. It…
Hot take: stop being authoritarian with code styles, perchance? You are not so wise as to determine what is clean code for the entire world, and the ego required to believe that you are is beyond astounding. And we're still having these discussions despite unconfigurably prescriptive formatters. This idea that such formatters end these discussions is just demonstrably false... you are literally taking part in one of…
Earlier quoted context omitted.
Hot take: stop being authoritarian with code styles, perchance? You are not so wise as to determine what is clean code for the entire world, and the ego required to believe that you are is beyond astounding. And we're still having these discussions despite unconfigurably prescriptive formatters. This idea that such formatters end these discussions is just demonstrably false... you are literally taking part in one of…
The point is, that the way it's formatted doesn't matter. It just matters that it's consistent. Consistency is better than being right.
The fact that Dart's formatter FAQ tells developers who are unhappy with the output to change their code to satisfy the formatter (https://github.com/dart-lang/dart_style/wiki/FAQ#i-dont-like...), rather than allowing developers to tweak the formatter to satisfy their code, is such a huge tell about their mindset. And again, these global styles do not "end the discussion" as people in this thread have asserted. The "tall style" PR (https://github.com/dart-lang/dart_style/issues/1253) refutes that. And that PR has since devolved into bickering and heated demands since its adoption into SDK 3.7.0, since it transforms people's code in ways they dislike and/or find less readable.
Just let people, projects, and organisations enforce their own styles conventions. It's not hard and it shouldn't be controversial.