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)
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
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"
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
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
Option<Option<T>> works fine, T | undefined | undefined doesn't. Typescript does weird things because they wanted to make it backwards compatible with Javascript.
