[localghost3000]

> And if you’re an engineer, you will be able to retain much higher market value over time if you dig into and understand core web technologies

Been working in FE for nearly 20 years and lived through several major paradigm shifts. I think I am qualified to have an opinion here:

I definitely think that you will be a more well-rounded engineer if you know all the core web tech. So strongly agree there. I am skeptical, however, that it will make you more attractive on the job market. It's not that knowing this stuff doesn't matter, it's that folks that make hiring decisions tend to pattern match. The fact is that if you want to maximize your "market value", you still need to be _very_ good at React. This is table stakes. Everything else is great, but if you don't have that foundation, you're limiting your options.

Maybe that is what the author meant and I am just misreading.

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

[colordrops]

I've been in the market for 30 years, had some of the best jobs on earth doing FE, and only did my first React project last year. Maybe I'm an anomaly but I never felt that not knowing React has been a problem. "table stakes" is too strong a phrase.

[CognitiveLens]

To be fair, "30 years of experience" likely opens more doors than any particular skill listed on your CV - that doesn't reflect the way that a majority of junior/mid-level devs need to present their abilities, where pattern-matching is an unfortunate norm, particularly when there are orders of magnitude more applicants than open roles.

[colordrops]

Everywhere I've worked would have judged heavy emphasis on framework expertise rather than fundamental CS concepts and web standards as a red flag. I don't think it's that rare.

Mentioning ability in React is obviously not a bad thing but some people make it their whole resume.

[jakub_g]

Counterargument: my colleague with 15y exp (10 C++ & 5 Angular/Vue) has been unemployed for 2yrs already because he has no React on the CV and no local company wants to hire him (secondary size tech hub in the country, EU). He's probably have to force-relocate soon.

[coffeebeqn]

I’d rather have my FE friends learn about API design, Unix tooling, networking, testing, hundred other things than keep re-learning a framework doing the same thing over and over

[ForTheKidz]

> The fact is that if you want to maximize your "market value", you still need to be _very_ good at React.

In some sense yes, but full-stack engineers are nowhere near the top of "market value". Frontend has a pretty hard ceiling on compensation. Past a certain level of advancement you'll never need to build a UI again.

[localghost3000]

I was speaking specifically about FE devs.

[vlucas]

Also working in FE for the past 10+ years with 20+ years total dev experience, and I agree with you.

The vast majority of companies out there - even large ones - don't really care, screen for, or hire for core fundamentals. They hire for "good at React" or "lots of experience with Next.js", etc. Fundamentals are great if you are building things from scratch, but the truth is companies very rarely do that. They just pull off the shelf things with large ecosystems and good documentation and use them. Just get good at those things and it's much easier to get hired. You can learn the fundamentals along the way.

[skwee357]

I have heard of first-hand stories where people interviewed and been asked to have experience in THIS particular framework. Despite the fact that the person had years of FE experience, worked with a similar framework, they were, eventually, rejected most likely due to the fact that they did not have experience with THIS particular framework.

So yeah, while I'm with you on the fundamentals, I'm also with you on the fact that it might not be the best approach if you want to stay employable.

[Cthulhu_]

Yeah, the issue is that those frameworks add their own paradigms and abstractions, almost to the point where you don't need to worry / know about the underlying core web standards.

However, this is also a missed opportunity, in that those standards haven't stood still. That is, a lot of web developers are stuck in 2015 and still use Angular / React, Bootstrap or some other framework, LESS/SCSS. Meanwhile in CSS there's things like oklch colours, advanced variables and selectors, layers, etc - I only learned about them recently while working with another developer who has in fact kept up with them.

That is, I'd argue that companies, designers, etc are being kept behind by sticking to these frameworks, because they can only design for and build in what those frameworks support, instead of what is now possible.

Likewise, React Native or other crossplatform app building toolkits, instead of truly understanding the underlying operating system and tools. For a lot of these same companies, things like widgets, live activities, watch apps etc are infeasible because their frameworks don't support them (or in the case of widgets, the frameworks take up all the memory budget). But I believe that if you want a great app experience for your end users, you gotta have dedicated app developers and -designers.

[speleding]

Or..or..or.. don't use a framework!

You can do so much with HTML5 + CSS + Vanilla JS nowadays. I think the default "let's start by picking a framework" is often wrong, unless you know from the start this is going to be a large SPA. Yes, you'll write a little bit more boilerplate for stuff you get for free from a framework, but it will pay itself back in the long run because there is no upgrade treadmill.

[localghost3000]

Can you help me understand how this relates to my comment? We’re talking about what skills make you more marketable.

[speleding]

I replied to the wrong comment! Sorry, I can no longer change it.

[localghost3000]

Ha! All good. Been there myself.

[Cthulhu_]

React and / or Angular, I was out of things for a few years but didn't realise that under water, at least in the Dutch market, Angular is still very popular.

[larodi]

Sorry, but people been maximizing value with ASCII-rendered tables of numbers at least since DB2 and Oracle came out. The UI has always been regarded as a key to success, but there are plenty of examples of ugly-as-fuck UI, which otherwise does okay for whatever means was created.

Add to that the fact that Perplexity-like search-RAG-services would very soon start munching not only search, but a plethora of APIs exposed by various services. And perhaps incur costs on the user for it, but the point is nobody cares about nobody else's UI that much. In fact people would love to have dashboards of data shown for their own needs in some open manner, and this is what we should expect to come, not a fancier version of SVG/canvas/React/WEBGL whatever.

last time UI was disruptively innovated was when reactive-functional-spreadsheets were introduced at the end of 90s and it stayed as an engineering concept more than actual implementation.

later on perhaps html/browsers could've disrupted something, and it did for a while, but very soon (only 15 years later) the soc.net.bros were already abusing all the good things in it and now we mostly have closed apps running on top of the open web infrastructure, which is basically the same as running closed apps on top of the open linux ecosystem.