Because web development sucks, web developers are always trying to reinvent web development such that it doesn’t suck, and they keep failing.

They keep failing because it’s impossible, and it’s impossible because the requirements are directly contradictory.

• Web application code must be simple and understandable (which requires the application to use a minimum of libraries and frameworks), but web applications must look and feel modern and fancy (which requires big, complicated frameworks).
• Web development must be easy (which requires the project to be written in JavaScript or something similarly simple), but web applications must have sophisticated functionality and not crash (which requires the project to be written in TypeScript, Rust, or something similarly non-simple).
• Web development must be easy (which requires the entire project to be written in a single language), but web applications must work to at least a basic degree with scripting disabled (which requires the project to contain non-trivial amounts of HTML and CSS in addition to JavaScript/TypeScript/Rust/etc).
• Web applications must be fast and not crash (which requires a compilation step with type checking), but it must be possible to iterate very quickly (which requires there to not be a compilation step).
• And so on.

And they keep failing because, quite frankly, they don’t know how to succeed. Most web developers are not grizzled 50-year-olds with decades of experience and a solid understanding of things like type systems and build automation, and most grizzled 50-year-olds with decades of experience and a solid understanding of things like type systems and build automation want nothing to do with web development. Microsoft somehow managed to scrape together enough exceptional individuals to create TypeScript, but they seem to have exhausted the supply of such individuals.

Most web developers don’t even seem to fully appreciate what TypeScript does and why it’s important, let alone have the skill to write similarly sophisticated tools themselves. Consider, for example, Vite not running TypeScript type checking with every build. Vite’s developers cite compilation speed as their motivation for cutting this corner. These people clearly do not understand the importance of correctness checking.

Another example: as far as I can tell, no web application build tools track dependencies between source files for incremental compilation, nor am I aware of any standard format for compilers (TypeScript, Sass, Babel, etc) to communicate that information to the build tools invoking them (Webpack, Vite, Grunt, etc).

Every once in a while there’s a ray of hope, like TypeScript, but that’s all it is: hope. The web developer experience has never been anywhere close to the caliber of developer experience you’ll get with a language like Rust, and sadly I don’t foresee that changing any time soon.

And no, htmx is not the answer to our prayers. It seeks to fix HTML, and HTML is not what’s fundamentally broken.

Like what happens when someone from that instance is in the middle of a comment chain?

Presumably, the same thing that happens if you block that user individually.

Problem: Oppenheimer, unlike JavaScript, was actually competent.

Case in point, actually. Whenever I’m forced to write a giant function, I always get nervous because it could be crawling with bugs that I have little hope of spotting.

Also, I hate mocks. I spent so long learning all the test doubles to pass interviews: what’s the difference between a spy, fake, stub, mock, etc.

Oh good grief. I haven’t even heard of half of those, and I’ve been writing code longer than most interviewers.

Also doing it with dependency injection and all that.

After struggling with several DI frameworks, I’ve come to the conclusion that DI is far too opaque and unpredictable to be useful.

OOP is also intentionally opaque, mind you, but debuggers can see through it if necessary, so that’s fine. DI, on the other hand, is opaque even to debuggers!

I much prefer having an in-memory database than mock what a database does.

I much prefer using the same DBMS for tests as the one used in production. That way, I can use its special features (like arrays as query parameters), and avoid bugs resulting from differences between DBMSes (which would only appear in production).

You obviously can’t always get replacements for things and you’ll need to mock and I get that. I just prefer to not use them if I can.

Indeed, and you usually can. Even if your system involves a bunch of services that normally run on different machines, who says you can’t spin up instances of them as part of the test? Tests are arbitrary code and can do anything that any other program can do, including starting subprocesses. Just be sure to terminate them once the test is finished, even if it fails.

It also forces you to not have giant functions.

No, being unable to read giant functions is what forces me not to have giant functions.

It doesn’t even sound great in theory. It sounds backwards in theory.

Which is pretty funny, because as far as I can tell, they’re actually Stalinists.

Since when were Turing machines ever nondeterministic?

There are plenty of things wrong with the tool itself.

For example, there is no way to define an equality and hash function for a class, so there is no sensible way to use arbitrary data structures as Map keys.

But does anybody ever thank me for never forgetting my password? Noooooo. Grumble grumble.

It’s super effective! Humanity hurt itself in its confusion!

It’s over nine one thousand!!!

Unless you subscribe to specific communities (or people, in the cast of Mastodon) those posts will never reach your server. So you don’t really have a “Federated” timeline

This seems like a pretty serious flaw in the federation protocol. Hope it’s fixed at some point.

Hello from Lemmy! Federation is neat.

Do you also have a few million dollars under your mattress? 😁

Perhaps the default should be a per-instance setting and/or a user preference.