5 ms·

The Thing is that most people here belittle Web Developers but they do not have a clue what we do. At all. In your pretty short answer you’ve already caught mi

The Thing is that most people here belittle Web Developers but they do not have a clue what we do. At all. In your pretty short answer you’ve already caught mistake. Let‘s see: > And if you want to stick the header to the top you can use `position: sticky` in CSS instead of including a huge Javascript file that can do all kinds of fancy stuff you don't need. Your „simple trick“ to avoid „including a huge javascript file“ doesn‘t work in: Opera, Chrome for Android, IE and a couple more[1]. It does work in Safari, but not as you would expect. Also, position:sticky is still a Working Draft. It is suspect to be changed at all times. Want the same functionality across all Browsers? Better use Js. Another thing is that most people here think „huge JS bundles“ are what make websites work. These are to be used for webapps though. If you want anything more than a static site, you‘ll need JavaScript. No way around it. [1]: https://caniuse.com/?search=Sticky https://caniuse.com/?search=Sticky

dahfizz 6y ago
> If you want anything more than a static site, you‘ll need JavaScript. Who doesn't want static sites? I certainly do. They're faster and easier to use. I've never heard a user say "I wish my back button didn't work and the page rendered wonky so that buttons move as I try to click them". It's web developers that push to turn simple HTML documents into "applications".
- 082349872349872 6y ago
  Every now and then I wish browser writers would compare timestamps between the link click and the last relayout, and throw away stale clicks instead of navigating to who knows where.
achairapart 6y ago
Come on, even the caniuse page you linked says `position:sticky` is supported by 94.33% of browser. For that ~5% left (very old browser versions or specific cases like Opera Mini, most likely even less real cases due to bot noise in statistics) there is a thing called "Graceful Degradation". If you do things right your page won't break at all if that CSS property is not supported. Your header will just be positioned fixed or even static. So, really, no huge (or small) JavaScript file needed at all in this case. Like most other bloat in web dev, that's just laziness that accumulates.
- thursday0987 6y ago
  94% is actually a really low number for support. that means that 6 out of every 100 people can't use it. Roughly 10 million people visit HN every month. that means that about 600,000 people can't use it just on HN alone.
  - achairapart 6y ago
    Well, statistics don't work in that linear way. For a start, that 94% is a global percentage that isn't evenly distributed worldwide, let alone on HN... Anyway in my comment I was actually saying that if you do things right it will work even for that 5%, without any JS. Maybe it wasn't clear enough?
  - earthboundkid 6y ago
    Flip it around: You're fucking up the browsing experience of 9.4 million people for a minor graphical effect that totally destroys scroll behavior and CPU. Just use CSS. No one will miss the sticky bar if it doesn't show up on their browser.
the8472 6y ago
> doesn‘t work in: Opera, Chrome for Android, IE and a couple more[1] Are we looking at the same compatibility tables? Caniuse lists it as working in android chrome and opera with the exception of <thead> elements, which are not relevant here because OP's example was about <h1>, not <thead>. I'll give you IE, but that's already ignored by many. > If you want anything more than a static site, you‘ll need JavaScript. Forms are still a thing. Then there's hover animations, summary/details, video elements and a few other interactive things that don't need javascript. There also is a middle ground between "static page" and "huge JS bundle". A little javascript usually isn't what makes web pages slow.
madeofpalk 6y ago
> If you want anything more than a static site The problem, as always, is (poor) developers making poor decisions. Implementing static sites as a JS-required, JS-heavy pages is something that some poor development teams are doing. Bungie, game developer, have been replatforming their site and they've turned what is mostly static content pages into purely client-side single page app which requires javascript to display anything https://www.bungie.net/7/en/Destiny/BeyondLight https://www.bungie.net/7/en/Destiny/BeyondLight It's sad because there are extremely productive ways to build this out using their preferrred technoligies (react) but deliver the static content from the server in the initial page load AND continue doing SPA-style navigations if desired. --- There are lots of webpages out there, that means there's lots of developers making them. Some developers will be good, some will be average, and some will be bad. The 'problem' with websites is that it's a lot easier to see when they've been done poorly, compared to say native apps.
the_gastropod 6y ago
> If you want anything more than a static site, you‘ll need JavaScript. No way around it. I’ve been noticing this kind of rebranding of what static means a lot. It seems to create lots of confusion (you can see it in this thread already). Traditionally, “static” websites were websites without a server-side programming language backing them—sites whose content was unchanged by any users. Javascript, CSS, and HTML are the tools used to build static websites. Today, some developers seem to use static to mean Javascriptless. The term fits both situations pretty well, so I get why it happened. I don’t know if there’s a better less-ambiguous term used for either of these things now?! Non-database-backed?! Nonjavascript’d?
- mrami 6y ago
  The term for JS enabled pages used to be DHTML back in the day. You'd be talking about a static-server DHTML site. Or something like that. https://en.m.wikipedia.org/wiki/Dynamic_HTML https://en.m.wikipedia.org/wiki/Dynamic_HTML
