6 ms·

(I don't know what tools you use so this isn't a comment directed at you specifically) If web developers spent a fraction of the time required to learn react,

(I don't know what tools you use so this isn't a comment directed at you specifically) If web developers spent a fraction of the time required to learn react, tailwind, etc on learning HTML the web would be in a much better spot. There are definitely quirks and rough edges, but if every web devs knew how to get the most out of semantic HTML we'd likely have a lot less JS in the browser, fewer accessibility bugs, and more eyes on when specs could use an update to fix our replace some of these quirks.

berkes 3y ago
> on learning HTML Anecdote. Was recently freelancing at a web-agency. They build complex web-apps. Lot's of senior and experienced web-devs there: react, mui, typescript, tailwind, and a large host of backend frameworks under the belt. But when I built a quick PoC using `<template>` a few lines of JS and some of the elements used in the article (meter, dialog, details) they were flabbergasted. This was a whole team of experienced developers doing web-ui development for their job, 40+ hours a week. And they didn't know, not even realized, that HTML had them covered for loads of use-cases. Edit: I am no frontend-dev, so I have to look up everything anyway. Which is probably why I come across those "new" things easier.
- afavour 3y ago
  Broadly, broadly broadly I agree with you and I’m endlessly frustrated with the state of React-based frontend dev. But that said you really do get a lot more out of the box with these frameworks. Tailwind makes consistent styling far far easier. MUI helps with the same and also (often overlooked) has a lot of accessibility features built in.
