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.

I think it’s mainly because they struggled to get consensus on which syntax to go with for pipelines, since people were divided into three different camps. I wish they would just standardize all three options with a slightly different operator for each one

You’re shooting yourself in the foot if you put naked fetch calls all over the place in your own client SDK though. Or at least going to extra trouble for no benefit

What is a validation quirk that would happen when using server side Zod schemas that somehow doesn’t happen with a codegened client?

The schema definition is more efficient than writing input validation from scratch anyway so it’s completely win/win unless you want to throw caution to the wind and not do any validation

This has been the case for quite awhile, most of the things in this article aren’t brand new

Oof. Now I’m looking into using an extension someone wrote to publish to Redis straight from Postgres, as a replacement for NOTIFY statements in triggers. Kind of a mess but any other way of waking up our app logic that walks change queues in Postgres seems worse

I think the pain of explaining to the LLM what I want is what's kept me from using AI at all so far

It's the new form of giving into the customer, lol

simplicity and ease of use is a pretty compelling feature to a lot of people, if not you

I don’t think there’s anything in ISO 8601 pertaining to integers that represent the number of years since some specific year though.

ISO 8601 prescribes string representations, not integers, and it requires at least four digits for the year, and the year the Convention du Mètre was signed is expressed as 1875, not 0.

The original post on X completely misinterpreted this to mean that ISO 8601 established days since 1875 as a standard date storage format

I’m still kind of surprised they would store days since 1800, but it makes a lot more sense than 1875. At least with 1800 the last two digits are the same, so debugging it is somewhat sane.

It's horrifying to see even the Associated Press repeating this claim a truth. AP links to the Wired article, which links to the same old ExTwitter post that originated the claim. Neither did any fact checking ffs

I was going by the example cost of $8 for 16 bits you stated in an earlier comment:

"2^16 = 65536

...

so if a search space of 65536 costs you $8"

If you think the numbers I'm arriving at are wrong then can you specify exactly where my cost function goes wrong?

Note: Y combinator messed up my formatting in the above example, many asterisks * are supposed to be double asterisks (expoentiation in JS)