4 ms·

I can't see how a bunch of esoteric incantations are better than just some straight-forward easy to understand and follow JavaScript.

by wvenable 10mo ago

yurishimo 10mo ago
Because you need 20x the JS to do the same thing and it’s still not hardware accelerated. These new CSS properties are well supported and will only get better.
- econ 9mo ago
  <span onclick=" banana. classlist. toggle('hidden') ">click</span> <div id="banana" class="hidden">loris</div>
  - spartanatreyu 9mo ago
    That's a poor example since it isn't accessible and doesn't work if a pending JS or CSS network request is preventing it from functioning. This is the HTML version, it's not susceptible to halted execution, and it is accessible. <details> <summary>Click</summary> loris </details>
paulddraper 10mo ago
1. CSS is declarative, so it avoid subtle bugs 2. CSS integrates better with HTML, as it has selectors to automatically bind to elements (yes there custom elements for JS)
onion2k 10mo ago
JS animations run on the main thread with everything else, so if your browser is busy doing something else the animation ends up being janky. Using CSS solves that problem.
dekoidal 10mo ago
Is CSS too hard to learn or something?
pikuseru 10mo ago
Because a team of browser engineers have already written and reviewed the code to do it for you; and (hopefully) it’ll be performant, properly tested and accessible… ;-D
berkes 10mo ago
Is that "straight-forward easy to understand and follow JavaScript" the whole thing written from scratch? Or does it use libraries (that use libraries, that use libraries)? Because I've written my share of javascript-from-scratch in my time - before npm and such. And even if my use-case was limited, in order to get edge-cases and details working - issues long solved by their HTML/CSS counterparts - we needed more and more JS. Many of which handwritten polyfills, agent-detection, etc. Seriously, things like scrollbars (because the client insisted on them being consistent across user-agents) or dropdowns (because they had to be styled) "visited" state on links, in pure JS are thousands of lines of code. Maybe not today, anymore, IDK, with current APIs like the history API or aria labeling. But back then, just in order to make the dropdown work with screen readers, or the scrollbars react well to touchpads -in the direction the user was used to based on their OS- took us thousands of lines of JS, hacks, workarounds and very hard to follow code - because of the way the "solutions" were spread out over the exact right combination of JS, HTML and CSS. Edit: I now recall we got the web-app back with the comment "When I select "Language" and start typing "Fr" I expect French to be picked and "enter" to then put the language in French". We spent another few days on functions that collect character inputs in memory and then match them with values. All because "flags in front of the names were of crucial importance". So, maybe this is solved in modern HTML/CSS/JS. But I highly doubt it. I think "some straight-forward ... JavaScript" is either an `import { foo } from foobar` or a pipe-dream in the area of "programmers always underestimate hours"
- scragz 10mo ago
  using flags for language is a bad pattern I wish would die. I'm not clicking on the British flag!
  - jimbob45 10mo ago
    What about strings + flags?
    - edoceo 10mo ago
      String of the language, in it's language: [Flag] Suomi (Finnish)
echelon 10mo ago
We've gotten so far away from semantic documents so we could build "apps". Data used to be first class. You would deliver everything in the HTML container and the style sheets or client could do whatever it wanted/needed with that data. Native search, native copy, no clever javascript tricks to hide or remove information from the document. The HTML data container should be immutable.
- wvenable 10mo ago
  > We've gotten so far away from semantic documents so we could build "apps". Exactly. We're still pretending that the browser is some kind of document display application when it's an application runtime. We keep adding more HTML tags and infinite number of CSS properties and features (that never get it right) when what we should have as a better application GUI API. Throw all the hardware acceleration and threading into that instead of @starting-style, transition-behavior: allow-discrete, interpolate-size: allow-keywords and ::details-content and breath some sanity into the platform. We've effectively re-implemented that desktop/mobile GUI using a bunch of cobbled together technologies and continue to get more esoteric and complicated every year. Hell, I'm not even sold on JavaScript -- it's just as clunky and weird as everything else. Move document rendering into high-level implementation on top of a better designed low-level API much like how PDF display in browsers is done with JavaScript.
  - echelon 10mo ago
    It sounds like you want a game engine. I want a hypertext document viewer. > @starting-style, transition-behavior: allow-discrete, interpolate-size: allow-keywords and ::details-content This is sane from a declarative document styling syntax.
    - wvenable 10mo ago
      As a developer, I want a sane platform. Sometimes I want to write documents and sometimes I want to write applications. > This is sane from a declarative document styling syntax. Is it? CSS intentionally avoided mixing animation with live layout resolution and now we have a "switch" to enable it. I wouldn't call that elegant. If we could just hook into layout with code this could have been resolved years ago instead of waiting for browser makers to invent yet another set keywords.
itishappy 10mo ago
I'm not particularly familiar with modern webdev, can anyone share a minimal example?
bee_rider 10mo ago
JavaScript encumbered pages break at least once for NoScript users.
- efreak 10mo ago
  To be fair, that's on the user. It's a trade-off the user is making, knowing that there's poorly made sites out there and sites that actively depend on JavaScript to function (sometimes because JavaScript is the only way they can function, but usually because someone's never heard of progressive enhancement). In the past, turning off JavaScript was a functional way to prevent things from running and to make sites load faster; today ads and progressive enhancement and optional functionality are hardly the only usage of JavaScript: lazy loading variable-size content (via fragments or otherwise) causes scroll issues if you're trying to go for performance on a complex layout. CSS containment and content-visibility with contain-intrinsic-size help solve this, but they're pretty new.

