4 ms·

> 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,

by 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.
    - Freedom2 3y ago
      > 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. I think that you'd have to reevaluate your users and your use case then. As someone, like berkes, who builds sites almost entirely with HTML / CSS, it's often the case that the developer is RIGHT over what the user needs. After speaking to many clients about the limitations of native HTML elements, I've successfully convinced users to change negative browsing patterns.
      - treis 3y ago
        Why should I write my own HTML and CSS over using what Bootstrap gives me? I can't think of a single reason to believe that my HTML/CSS will look or perform better than Bootstrap's. Especially since you can selectively import only the components you use. You're essentially betting that you can like for like implement what Bootstrap gives you better than what they can. Which just seems like a terrible bet regardless of how good that particular developer may be.
- aargh_aargh 3y ago
  Look terrible? Didn't we have this debate a couple of decades ago about separation of semantics and presentation? Sorry, I should have let it slide.
  - kethinov 3y ago
    I think what that person meant was if browser default styles made semantic HTML look more beautiful, it would probably reduce the incentive for lazy devs to make div soup. Like imagine if every browser preloaded a dozen attractive classless CSS frameworks for users and/or devs to choose from sort of like CSS Zen Garden. If all browsers had that, I think we'd get less div soup.
    - treis 3y ago
      Three things I think: (1) Unstyled HTML looks terrible. (2) There's relatively few native components and the ones that exist are limited. Like not even what JQueryUI gave you 15 years ago limited. No cards, accordions, avatars, and other sorts of basic building blocks. (3) No real support for common page layouts. Like a Dashboard or Hero marketing page sorts of things.
- cassepipe 3y ago
  That was indeed my point: Good defaults are the best but when you have bad defaults you might as well go for full-fledged well thought-out third party tools
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?

by berkes 3y ago

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.
  - Freedom2 3y ago
    > 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. I think that you'd have to reevaluate your users and your use case then. As someone, like berkes, who builds sites almost entirely with HTML / CSS, it's often the case that the developer is RIGHT over what the user needs. After speaking to many clients about the limitations of native HTML elements, I've successfully convinced users to change negative browsing patterns.
    - treis 3y ago
      Why should I write my own HTML and CSS over using what Bootstrap gives me? I can't think of a single reason to believe that my HTML/CSS will look or perform better than Bootstrap's. Especially since you can selectively import only the components you use. You're essentially betting that you can like for like implement what Bootstrap gives you better than what they can. Which just seems like a terrible bet regardless of how good that particular developer may be.
aargh_aargh 3y ago
Look terrible? Didn't we have this debate a couple of decades ago about separation of semantics and presentation? Sorry, I should have let it slide.
- kethinov 3y ago
  I think what that person meant was if browser default styles made semantic HTML look more beautiful, it would probably reduce the incentive for lazy devs to make div soup. Like imagine if every browser preloaded a dozen attractive classless CSS frameworks for users and/or devs to choose from sort of like CSS Zen Garden. If all browsers had that, I think we'd get less div soup.
  - treis 3y ago
    Three things I think: (1) Unstyled HTML looks terrible. (2) There's relatively few native components and the ones that exist are limited. Like not even what JQueryUI gave you 15 years ago limited. No cards, accordions, avatars, and other sorts of basic building blocks. (3) No real support for common page layouts. Like a Dashboard or Hero marketing page sorts of things.
cassepipe 3y ago
That was indeed my point: Good defaults are the best but when you have bad defaults you might as well go for full-fledged well thought-out third party tools

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?