5 ms·

A good hover style reminds me of how fast and responsive our computers can be, if we let them. For example, I add a thicker underline when you hover over a link

by wruza 2y ago

A good hover style reminds me of how fast and responsive our computers can be, if we let them. For example, I add a thicker underline when you hover over a link on this site, and it appears/disappears almost instantly as I move my cursor around. It feels snappy; it makes me smile. Sigh. We managed to raise a generation for which an instant interaction on a 1000+MHz multi-core gpu-accelerated 1000+MB/s io system feels snappy and that’s special. Good job, goob job. you could add a negative margin to offset the border, or an always-on transparent border that only changes colour when you hover – but those can interfere with other CSS rules The worst part of CSS is its globalness. You can’t have two paddings sourced from different subsystems, can’t name a border so you could address it specifically (e.g. as in el:border(myhover) {background: <gradient>}). CSS is so poor and antipattern and nobody bats an eye. You write an article like this and already see all these fragile hacks advices coming in, normalized by years of stockholming through even most basic layouts.

wackget 2y ago
We managed to raise a generation who think it's acceptable for JavaScript to be required in order to render a single page. For some "web developers", this is literally how they create a page: import React from 'react'; function App() { return ( <div> <h1>Hello world!</h1> <p>This is my HTML page.</p> </div> ); } export default App;
- Spivak 2y ago
  I can't really knock it when no one is ever going to ask them to do anything else. HTML might as well be assembly. It's starting to feel pretty vestigial at this point, it's all just different colored divs and aria labels. Elements on the screen as a human would perceive them stopped mapping to single elements ages ago. For some "systems developers" this is literally how they create a program: #include <stdio.h> int main(int argc, char *argv[]) { println("Hello world."); } GTK/Unity/WinForms, everyone has their working level of abstraction.
  - rnewme 2y ago
    This is good argument, but also it's apples to oranges. You list GTK/Unity/informs where, I suppose, you refer to their GUI editors that output xml etc, and code just ties everything up, but you can drive all three with code only, and again end up placing every component by hand. Replace your prntln with " ImGui::Text("hello, world");" and you have GUI window on the screen.
- wruza 2y ago
  I don’t see anything bad here, tbh (ignoring my acute allergy to react—alikes). The problem is not how they write. DX is a good thing. Interactivity too. The problem is what happens at runtime: fetch html, fetch script, fetch data multiple times. It should be fetch html which contains a script which contains all the necessary data and creates elements and sets handlers.
- Cthulhu_ 2y ago
  It's ironic because I'm sure this lament has been voiced in one way or another with every generation of developers. Anyway, your comment feels like a straw man; I don't know anyone who actually believes what you're claiming, nor is this sentiment anywhere on HN. The closest things are discussions about whether your website should work with JS disabled whenever a too-clever website is linked.
  - indrora 2y ago
    Having worked in enterprise web development... Nah they're right. There's developers, in major corporations right now, who literally have no idea that you can just put HTML in a container and who are so drunk on node.js that they LITERALLY DO NOT UNDERSTAND what something like nginx, traefik, or Caddy is for. These people are building healthcare systems.
- hnbad 2y ago
  As someone who experienced the rise of JavaScript, CSS and modern frontend frameworks, your comment gives me a chuckle because I'm pretty sure using JavaScript for hover effects pre-dates the ability to do that reliably using CSS.
  - oneeyedpigeon 2y ago
    Isn't this just pointing out that progress = functional -> declarative?
    - rererereferred 2y ago
      More like progress is figuring out the common patterns and offering shortcuts for them. The querySelector api for example was born from jquery's popularity.
      - oneeyedpigeon 2y ago
        And it makes sense for those shortcuts, in general, to migrate 'up' the stack, JS -> CSS, JS+CSS -> HTML.
      - wruza 2y ago
        Really? I always thought jQuery was just a shorthand for it cause it’s too long to type. And they really walked the DOM to look for an element? What an ugly runtime it was, ugh. https://stackoverflow.com/questions/39979816/how-was-jquery-selector-defined-before-queryselector-wasnt-available https://stackoverflow.com/questions/39979816/how-was-jquery-...
        hnbad 2y ago
        Before `querySelectorAll` there was Sizzle, which was the selector engine that was eventually spun out of jQuery itself: https://github.com/jquery/sizzle https://github.com/jquery/sizzle If you think that's wild, before there were dev tools in every browser, there was only Firebug (yes, there was only `alert` before that, we didn't even have `console.log`): https://getfirebug.com/ https://getfirebug.com/
