jedwards1211

GraphQL joins are entirely up to the underlying resolvers, it has no syntax for expressing different kinds of joins or filter conditions on values from multiple joined relations

It’s not that hard to pass values as query parameters of a manually written query. With inferior databases that don’t support array parameters it’s a bit more work to construct the correct number of $ parameters in the query, but still not that hard

The streams API exists on the FE, you can pipe an upload or download through a TransformStream to monitor progress

The other thing that's dumb about this is frameworks are usually consolidating repetitive boilerplate so it's going to cost a lot more tokens for an AI to inline everything a framework does.

I know what you mean, but from a physics perspective, no, it just takes force to move mass. More mass will generate more downward force due to gravity, and more force in other directions due to momentum once it’s moving, but there’s more to generating force than just mass. I’m not a kinesiologist but I would think how much force muscles generate depends on the amount and size of the fibers (mass) but also on their contractive efficiency and the amount of energy they can obtain and employ to contract (not necessarily proportional to mass, involves cardiovascular fitness)

for example, I got fed up with the old form library we were using because it wasn't capable of checking field names/paths and field value types at compile time and I kept having unexpected runtime errors. I wrote a replacement form library that can deeply typecheck all of that stuff.

If I had turned an AI loose against the original codebase, I think it would have just churned away copying the existing patterns and debugging any runtime errors that result. I don't think an AI would have ever voluntarily told me "this form library is costing time and effort, we should replace it with such and such instead"

Some of the biggest improvements I've made in the clarity and typesafety of the code I write came from seeing the weak points while slogging through writing code, and choosing or writing better libraries to solve certain problems. If everyone stops writing code I can only imagine quality will stagnate

I’ve VNCed into CI to debug selenium tests failing because of platform font and scrollbar rendering. I never really thought about doing that locally in a docker container, but it definitely wouldn’t be convenient to always run those tests locally in a docker container. I guess having an option to would sort of simplify debugging, but I’d still have to VNC into the docker container I think

The people who love writing code were the ones who created the languages and frameworks that make it even possible for an LLM to cobble something together for you.

There is tons of satsifaction in actually creating nuts and bolts frameworks. After you encounter difficulties in creating a real world product you see the need for tools to solve those problems, so crafting those tools and then using them does feel like winning and shipping and solving real problems.

I think it’s easier to manage full-stack development as a solo developer now even without AI.

Now TypeScript catches a lot of my mistakes before they reach runtime.

Now I have good enough browser automation testing tools to catch regressions in the frontend.

Now it’s quick and easy to run a specific database version for each app I’m working on with docker.

Now I can automate deployment to the cloud instead of having to rely on an entire IT department.

Now I have a scalable way to publish and consume reusable units of code as npm packages.

None of this was the case in what this author seems to think were the good old days. If web development seemed easy to him back then, I doubt he was working on complex projects

I don’t think it’s a good idea to require an icon for everything, some actions are hard to depict with an icon.

But on the other hand, I think 95% of the icons in the first menu in this article are clear and probably help most people navigate faster.

Yeah in Typescript I rarely run into null deference errors at runtime either. It can happen if you unsafely cast the type of values coming into your code, but if you runtime validate input at your application boundary it’s very unlikely

Now looking back at a lot of other languages that don’t express nullability, it’s like, what were they thinking? How did I not wish for nullability in type declarations in all my years of dealing with NullPointerExceptions?

After using TypeScript I see userland Maybe types as a workaround for a language design flaw. When the builtin type system allows you to declare nullable and non-nullable reference types and produces compile errors when you don’t check a nullable value before dereferencing it, the problems with null go away

Stack-based programming may be simple but it doesn’t seem like it would be easy to read and understand for large-scale programs at all.

There’s been a lot of criticism that Koko’s language abilities were overblown and her expressions were overinterpreted as well.