The article mentions "web fundamentals" and "getting back to the fundamentals". Sounds great! Would anyone care to have a conversation about what this means? Like does the author mean DOM manipulation or TCP stack? I feel like this is pretty broad and even though I've been doing full stack for a bit now I'm suddenly not sure if I know the fundamentals.
I think a lot of people are yearning for the "good old days", where you'd install Apache, drop some .php files into /var/www and start hacking around with only static HTML and maybe a sprinkle of progressive-enhancement JS here and there. I think it's totally okay way to build a dynamic webpage. But web application? Not so sure.
Everyone thinks they have a web application but a lot of the React I get asked to build could have easily just been a dynamic webpage (it is usually a dashboard). I think there is an over-emphasis on what constitutes a "web app".
I think "web fundamentals" here might mean DOM manipulation, browser-native APIs, default form inputs. Stuff like <input type=date> and document.querySelector() and appendChild(), which are often abstracted over or replaced with frameworks.
He's missing the bigger picture, IMHO. Nobody goes back to fundamentals because the industry is not allowing the role to do that. FE engineers don't have control over the codebase to this degree, and the expectation from the company is more about business profit, more usage, etc., instead of building something that will not need to be rewritten.
In other words, the article misses the huge factor that companies don't care enough to allow FE engineering to be about building things properly, and instead make it something akin to a product owner with technical skills.
Besides knowing JavaScript well, there are so many stable web APIs that are not used often. IndexedDB, WebRTC, PWAs, WebComponents, service workers, web/shared workers, Broadcast Channel API, File System APIs, Cache API...
