It’s been a real pleasure getting back into Ruby after so many years in typescript, python, and rust.
Happy to see the update. Real shame about the haters here, the Ruby community is a supportive and positive bunch that has shipped real products while others seem to worship at the altar of computer science alone… that’s about as counter snarky as I want to be here
A side effect is an increased intolerance to agony, boilerplate verbosity, complexity. I look at the JavaScript world and shudder.
Also, Ruby being as expressive as it is, describing things to an LLM is not really a timesaver over writing the code myself.
They aren't native american of course. That's a silly dishonest argument based on wordplay.
If so, is it racist to assert or assume that ethnic Europeans exist?
True believers have created a largely arbitrary grouping called “white people”, assigning it the “oppressor” label.
If a favored group’s nation were flooded by “white people”, that would be seen as an emergent situation requiring remedy; the opposite is what we’re seeing play out in societies like Britain, and is Not a Problem. I’m committing an act of violence by even describing it in this way.
How or when a disfavored group is restored to neutral or favored status is undefined; one would presumably have to consult a head priest of the movement for an answer (and I wouldn’t expect any coherence or clarity).
"Native brit" does not identify a people the way "native american" does.
There is no entry in the dictionary for "native brit".
This is all I'm talking about.
Quit trolling.
Speaking from experience (recently we rebuilt 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 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!
Clicking through the code examples on your new website, I kept being amazed at some of the great things Raku does. It's night and day in understanding the uses and purpose of the language! Thank you.
Unfortunately, as soon as I click into the "introduction" section of the docs I'm abandoned to a wall of links and am once again lost. I'll try persevere this time, but I think you could do adoption of Raku a great favour by working on organising your docs site a bit more clearly. Astro's docs are an amazing case-study on best-in-class docs layout and writing: https://docs.astro.build/en/getting-started/
FYI, front-page has a lot of examples, that I assume change when switching tabs, e.g. "multi-paradigm" "strict-gradual" "interactive-mode", etc.
But nothing happens, neither Safari 18.6, nor Chrome 143.0, on macOS 15.5.
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.
The website looks cool to me, makes me want to try Ruby.
So what do you expect? People ignoring the frankly idiotic choices made that you now defend with "they will come back and optimize it"?
> HTPP/2 parallel requests aren't that big a deal, all things considered.
I literally see a progress counter that is for some reason required to display the most trivial animation to show ... a single static link. On a gigabit connection. All that takes up to two seconds.
On that same connection the same thing happen to three purely three static examples of code that somehow need up to two seconds to appear and to shift the entire content of the page.
Both are especially jarring on mobile.
That said, I've no reason to defend the page. It just didn't strike me as bad, but I can see how others are experiencing a bad page.
The same is on desktop Firefox. For some reason youtube can't process the screencast for that :)
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.
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.
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.
What if I told you that you don't need javascript?
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.
It is part of what distinguishes actually good web devs from move fast and break everything kind of people.
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.
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.
care to elaborate?
- 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.
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.
The theme toggle has three states. How do you model this with a checkbox?
(Also, technically, alternative stylesheets can be defined in HTML, except every browser except Firefox removed it: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...)
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.
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.
Amateur hour.
ruby-lang.com stood out with a text in a big font:
Ruby is...
Followed by a paragraph about what makes Ruby special. I think that was an exceptionally simple and natural way of introducing something as complex as a programming language.
For reference this is the old one, which is much better: https://www.ruby-lang.org/images/about/screenshot-ruby-lang-... From: https://www.ruby-lang.org/en/about/website/
The old one was better because it said something about what the language is and how it benefits the user. "Best friend" is not descriptive. "dynamic language with minimal syntax that is easy to read and write" at least tells me something about Ruby, its priorities, and value proposition. I'm very concerned about a language that claims it wants to be my friend.
What does it do exactly? It just fetches[1] to another part of site and retrieves static text[2] to be displayed. This part could've been kept as part of the html, no need for this artificial loading. It's not a webapp, it's a website.
1. https://www.ruby-lang.org/javascripts/try-ruby-examples.js
2. https://www.ruby-lang.org/en/examples/i_love_ruby
In this day and age, it is possible to have an appealing, responsive, lightweight website with no JS (maybe except for darkmode toggle).
The homepage loads 9.7kB of JS. Navigating to every single link in the main nav results in no additional JS being loaded.
The site is fine.
Right, but I do not think this is the case here
For instance, here's Python's 144kB JS-powered homepage mid-load: https://imgur.com/a/OvYVAMS
And theirs doesn't even have any pretty images! That said, Ruby really ought to give those images a compress.
But you can have a button that saves your state when you enable javascript, and doesn't save your state (but still works) when you disable javascript.
edit: I think it is possible to save your state on the second click. So the UX is: you have 3 options with a slide. You click one of them, the page theme changes, and the option icon becomes a padlock. You click on it again, and the option is saved.
It seems to be a limitation that without javascript a single click can't change a switch and do something else--make a request to set a cookie. But you can do changing style on first click, then setting a cookie on the second. Here's a demo (written by Claude) (it doesn't work without server, just the HTML part) https://jsfiddle.net/r134vgo7/3/
[1] https://github.com/ruby/www.ruby-lang.org/graphs/contributor...
- https://glot.io/snippets/he42jpfm27
- https://glot.io/snippets/he42trx6w6
- https://glot.io/snippets/he434b6ryj
Ex 1
let say = "I love OCaml"
let () = print_endline say
(* Requires linking in the 'str' library *)
let say = Str.replace_first (Str.regexp {|\(.*\)love\(.*\)|}) {|\1*love*\2|} say;;
let () = print_endline (String.uppercase_ascii say)
let () = ignore |> Seq.init 5 |> Seq.iter (fun () -> print_endline say)
module StringSet = Set.Make(String)
let cities = StringSet.of_list [
"London";
"Oslo";
"Paris";
"Amsterdam";
"Berlin";
]
let visited = StringSet.of_list ["Berlin"; "Oslo"]
(* Requires the 'fmt' library *)
let string_set fmt v = Fmt.Dump.list Fmt.string fmt (StringSet.to_list v)
let () =
Format.printf "I still need to visit the following cities: %a\n"
string_set
(StringSet.diff cities visited)
module Greeter : sig
type t
val make : string -> t
val salute : t -> unit
end = struct
type t = { name : string }
let make name = { name = String.uppercase_ascii name }
let salute t = Format.printf "Hello %s\n" t.name
end
let g = Greeter.make "world"
let () = Greeter.salute g
my Cro $service; # geddit?
Also, if you want a more opinionated, HTMX centric web application library, then https://harcstack.org was used to make the new https://raku.org site