5 ms·

This is why I moved away from web frameworks. I could feel them making me incapable of solving really simple problems like this. Autofocus & tab order are a ni

This is why I moved away from web frameworks. I could feel them making me incapable of solving really simple problems like this. 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.

codex_i 3y ago
That is the whole reason that made me stop using them. 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.
- ttfkam 3y ago
  Try Svelte. It's quite easy to use most vanilla JS libraries and techniques with it. https://hackmd.io/@roguegpu/r1RKQMdt3 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.
frob 3y ago
I have this battle with newer developers quite frequently. They immediately want to reach for a framework for everything and they try to abstract away as much html and css as possible. 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.
- teaearlgraycold 3y ago
  I remember a front-end interview my coworker administered where the candidate was asked what a CSS rule and CSS selector were, and the candidate could not answer. They had no idea what those terms meant. I think they'd only ever used React styled components.
  - bluepod4 3y ago
    “React-styled components”? 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.)
    - Tronno 3y ago
      Styled Components is a library for React that moves CSS styles into the JS code. Depending on how junior the interviewee was, and what tech they were primarily working with, it's possible they never encountered those terms even as they contributed to the code. 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.
      - bluepod4 3y ago
        > Styled Components is a library for React that moves CSS styles into the JS code. Thanks, I see. > Doesn't seem that far-fetched to me. The veracity of GP’s comment wasn’t my main concern.
    - teaearlgraycold 3y ago
      I’m disappointed you’d assume the most toxic interpretation possible there. My coworker came to me and was just curious if the question, which was new, was reasonable - having seen it received so much confusion.
amelius 3y ago
The problem here is that the requirement of one tiny little feature on top of a browser's HTML engine might force you to implement a DOM circus from scratch, simply because you can't change the browser's code. Should that feature then be left unimplemented? That's not for you or me to decide. Also: it might not be known beforehand what features will be added later, so it makes sense to use a framework because at least you will be able to extend it.
- bob1029 3y ago
  > Should that feature then be left unimplemented? That's not for you or me to decide 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?
jahewson 3y ago
Great, now disable it on mobile where opening the on-scree keyboard is jarring.
nosefurhairdo 3y ago
There is nothing about the dominant web frameworks that prevents one from implementing semantically correct HTML.
- ttfkam 3y ago
  Prevent? No. Discourages? All the time.
  - nosefurhairdo 3y ago
    Can you give an example?
    - ttfkam 3y ago
      /me gestures emphatically at the entire "HTML & CSS in JS" paradigm. 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.
      - nosefurhairdo 3y ago
        Gotcha; JSX, by colocating related JS and HTML, tempts inexperienced developers to write JS hacks for behaviors already available natively in HTML and CSS. 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.
paulddraper 3y ago
I don't see how autofocus and tab order are made any worse by a web framework. What's the connection?
- cstrahan 3y ago
  An example from personal experience: 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.
  - nullindividual 3y ago
    ASP.NET 4.x and below Session State and WebForms made sense when, at the time, the goal was to make desktop applications on the web. Now that no one knows what a desktop application is, we no longer need Session State like functionality.

codex_i 3y ago

That is the whole reason that made me stop using them. 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.

ttfkam 3y ago
Try Svelte. It's quite easy to use most vanilla JS libraries and techniques with it. https://hackmd.io/@roguegpu/r1RKQMdt3 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.

frob 3y ago

I have this battle with newer developers quite frequently. They immediately want to reach for a framework for everything and they try to abstract away as much html and css as possible. 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.

teaearlgraycold 3y ago
I remember a front-end interview my coworker administered where the candidate was asked what a CSS rule and CSS selector were, and the candidate could not answer. They had no idea what those terms meant. I think they'd only ever used React styled components.
- bluepod4 3y ago
  “React-styled components”? 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.)
  - Tronno 3y ago
    Styled Components is a library for React that moves CSS styles into the JS code. Depending on how junior the interviewee was, and what tech they were primarily working with, it's possible they never encountered those terms even as they contributed to the code. 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.
    - bluepod4 3y ago
      > Styled Components is a library for React that moves CSS styles into the JS code. Thanks, I see. > Doesn't seem that far-fetched to me. The veracity of GP’s comment wasn’t my main concern.
  - teaearlgraycold 3y ago
    I’m disappointed you’d assume the most toxic interpretation possible there. My coworker came to me and was just curious if the question, which was new, was reasonable - having seen it received so much confusion.

amelius 3y ago

The problem here is that the requirement of one tiny little feature on top of a browser's HTML engine might force you to implement a DOM circus from scratch, simply because you can't change the browser's code. Should that feature then be left unimplemented? That's not for you or me to decide. Also: it might not be known beforehand what features will be added later, so it makes sense to use a framework because at least you will be able to extend it.

bob1029 3y ago
> Should that feature then be left unimplemented? That's not for you or me to decide 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?

jahewson 3y ago

Great, now disable it on mobile where opening the on-scree keyboard is jarring.

nosefurhairdo 3y ago

There is nothing about the dominant web frameworks that prevents one from implementing semantically correct HTML.

ttfkam 3y ago
Prevent? No. Discourages? All the time.
- nosefurhairdo 3y ago
  Can you give an example?
  - ttfkam 3y ago
    /me gestures emphatically at the entire "HTML & CSS in JS" paradigm. 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.
    - nosefurhairdo 3y ago
      Gotcha; JSX, by colocating related JS and HTML, tempts inexperienced developers to write JS hacks for behaviors already available natively in HTML and CSS. 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.

paulddraper 3y ago

I don't see how autofocus and tab order are made any worse by a web framework. What's the connection?

cstrahan 3y ago
An example from personal experience: 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.
- nullindividual 3y ago
  ASP.NET 4.x and below Session State and WebForms made sense when, at the time, the goal was to make desktop applications on the web. Now that no one knows what a desktop application is, we no longer need Session State like functionality.