Looks nice. I'd love to have a way to select anything on the screen or at least have a button to copy more info, like manufacturer name of a found device.
I think the benefits of either clean code (sepearate methods) and commenting "what" are of different kind:
- clean code one, for me it just reads easier, specific bits of the larger operation are not surrounded with noise coming from other bits like it is in the commenting "what" one. I can focus more on each step, and that can make it easier to spot a bug or to refactor/adjust/extend, as now I'm more like on a given page of Lego set instructions
- the commenting of "what" one - yeah, this obviously makes it quicker (but probably not easier) to see the larger picture. It has benefits, but I believe this helps more hacker/scripter kind of people than programmers
I like how it looks. I don't like to see how badly it is crafted tech-wise - not optimized images by size and deferring, JS for things that work natively in the browser, bloat of tailwind instead of nice clean and modern CSS.
Knowing ruby I can tell that the relaxed approach to the website does not correspond with sophistication in the language itself. If I wouldn't know ruby, that would be a put off for me, thinking that if they don't want to convince me tech-wise by their site, it might be similarly annoying to deep-dive into the language.
- images: none are visible above the fold - all should be lazy loaded (like it is done with all conference images) and
the pragdave.jpeg one does not need to be that large;
- JS: navigation toggle, including chevron rotation can be done in CSS using :has combined with checkbox/radio input. Similarly for header-navigation and theme-toggle (here combined with cookie store). Then toc.js - seems like something easy to do in the backend. Hero-animation - I haven't looked much through it but seems like at least some parts can be done in CSS;
- CSS/tailwind - well it would probably take less typing to do it just in CSS, the site does not seem to be that much componentized to benefit from tailwind.
I would generally caution against doing toggles with CSS. While it can be done, it often has surprising effects, and can be difficult to make properly accessible (for example in the case of opening the navigation, I don't believe it's possible to set the correct aria tags to indicate that the toggle is a button that is showing/hiding another element on screen).
Instead, for a brochure site like this, I'd rather have the links just always visible, because this is the reference site for Ruby and I imagine a lot of people find them by searching "Ruby", coving l clicking the homepage, and scanning for the link to the docs/downloads/etc.
Alternatively, if the show/hide feature is really that important, right now I would (a) explore whether it can be done accessibly using the new invoker API, so you don't need JavaScript at all (with a JS fallback), or (b) just do it in JavaScript directly, but with an accessible default if the JS doesn't get loaded properly.
But yeah, the rest I largely agree with. There's a bunch of stuff here that would have been simpler, and arguably also easier, if they'd taken a slightly different approach.
Why does a site even need a light/dark toggle, when you can just use prefers-color-scheme in CSS, and the user can select that in their browser settings?
Because being able to switch from light to dark mode by clicking a single button is a useful feature, and while it would be nice if operating systems provided this out of the box, many (e.g., Windows) do not.
> Why does a site even need a light/dark toggle, when you can just use prefers-color-scheme in CSS, and the user can select that in their browser settings?
Good question, especially since the Ruby site already does this by default. Perhaps the argument is that one of the two color schemes may be designed so poorly that the user may want to manually switch to the other one.
Because as a user, I want to change the light/dark of your site, not every set, and not my OS. If you don't have a toggle, you are making assumptions that aren't accurate.
I am assuming that if the user selected a specific brightness mode, they want sites they visit to respect that theme. Call me crazy but this seems like common sense.
I know some web developers think that that’s true, but looking at the average people I know, they tend to want different settings depending on the site. People don’t generally want computer-wide settings for darkmode.
This is true, also for people immersed in this world. Sometimes the dark mode of a site is ass, and it's better to set a preference for that site to use light mode to make it more usable.
It could be done with :indeterminate state (so key in a cookie would be absent or removed when switching), but I'd probably would do it with radios instead
Note that a checkbox's indeterminate state can only be set via JavaScript, so that lessens the elegance of a CSS-based approach.
I agree that using radios would be better. Or just prefers-color-scheme, which sidesteps the FOUT issue that often occurs when storing theme settings in localStorage.
Ruby isn't necessarily for web devs. Ruby is popular for all sorts of business line applications. In Japan is popular for lower level programming. You can do game programming via something like Dragon Ruby. Sure its very popular for Rails, but you don't necessarily need to do web dev.
That's exactly the use case I would go too (since I'm not native English) and while we have a technology now for this, people will straight away reject because LLM. Funny how we always wanted to connect the world and know it is just not compatible with the situation.
The type of developers that would go with <div> in such cases are also those that know very, extremely little about semantic HTML and its purpose.
Then if one is challenged about using React or other heavy-JS framework when you don't really have to, the discussion will be met with utter even surprise that someone out there is actually not using React.
The web is darn simple, but we are the place where it is made extremely over engineered and expensive for both companies (salaries and 2-3x more staff needed than necessary because of the bloat) and users of their products (in terms of payloads).
And yet JS-heavy frameworks seems to have the best job market.
reply