Sorry for the tangential question, but do people working in frontend feel that knowledge of the web fundamentals is not present in newer developers? Like the fundamentals of HTML, HTTP, CSS and vanilla JS?
I am no longer very exposed to the frontend landscape but I am curious if those who gained intimate knowledge of those technologies back when it was all that was present might have a niche lucrative role in the future of web tech. I know they are quick to learn, but the idiosyncrasies were always an arcane art.
I've been a full stack developer for a long time and I focused more on the front-end recently. I had to build a large team, so I attended a lot of interviews (a LOT, we are talking three digit numbers, for a remote position with global availability) as an evaluator. There is this very-well-paid 10% top coders who can do everything and do it well, 30% who are very good in their area of expertise but lack quite some general knowledge, 40% who can do things with a very specific choice of technologies and tools, and the rest 20% are clueless enough to give answers like "I can't solve fizzbuzz as I'm not a backend developer" (quote from an actual interview).
I'm not sure how it compares to the backend world, but here everybody is fighting to hire the top 10%, while the lower tiers keep applying to many positions to get hired eventually.
I recently saw a blog post from a front end dev who was completely amazed about finding out that you can send an HTML form without JS, followed by equally amazed comments.
So, yes.
Judging by people who make links via click listener on DIV, the answer is no.
On one side it’s understandable that people work more on abstractions and are more productive (e.g. learn React first, then maybe understand how P is different from DIV), on the other side it’s incredibly frustrating to see links that aren’t real links even on Google’s websites.
> people work more on abstractions and are more productive
Well, that's one way to define "productive". If a site contains links that are "clickable divs" or has layout shifts, or whatever other "modern" atrocity, can the work really be rated as "done"?
Without done work, productivity is either zero, or undefined.
It's reinventing what browsers can already do if you use an HTML link <a href="…"> so it's inefficient. It's also inaccessible.
* It's not in the focus order so you can't keyboard navigate to it. You have to add tabindex="0" to the div to correct that.
* It's not keyboard operable. You have to add not just a click listener but also a key press event listener and check that the key pressed is Enter.
* It has no role so a screen reader user doesn't know that it's a link. You have to add role="link" to it.
It's also missing useful user experience features of actual links
* You can hover a cursor over a real link to see the destination URL in the status bar.
* You can copy a real link's URL.
* You can use alternate clicks or a contextual menu to open a link destination in a new window.
Search engines can't find and index the destination of fake links.
HTML means HyperText Markup Language. HyperText means “documents linked to each other”. By not using <A> you’re skipping the core reason why HTML exists, as defined by its name.
The other comment explains pretty well what that causes in the browser.
From the point of view of somebody who has been writing front-end code on and off from the late 90s through to present day:
There isn’t much understanding of the architecture of the web these days.
People commonly think of web development as a combination of two things: a browser environment in which their JavaScript application runs, and a backend that can provide an API for it to use.
HTML is seen as something that is constructed by JavaScript in the browser. HTTP is just the way you get JSON from the API. URLs are unimportant beyond the desire to make what appears in the browser’s location bar look nice. There’s little understanding of how hypertext is supposed to work.
Tailwind is popular for CSS. People construct their layouts and styles by adding numerous very finely-grained classes to every element in a way that resembles inline styles. There’s very little understanding of how to organise CSS – the most common argument I hear for Tailwind is that it’s impossible to keep CSS organised without it, as if the alternative is to just write one big stylesheet with everything in a mess. “Coming up with names for classes is hard” is something I’ve heard loads.
Graceful degradation / progressive enhancement is now niche. Unobtrusive JavaScript is pretty dead. Fortunately, server-side rendering is making a comeback, but unfortunately most of it relies upon running front-end things on the server with JavaScript as a speedup to bootstrapping the JavaScript running in the browser.
Front-end code is now written in the context of front-end JavaScript frameworks instead of what the browser natively provides. Browsers natively support web components these days, but they were devised by architecture astronauts and are not pleasant or easy to use. Instead people write components with React, Vue, Lit, etc., which have varying degrees of interoperability with web components, which very few people care about. If you want to use a third-party component, you look for one that is written specifically for your framework.
The web platform itself has come a long way though. Browsers almost completely agree on how to render things; CSS layouts are a lot easier and more capable; you don’t need CSS hacks to target workarounds for specific browsers any more; people upgrade their browsers frequently; and even when there are backwards compatibility issues, there are a lot of tools that will transcode it to more compatible older code at build time or polyfill at run time.
If you’re an old-school web developer, you’d probably enjoy writing code with all of the new options available to you. But you’ll probably be quite frustrated when working with newer developers who view the web more like a deployment target for an executable than a real platform with unique strengths.
> There’s very little understanding of how to organise CSS
Was there ever? It seems everyone thinks they have the best way to organize CSS. But it's always just a system that makes sense to them and only them. I'm not convinced there's some enlightened way to organize CSS
There are multiple way of organising CSS effectively that aren’t specific to single organisations. But my point wasn’t that there is an “enlightened method” that will solve all of your problems, I was pointing out the common misconception that there are only two options: organised CSS with Tailwind or a chaotic free-for-all.
I think css must be the worst invention in computing, at least all the obfuscated javascript i know is trying to do something (spy on me), instead css just bloats up 800ms on linkedin into the size of war and peace because of how much they throw their weird 6 character psuedohashes in (WHY)
A bloated linked in has nothing to do with css, but with the company behind it. Everything Microsoft touches is bloated, slow, complex, but somewhat functional enough that common people use it. Tech people hate it in most cases.
I am not sure this is related to being a newer developer, the thing is that sources of truth regarding frontend languages are not obvious to find, contrary to say the official Golang tutorial
I am amazed at the quality of the Mozilla Developer documentation though it's a good place to learn
I am no longer very exposed to the frontend landscape but I am curious if those who gained intimate knowledge of those technologies back when it was all that was present might have a niche lucrative role in the future of web tech. I know they are quick to learn, but the idiosyncrasies were always an arcane art.