4 ms·

I think what the author is saying is that paradigm 2 is built _on top of_ paradigm 1 and if you can't do #1 right, then by definition _neither_ can be right. It

I think what the author is saying is that paradigm 2 is built _on top of_ paradigm 1 and if you can't do #1 right, then by definition _neither_ can be right. It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. React will die (It's already started to) and we'll migrate back to the actual Web at some point and for my money it can't happen fast enough.

frenchyatwork 7y ago
> React will die Hopefully, but people have a large capacity to deal with broken web software. Back when I was young, it was all the Java & .Net websites that turned every friggin link into a POST form so that navigating back, and opening in a new window was completely broken.
hombre_fatal 7y ago
> It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. Go on?
- saagarjha 7y ago
  Because you've literally just described what a <button> is.
  - felxh 7y ago
    That would mean that anything that responds to click events is a button. From your experience of using UIs, you can probably think of many more UI elements that respond to clicks and are not buttons
- snek 7y ago
  Putting a click element on a div is transparent to accessibility systems. And no, it isn't possible to consider an element with an onclick the same as a button, because events bubble, which means the element with the event listener isn't necessarily the element being watched for a click. IIRC there even used to be a "good practice" where people would attach a single click handler at the root and use it to dispatch events based on the `event.target` instead of attaching a separate handler to each target.
  - dsego 7y ago
    React does that, they call it synthetic events, but it's hidden from the developer. In jQuery it used to be called event delegation, made it easy to handle events on dynamic elements without the need to constantly attach/detach handlers.
- dreamcompiler 7y ago
  Because the user can't hover over it and see where the link goes. Because the click handler represents a Javascript program that has to be downloaded. Because it can't be used with Javascript turned off -- which is increasingly necessary these days since ad networks abuse Javascript. But mostly because it's usually unnecessary and smacks of laziness on the developer's part.
- paulhebert 7y ago
  Using a button here would be more appropriate for a few reasons: Buttons by default have keyboard support for focusing and clicking. You’d have to manually add this to a div. Screenreaders, scrapers, and other automated tools reading your html understand buttons and treat them differently from divs. It’s easier for other devs to understand your code at a glance if clickable elements are buttons.
stellar678 7y ago
I’ll bite: Why is it bad to put a click handler on a div? Because we’re losing the semantic content of the markup?
- cortesoft 7y ago
  For one, it won't play nice with accessibility helpers... screen readers, keyboard interaction, etc.
  - giobox 7y ago
    While I agree semantically use of <button> can be clearer, clickable divs can still play largely fine with most accessibility technologies if ARIA attributes are used. Does it semantically make the most sense? Not necessarily, but it isn't a blocker to most accessibility tools and use and support for ARIA attributes is pretty widespread nowadays, including all of the major browsers and screen readers. > https://developers.google.com/web/fundamentals/accessibility/semantics-aria/ https://developers.google.com/web/fundamentals/accessibility... > https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Web_applications_and_ARIA_FAQ https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
    - ricardobeat 7y ago
      Number of times I remember seeing an an app using `<div onclick>` with proper aria attributes: 0.
      - deleted 7y ago
        [deleted]
      - giobox 7y ago
        It's often a legal or contractual requirement when selling software to public bodies in many countries, so I've seen it used a lot. Mileage may vary in other markets. The important point is that fundamentally using a <div> in place of <button> can still be made to work easily with these accessibility tools - many comments here imply it can't be done at all and only a button will work. Does it semantically make sense? Likely no, but it isn't a hard blocker on accessibility.
