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.
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.
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.
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!
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.
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.
It is part of what distinguishes actually good web devs from move fast and break everything kind of people.
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.
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.
[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
Obviously Raku leans more to `{}` and `my $var` than Ruby - but otherwise I think it does a credible job. Obviously these are carefully chosen Ruby snippets to highlit its unique abilities in strings, "array math" and classes. On the string interpolation, I would say that Raku has the slight edge (and has the whole Q-slang for a lot of fine grained control). On the array math, I had to apply the (built in) Raku set diff operator ... so I guess that Ruby is a little more natural for this (rather quirky) feature. On the class stuff, again very close. Raku has much more powerful OO under the hood ... multi-inheritance, role-composition, punning, mixins, MOP, and yet is a delight to use in this lightweight way.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)
Ex 2 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)
Ex 3 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
Obviously, OCaml is a much lower-level language than Ruby or Raku–notably, regex support is not as great, and we have to explicitly tell it how to print values of custom types. Still, I find its lack of syntax sugar makes it easy to read nearly any OCaml code I come across in the wild! my Cro $service; # geddit?
There are others, notably the more lightweight Humming-Bird https://raku.land/zef:rawleyfowler/Humming-BirdAlso, 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
It does reflect what the language creators pay attention to. Way back when, when I was undecided between learning Python or Ruby, after visiting countless resources I noticed Ruby websites in general looked way nicer and clearer than Python websites, so I picked Ruby. Now, years of experience with both languages later, I have zero doubt that to me that was the right choice at the time. I would’ve been frustrated with Python to no end.
I no longer need either language regularly, but given the choice again I would not hesitate to go for Ruby.
All that said, I do agree with some other comments on the thread regarding the disappointing reliance on JavaScript here. Should just be static.
Sometimes it's nice to just let people rest and get on with life.
i agree it's not a great look.
Hopefully the website will keep getting regularly updated and tweaked (software, is a living organism!), instead of being frozen in amber for a decade like the last version!
Same for absolutely static code examples that take a few seconds to load and shift the content away.
Why?
Unfortunately, most people today probably don't care about what you're talking about. (I do, but I've decided not to comment on it anymore, because it would probably drive me crazy :)
The designer fail to target their audience.
This is bit too much to ask. Just check the source it is swollen with Tailwind.
I like the design and content. Being able to immediately try a language online is huge
But there has to be a way to load that content in a progressive manner. Loading a static version first and then hydrating the content if you need interactive actions
Is the design debate public? I'd imagine it would make great reading.
It seems this site doesn't work so well without JS.
1. Code examples are fetched via JS instead of being in the HTML. They're static text - there's zero reason for this.
2. The "0%" loading spinner blocks everything. It's literally just displaying a download button and some text.
3. With JS disabled, you get nothing. A language website should be the poster child for progressive enhancement.
The irony is that Ruby itself has always emphasized developer happiness and doing things "the right way." This site feels like it was built with the modern JS framework mindset rather than the Ruby philosophy.
Still, huge improvement over the 2005-era design. Just wish they'd optimized it properly.
https://en.wikipedia.org/wiki/Progressive_enhancement
There were a lot of practical reasons for that: The browser landscape was much more diverse, different browsers had different support of standard Javascript, some browsers didn't even support JS and some people still kept text-only browsers like lynx/links in mind. Also browsers were not evergreen, so a large part of the audience could be on some older versions. Another thing were sometimes brittle network connection, especially over mobile. Depending on JS could in the case of corruption mean non-functioning websites.
For a lot whose exposure to web development and the discussions abound that, that reason will be stuck in their head, even if in the last decade of React ets the "best practices" will have changed.
There is also an aesthetic thing: There is a thing of beauty in simply curling an url and piping it into grep or such to get the thing you need, instead of having so have an headless browser. In my mind that is still how the web should work.
> Why the target audience of the ruby, probably primary web developers, whould do that?
In my experience, it's mostly web developers who care about this in the first place.
I’m not sure what you mean by this. We care about our users and how they use our websites. JavaScript is everywhere and has been the de facto frontend standard for the past few years. Supporting no-JS is starting to feel like supporting a new browser. As much as I’d like to, from a business and product point of view, the numbers are just too small for us to even consider it.
Maybe I'm not reading enough webdev forums. I agree though that things that don't required js should be written in no js way.
[1] https://www.ruby-lang.org/en/news/2025/12/17/ruby-3-4-8-rele...
I also wish the documentation search parameter were saved in the URL. This would allow people to create a custom Chrome search engine like @ruby and dramatically speed up doc searching.
Why you might ask? - Omakase Stack - high level is good for business processes - modern concepts without JS ecosystem churn - great testing capabilities - great ecosystem - highly effective stack for LLMs (conventions)
Is it fast in Benchmark Games - not by any means. Will you be able to finish projects and make money with it? Absolutely.
cities = %w[ London
Oslo
Paris
Amsterdam
Berlin ]
Do it properly with quotes you lazy people :)EDIT: typical ruby (on rails) code: saves a few characters, breaks readily (Hint: consider "New Orleans")
https://web.archive.org/web/20251113164224/https://www.ruby-...
Seems like a more grounded and healthier approach to programming languages.
This is ironic because Ruby has always emphasized doing things "the right way" and developer happiness. A language website should be a poster child for progressive enhancement - especially one that champions elegance and proper practices.
Still, huge improvement over the 2005-era design. Just needs optimization work to align the implementation with Ruby's philosophy.
For some reason there’s a large swath of people who really don’t like people saying that.
Also, apart from a quote from David Heinemeier Hansson the home page doesn’t even mention that ruby is a programming language.
For comparison, the following all mention that above the fold, with a short phrase indicating what you would want to use the language.
- https://www.python.org/ has “Python is a programming language that lets you work quickly and integrate systems more effectively. Learn More”
- https://www.perl.org/ has “Perl is a highly capable, feature-rich programming language with over 37 years of development”
- https://www.php.net/ has “A popular general-purpose scripting language that is especially suited to web development. Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world.”
- https://www.swift.org/ has “Swift is the powerful, flexible, multiplatform programming language. Fast. Expressive. Safe.”
Python is pretty well known as a data, analytic and machine learning oriented language, and they lean into a more broad characterization.
Perl might be described as dead/dying, and they characterize its development as ongoing.
PHP might be described as a web scripting language, and they characterize it as general purpose and broad.
Swift might be described as an Apple platform a language, and they really want us to know its multi-platform.
A site (re)design starts with determining who’s your audience, and what you want to tell them.
These sites will want to serve both existing and new developers.
What they want to tell them will be different for the two groups, but the existing ones won’t be chased away by a short description aimed at newcomers, but newcomers can easily turn away by the lack of such a description.
As to what to put in the description: it sort-of is an advert, so you often don’t exactly say what you are, but more what you want to be.
https://www.swift.org is a clear example. They definitely want to tell everybody that Swift is multiplatform, giving cloud services, command line tools and embedded development more prominence than iOS apps.
I think they do that particularly well, much better than this ruby site (https://www.ruby-lang.org/en/)
For example, on the swift site, they claim ‘embedded’. If you click on that, you get examples for various platforms such as Raspberry Pi and STM32 (https://www.swift.org/get-started/embedded/). That allows you to verify that claim.
In contrast, this Ruby site makes claims such as 'Easy to write, easy to read. Natural syntax like spoken language’, 'Do more with less code', but it’s not easy for users to check whether that’s true.
Comparing to Python, where virtualenv is de facto default, and pyls works by default, the experience with Ruby is not that great.
New website looks like a website for a startup project that will be closed in 2 years.