> Web dev nowadays don't need to learn how to build compilers, vms, etc. For me they are separate branch / subject, same with gaming which is also a separated one.

Disagree. Most JS frameworks require toolchains these days, particularly in the form of Babel (parsing/compilation) and Webpack (linking). If you understand the way compilers and linkers work, then these web tools are more useful.

Sadly, a lot of web devs just think it's too complicated and so copypasta their configs without understanding, but lots of frustration.

> If you understand the way compilers and linkers work, then these web tools are more useful.

I'm interested with it. Got any examples at what can they be used further if you know compilers and linkers? So far without understanding it I can use it for compiling react.

However I didn't said that those skills aren't useful. They just aren't requirement for CRUD / web devs. And I'd argue that learning business side is far more useful than technical side (after you've learnt up to certain level)

> And I'd argue that learning business side is far more useful than technical side (after you've learnt up to certain level)

This is an excellent perspective, and a recommendation for OP I hadn't thought of. Learning how accounting or finance works, how sales works and then how to think strategically about what each faction involved in a business is interested in (including customers and various types of employees) can be very helpful. Appreciating and starting to understand design can also be helpful.

> I'm interested with it. Got any examples at what can they be used further if you know compilers and linkers? So far without understanding it I can use it for compiling react.

I'd take a look at the sources on GitHub at first. Maybe clone them, set breakpoints and start debugging.

In React, the compiler (based on Babel) is going to translate JSX into (virtual) DOM operations, plus handle some of the JS features that aren't supported in the vanilla browser implementations. Webpack is going to read in these translated sources as well as the React runtime (which has the logic handling virtual DOM operations) and any other assets you use (images, CSS, etc.) as represented in JavaScript. With everything in the same namespace, Webpack can then begin "linking" the "objects" and resolving references. It will then begin writing them all out as you specify in the webpack config.

This is highly analogous to e.g. `gcc` (C compiler) and `ld` (linker). The compiler takes sources and translates them to something the machine understands, the "object" files. But the references to anything outside of each object file are all broken. The linker takes all of the object files and resolves the references, including to runtime dependencies like "shared libraries"/DLLs, and then it organizes the final outputs in a way the programmer specifies (usually there's a default that just works, but for some types of outputs, you write "linker script").

Also like with webpack, there are all sorts of kind of lousy tools that aim to automate the creation of the build scripts, like Automake or CMake. These tools do save time in most cases, but they are leaky abstractions that are quite complex to understand vs. the relatively simple (though also difficult) compiler and linker, which are fairly easy to reason about with some experience. React-scripts is I guess the latest analogous tool I've seen that tries to hide away webpack, though I've also seen create-react-app and razzle.

The beauty is, if you understand how people were dealing with some of these issues in compiling C or FORTRAN or whatever 50 years ago, it's easier to see what the pitfalls and strengths of the current web toolchains, despite the complete dissimilarity on the surface. The patterns are quite similar.

EDIT: it might be useful to find a tutorial you like on regex and parsing. (Strict) regex are equivalent to "deterministic finite automata," which are conceptual, abstract virtual machines that transition between states based on inputs. Parsers are more related to a class of automata called "pushdown" automata (though there's a lot more variation, and parsers are not actually implemented as PDAs despite some loose equivalence). Understanding the hierarchy of automata (DFAs up to Turing machines and then the purely imaginary ones like "oracles"), as well as the distinction between deterministic and non-deterministic and how those can be made equivalent (for some trade-off in real world efficiency) is also useful. It might also be good to study and explore BNF-type grammars and parser generators. Some of these exist in JavaScript, like Ohm. Ohm is particularly useful because it has a visual browser-based editor that explains exactly how a parse is being performed given some test input and grammar. Once you kind of understand that, you can experiment with other kinds of parsers (Earley, LALR, recursive descent, etc.).

Writing a small calculator from scratch or building your own JSON parser could be useful tools.