- caporaltito 2y ago
  "The future is now, old man!"
croes 2y ago
Isn‘t that what the id selector is for?
the_other 2y ago
> The worst part of CSS is its globalness. But global-ness is what you want from design directives. You want all your buttons to look the same, your links consistent. You want to define your base fonts once and then not have to worry about it for the rest of the build. You want to have your vertical rhythm (line spacing) repeated on most pages. You want most pages to have the same background and foreground colours. CSS syntax gives you all that for free. Giving multiple elements the same border definitions is easy: elem, another-elem, .some-class, #just-this-one { border: whatever; background: swoosh; } When I look at the hoops you have to leap through to get the same behaviour using any of the frameworks, my mind reels. Build steps, runtime libraries, repeated syntaxes in the mark-up... I accept that managing things like the shared border example can get fiddly. SASS made it easier; some flavour of react-plus-css-helper-library thing can make it easier, kinda, if you squint. But it's actually _very_ simple to write the basic core idea in plain CSS. Personally, I feel that the discipline required to manage larger CSS codebases isn't that different than the discipline required to write good JS or TS; we just have a habit of pretending we shouldn't need to do that and wishing someone else would (via a library, or changing the standards). I don't know why we're happy doing it in JS or TS, but not CSS.
- wruza 2y ago
  That’s as easy as fooModule.*(x), bar(x), Math.floor(x) { if (x === 42) return “oops”; return thisfunc(x); } Or as COMEFROM. The proper way for modularity is to import subtrees of declarations and have them applied explicitly. // elem.css elem { use border-bg from “./bbg.css”; } // html <div> import elem from “./elem.css” <elem/> // has it </div> <elem/> // doesn’t I don’t want aspect-oriented/comefrom globalness. It is an antipattern and dead tech in which you have to runtime-debug an element to learn its properties in each case, cause there’s no single place to treewalk your logic from.
  - the_other 2y ago
    Your example is solving a different problem from mine. We can’t compare. I was arguing that global declarations are useful. Your example is intentionally differentiatiating similar elements, and placing the specialisation inline with the DOM declaration. So far these seem more like style preferences. I can’t infer the “anti-patterns” you’re concerned about, nor how your version solves them. Could you expand some? Personally, I much prefer keeping the layout and style code out of my JS/behavior code. It makes both easier to read.

by wruza 2y ago

wackget 2y ago

We managed to raise a generation who think it's acceptable for JavaScript to be required in order to render a single page. For some "web developers", this is literally how they create a page: import React from 'react'; function App() { return ( <div> <h1>Hello world!</h1> <p>This is my HTML page.</p> </div> ); } export default App;

Spivak 2y ago
I can't really knock it when no one is ever going to ask them to do anything else. HTML might as well be assembly. It's starting to feel pretty vestigial at this point, it's all just different colored divs and aria labels. Elements on the screen as a human would perceive them stopped mapping to single elements ages ago. For some "systems developers" this is literally how they create a program: #include <stdio.h> int main(int argc, char *argv[]) { println("Hello world."); } GTK/Unity/WinForms, everyone has their working level of abstraction.
- rnewme 2y ago
  This is good argument, but also it's apples to oranges. You list GTK/Unity/informs where, I suppose, you refer to their GUI editors that output xml etc, and code just ties everything up, but you can drive all three with code only, and again end up placing every component by hand. Replace your prntln with " ImGui::Text("hello, world");" and you have GUI window on the screen.