- bo1024 6y ago
  Good point - Hacker News works with barely any javascript (and it's optional); hard to argue that a forum is "static"!
thdrdt 6y ago
"Want the same functionality across all Browsers? Better use Js." This is not the point. The point is some developers just include big Javascript files because they don't know what other methods and options there are. I have seen developers include Javascript to 'fix' things across browsers but it made things worse because the `let` keyword was not supported in some browsers at that time. So it is not about if you should use Javascript. It is about the fact a website or webapp can and should be fast. But when a developer does not know about the technical aspects we will end up with multi-megabyte pages that take 10 seconds to complete. -- About the `position: sticky`: it is not smart to promise a client a pixel perfect experience across all browsers (unless they want or need to and will pay the extra price). In the case of a sticky header you can support all modern browsers with two lines of CSS (`position` and `top`). The other 6% won't have a sticky header but still a perfectly working website. So imho you did not caught a mistake but a real world example.

dahfizz 6y ago

> If you want anything more than a static site, you‘ll need JavaScript. Who doesn't want static sites? I certainly do. They're faster and easier to use. I've never heard a user say "I wish my back button didn't work and the page rendered wonky so that buttons move as I try to click them". It's web developers that push to turn simple HTML documents into "applications".

082349872349872 6y ago
Every now and then I wish browser writers would compare timestamps between the link click and the last relayout, and throw away stale clicks instead of navigating to who knows where.

achairapart 6y ago

Come on, even the caniuse page you linked says `position:sticky` is supported by 94.33% of browser. For that ~5% left (very old browser versions or specific cases like Opera Mini, most likely even less real cases due to bot noise in statistics) there is a thing called "Graceful Degradation". If you do things right your page won't break at all if that CSS property is not supported. Your header will just be positioned fixed or even static. So, really, no huge (or small) JavaScript file needed at all in this case. Like most other bloat in web dev, that's just laziness that accumulates.

thursday0987 6y ago
94% is actually a really low number for support. that means that 6 out of every 100 people can't use it. Roughly 10 million people visit HN every month. that means that about 600,000 people can't use it just on HN alone.
- achairapart 6y ago
  Well, statistics don't work in that linear way. For a start, that 94% is a global percentage that isn't evenly distributed worldwide, let alone on HN... Anyway in my comment I was actually saying that if you do things right it will work even for that 5%, without any JS. Maybe it wasn't clear enough?
- earthboundkid 6y ago
  Flip it around: You're fucking up the browsing experience of 9.4 million people for a minor graphical effect that totally destroys scroll behavior and CPU. Just use CSS. No one will miss the sticky bar if it doesn't show up on their browser.

the8472 6y ago

> doesn‘t work in: Opera, Chrome for Android, IE and a couple more[1] Are we looking at the same compatibility tables? Caniuse lists it as working in android chrome and opera with the exception of <thead> elements, which are not relevant here because OP's example was about <h1>, not <thead>. I'll give you IE, but that's already ignored by many. > If you want anything more than a static site, you‘ll need JavaScript. Forms are still a thing. Then there's hover animations, summary/details, video elements and a few other interactive things that don't need javascript. There also is a middle ground between "static page" and "huge JS bundle". A little javascript usually isn't what makes web pages slow.

madeofpalk 6y ago

> If you want anything more than a static site The problem, as always, is (poor) developers making poor decisions. Implementing static sites as a JS-required, JS-heavy pages is something that some poor development teams are doing. Bungie, game developer, have been replatforming their site and they've turned what is mostly static content pages into purely client-side single page app which requires javascript to display anything https://www.bungie.net/7/en/Destiny/BeyondLight https://www.bungie.net/7/en/Destiny/BeyondLight It's sad because there are extremely productive ways to build this out using their preferrred technoligies (react) but deliver the static content from the server in the initial page load AND continue doing SPA-style navigations if desired. --- There are lots of webpages out there, that means there's lots of developers making them. Some developers will be good, some will be average, and some will be bad. The 'problem' with websites is that it's a lot easier to see when they've been done poorly, compared to say native apps.

the_gastropod 6y ago

> If you want anything more than a static site, you‘ll need JavaScript. No way around it. I’ve been noticing this kind of rebranding of what static means a lot. It seems to create lots of confusion (you can see it in this thread already). Traditionally, “static” websites were websites without a server-side programming language backing them—sites whose content was unchanged by any users. Javascript, CSS, and HTML are the tools used to build static websites. Today, some developers seem to use static to mean Javascriptless. The term fits both situations pretty well, so I get why it happened. I don’t know if there’s a better less-ambiguous term used for either of these things now?! Non-database-backed?! Nonjavascript’d?

mrami 6y ago
The term for JS enabled pages used to be DHTML back in the day. You'd be talking about a static-server DHTML site. Or something like that. https://en.m.wikipedia.org/wiki/Dynamic_HTML https://en.m.wikipedia.org/wiki/Dynamic_HTML
bo1024 6y ago
Good point - Hacker News works with barely any javascript (and it's optional); hard to argue that a forum is "static"!

thdrdt 6y ago

"Want the same functionality across all Browsers? Better use Js." This is not the point. The point is some developers just include big Javascript files because they don't know what other methods and options there are. I have seen developers include Javascript to 'fix' things across browsers but it made things worse because the `let` keyword was not supported in some browsers at that time. So it is not about if you should use Javascript. It is about the fact a website or webapp can and should be fast. But when a developer does not know about the technical aspects we will end up with multi-megabyte pages that take 10 seconds to complete. -- About the `position: sticky`: it is not smart to promise a client a pixel perfect experience across all browsers (unless they want or need to and will pay the extra price). In the case of a sticky header you can support all modern browsers with two lines of CSS (`position` and `top`). The other 6% won't have a sticky header but still a perfectly working website. So imho you did not caught a mistake but a real world example.