[simonw]

    var checkbox = document.querySelector(
        "input[type=checkbox]"
    ), container = document.querySelector(
        "#wrapper"
    );
    checkbox.addEventListener("change", () => {
        if (checkbox.checked) {
            container.classList.add("checked");
        } else {
            container.classList.remove("checked");
        }
    });

Then use CSS to show or hide the message inside the container based on if it has class "checked" or not.

You can get a whole lot done with very little code if you learn to take advantage of the three-legged stool of HTML, CSS and JavaScript.

[RodgerTheGreat]

or save a conditional:

    container.classList.toggle('checked',checkbox.checked)

[simonw]

I forgot about .toggle(), that's definitely neater.

[SeriousM]

That's the right way of separation of concerns: handle states with code, look/layout with css.

[nsonha]

funny you should say that, because there is no explicit state here, what happens when there are 10 checkboxes? Just read `.checked` in the dom element?

[simonw]

Yes that would work great.

Usually for things like that I'll come up with a CSS class that means "set it up so this element has its class toggled based on the state if the checkbox it contains". Sometimes I'll use data- attributes for additional configuration.

[Zababa]

I think there are two ways of looking at things: the DOM is the view layer, created as a function of the state (React and things like that), or the DOM is the state and the view part is handled part by the DOM and part by the CSS. CSS already automatically creates the view as a function of the DOM.

[nsonha]

you may think they're equal but to me one of the two is fundamentally flawed. I speak from the experience of developing for Android and web, but I suspect in all UI platforms, it's best practice to have the source of truth out of the views and treat states in the native views (checked) as derivative throwaways

[Zababa]

I don't think they are equal. On the web, the "react approach" is seems to be really good if not the best for medium-complexity apps. Under that, it creates more complexity than it solves and over that it can affect the performance too much. The thing is, we work in a industry that has to deal a lot with change. Using the "react approach" from the beginning when your website is not that complex can be a way to future-proof it. But you're going to pay a cost of increased complexity at the beginning. I think that's the opposite of technical debt in a way. Technical investment maybe?

[nsonha]

There is no cost, these are just 2 diferent styles of code, there is no reason for one way to be more expensive than the other. If you find react cumbersome then find a better way, a library, or vanila. Just because you dont do react doesnt mean you should write vanilla js in a spagetti manner. The "react approach" is only awkward if you fixated on the mindset that there is something special about "the platform", that you should write code in such a way that spread the platform dependencies all over the place.

In all of my programming exp, back-end or front-end, "the platform" is what people try to restrict access to and abstract away so that they can think about the problems they're solving. Only on the web, after decades of putting up with a then crappy platform, now better, that developers now have a Stockholm syndrome for it.

[pgcj_poster]

There's already a :checked selector, so you don't really need JavaScript at all in this example.

  <input type="checkbox" id="discount">
  <label for="discount"></label>
  <style>
    #discount + label:before {
      content: "Click me to apply fake discount!";
    }
    #discount:checked + label:before {
      content: "Click on me to remove fake discount";
    }
    #discount + label:after {
      content: "You have not availed discount";
      display: block;
    }
    #discount:checked + label:after {
      content: "Discount Availed!";
    }
  </style>

[simonw]

Even better!