Opinion of one frontend dev:

The basics are important (HTML/CSS/Internet/basic JS), but after that, I think it's generally more helpful to "BUILD BUILD BUILD", as the parent said, than to expand your breadth across multiple similar libs/frameworks/concerns.

In the detailed roadmap, for example, there's a lot of similar tooling with purple checks (recommended) and green checks (alternatives that do the same thing). It isn't necessary to know all of them, and may not be helpful to explore so many options to begin with. As a junior, chances are that those decisions will be made by someone else anyway, and you'll just have to implement working code in whatever tech stack they've already chosen.

Instead, just pick one (honestly, probably React + Next, not because it's the best but because it's the most popular right now, and many of those skills will transfer to other frameworks anyway) and try to build a semi-realistic project.

The hard part of frontend dev (as a specialization), IMO, has to do with state management and async stuff, because that's where the actual "programming" comes in, vs the "declaring" of HTML/CSS/basic UI components & screens. By that I mean: How do you sync up your frontend UI with the backend data store, both from and to the user, in a way that balances good UX with backend constraints, security concerns, accessibility, maintainability and debuggability, performance, cost, etc.

If you're just building mostly static pages (like blog posts, marketing landing pages), you won't have to do most of that, but companies don't generally hire frontend specialists for sites that simple. Any full-stack programmer or IT person can generally do that these days, and so can many non-coders who use no-code/low-code tools. That's not where frontend-specific work is.

If you have an interest specifically in the frontend, I think it would be more helpful to try to build a realistic frontend "app" (as opposed to a bunch of static informational pages) and learn to solve the real-world problems that you'll face along the way, like routing, state management, internationalization, authentication, race conditions, UI states, optimistic updates, image and video optimizations, etc.

For example, take a look at this list of MUI templates: https://mui.com/store/#populars (MUI is a UI kit with powerful components that you can use with React, and people can "compose" apps out of those components). You'll see mostly dashboards and ecommerce apps.

Try to build one of those if you can (either using MUI and those same templates, or whatever framework you choose, including writing it from scratch), and hook it up to either mock APIs (like simple endpoints that will always return the same data, or automatically auth you, or whatever -- you don't have to write a real backend if you don't want to work on that in the future) or you can connect them to real-world cloud services and their free plans.

But at the end of the day, having a complete project that can deal with client-server state, work across different device sizes, be reasonably performant, etc. is a big enough "final project" that will closely mirror real day-to-day frontend work and teach you useful skills. I think that would be a better use of your time than learning every last JS framework out there.

Doing so teaches you to reason about what is actually happening on the client and the server and how to manage the HTML accordingly, whether you mutate the DOM directly or use a framework like React + MUI.

-----------------

Now for a more controversial take: IMO (in disagreement with the parent), for most employers, I think frameworks are actually more important these days than in-depth Javascript know-how. Most apps you'll end up building are bog-standard business apps and probably not anything super fancy (unless you specifically want to go down that path, working for companies with heavy and truly complex frontends like Figma, FAANG, etc.).

Keep in mind this is my opinion, only, as someone who's never worked for FAANG but did work for many smaller businesses. If you're just one of the endless frontend devs for generic small or medium companies, there's not really a need to learn JS in depth, like data structures and algorithms, because those are generally just optimizations that you can learn on a case-by-case, as-needed basis. AI can generally provide good-enough guides for those when you come across them (like how do I optimize this search, what sort of data structure do I need for this kind of user input).

The rest of the time, you'll generally be working in frameworks, writing very simple and (and hopefully maintainable) code, tying new components and pages into existing state management and routing solutions. Those are generally not part of the vanilla JS/Ecmascript spec, but proprietary, framework-specific solutions. This is the overwhelming bulk of the work, and it's really about reading docs and adhering to their recommended practices rather than trying to out-smart the framework and building something better. Because whatever you build will have to be maintained by someone else, eventually, and they generally hate it when you diverge from established practices for no good reason, or if you did it just to prove you are very smart.

That's one of the distinctions between academic computer science (with its emphasis on "proper" coding) and real-world business apps (how can I deliver business value with lowest cost and frustration, working with other devs and teams of various skill levels). Your employer generally won't care about the "quality" of your code per se (and many managers won't be able to even evaluate it effectively), but simply your output (does this page work, does it have good UX) and your relationships (can you work with the designer and take their Figma file and implement it as close to pixel-perfect as possible, can you survive under an Agile management system and reliably deliver story points), things like accessibility, performance, responsiveness, etc.

That's a long-winded way of saying that many frontend devs make a living working in someone else's framework, where knowing the nuances of that framework is far more important than being able to create the world's fastest JS sorting algorithm or whatever. Most of our jobs is just copypasta and shimming together NPM libs.

On the other hand, if you look down on that kind of basic work (and I wouldn't blame you if you did!), then yes, it could be helpful to be an expert Javascript developer -- the kind of person who not merely uses frameworks to build standard apps, but might be involved in the creation of those frameworks themselves (i.e. you'd be in Meta working on React or Google working on Angular, or contributing to the various open-source/open-core frameworks). But for every superstar dev like that, there's probably hundreds (thousands? millions?) of us just doing the basic stuff to get by and get a paycheck.

Anyway, sorry for the rant. You can figure all that out later. For now, just BUILD BUILD BUILD! :)