wruza 2y ago
I don’t see anything bad here, tbh (ignoring my acute allergy to react—alikes). The problem is not how they write. DX is a good thing. Interactivity too. The problem is what happens at runtime: fetch html, fetch script, fetch data multiple times. It should be fetch html which contains a script which contains all the necessary data and creates elements and sets handlers.
Cthulhu_ 2y ago
It's ironic because I'm sure this lament has been voiced in one way or another with every generation of developers. Anyway, your comment feels like a straw man; I don't know anyone who actually believes what you're claiming, nor is this sentiment anywhere on HN. The closest things are discussions about whether your website should work with JS disabled whenever a too-clever website is linked.
- indrora 2y ago
  Having worked in enterprise web development... Nah they're right. There's developers, in major corporations right now, who literally have no idea that you can just put HTML in a container and who are so drunk on node.js that they LITERALLY DO NOT UNDERSTAND what something like nginx, traefik, or Caddy is for. These people are building healthcare systems.
hnbad 2y ago
As someone who experienced the rise of JavaScript, CSS and modern frontend frameworks, your comment gives me a chuckle because I'm pretty sure using JavaScript for hover effects pre-dates the ability to do that reliably using CSS.
- oneeyedpigeon 2y ago
  Isn't this just pointing out that progress = functional -> declarative?
  - rererereferred 2y ago
    More like progress is figuring out the common patterns and offering shortcuts for them. The querySelector api for example was born from jquery's popularity.
    - oneeyedpigeon 2y ago
      And it makes sense for those shortcuts, in general, to migrate 'up' the stack, JS -> CSS, JS+CSS -> HTML.
    - wruza 2y ago
      Really? I always thought jQuery was just a shorthand for it cause it’s too long to type. And they really walked the DOM to look for an element? What an ugly runtime it was, ugh. https://stackoverflow.com/questions/39979816/how-was-jquery-selector-defined-before-queryselector-wasnt-available https://stackoverflow.com/questions/39979816/how-was-jquery-...
      - hnbad 2y ago
        Before `querySelectorAll` there was Sizzle, which was the selector engine that was eventually spun out of jQuery itself: https://github.com/jquery/sizzle https://github.com/jquery/sizzle If you think that's wild, before there were dev tools in every browser, there was only Firebug (yes, there was only `alert` before that, we didn't even have `console.log`): https://getfirebug.com/ https://getfirebug.com/
caporaltito 2y ago
"The future is now, old man!"

croes 2y ago

Isn‘t that what the id selector is for?

the_other 2y ago

> The worst part of CSS is its globalness. But global-ness is what you want from design directives. You want all your buttons to look the same, your links consistent. You want to define your base fonts once and then not have to worry about it for the rest of the build. You want to have your vertical rhythm (line spacing) repeated on most pages. You want most pages to have the same background and foreground colours. CSS syntax gives you all that for free. Giving multiple elements the same border definitions is easy: elem, another-elem, .some-class, #just-this-one { border: whatever; background: swoosh; } When I look at the hoops you have to leap through to get the same behaviour using any of the frameworks, my mind reels. Build steps, runtime libraries, repeated syntaxes in the mark-up... I accept that managing things like the shared border example can get fiddly. SASS made it easier; some flavour of react-plus-css-helper-library thing can make it easier, kinda, if you squint. But it's actually _very_ simple to write the basic core idea in plain CSS. Personally, I feel that the discipline required to manage larger CSS codebases isn't that different than the discipline required to write good JS or TS; we just have a habit of pretending we shouldn't need to do that and wishing someone else would (via a library, or changing the standards). I don't know why we're happy doing it in JS or TS, but not CSS.

wruza 2y ago
That’s as easy as fooModule.*(x), bar(x), Math.floor(x) { if (x === 42) return “oops”; return thisfunc(x); } Or as COMEFROM. The proper way for modularity is to import subtrees of declarations and have them applied explicitly. // elem.css elem { use border-bg from “./bbg.css”; } // html <div> import elem from “./elem.css” <elem/> // has it </div> <elem/> // doesn’t I don’t want aspect-oriented/comefrom globalness. It is an antipattern and dead tech in which you have to runtime-debug an element to learn its properties in each case, cause there’s no single place to treewalk your logic from.
- the_other 2y ago
  Your example is solving a different problem from mine. We can’t compare. I was arguing that global declarations are useful. Your example is intentionally differentiatiating similar elements, and placing the specialisation inline with the DOM declaration. So far these seem more like style preferences. I can’t infer the “anti-patterns” you’re concerned about, nor how your version solves them. Could you expand some? Personally, I much prefer keeping the layout and style code out of my JS/behavior code. It makes both easier to read.