[Jcampuzano2]

Knowing basic web technologies to a deep level are very important and highly valued, especially so at larger companies where they know that the framework itself is a minor detail for skilled engineers who can pick up and be productive in any framework in less than a weeks time, so I do think you can command high market value with very deep knowledge of the platform itself.

However, that said I agree with you. Especially so when it comes to things like consulting work, contracting, etc. Having worked alongside the people who do the hiring or make the decision as to whether to bring somebody in for an interview at all in big consulting firms, they basically automatically disqualify anybody who doesn't already know the stack they prefer to use or that the client they are currently hiring somebody for uses. And this is including technical architects, so this isn't even just an issue of non-tech aligned hiring people. They simply don't want anybody to have to ramp up on the tech itself regardless of skill.

For these types of roles it is very important to be up to date if you want to stay hirable, or the hiring manager will just throw your resume in the trash before it even gets in front of an engineer who can evaluate your skills without the buzzwords.

[DidYaWipe]

Lots of reference in these comments to "core" or basic Web technologies. What would you say they are? What's the highest-level thing that's still "core?"

[tylerchurch]

I always interpret “core” as “no libraries”. What can you do with just your browser and an HTML file?

Poke through MDN and see what you find.

Do you know about dialog? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

MutationObserver? https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...

URL? https://developer.mozilla.org/en-US/docs/Web/API/URL_API

[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).

[austin-cheney]

The DOM, events, CSS, WCAG. If you want to get into TypeScript then just type and interface keywords. If you want to get into Node then it’s the library system in Nodes documentation. That is it.

I never mentioned build tools. You can write your own quickly.

[austin-cheney]

The DOM, events, CSS, WCAG. If you want to get into TypeScript then just type and interface keywords. If you want to get into Node then it’s the library system in Nodes documentation. That is it.

Here is a practical example: https://github.com/prettydiff/wisdom/blob/master/performance...

I never mentioned build tools. You can write your own quickly, and you don’t need all the framework bullshit. That stuff is for insecure people and otherwise just slows you down.