5 ms·

So many Web designers put zero thought into how their page looks when it is not loaded or not scrolled exactly past the trigger. So many sites say "0 happy cust

by Kwpolska 10mo ago

So many Web designers put zero thought into how their page looks when it is not loaded or not scrolled exactly past the trigger. So many sites say "0 happy customers", because someone thought showing incrementing numbers is cool. On this page, it opens up with a "100%" loading indicator, for a site that appears to have no interactivity that would require JS, just to show a pointless animation.

MrJohz 10mo ago
Yeah, I thought those code samples would run immediately, in which case maybe the loading would be justified (although surely very easy to avoid). Instead, they're links to a different page that has the same code sample and a link to run the code, meaning I need to press twice to see what the code does when it runs, which isn't a lot but is surely at least one (possibly two) clicks more than necessary. That said, it's cool seeing some of those samples, because they're honestly not really what I expected. For example, I didn't expect the list subtraction to work at a set operation, so seeing that example gives me a feel for what sort of things I can do with Ruby code.
- ModernMech 10mo ago
  > I need to press twice to see what the code does when it runs, which isn't a lot I don't know the exact numbers, but the figures show you lose a high percentage of viewers with each click. So if you have 100 people who view the first page, 10 of them might click the link to the second page, and only 1 of them might click the link to the third page. If having customers view the running code is crucial, you'd want it on the very first page, above the fold.
firefax 10mo ago
I really like the 90s-esque aesthetic of sites like HN. Low bandwidth, minimal in an artistic way. I wish less sites would try to make them look like a wordpress from the early twenty aughts.
- Elfener 10mo ago
  You don't even need to do a certain aesthetic to make your website fast. Just send your entire content in the HTML, instead of needing extra HTTP requests for JS and then more HTML before having all the stuff for your first render.
  - firefax 10mo ago
    [matrix voice] What if I told you that you don't need javascript?
- elxr 10mo ago
  The early internet aesthetic is why, as much as I dislike the site's culture, I continue to use reddit + RES. The UI, the minimal buttons, the tight paddings, the lack of pop-in, the complete lack of animations; these have all been essentially unchanged for the past decade. Even the dark mode colors look exactly as it did the first time I switched it on.
