The Daily WTF: Curious Perversions in Information Technology

Jonathan Lydall · 2026-02-09 Reply Admin

Even ignoring the other WTFs, the nesting also makes readability more challenging than it needs to be, you can decide for yourself if the following (also assuming the User.Query().where(...).first() is a promise) is easier to read:

passport.authenticate('local', { session: true }, async (err, user) => {
  if (err) {
    res.send({ success: false, message: 'Error authenticating user.' })
    return;
  }

  if (!user) {
    try {
      const targetUser = await User.query()
        .where({ username: req.body.username })
        .first()

      if (!targetUser) {
        res.send({
          success: false,
          message: 'Incorrect username or password.',
        })
        return;
      }

      const hash = User.hashPassword(
        targetUser.password_salt,
        req.body.password
      )

      if (hash != targetUser.password_hash) {
        res.send({
          success: false,
          message: 'Incorrect username or password.',
        })
        return;
      }

      res.send({
        success: false,
        message: 'Incorrect username or password.',
      })
    } catch (err) {
      res.send({ success: false, message: 'Internal server error' })
    }

    return;
  }

  if (user.firstLogin) {
    //......
  }
})(req, res, next);

2026-02-09 Reply Admin

Allowing Javascript in the backend is just begging for WTFs.

Remy Porter · 2026-02-09 Reply Admin

I mean, let's be honest, it creates a lot of WTFs on the front end. Sure, we can have the whole "blame the user, not the language," but JavaScript is emphatically not a sane language. It's gotten better, but the demand for backwards compatibility means that it will always remain a little insane.

2026-02-09 Reply Admin

Javascript is like that hot but crazy chick you dated in college. Oh the things she will let you do if you know how to flex her features. But she ain't the kind of girl you want to take to production.

2026-02-09 Reply Admin

An external problem is that the use of JS invites inexperienced developers. Everybody can write JS, after all! So it makes the step to contributing to the back-end smaller. Then, under pressure, that fatal step is taken (Can you write JS? Good! Here's the server repo.), and before you know it, your tech debt is larger than your node_modules directory.

2026-02-09 Reply Admin

My guess: the code paths were more sane in the past and someone came through and removed all error details in the name of security. Thus a bunch of paths that do exactly the same thing.

dpm · 2026-02-09 Reply Admin

I've always hear JavaScript put down a lot here, and I know y'all are not stupid, so someone's gotta link me to a fair explanation of why it sucks. I created a widely used application for XXX and am currently maintaining two applications for ZZZ --- all three are .NET MVC C#/Razor/jQuery/JavaScript/EF on SQL Server . . . and all three are IMHO pretty good. Solid, reliable, easy for someone to come in raw and figure out how to fix/add something with a minimal learning curve. It helps that I work solo, so I have total control of the entire SDLC, but still I just don't see the problem with JavaScript. Am I lucky or a coding god or just intuitively avoiding the bad spots?

Addendum 2026-02-09 15:55: "I'm always hearing"

2026-02-09 Reply Admin

Like Remy says: "It's gotten better, but the demand for backwards compatibility means that it will always remain a little insane." One of the things I always found slightly not sane is that it didn't have an integer type, all numbers were floats (I say "were" because now we have things like Int8Array). One definitely insane thing is the whole 1+"1"="11" thing. It may be a help to newbies, but it's an annoyance to more experienced developers who know how data types are supposed to work.

2026-02-10 Reply Admin

JS in the backend is particularly grinding. It's inefficient, and is too permissive. There's no way to validate data, except by doing it yourself. Any path that avoids such validation can send out bad data, or worse, store it in the database. And typescript and async have improved life, but back in JS callback hell, the dangers of using the wrong object were considerable. It's a pretty loose programming language, yet many people think they can write it.

2026-02-10 Reply Admin

The reasons JS sucks are many, but ultimately it all boils down to the fact that it is a badly designed language whose flaws are greatly exacerbated by the fact it is marketed at the lowest common denominator in terms of developers.

The language is too permissive, too loose and generally too undefined. And when you combine that with the fact there is no compiler to hold your hand it's very easy to write very bad code through ignorance or just by mistake.

This is newer fine, but it would be tolerable if it was some sort of high speed low drag tool for elite developers who know what they are doing. But it ain't.

Instead what you end up is the largest single network of interlinked software ever created built using a language that's as easy to screw up in as raw C by people who can barely be relied on to stop eating glue long enough to write the code.

And the world runs on that crap.

This is why I drink.

MaxiTB · 2026-02-11 Reply Admin

I've always hear JavaScript put down a lot here, and I know y'all are not stupid, so someone's gotta link me to a fair explanation of why it sucks.

JavaScript is a type-less language with a ton of legacy baggage. So for example to achieve the same quality level as say a typed language like C# or Java, you would need to write around 10-100x more tests - basically making sure that with every possible auto type cast the cast works as expected. Obviously nobody writes those tests, so you always end with lower quality code than a type-checked language. Cause spoiler, no matter how good you are, humans make mistake and even if you are a god, people implementing APIs that you use might not be and suddenly return an unexpected type that messes with your logic while you didn't even touch the code. And spoiler, the last example is not only common with JS libs, it's expected by this point.

So yeah, TypeScript is a work-around but still comes with a lot of issues. It's similar to Java's generic, workarounds only work as long as you don't end up with code written by someone who thought he knows better and is messing around on a low enough level to mess with conventions and suddenly you end up exactly where you have been with JS. In other words, anything you build on weak foundations will also end up being weak - there's just paint over the cracks.

2026-02-12 Reply Admin

As an old carpenter once put it, it's foolish to build your house on sand. So we built the whole world on it instead.

Invalid Passport

Leave a comment on “Invalid Passport”