3 ms·

I always chime into these articles with the exact same sentiment: this is a business problem, not a developer problem. Developers love simplicity and semantics

I always chime into these articles with the exact same sentiment: this is a business problem, not a developer problem. Developers love simplicity and semantics. But when a UI gets to a certain level of complexity (I say 10 interactions per page) then semantics get hard to maintain or translate. I'm building a recommendation engine for a client right now. Lots of wooshes, whirring and moving parts, a good amount of items don't directly translate to semantic HTML elements. It's not clear if my app should have <section> tags, <article> tags or <aside> tags. And again, when a developer has to manage that much complexity, then it's a-ok to breakdown or lose semantics in exchange for comprehensibility. Pretty much any trade-off is ok for comprehensibility. And making my users pay the 500kb React tax is a-ok with me, because I'm not superman and it's only 500kb. One un-optimized image can be that size. It's worth it for the project to be maintainable and reasonable by the next person. And one day when the business stakeholder decides that people on your education site don't need badges, or that quality content matters more than gamification, then we can dial these interactions back and make the web sane again.

andersonvom 7y ago
Since the article's main point is that you should use semantics as much as possible, it's probably better that you used the "wrong" tag when choosing between <section> or <article>, than using the wrong tag and choosing <div>s for lack of not even having asked the question "what should this be?". While rewriting what's already out there may be a business decision, choosing between what HTML tag to use when changing/writing new ones, is completely business agnostic.
- player2121 7y ago
  There are plenty of apps out there where you cannot apply HTML document semantics or that would be a waste of time (money) doing so. If using canvas or web-assembly would be easier/possible than using HTML tags for a rendering layer, nobody would ever disturb the HTML document designers with this div "soup" :) Semantic HTML serves 2 purposes: lets search engines correctly index your content and makes it easier for a human to edit this HTML directly. Other than that, there is no other reason which requires semantic HTML. True accessibility is achieved through other means.
TheCoelacanth 7y ago
500kb React tax? You're off by an order of magnitude. React+React DOM is 32kb when gzipped[1]. [1] https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d

andersonvom 7y ago

Since the article's main point is that you should use semantics as much as possible, it's probably better that you used the "wrong" tag when choosing between <section> or <article>, than using the wrong tag and choosing <div>s for lack of not even having asked the question "what should this be?". While rewriting what's already out there may be a business decision, choosing between what HTML tag to use when changing/writing new ones, is completely business agnostic.

player2121 7y ago
There are plenty of apps out there where you cannot apply HTML document semantics or that would be a waste of time (money) doing so. If using canvas or web-assembly would be easier/possible than using HTML tags for a rendering layer, nobody would ever disturb the HTML document designers with this div "soup" :) Semantic HTML serves 2 purposes: lets search engines correctly index your content and makes it easier for a human to edit this HTML directly. Other than that, there is no other reason which requires semantic HTML. True accessibility is achieved through other means.

TheCoelacanth 7y ago

500kb React tax? You're off by an order of magnitude. React+React DOM is 32kb when gzipped[1]. [1] https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d