I can't see how a bunch of esoteric incantations are better than just some straight-forward easy to understand and follow JavaScript.

yurishimo 10mo ago

Because you need 20x the JS to do the same thing and it’s still not hardware accelerated. These new CSS properties are well supported and will only get better.

econ 9mo ago
<span onclick=" banana. classlist. toggle('hidden') ">click</span> <div id="banana" class="hidden">loris</div>
- spartanatreyu 9mo ago
  That's a poor example since it isn't accessible and doesn't work if a pending JS or CSS network request is preventing it from functioning. This is the HTML version, it's not susceptible to halted execution, and it is accessible. <details> <summary>Click</summary> loris </details>

paulddraper 10mo ago

1. CSS is declarative, so it avoid subtle bugs 2. CSS integrates better with HTML, as it has selectors to automatically bind to elements (yes there custom elements for JS)

onion2k 10mo ago

JS animations run on the main thread with everything else, so if your browser is busy doing something else the animation ends up being janky. Using CSS solves that problem.

dekoidal 10mo ago

Is CSS too hard to learn or something?

pikuseru 10mo ago

Because a team of browser engineers have already written and reviewed the code to do it for you; and (hopefully) it’ll be performant, properly tested and accessible… ;-D

berkes 10mo ago

Is that "straight-forward easy to understand and follow JavaScript" the whole thing written from scratch? Or does it use libraries (that use libraries, that use libraries)? Because I've written my share of javascript-from-scratch in my time - before npm and such. And even if my use-case was limited, in order to get edge-cases and details working - issues long solved by their HTML/CSS counterparts - we needed more and more JS. Many of which handwritten polyfills, agent-detection, etc. Seriously, things like scrollbars (because the client insisted on them being consistent across user-agents) or dropdowns (because they had to be styled) "visited" state on links, in pure JS are thousands of lines of code. Maybe not today, anymore, IDK, with current APIs like the history API or aria labeling. But back then, just in order to make the dropdown work with screen readers, or the scrollbars react well to touchpads -in the direction the user was used to based on their OS- took us thousands of lines of JS, hacks, workarounds and very hard to follow code - because of the way the "solutions" were spread out over the exact right combination of JS, HTML and CSS. Edit: I now recall we got the web-app back with the comment "When I select "Language" and start typing "Fr" I expect French to be picked and "enter" to then put the language in French". We spent another few days on functions that collect character inputs in memory and then match them with values. All because "flags in front of the names were of crucial importance". So, maybe this is solved in modern HTML/CSS/JS. But I highly doubt it. I think "some straight-forward ... JavaScript" is either an `import { foo } from foobar` or a pipe-dream in the area of "programmers always underestimate hours"

scragz 10mo ago
using flags for language is a bad pattern I wish would die. I'm not clicking on the British flag!
- jimbob45 10mo ago
  What about strings + flags?
  - edoceo 10mo ago
    String of the language, in it's language: [Flag] Suomi (Finnish)

echelon 10mo ago

We've gotten so far away from semantic documents so we could build "apps". Data used to be first class. You would deliver everything in the HTML container and the style sheets or client could do whatever it wanted/needed with that data. Native search, native copy, no clever javascript tricks to hide or remove information from the document. The HTML data container should be immutable.

wvenable 10mo ago
> We've gotten so far away from semantic documents so we could build "apps". Exactly. We're still pretending that the browser is some kind of document display application when it's an application runtime. We keep adding more HTML tags and infinite number of CSS properties and features (that never get it right) when what we should have as a better application GUI API. Throw all the hardware acceleration and threading into that instead of @starting-style, transition-behavior: allow-discrete, interpolate-size: allow-keywords and ::details-content and breath some sanity into the platform. We've effectively re-implemented that desktop/mobile GUI using a bunch of cobbled together technologies and continue to get more esoteric and complicated every year. Hell, I'm not even sold on JavaScript -- it's just as clunky and weird as everything else. Move document rendering into high-level implementation on top of a better designed low-level API much like how PDF display in browsers is done with JavaScript.
- echelon 10mo ago
  It sounds like you want a game engine. I want a hypertext document viewer. > @starting-style, transition-behavior: allow-discrete, interpolate-size: allow-keywords and ::details-content This is sane from a declarative document styling syntax.
  - wvenable 10mo ago
    As a developer, I want a sane platform. Sometimes I want to write documents and sometimes I want to write applications. > This is sane from a declarative document styling syntax. Is it? CSS intentionally avoided mixing animation with live layout resolution and now we have a "switch" to enable it. I wouldn't call that elegant. If we could just hook into layout with code this could have been resolved years ago instead of waiting for browser makers to invent yet another set keywords.

itishappy 10mo ago

I'm not particularly familiar with modern webdev, can anyone share a minimal example?

bee_rider 10mo ago

JavaScript encumbered pages break at least once for NoScript users.

efreak 10mo ago
To be fair, that's on the user. It's a trade-off the user is making, knowing that there's poorly made sites out there and sites that actively depend on JavaScript to function (sometimes because JavaScript is the only way they can function, but usually because someone's never heard of progressive enhancement). In the past, turning off JavaScript was a functional way to prevent things from running and to make sites load faster; today ads and progressive enhancement and optional functionality are hardly the only usage of JavaScript: lazy loading variable-size content (via fragments or otherwise) causes scroll issues if you're trying to go for performance on a complex layout. CSS containment and content-visibility with contain-intrinsic-size help solve this, but they're pretty new.