robertoandred 7y ago
Nothing about React stops you from correctly putting click handlers on buttons.
antibland 7y ago
> React will die (It's already started to) I read a lot of articles about front end, including framework & library trends, usage statistics, rumors, etc., though I've never heard that React has begun to die. Can you provide a citation?
tracker1 7y ago
Well, the behavior is a bit awkward, and older browsers don't even work right. Of course, some older browsers that shall not be named, you couldn't disable certain styling attributes of buttons, which means an anchor may have been more appropriate back then. I tend to prefer semantic tags most of the time. I do wish there was a CSS declaration, or maybe an <html> attribute to start off with absolutely NO styling, so that it all comes up from what's in the CSS only. Various resets suck or don't work well, or are really big for various reasons. For that matter, being able to reset everything under a given element that way so that in-browser rules aren't applied would be really nice for WebComponents. My own weakest point is probably on CSS these days, I just haven't really kept up since 2.x as I haven't really needed to, and can usually google when I need more. I feel the flexbox stuff is more complex than it should be.

frenchyatwork 7y ago

> React will die Hopefully, but people have a large capacity to deal with broken web software. Back when I was young, it was all the Java & .Net websites that turned every friggin link into a POST form so that navigating back, and opening in a new window was completely broken.

hombre_fatal 7y ago

> It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. Go on?

saagarjha 7y ago
Because you've literally just described what a <button> is.
- felxh 7y ago
  That would mean that anything that responds to click events is a button. From your experience of using UIs, you can probably think of many more UI elements that respond to clicks and are not buttons
snek 7y ago
Putting a click element on a div is transparent to accessibility systems. And no, it isn't possible to consider an element with an onclick the same as a button, because events bubble, which means the element with the event listener isn't necessarily the element being watched for a click. IIRC there even used to be a "good practice" where people would attach a single click handler at the root and use it to dispatch events based on the `event.target` instead of attaching a separate handler to each target.
- dsego 7y ago
  React does that, they call it synthetic events, but it's hidden from the developer. In jQuery it used to be called event delegation, made it easy to handle events on dynamic elements without the need to constantly attach/detach handlers.
dreamcompiler 7y ago
Because the user can't hover over it and see where the link goes. Because the click handler represents a Javascript program that has to be downloaded. Because it can't be used with Javascript turned off -- which is increasingly necessary these days since ad networks abuse Javascript. But mostly because it's usually unnecessary and smacks of laziness on the developer's part.
paulhebert 7y ago
Using a button here would be more appropriate for a few reasons: Buttons by default have keyboard support for focusing and clicking. You’d have to manually add this to a div. Screenreaders, scrapers, and other automated tools reading your html understand buttons and treat them differently from divs. It’s easier for other devs to understand your code at a glance if clickable elements are buttons.

stellar678 7y ago

I’ll bite: Why is it bad to put a click handler on a div? Because we’re losing the semantic content of the markup?

cortesoft 7y ago
For one, it won't play nice with accessibility helpers... screen readers, keyboard interaction, etc.
- giobox 7y ago
  While I agree semantically use of <button> can be clearer, clickable divs can still play largely fine with most accessibility technologies if ARIA attributes are used. Does it semantically make the most sense? Not necessarily, but it isn't a blocker to most accessibility tools and use and support for ARIA attributes is pretty widespread nowadays, including all of the major browsers and screen readers. > https://developers.google.com/web/fundamentals/accessibility/semantics-aria/ https://developers.google.com/web/fundamentals/accessibility... > https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Web_applications_and_ARIA_FAQ https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
  - ricardobeat 7y ago
    Number of times I remember seeing an an app using `<div onclick>` with proper aria attributes: 0.
    - deleted 7y ago
      [deleted]
    - giobox 7y ago
      It's often a legal or contractual requirement when selling software to public bodies in many countries, so I've seen it used a lot. Mileage may vary in other markets. The important point is that fundamentally using a <div> in place of <button> can still be made to work easily with these accessibility tools - many comments here imply it can't be done at all and only a button will work. Does it semantically make sense? Likely no, but it isn't a hard blocker on accessibility.

robertoandred 7y ago

Nothing about React stops you from correctly putting click handlers on buttons.

antibland 7y ago

> React will die (It's already started to) I read a lot of articles about front end, including framework & library trends, usage statistics, rumors, etc., though I've never heard that React has begun to die. Can you provide a citation?

tracker1 7y ago

Well, the behavior is a bit awkward, and older browsers don't even work right. Of course, some older browsers that shall not be named, you couldn't disable certain styling attributes of buttons, which means an anchor may have been more appropriate back then. I tend to prefer semantic tags most of the time. I do wish there was a CSS declaration, or maybe an <html> attribute to start off with absolutely NO styling, so that it all comes up from what's in the CSS only. Various resets suck or don't work well, or are really big for various reasons. For that matter, being able to reset everything under a given element that way so that in-browser rules aren't applied would be really nice for WebComponents. My own weakest point is probably on CSS these days, I just haven't really kept up since 2.x as I haven't really needed to, and can usually google when I need more. I feel the flexbox stuff is more complex than it should be.