<input name="foo" type="text" autofocus>
Autofocus & tab order are a nightmare-tier mission if you absolutely have to get them right but find yourself trapped inside some dynamic DOM circus.
As far as I am aware, whatever magic is happening inside the browser's HTML engine is infinitely more reliable and predictable than what any JS framework could provide on top. JS certainly won't be making it faster or more responsive.
A common experience has been with new grads who have a lot of experience with tailwind. They're used to being able to just apply a tailwind class for everything. However, I find they often lack the understanding of what is actually going on at a css-level so are unable to easily do anything that breaks the tailwind mold. I often have them sit down with a more senior developer to watch them use raw css (with some developer ergonomics like styled components or sass) for a bit, and they come away with a new appreciation for how the fundamental languages of the (modern) browser are quite expressive and powerful.
What do you mean by this? You still use CSS rules and selectors to style React components.
Also, maybe your coworker should up their interview game. Instead of asking “define this term” questions, maybe they should ask candidates to actually demonstrate skill.
(Also, it’s a bit weird to tell a “story” like this that happened to your coworker. Were you guys making fun of the candidate afterwards or something? I think we learned more about you and your coworker than about the candidate from your anecdote.)
Or maybe they just pitched themselves as "full stack" when they were really more back end focused. Doesn't seem that far-fetched to me.
Thanks, I see.
> Doesn't seem that far-fetched to me.
The veracity of GP’s comment wasn’t my main concern.
I feel like this shuts down a really important part of the conversation. Why does there exist zero feedback between technology owner and business/user expectations?
When you elevate JS above the others, you deprioritize those others in practice. Advanced knowledge of HTML among React developers is a surprisingly rare talent. Whereas Node developers gobbled up (and choked on) left-pad due to incomplete knowledge of JS, far too many (a majority of?) web framework developers reach for packaged components without realizing it was a standard tag with two lines of CSS away.
Accordion: <detail> + <summary>
Button (as a link): <a href> with inline-block, background-color, and other basic CSS
Card: <article> with border-radius and box-shadow
…pretty sure I could do most of the English alphabet in examples.
JS could be used for progressive enhancement—animating the accordion, for example—but almost all accordions I've seen were the typical spaghetti of div tags, chunky event handlers, and accessibility lipstick of aria-roles. But most React devs see some library's Accordion object and think it's normal to see the dark <div> forest in the inspector.
I think that is a fine tradeoff when the alternative is an arbitrary separation of technologies, a web of querySelectors, imperative DOM manipulation, and walls of incoherent stylesheets.
What's the connection?
When I was really young, I wanted to figure out web programming. I knew C#, so when I came across a book on making websites in C# with ASP.NET, it was a no-brainer.
I the slogged through 2000+ pages on how to handle connection state, WYSIWYG web forms generation with drag and drop component, etc. The experience was horrible, and turned me off to web programming.
A brief aside, for those unfamiliar: ASP.NET presents the programmer with a (leaky) abstraction over HTTP and HTML, pretending that the protocols involved are stateful, whereas the reality is that HTTP is stateless. This creates all sorts of new ASP.NET specific problems, which are then addressed by jumping through hoops to ensure control state is (de)serialized just right, etc. Thus the 2000+ page count.
Later on I discovered ASP.NET MVC, which did away the the “let’s pretend HTTP is stateful”, and takes an approach much like just about any other web framework out there. You’re expected to know HTML, CSS and HTTP. I was like “oh, is this it? I just learn some HTML, register some request handlers, and generate some HTML?”. Until then, my focus was on getting something working, and I trusted that what they covered would get me up and running. That line of reasoning failed me with ASP.NET, as the book set me up to ignore the underlying (and ironically, much simpler) machinery of the web.
I’m positive ASP.NET isn’t the only framework guilty of distracting developers from learning the fundamentals. And think about it: when’s the last time you’ve seen HTTP or HTML listed as required proficiencies in a job description? I can’t remember. What I do see is an expectation to know all the intricacies of React, Babel, Grunt, Redux, whatever. If you’re trying to land your first job, or working on climbing the ladder, it’s easy to fall into the trap of investing all your time in finding your way around the accidental complexity of the frameworks you intend to make your living from using, and underestimate the value of understanding what’s going on in the layers beneath the abstractions.
Now that no one knows what a desktop application is, we no longer need Session State like functionality.
Frameworks make you lose capability to write anything outside of them, locking you inside it's own Ecosystem and making you unable to write a single line of code outside of it.
https://hackmd.io/@roguegpu/r1RKQMdt3
The ChartJS section is a good example. You're following the ChartJS tutorials to use it, not just some bespoke framework wrapper around it.
This starts by using the right tags for things (articles, section, header, ...) over autofocus, alt and title tags and even rel attributes. No magical js page builds. All my websites are screen reader friendly by default.
Folks just seem to go out of their way to make things harder by focusing on the JS layers and frameworks above it all. Converting everything to a sea of divs that you have to go back it to style, add ARIA roles and labels, and make keyboard-accessible.
It's all like enriched white bread: stripping out everything healthy, adding a bucket of preservatives, supplement with a few of the vitamins and minerals they leached out earlier, and market its insubstantial tastelessness like it's normal.
it's amazing how many web developer don't know what browsers are capable of, and only consider what features the framework they're using has.
I made a JS file explorer, to see files on the server from the browser.
I wanted to mimic the windows explorer breadcrumb path bar. If you look at the behavior of the breadcrumb pathbar, you can't do that on page load, you have to replace the breadcrumb by an input text on clic, so not at page load.
Yes theroically, you can fetch a whole new page for that, but it would imply fetching a new page from the server just for this: it doesn't make sense.