I used cursor over the past three weeks to update a 12 year-old Ruby on rails project. While it has been slightly updated throughout the years, this was my first proper modernization of the code base.
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
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.
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.
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.
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
I like the new design, however, I strongly believe the website could've been optimized further and used much less JS. Opening the website with JS turned off makes the code examples not load and the front page freezes as "0%" loading.
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.
Not long ago I was looking through programming language sites to figure out how to best introduce the language I'm working on.
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.
Meta, but it's kind of ironic that the main Ruby language website shows a "0%" Ruby symbol with javascript deactivated, and doesn't even show the code examples, which are all just links to some sandbox anyway.
It annoys me so much when developers think they can do it better and link with JavaScript. Interactions (like opening a dialog) witj JS - yes. Navigating to sites/positions in-site - that is just dumb. So many pages break the "open in new tab" behaviour with this implementation.
Refreshing and delightful! I know how the home page looks doesn't reflect the programming itself, but this design really makes me want to try Ruby again :)
> I know how the home page looks doesn't reflect the programming itself
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.
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
Nice! There is a Japanese feel to the lead graphic, their prevalence of cartoon imagery, that one might not recognize without having traveled in Japan.
Is the design debate public? I'd imagine it would make great reading.
On my iPad, without scrolling, the screen shows almost nothing, just a download button and some text that, I think users will ignore. I think that’s a waste of valuable screen estate.
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.”
Ruby is GOATED.
You can say what you want but Ruby coupled with Rails is the most productive web stack period.
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.
The Lighthouse report is telling. It scores 100% for Best practices and SEO, but 54% for Performance. Pages like these used to be caricatures of the modern web, but are now acceptable. DHH's statement doesn't help either.
So, in order to show a single download link it needs to load an animation with visible loading progress even on a gigabit connection. It takes a few seconds to appear. All to show a scaling animation that can be achieved with a couple of lines of CSS.
Same for absolutely static code examples that take a few seconds to load and shift the content away.
You are a rare species, on the verge of extinction.
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 :)
Sure, if you ignore the SSR and SSG part, which sadly most nodejs stuff lacks.
Additionally, Next.js should only be used when SaaS product vendor doesn't allow for any other option, which sadly is the case when making themselves sellable to magpie developers, while riding VC money until the IPO takes off.
I rather deliver, than do yak shaving, but at least can deliver only HTML and CSS if I chose to.
Tailwind maps directly to CSS (well, it is pure CSS) and doesn't require a loading progress for a one-line animation: https://tailwindcss.com/docs/animation
We went from a world where you had tremendous computational biodiversity, where your potential users could be running SPARC, POWER, VAX, PA-RISC, MIPS--to name a few--to one where it's almost certainly just x86-64 or Arm. Yet somehow, the Ruby community (and Python as well) think it's acceptable to have a standard implementation that does neither AOT nor JIT native code compilation, despite V8 (JS) being 17-years-old, and less popular dynamic languages managing to pull it off (e.g., Lua, SBCL, or Pharo/Squeak).
The Ruby (and Python) communities need to be told firmly that a JIT--and not as an experimental or secondary option--is table stakes for a runtime in 2025. Doesn't matter that you have a hip website with cartoons of "furbabies" and diverse, disembodied faces, with the number of white faces kept to a socially-conscious limit of 1 in 10, or how supportive/wholesome/creative the community supposedly is. No JIT = no greenfield projects. Make it clear that you'll use JavaScript (or something that transpiles to it) because of V8, or Go, Rust, Zig or something else.
Especially now that the tide has turned against dynamic languages, meaning that Ruby has to work that much harder to prove itself.
> somehow, the Ruby community [...] think it's acceptable to have a standard implementation that does neither AOT nor JIT native code compilation
Ruby have YJIT, which is a production ready JIT compiler that generates native machine code. But it requires enabling via flag "--yjit" rather than running by default.
Why? I think it's primarily to avoid build time dependencies on Rust and prevent unexpected overhead for users. This keeps binary light and avoids forcing Rust installation on users, especially for those who run interpreter only, where YJIT adds no value.
Note that including YJIT also bloat binaries by 5 to 10MB (Rust static lib + code cache structures) for source builds and complicates cross compilation since Rust targets vary by architecture (focus x86-64 and arm64, not all platforms).
Also, Rails 7.1+ enables YJIT by default, so JIT (to native code) in Ruby is being utilized when actually needed.
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
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.
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.
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.
The theme toggle has three states. How do you model this with a checkbox?
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.
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.
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.
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.
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.”
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.
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.
It's C/C++ developers that typically prefer a no-fluff approach.
One of the reasons Next.js is attractive to me, is exactly they have rediscovered why so many of us have stayed with SSR.
Hmm. We can agree to disagree on the definition of fluff.
Additionally, Next.js should only be used when SaaS product vendor doesn't allow for any other option, which sadly is the case when making themselves sellable to magpie developers, while riding VC money until the IPO takes off.
I rather deliver, than do yak shaving, but at least can deliver only HTML and CSS if I chose to.
This is bit too much to ask. Just check the source it is swollen with Tailwind.
> flex-shrink-0 transition-transform duration-300 hover:scale-105 w-[160px] h-[144px] 2xl:w-[200px] 2xl:h-[180px]
just to avoid CSS, not sure they would bother with CSS animation.
The Ruby (and Python) communities need to be told firmly that a JIT--and not as an experimental or secondary option--is table stakes for a runtime in 2025. Doesn't matter that you have a hip website with cartoons of "furbabies" and diverse, disembodied faces, with the number of white faces kept to a socially-conscious limit of 1 in 10, or how supportive/wholesome/creative the community supposedly is. No JIT = no greenfield projects. Make it clear that you'll use JavaScript (or something that transpiles to it) because of V8, or Go, Rust, Zig or something else.
Especially now that the tide has turned against dynamic languages, meaning that Ruby has to work that much harder to prove itself.
Ruby have YJIT, which is a production ready JIT compiler that generates native machine code. But it requires enabling via flag "--yjit" rather than running by default.
Why? I think it's primarily to avoid build time dependencies on Rust and prevent unexpected overhead for users. This keeps binary light and avoids forcing Rust installation on users, especially for those who run interpreter only, where YJIT adds no value.
Note that including YJIT also bloat binaries by 5 to 10MB (Rust static lib + code cache structures) for source builds and complicates cross compilation since Rust targets vary by architecture (focus x86-64 and arm64, not all platforms).
Also, Rails 7.1+ enables YJIT by default, so JIT (to native code) in Ruby is being utilized when actually needed.
The current experimental JIT is ZJIT. And the fastest Ruby JIT Runtime is TruffleRuby. ( I wish JRuby gets more love )