[DidYaWipe]

Thanks! I looked at MutationObserver and wondered about the example:

    if (mutation.type === "childList") {
      console.log("A child node has been added or removed.");

How can such changes occur to the DOM that aren't brought about by other code on the page? And if other code on the page brought them about, why didn't it also perform whatever the MutationObserver is doing?

Anyway, not to get too mired in details... I've done no front-end dev, but I'm building a mobile app that'll need administrative pages for me (or, hopefully, other staff) to use. Is there a "next-level up" front-end layer that provides convenience functions but still isn't a bloated framework liable to be obsolete?

I like to hand-roll stuff from the basics, by all means, but I already have my hands full with a back end and a client application.

[hecanjog]

Consider an HTML fragment being inserted into the DOM as a result of a user interaction. If the fragment contains elements which need event listeners attached, or any other js-enabled behavior (like a progressively enhanced select component) the mutation observer can see it arrive (or leave) the DOM, and attach or remove the listeners. You write your initialization code for the enhanced select once somewhere, and then use mutation observer to handle its lifecycle management. (Edit: this isn't a theoretical pattern, it's what I'm using in our frontend at work.)

[iainmerrick]

How can such changes occur to the DOM that aren't brought about by other code on the page? And if other code on the page brought them about, why didn't it also perform whatever the MutationObserver is doing?

You're right, that approach would also work. But MutationObserver can be useful for decoupling, to reduce complexity -- you don't need to think about all the possible ways some part of the page could change, you just want to be able to say "if the contents of this div change, do this".

I used it in a recent project for layout animations. I needed to measure the size of a particular div that slides in and out, to position it correctly, so I added a MutationObserver to re-runs the calculation any time there are changes.

Is there a "next-level up" front-end layer that provides convenience functions but still isn't a bloated framework liable to be obsolete?

Well, pretty much all frameworks will claim to be that...!

I think some things you might find useful are:

- Polyfills. Just use standard browser APIs (which are getting really good these days) but use polyfills to ensure they work correctly/consistently across different browsers.

- Web components. I haven't used these myself, but as I understand it, it's a way of packaging JS modules so they can be used exactly like new HTML tags. So somebody could make a nice <calendar> component for example. I've heard that Lit is a good library for developing web components, but it's not a framework in the sense that it will take control of your whole architecture.

- Vite. This bundles your HTML, scripts and assets -- you can develop your code in vanilla HTML and JS, and Vite will package it up neatly for publishing. It's really fast and reliable. Tons of frameworks are built on top of Vite, but you can go quite a long way just with Vite on its own (and there isn't any lock-in as its input is just HTML).

[joestrouth1]

"How can such changes occur to the DOM that aren't brought about by other code on the page?"

- The other code that made the change may have been written by another team or a third-party organization

- The code setting the MutationObserver may not originate from the page e.g. a browser extension or bookmarklet

[ivan_gammel]

Let‘s say you have an UI pattern that styles some element and defines possible interactions with it. You do not want business code to do that job, so it’s easier to have a decorator that detects certain elements on the page.

(This is a purely theoretical example coming from someone with lots of architectural experience, I didn’t use it before).