5 ms·

HTML has a bunch of good stuff in it that'd replace the need for so much heavy and slow and non-native-feeling javascript if that'd just been improved. Lots of

HTML has a bunch of good stuff in it that'd replace the need for so much heavy and slow and non-native-feeling javascript if that'd just been improved. Lots of it's now rarely used because it sucks, but there's no good reason it has to suck. It's like whole sections of the spec just got abandoned around 2005, but the need is still there.

tombert 2y ago
The <blink> tag needs to make a comeback; I'm so tired of having to write my own JavaScript to get annoying flashy text. In all seriousness, I'm not entirely sure why so many features in HTML are eschewed in favor of a slow JS mess. It doesn't feel like bolting on an entire relatively-slow programming language is going to make your code more organized than a relatively easy to use tag.
- alabastervlog 2y ago
  We could have datasource-backed tables and list elements. Built-in. Sorting for most purposes, "for free", and more with simple and light JS hooks for sort functions. Frames that actually work as useful UI elements. "Basic auth" screens that look and function well enough for lots of purposes. Something like "Apple Pay" or other external payment systems but built into the browser, replacing stupid amounts of time spent writing yet another payment form (and usually fucking it up in several ways) But no.
- lelandfe 2y ago
  > I'm so tired of having to write my own JavaScript to get annoying flashy text Fret no more: <style> .blink { animation: blink 1s steps(2, start) infinite; } @keyframes blink { 50% { visibility: hidden; } } </style> <p class="blink">Lorem ipsum</p> https://jsfiddle.net/xrkLt2nz/ https://jsfiddle.net/xrkLt2nz/
  - tombert 2y ago
    This is certainly better than nothing, but it should just be a tag! I shouldn't need this fancy new-fangled "CSS" fad to bail me out of the problems that W3C created by removing it in the first place!
    - lelandfe 2y ago
      Definitely. Much less the many several users who yet lack CSS support in their preferred browser.
      - tombert 2y ago
        The good news is that <marquee> still works in the latest Firefox. No need for any new-fangled animation libraries for me.
  - Sohcahtoa82 2y ago
    If front-end devs would stop reinventing things using JS that can be done in CSS, I'd be so happy.
    - wruza 2y ago
      Why?
      - thesuitonym 2y ago
        Not the GP, but my two cents: because JS sucks and CSS can already do it.
      - Sohcahtoa82 2y ago
        Because the JS version will likely take more resources and probably end up being done wrong anyways. I just don't get why front-end devs feel the need to reinvent everything. I mean, for fuck's sake, front-end devs for some reason have a fascination with reinventing fucking SCROLLING. And 100% of the time, it either doesn't work, has less functionality than what was built-in, or is annoying for the simple fact that it changes an expected behavior. If I click my scroll wheel once, and the page keeps scrolling and the scrolling slowly comes to a stop as if it had momentum, that's a bug, not a feature. Stop wasting time deliberately writing bugs.
        wruza 2y ago
        Scrolling is sort of a strawman here, so I’ll focus on blinking and css features and the need to reinvent these. First, not all css features are consistent enough from the side you usually tend to approach things, due to various backgrounds and thinking modes. Css is notoriously overcomplicated, nuanced and ad-hoc applicable, and tendency to neglect it is its own self-imposed problem. Second, there’s no law that dictated some true way to do things. People use instruments they know, and if these work, there’s no need to go and find true ways. Overall, there’s no difference if you do something in js that css can do, apart from hurting someone’s feelings. All the difference you see is in multi-megabyte tracking scripts, not in js-dom chain per se. The difference betwen css and js ways is barely measurable when you start actually testing it. But js is more powerful in expression and familiar to a developer (except for 60fps+ animations and such). I say this as a non-frontend dev who makes dashboards and other report/control pages for myself, so opinions may vary. But I’ve never seen a higher resource consumption from avoiding css. To my understanding, literally all sites I ever visited can be implemented in a straightforward way in js and will never “take more resources” and will work as fast as just html. Because it’s literally how any non-C GUI app works on desktops. An interpreted jit-able language controlling some widgets. It’s nothing new or unusual or bizarre. In fact, css is also a language, even if declarative, and keyframes structures and other calc()s also get interpreted many times per second, even if not using a full-blown vm. In my opinion, people’s web bloat ideas are all over the place and miss the basics comletely, e.g. https://news.ycombinator.com/item?id=42990724 https://news.ycombinator.com/item?id=42990724 , and tend to blame wrong parts.