deleted 10mo ago
[deleted]
librasteve 10mo ago
I am sure that the designers had to juggle a massive amount of community input and feedback and I know that this is not easy. Kudos to them for (i) leading with some very apt code examples, (ii) the 4 "whys" and (iii) the multilingual support. Speaking from experience (recently we rebuilt https://raku.org https://raku.org), I am sure that they will come back and optimize, but tbh this is not the priority with a new site where the hits will top out at ~ 10k / hour. I am no great fan of animations, simpler is better imho - and I have resisted requests to add a sandbox to the Raku site since https://glot.io/new/raku https://glot.io/new/raku does such a good job anyway... but I think Ruby is likely to appeal to a wider audience via a cool design vibe, whereas Raku is still in the early adopter / geek phase of adoption. btw Ruby is a fantastic language!
- troupo 10mo ago
  > I am sure that they will come back and optimize, but tbh this is not the priority with a new site where the hits will top out at ~ 10k / hour. You don't need to "come back and optimize" if you don't start with needing a progress indicator for a "transform: scale" animation to display a single static download link. The number of hits is not relevant. Neither do you need to do three separate fetch requests for static plain text examples that you then laboriously dump into the DOM by creating dummy elements, putting content in there, then looking up and cloning `code` tags to then dump those code tags on the page.
  - port11 10mo ago
    I think you might have an issue with modern frontend practices. That's okay, but there's a disproportionate amount of hate towards Ruby's redesigned page. And it looks perfectly fine. HTPP/2 parallel requests aren't that big a deal, all things considered. The website looks cool to me, makes me want to try Ruby.
    - braiamp 10mo ago
      He doesn't hate Ruby's redesigned page. He is complaining about yet another example of waste of resources that clients have to do because you want your page look "dynamic". Please, make sure and be aware were these comments are being posted, a site that it's both "dynamic" and doesn't require much resources from the client.
zelphirkalt 10mo ago
Yep, and for such cases it is usually very easy to make it work properly, if only a web developer put a little thought to it. We have most or all of the tools we need in HTML and APIs to make it work regardless. Like for example for the happy customer counter one could easily have a noscript fallback, that uses the number one already needs to retrieve to show the animation, but puts it there immediately. Then, iff JS gets executed, one can still animate the shit out of it. It is part of what distinguishes actually good web devs from move fast and break everything kind of people.
- efilife 10mo ago
  The noscript would not be needed at all. The value could be the real one by default, then in js set to 0 and incremented
  - zelphirkalt 10mo ago
    True, in this case even easier! I guess I thought of noscript due to other cases I had recently, where I noscript-ed a whole workflow and displayed elements, that should never appear, when JS is running.
  - deleted 10mo ago
    [deleted]
  - deleted 10mo ago
    [deleted]
mb2100 10mo ago
It even loads the code snippets in separate HTTP requests :-( But the snippets themselves are really good! I'm going to update mine on https://mastrojs.github.io https://mastrojs.github.io

MrJohz 10mo ago

Yeah, I thought those code samples would run immediately, in which case maybe the loading would be justified (although surely very easy to avoid). Instead, they're links to a different page that has the same code sample and a link to run the code, meaning I need to press twice to see what the code does when it runs, which isn't a lot but is surely at least one (possibly two) clicks more than necessary. That said, it's cool seeing some of those samples, because they're honestly not really what I expected. For example, I didn't expect the list subtraction to work at a set operation, so seeing that example gives me a feel for what sort of things I can do with Ruby code.

ModernMech 10mo ago
> I need to press twice to see what the code does when it runs, which isn't a lot I don't know the exact numbers, but the figures show you lose a high percentage of viewers with each click. So if you have 100 people who view the first page, 10 of them might click the link to the second page, and only 1 of them might click the link to the third page. If having customers view the running code is crucial, you'd want it on the very first page, above the fold.

firefax 10mo ago

I really like the 90s-esque aesthetic of sites like HN. Low bandwidth, minimal in an artistic way. I wish less sites would try to make them look like a wordpress from the early twenty aughts.

Elfener 10mo ago
You don't even need to do a certain aesthetic to make your website fast. Just send your entire content in the HTML, instead of needing extra HTTP requests for JS and then more HTML before having all the stuff for your first render.
- firefax 10mo ago
  [matrix voice] What if I told you that you don't need javascript?
elxr 10mo ago
The early internet aesthetic is why, as much as I dislike the site's culture, I continue to use reddit + RES. The UI, the minimal buttons, the tight paddings, the lack of pop-in, the complete lack of animations; these have all been essentially unchanged for the past decade. Even the dark mode colors look exactly as it did the first time I switched it on.

deleted 10mo ago

[deleted]

librasteve 10mo ago

I am sure that the designers had to juggle a massive amount of community input and feedback and I know that this is not easy. Kudos to them for (i) leading with some very apt code examples, (ii) the 4 "whys" and (iii) the multilingual support. Speaking from experience (recently we rebuilt https://raku.org https://raku.org), I am sure that they will come back and optimize, but tbh this is not the priority with a new site where the hits will top out at ~ 10k / hour. I am no great fan of animations, simpler is better imho - and I have resisted requests to add a sandbox to the Raku site since https://glot.io/new/raku https://glot.io/new/raku does such a good job anyway... but I think Ruby is likely to appeal to a wider audience via a cool design vibe, whereas Raku is still in the early adopter / geek phase of adoption. btw Ruby is a fantastic language!

troupo 10mo ago
> I am sure that they will come back and optimize, but tbh this is not the priority with a new site where the hits will top out at ~ 10k / hour. You don't need to "come back and optimize" if you don't start with needing a progress indicator for a "transform: scale" animation to display a single static download link. The number of hits is not relevant. Neither do you need to do three separate fetch requests for static plain text examples that you then laboriously dump into the DOM by creating dummy elements, putting content in there, then looking up and cloning `code` tags to then dump those code tags on the page.
- port11 10mo ago
  I think you might have an issue with modern frontend practices. That's okay, but there's a disproportionate amount of hate towards Ruby's redesigned page. And it looks perfectly fine. HTPP/2 parallel requests aren't that big a deal, all things considered. The website looks cool to me, makes me want to try Ruby.
  - braiamp 10mo ago
    He doesn't hate Ruby's redesigned page. He is complaining about yet another example of waste of resources that clients have to do because you want your page look "dynamic". Please, make sure and be aware were these comments are being posted, a site that it's both "dynamic" and doesn't require much resources from the client.

zelphirkalt 10mo ago

Yep, and for such cases it is usually very easy to make it work properly, if only a web developer put a little thought to it. We have most or all of the tools we need in HTML and APIs to make it work regardless. Like for example for the happy customer counter one could easily have a noscript fallback, that uses the number one already needs to retrieve to show the animation, but puts it there immediately. Then, iff JS gets executed, one can still animate the shit out of it. It is part of what distinguishes actually good web devs from move fast and break everything kind of people.

efilife 10mo ago
The noscript would not be needed at all. The value could be the real one by default, then in js set to 0 and incremented
- zelphirkalt 10mo ago
  True, in this case even easier! I guess I thought of noscript due to other cases I had recently, where I noscript-ed a whole workflow and displayed elements, that should never appear, when JS is running.
- deleted 10mo ago
  [deleted]
- deleted 10mo ago
  [deleted]

mb2100 10mo ago

It even loads the code snippets in separate HTTP requests :-( But the snippets themselves are really good! I'm going to update mine on https://mastrojs.github.io https://mastrojs.github.io