- treis 3y ago
  Covered is stretching it. Most raw HTML elements look terrible and wouldn't pass muster with pretty much anyone. IMHO, this is a big miss with browsers. Sites look awful without styling and you have to be pretty good with CSS to even make them look passable. Way easier to reach for a framework with prebuilt components
  - berkes 3y ago
    This anecdote was a "pixel perfect" HTML version of some figma design. I did some CSS tricks to style the `<details>` and was lucky the designer was lazy and never specified the styles of all the dialogs around date/time pickers (they weren't that important anyway). You can style a lot of these native elements. And where you cannot, I'd argue that's actually good. I've worked with designers who insisted that everything looked and feeled the way they had designed it. But I've also worked with designers who, when showed how the date-picker looked on IOS, OSX and even Gnome, were incredibly happy that finally there was design that just followed what the users were used to. Point being: it will vary. But I'm certain we need all these JS UI-frameworks like MUI far less than we use them. I'm certain plain-old HTML, CSS and a little JS suffices far more often than it's currently used.
    - treis 3y ago
      >You can style a lot of these native elements. And where you cannot, I'd argue that's actually good. I've worked with designers who insisted that everything looked and feeled the way they had designed it. But I've also worked with designers who, when showed how the date-picker looked on IOS, OSX and even Gnome, were incredibly happy that finally there was design that just followed what the users were used to. The native browser date picker is very limited. You can't do basic things like disable weekends or select a range making it unsuitable for a wide swath of usecases. >Point being: it will vary. But I'm certain we need all these JS UI-frameworks like MUI far less than we use them. I'm certain plain-old HTML, CSS and a little JS suffices far more often than it's currently used. These UI frameworks are just plain-old HTML, CSS, and a little JS. All conveniently built for you to easy build a site that looks pretty good and covers most UX needs. >This anecdote was a "pixel perfect" HTML version of some figma design. I did some CSS tricks to style the `<details>` and was lucky the designer was lazy and never specified the styles of all the dialogs around date/time pickers (they weren't that important anyway). If you had used MUI you wouldn't have had to do CSS tricks and if it's using a small fraction of MUI then treeshaking will result in a negligible amount of JS/CSS sent over the wire. So no real performance gain, harder for the next engineer, and no great path forward if the UI needs to be snazzier. It's just worse all around than picking one of the well known frameworks.
- chrisweekly 3y ago
  This is one of the things I like best about Remix (https://remix.run https://remix.run) -- it leverages React in a way that "grounds" it in web fundamentals instead of piling on further layers of abstraction. Remix is refreshingly simple, and its docs are chock full of references to MDN as the more authoritative source for web platform APIs.
- boredumb 3y ago
  I don't think people realize how CSS3 and HTML5 will do everything they need. And also that no one actually enjoys using a SPA.
  - Spivak 3y ago
    But it does seem that no one enjoys actually building MPAs and that force is currently winning right now.
    - boredumb 3y ago
      Using your favorite language, a simple http listerner+routing and what ever HTML templating engines are supported, MPAs are simple and enjoyable to build. I think product people enjoyed pretending they were facebook for a while and decided the world needed more infinitely scrolling SPAs and forced a lot of people into having to use react and other frontend heavy frameworks to try to wrangle all the (often times brittle) javascript involved to juggle client state. I don't think we're better off as users or developers because of this.
      - berkes 3y ago
        It's rather easy to add infinite scrolling to an MPA too, though. A few lines of JS is all you need. I'd argue this is simpler and easier than investing in a full blown ui library and state manager or painting yourself into some corner of today's JS framework.
  - tjpnz 3y ago
    That would require accepting that the complexity merchants sold them a lie.
    - syncbehind 3y ago
      > complexity merchants I have never heard of this term before. But I do think it is quite apt. Is this an established concept (can I read more about it somewhere)? Or did you come up with it on the fly?
- VoodooJuJu 3y ago
  >senior engineers flabbergasted by basic HTML & JS These are the people rejecting your job application.
- JyB 3y ago
  I mean. Doesn't it always boils down to supporting all "old/different browsers" hence why all web-agencies have to use all those JS libraries that seamlessly abstract it all?
  - berkes 3y ago
    Sometimes. But do you really need to support a browser that less than half a percent uses? And isn't the fallback that HTML offers out of the box good enough then? Sure, there are those rare cases where you build an appointment system for a hospital and where laws (rightfully!) dictate that the date picker must be both accessible and working on anything from IE6 to the browser on the first Wii. But your average 99.99% of the sites?
cassepipe 3y ago
I am using svelte as it seems the best of both world, I can actually pretend I am just writing html and js where related pieces are colocated with a module system enough that it is actually readable while also harnessing my html and js/ts knowledge. And since js has to be minified there's a "compilation" step anyways. Didn't find a better solution so far. The web is almost nice to write code for.
d357r0y3r 3y ago
I think if the web apps we were working on were marketing landing pages, you'd be right. For any real application that software engineers are hired to work on, "learning HTML" would do very little. Most high-level front-end engineers do know HTML. There's not that much to know. The web today is basically a universal desktop client. Apps like Figma, Slack, Airtable, and thousands of others are not really websites, they're hosted applications that have a mind boggling amount of interactivity.
- kethinov 3y ago
  Attitudes like that are why so many "real applications" have things like progress bars assembled from divs and JS instead of using a progress element or show/hide toggles assembled from divs and JS instead of using details/summary elements. Turns out there are so many HTML elements for a reason.
  - d357r0y3r 3y ago
    Attitudes like what? How do you build Figma using "semantic HTML"? Everyone likes the idea of keeping things simple and using web native constructs. The problem is that web native constructs can't do the things people them to do. Even the progress bar example is a good one. Yes, there is a minimal progress indicator element shipped in the browser. It is completely useless for all but rudimentary cases.

berkes 3y ago

> on learning HTML Anecdote. Was recently freelancing at a web-agency. They build complex web-apps. Lot's of senior and experienced web-devs there: react, mui, typescript, tailwind, and a large host of backend frameworks under the belt. But when I built a quick PoC using `<template>` a few lines of JS and some of the elements used in the article (meter, dialog, details) they were flabbergasted. This was a whole team of experienced developers doing web-ui development for their job, 40+ hours a week. And they didn't know, not even realized, that HTML had them covered for loads of use-cases. Edit: I am no frontend-dev, so I have to look up everything anyway. Which is probably why I come across those "new" things easier.

afavour 3y ago
Broadly, broadly broadly I agree with you and I’m endlessly frustrated with the state of React-based frontend dev. But that said you really do get a lot more out of the box with these frameworks. Tailwind makes consistent styling far far easier. MUI helps with the same and also (often overlooked) has a lot of accessibility features built in.
treis 3y ago
Covered is stretching it. Most raw HTML elements look terrible and wouldn't pass muster with pretty much anyone. IMHO, this is a big miss with browsers. Sites look awful without styling and you have to be pretty good with CSS to even make them look passable. Way easier to reach for a framework with prebuilt components
- berkes 3y ago
  This anecdote was a "pixel perfect" HTML version of some figma design. I did some CSS tricks to style the `<details>` and was lucky the designer was lazy and never specified the styles of all the dialogs around date/time pickers (they weren't that important anyway). You can style a lot of these native elements. And where you cannot, I'd argue that's actually good. I've worked with designers who insisted that everything looked and feeled the way they had designed it. But I've also worked with designers who, when showed how the date-picker looked on IOS, OSX and even Gnome, were incredibly happy that finally there was design that just followed what the users were used to. Point being: it will vary. But I'm certain we need all these JS UI-frameworks like MUI far less than we use them. I'm certain plain-old HTML, CSS and a little JS suffices far more often than it's currently used.
  - treis 3y ago
    >You can style a lot of these native elements. And where you cannot, I'd argue that's actually good. I've worked with designers who insisted that everything looked and feeled the way they had designed it. But I've also worked with designers who, when showed how the date-picker looked on IOS, OSX and even Gnome, were incredibly happy that finally there was design that just followed what the users were used to. The native browser date picker is very limited. You can't do basic things like disable weekends or select a range making it unsuitable for a wide swath of usecases. >Point being: it will vary. But I'm certain we need all these JS UI-frameworks like MUI far less than we use them. I'm certain plain-old HTML, CSS and a little JS suffices far more often than it's currently used. These UI frameworks are just plain-old HTML, CSS, and a little JS. All conveniently built for you to easy build a site that looks pretty good and covers most UX needs. >This anecdote was a "pixel perfect" HTML version of some figma design. I did some CSS tricks to style the `<details>` and was lucky the designer was lazy and never specified the styles of all the dialogs around date/time pickers (they weren't that important anyway). If you had used MUI you wouldn't have had to do CSS tricks and if it's using a small fraction of MUI then treeshaking will result in a negligible amount of JS/CSS sent over the wire. So no real performance gain, harder for the next engineer, and no great path forward if the UI needs to be snazzier. It's just worse all around than picking one of the well known frameworks.
chrisweekly 3y ago
This is one of the things I like best about Remix (https://remix.run https://remix.run) -- it leverages React in a way that "grounds" it in web fundamentals instead of piling on further layers of abstraction. Remix is refreshingly simple, and its docs are chock full of references to MDN as the more authoritative source for web platform APIs.
boredumb 3y ago
I don't think people realize how CSS3 and HTML5 will do everything they need. And also that no one actually enjoys using a SPA.
- Spivak 3y ago
  But it does seem that no one enjoys actually building MPAs and that force is currently winning right now.
  - boredumb 3y ago
    Using your favorite language, a simple http listerner+routing and what ever HTML templating engines are supported, MPAs are simple and enjoyable to build. I think product people enjoyed pretending they were facebook for a while and decided the world needed more infinitely scrolling SPAs and forced a lot of people into having to use react and other frontend heavy frameworks to try to wrangle all the (often times brittle) javascript involved to juggle client state. I don't think we're better off as users or developers because of this.
    - berkes 3y ago
      It's rather easy to add infinite scrolling to an MPA too, though. A few lines of JS is all you need. I'd argue this is simpler and easier than investing in a full blown ui library and state manager or painting yourself into some corner of today's JS framework.
- tjpnz 3y ago
  That would require accepting that the complexity merchants sold them a lie.
  - syncbehind 3y ago
    > complexity merchants I have never heard of this term before. But I do think it is quite apt. Is this an established concept (can I read more about it somewhere)? Or did you come up with it on the fly?
VoodooJuJu 3y ago
>senior engineers flabbergasted by basic HTML & JS These are the people rejecting your job application.
JyB 3y ago
I mean. Doesn't it always boils down to supporting all "old/different browsers" hence why all web-agencies have to use all those JS libraries that seamlessly abstract it all?
- berkes 3y ago
  Sometimes. But do you really need to support a browser that less than half a percent uses? And isn't the fallback that HTML offers out of the box good enough then? Sure, there are those rare cases where you build an appointment system for a hospital and where laws (rightfully!) dictate that the date picker must be both accessible and working on anything from IE6 to the browser on the first Wii. But your average 99.99% of the sites?

cassepipe 3y ago

I am using svelte as it seems the best of both world, I can actually pretend I am just writing html and js where related pieces are colocated with a module system enough that it is actually readable while also harnessing my html and js/ts knowledge. And since js has to be minified there's a "compilation" step anyways. Didn't find a better solution so far. The web is almost nice to write code for.

d357r0y3r 3y ago

I think if the web apps we were working on were marketing landing pages, you'd be right. For any real application that software engineers are hired to work on, "learning HTML" would do very little. Most high-level front-end engineers do know HTML. There's not that much to know. The web today is basically a universal desktop client. Apps like Figma, Slack, Airtable, and thousands of others are not really websites, they're hosted applications that have a mind boggling amount of interactivity.

kethinov 3y ago
Attitudes like that are why so many "real applications" have things like progress bars assembled from divs and JS instead of using a progress element or show/hide toggles assembled from divs and JS instead of using details/summary elements. Turns out there are so many HTML elements for a reason.
- d357r0y3r 3y ago
  Attitudes like what? How do you build Figma using "semantic HTML"? Everyone likes the idea of keeping things simple and using web native constructs. The problem is that web native constructs can't do the things people them to do. Even the progress bar example is a good one. Yes, there is a minimal progress indicator element shipped in the browser. It is completely useless for all but rudimentary cases.