tombert 2y ago

The <blink> tag needs to make a comeback; I'm so tired of having to write my own JavaScript to get annoying flashy text. In all seriousness, I'm not entirely sure why so many features in HTML are eschewed in favor of a slow JS mess. It doesn't feel like bolting on an entire relatively-slow programming language is going to make your code more organized than a relatively easy to use tag.

alabastervlog 2y ago
We could have datasource-backed tables and list elements. Built-in. Sorting for most purposes, "for free", and more with simple and light JS hooks for sort functions. Frames that actually work as useful UI elements. "Basic auth" screens that look and function well enough for lots of purposes. Something like "Apple Pay" or other external payment systems but built into the browser, replacing stupid amounts of time spent writing yet another payment form (and usually fucking it up in several ways) But no.
lelandfe 2y ago
> I'm so tired of having to write my own JavaScript to get annoying flashy text Fret no more: <style> .blink { animation: blink 1s steps(2, start) infinite; } @keyframes blink { 50% { visibility: hidden; } } </style> <p class="blink">Lorem ipsum</p> https://jsfiddle.net/xrkLt2nz/ https://jsfiddle.net/xrkLt2nz/
- tombert 2y ago
  This is certainly better than nothing, but it should just be a tag! I shouldn't need this fancy new-fangled "CSS" fad to bail me out of the problems that W3C created by removing it in the first place!
  - lelandfe 2y ago
    Definitely. Much less the many several users who yet lack CSS support in their preferred browser.
    - tombert 2y ago
      The good news is that <marquee> still works in the latest Firefox. No need for any new-fangled animation libraries for me.
- Sohcahtoa82 2y ago
  If front-end devs would stop reinventing things using JS that can be done in CSS, I'd be so happy.
  - wruza 2y ago
    Why?
    - thesuitonym 2y ago
      Not the GP, but my two cents: because JS sucks and CSS can already do it.
    - Sohcahtoa82 2y ago
      Because the JS version will likely take more resources and probably end up being done wrong anyways. I just don't get why front-end devs feel the need to reinvent everything. I mean, for fuck's sake, front-end devs for some reason have a fascination with reinventing fucking SCROLLING. And 100% of the time, it either doesn't work, has less functionality than what was built-in, or is annoying for the simple fact that it changes an expected behavior. If I click my scroll wheel once, and the page keeps scrolling and the scrolling slowly comes to a stop as if it had momentum, that's a bug, not a feature. Stop wasting time deliberately writing bugs.
      - wruza 2y ago
        Scrolling is sort of a strawman here, so I’ll focus on blinking and css features and the need to reinvent these. First, not all css features are consistent enough from the side you usually tend to approach things, due to various backgrounds and thinking modes. Css is notoriously overcomplicated, nuanced and ad-hoc applicable, and tendency to neglect it is its own self-imposed problem. Second, there’s no law that dictated some true way to do things. People use instruments they know, and if these work, there’s no need to go and find true ways. Overall, there’s no difference if you do something in js that css can do, apart from hurting someone’s feelings. All the difference you see is in multi-megabyte tracking scripts, not in js-dom chain per se. The difference betwen css and js ways is barely measurable when you start actually testing it. But js is more powerful in expression and familiar to a developer (except for 60fps+ animations and such). I say this as a non-frontend dev who makes dashboards and other report/control pages for myself, so opinions may vary. But I’ve never seen a higher resource consumption from avoiding css. To my understanding, literally all sites I ever visited can be implemented in a straightforward way in js and will never “take more resources” and will work as fast as just html. Because it’s literally how any non-C GUI app works on desktops. An interpreted jit-able language controlling some widgets. It’s nothing new or unusual or bizarre. In fact, css is also a language, even if declarative, and keyframes structures and other calc()s also get interpreted many times per second, even if not using a full-blown vm. In my opinion, people’s web bloat ideas are all over the place and miss the basics comletely, e.g. https://news.ycombinator.com/item?id=42990724 https://news.ycombinator.com/item?id=42990724 , and tend to blame wrong parts.