[hombre_fatal]

Yeah, I don't know how someone can say that with a straight face to other engineers.

It's like people just talk in memes or something.

This is how a lot of discourse feels these days. People living in very different realities.

Though in this case, seeing the most complex C++ app they've built would illuminate what's going on in theirs.

[const_cast]

It's not a different reality. To give perspective to what JS I've dealt with - I worked a couple years on a legacy webapp. It used vanilla JS and the only library used was jQuery. It heavily used iframes for async functionality in combination with XSLT to translate backend XML apis to HTML.

Opening up a 10K lines JS file is like jumping into the ocean. Nothing is obvious, nothing makes sense. You're allowed to just do whatever the fuck in JS. Bugs where always ephemeral. The behavior of the code was impossible to wrap your head around, and it seemed to change under your feet when you weren't looking.

Now, the backend was written in old C++. And yes, it was easier to understand. At least, I could click and go to definition. At least, I could see what was going in and out of functions. At least, I could read a function and have a decent understanding of what it should be doing, what the author's intention is.

The front end, spread across a good thousand JS files, was nothing of the sort. And it was certainly more buggy. Although, I will concede, bugs in C++ are usually more problematic. In JS usually it would just result in UI jankyness. But not always.

[sroussey]

> You're allowed to just do whatever the fuck in JS.

I think that’s a feature not a bug.

But then again, I generally like and use Typescript.

[const_cast]

It's definitely a feature when you're starting out. But as the codebase grows and ages, it becomes a bug.

The problem is that the behavior becomes so complex and so much is pushed to runtime that there's no way to know what the code is actually doing. There's paths that are only going to be executed once a year, but you don't know which ones those are. Eventually, editing the code becomes very risky.

At this particular codebase, it was not uncommon to see 3, 4 or 5 functions that do more or less the same thing. Why? Because nobody dared change the behavior of a function, even if it's buggy. Maybe those bugs are the only thing keeping other bugs from cropping up. It's like wack-a-mole. You fix something, and then the downstream effects are completely unpredictable.

It becomes a self-eating snake. Because the codebase is so poor, it ends up growing faster and faster as developers become more risk-averse.

[Capricorn2481]

> The problem is that the behavior becomes so complex and so much is pushed to runtime that there's no way to know what the code is actually doing. There's paths that are only going to be executed once a year, but you don't know which ones those are. Eventually, editing the code becomes very risky.

It's clear you've worked on a really bad codebase, but this is totally different from what you were originally suggesting, which was null being a bigger problem in JS than C++.

What you're describing is frontend development with JQuery, not the capabilities of JS. Now, I don't like NextJS for a lot of reasons, but code organization is not one of them. Everything you're complaining about is dead simple in NextJS. Functions are localized, tracking localized state is easy, and even the older React state libraries have lots of support for tracking and visualizing the more global state changes.

I will die on the hill that JQuery, outside of very small interactivity, is fucking bad. People use JQuery terribly and it creates spaghetti code where you can't tell what the execution path is. People don't document QA testing. And JQuery makes you target html attributes to make changes. That's fun if you have to do it once, it's terrible if all of your app interactivity relies on it.

But that's not due to "undefined", and it would be 100x worse in C++. I am assuming the C++ codebase you compared it to was not a DOM manipulating app?

I don't like NextJS for performance and market reasons, but the codebases I've worked on have been very clean.

[const_cast]

IMO jQuery is a symptom, not a cause. It’s the natural end-state of a stringly-typed “do whatever the fuck you want” attitude. You can create just as much spaghetti without jQuery, jQuery just lets you do it with less characters.

The horrors I’ve seen. Constructing a custom string based off of user input and then tacking on () and calling it as a function? We can do that? Apparently yes we can. The most cursed type of polymorphism where nothing makes sense and you’d have more success communing with the dead than deducing the control flow.