Frontend Ruby with Glimmer DSL for Web - Ruby on Rio - 2025-06-06 Meetup

A video has been uploaded of the Ruby on Rio 2025-06-06 talk I gave: "Frontend Ruby with Glimmer DSL for Web". It covers Glimmer DSL for Web, the Frontend Ruby on Rails gem that won a Fukuoka Prefecture Future IT Initiative 2025 award by Matz, the creator of Ruby.

YouTube link: https://www.youtube.com/watch?v=LY6ulYICuzE

Otherwise, I am happy to report that my talk proposal "Frontend Ruby on Rails with Glimmer DSL for Web" has been accepted at RubyConf Austria 2026.

Merry Christmas!

Recommended Plan for Migrating from React.js To Opal Ruby & Glimmer DSL for Web

In a recent team retrospective meeting at my job, 5 team devs (all) voted for the future plan item "More use of Opal Ruby & Glimmer DSL for Web in the Rails Web App Frontend". 

We are following a gradual rollout plan for migrating our React.js Frontend to Opal Ruby & Glimmer DSL for Web inside our Fintech Ruby on Rails web application:

• Step 1: Use Opal/Glimmer in new Admin UI features
• Step 2: Use Opal/Glimmer in new Manager UI features
• Step 3: Use Opal/Glimmer in new Customer UI features
• Step 4: Rewrite all legacy React components with Glimmer DSL for Web (either whenever touching legacy React components to make fixes/changes or in an incremental planned fashion that can be spaced out over a period of time with other business priorities taking precedence)

The plan could be adjusted to have as many steps as your web application has user roles with their own groups of webpages that they use, expanding gradually from migrating the least used webpages (lowest risk) to migrating the most used webpages (highest risk).

Step 1 in the process, using Glimmer DSL for Web in the Admin UI, was a success! So, the aforementioned retrospective item was about progressing further into Step 2 in 2026.

Glimmer improved performance in one re-written React page by 33% while cutting its code overall by about ~50% (and the component code became 1/10 what it was given there is no state management code in Glimmer components). 

One other 32-line Glimmer component was reused on 7 Admin UI pages very effectively and its performance of rendering was instant (aka fast enough). 

Also, when a relatively new Software Engineer on the team used Glimmer DSL for Web for the first time, he was able to complete his work in less than a week with much less code than what React.js would have needed, and with much better readability and maintainability. I was really impressed by the work of that Software Engineer in Opal Ruby & Glimmer DSL for Web. 

Eventually, that same developer ended up building another Admin UI feature in Glimmer DSL for Web, and his code was pure poetry! Such small components that don't exceed 43 lines of code.

Part of the reason why Step 4 is recommended at the end of the migration plan is because it is much cheaper to maintain Glimmer Ruby code compared to React JavaScript code. Also, I noticed that I could rewrite a very complicated React.js component that probably took a week or multiple weeks to build in only about 1-2 days tops in Glimmer Ruby code, and the overall code gets cut by about half. In other words, it is faster and cheaper to rewrite React components in Glimmer than to maintain them as they are when making fixes and changes. We literally feel like we're flying in Glimmer compared to moving like a slug in React.

This is the true state of the art in Ruby on Rails Frontend Development in 2025 (not silly Inertia that thinks inside the box of JavaScript by enabling more of the same garbage code in React.js/inferior-JavaScript-frameworks).

The future of Frontend Development in Ruby on Rails is very bright!!! I can't wait for what 2026 will bring!

I'm finally ready for the post-DHH Rails era! Are you!?!

The other day I chatted with someone from 37Signals. He didn't even tell me "Congratulations" for winning the Fukuoka Prefecture Future IT Initiative 2025 award for Glimmer DSL for Web when I mentioned it as a Ruby accomplishment. I mean any normal person would say "Congrats", let alone Ruby devs who should find any Ruby accomplishments infinitely interesting. That was not nice whatsoever, and frankly very creepy and weird. 

This proves my point once again about the Ruby on Rails community not being nice anymore and having become corrupt from the top. Both 37Signals and Shopify have become garbage in recent years. DHH is a terrible leader. I supported him a lot in the last 10 years, defending Rails whenever possible, but given that I know now he hires trash at his company, which doesn't support my award-winning highly useful open-source projects or other highly useful tools like Opal out of a sense of community, I think I'm finally done with supporting DHH. I don't appreciate the unequal relationship in which I support DHH and Rails folks, but they don't support me back. I'm finally ready for the post-DHH Rails era!

I mean 2025 was such an ugly year for the Ruby on Rails community and DHH. It hosted the last RailsConf due to issues between RailsConf and DHH. It had a huge conflict between Mike Perham and DHH that removed Sidekiq's financial support for Ruby Central. Shopify showed its true colors when it did a hostile take over of Ruby Central's RubyGems and Bundler (which fortunately later got moved under the purview of the Ruby core committers team, including Matz, the creator of Ruby). Ruby Conferences rejected my Matz-award-winning open-source Ruby Frontend project that saves developers 6 months of Frontend work every year over JavaScript, and allowed JavaScript in instead, believe it or not! And, Ruby/Rails subreddit members demonstrated over and over again mean unintelligent behavior, false privilege entitlement without qualifications, and closed-mindedness/standing-in-the-way-of-progress by downvoting novel posts to zero without even discussing them while sharing very nasty comments that ignored wrongdoing and clearly took sides just for 100% tribal bias reasons instead of thinking of everyone as an equal accountable for equal standards while being equally fallible, thus required to apologize for any committed mistakes instead of sweeping them under the rug. These things prove 100% that the Ruby on Rails community isn't nice anymore as per MINASWAN (Matz Is Nice And So We Are Nice). That is no longer arguable.

Not being truly nice goes hand in hand with stupidity. Nicer people collaborate better with others, so they end up with better information exchange and better work overall. No wonder the Ruby community has gone down the drain in recent years given that discrimination and unniceness have been normalized. Don't be deceived by discriminatory niceness, which is given to some people only but not to everyone equally. Some think the community is still nice because they're treated nicely without paying attention and noticing that niceness is offered to them as preferential treatment that is masking the problem. 

I would say that it's definitely the Rails subcommunity of the Ruby community that has the very big problems of unniceness and discrimination. The Ruby community outside of Rails is a lot nicer as it doesn't include companies like 37Signals and Shopify, and has devs who use Ruby with GUI Desktop Development, Opal, and TUI Development. Unfortunately, this fact gets lost sometimes because the Rails subcommunity is the loudest in the Ruby community and it gives the Ruby community a bad name.

Frontend Ruby on Rails with Glimmer DSL for Web (accepted at RubyConf Austria 2026)

My talk "Frontend Ruby on Rails with Glimmer DSL for Web" has been accepted at RubyConf Austria 2026.

Title:

Frontend Ruby on Rails with Glimmer DSL for Web

Elevator Pitch [FOR JUDGES]:

Glimmer DSL for Web is a Ruby Frontend Framework for Rails that won a Fukuoka Prefecture Future IT Initiative 2025 award from Matz. It is the missing piece of the puzzle that finally enables devs to write the Frontend of Rails web apps in Ruby too. This talk will cover its features and demo samples.

Description [PUBLIC]:

Glimmer DSL for Web is an SPA (Single Page Application) Framework for Rails that runs in Opal Ruby and has won a Fukuoka Prefecture Future IT Initiative 2025 award from Matz, the creator of Ruby. It provides a paradigm shift and the next stage of evolution in Frontend Development beyond JS libraries like Angular/Ember/React/Vue/Svelte by cutting down 12 months of JS work into 6 months of Ruby work every year. It has a more intuitive development model than Hotwire that better adheres to Software Engineering principles, albeit Hotwire has its place, and Glimmer can be used once Stimulus controllers grow too large or the need arises for using a Frontend SPA Framework.

It is currently in use at Eltropy inside the Collections 2.0 Fintech Rails web app as a gradual upgrade from React.js. It was able to cut down some React components by 1/10 the code and overall Frontend code by about ~50%, albeit with significantly more readable and maintainable Ruby, the language we all love. As a result, Glimmer DSL for Web should become the biggest difference maker and game changer in Rails development productivity in 2026, completely eliminating the need for directly using inferior JS libraries like React because Opal Ruby supports indirectly using any library in the entire JS ecosystem from Ruby.

Glimmer DSL for Web provides a Ruby HTML DSL, a Ruby CSS DSL (optional or to be used in a hybrid fashion with standard CSS/SCSS/Tailwind when Ruby logic is needed), Glimmer Web Components, Component Slots, Component Custom Event Listeners, ERB embedding glimmer_component Rails helper, Element Property Unidirectional/Bidirectional Data-Binding, Element Content Data-Binding, Element Inline Style Data-Binding, Element Class Inclusion Data-Binding, html_to_glimmer/css_to_glimmer commands for converting legacy HTML/CSS code to Glimmer DSL Ruby code, HTTP REST API Web Requests, and JavaScript library integration.

Using an isomorphic one language approach for both the Frontend and Backend in Rails web apps not only achieves significant productivity and maintainability improvements, but also opens the door to new possibilities, like the ability to reuse Backend Ruby logic directly in the Frontend without making API calls to provide faster response times for users, extending the Rails’ One Person Framework approach by enabling Backend Ruby Software Engineers to handle Frontend work in the same language (cutting hiring costs down by half), and enabling future architectural improvements such as connecting Frontend Ruby Models to Backend Ruby Models by automatically generating Rails REST APIs, thus removing the need for developers to write Rails controllers manually anymore, which would then cut down work in the Backend in addition to cutting down work in the Frontend, providing unheard of productivity benefits in Rails in the future.

Bio [FOR JUDGES] (including why I am the best person to give the talk):

The reason I am the best person to speak about this subject is that I wrote the Glimmer DSL for Web open-source project (glimmer-dsl-web Ruby gem) starting around 2024 and won the international Fukuoka Prefecture Future IT Initiative 2025 award for it in January of 2025 from Matz and other Fukuoka judges. I have spoken at RubyConf (2008/2022/2023/2024), RailsConf (2012/2014), MountainWest RubyConf 2011, MagicRuby 2011, and AgileConf 2008. I am the organizer of the monthly Montreal.rb Ruby Meetup in Montreal, Canada. I have a Master’s Degree in Software Engineering from DePaul University, Chicago, USA and a Bachelor’s Degree in Computer Science from McGill University, Montreal, Canada. I have 23 years of Software Engineering professional experience and 20 years of Ruby/Rails experience.

Interviewing Ruby Software Engineers Is Easier Than Ever in 2025!

(This article, which was posted at the end of 2025, doubles as a guide on "How To Be a Top-Level Ruby Software Engineer in 2026")

My team's approach to interviewing Ruby Software Engineers involves giving a candidate a small-size Rails web app project to complete over a week (some finish it in much less time), reviewing the solution to check if it follows good Software Engineering principles and practices, and conducting a follow-up interview meeting to ensure that the candidate did solve the project themselves and can answer follow-up questions that test their general Software Engineering skills and specific Ruby on Rails skills.

Regarding the follow-up interview, new developments in recent years and not so recent years have made it super-easy to interview Ruby Software Engineers and tell the good ones from the bad ones in 2025:

1. GitHub: With GitHub becoming so proliferate in the Software Engineering community, there is no excuse for any Software Engineer not to have a GitHub account with GitHub open-source repositories showcasing their code anymore. If a hiring candidate doesn't include a GitHub account on their resume with at least one open-source project (could be an experimental or purely learning project), then they won't make a good member in a modern Software Engineering team that sometimes contributes fixes to existing open-source libraries or extracts new open-source Ruby gems from existing work for the benefit of the Ruby community at large. Also, having open-source projects on GitHub demonstrates initiative and passion whereas not having any demonstrates laziness and lack of true passion. Many talk the talk of passion in Software Development, but few walk the walk by demonstrating passion with actions (e.g. open-source projects), not just words alone.
2. AI: Just ask a Ruby dev to tell you what they think of the Gen AI movement (e.g. Chat GPT) and its effects on Software Engineering. If they respond with anything other than stating facts like solving the right customer problems has a lot more effect on productivity than generating code, human interactions are more important for producing the best work possible than actually increasing machine interaction by replacing humans, or generating code isn't the bottleneck, yet maintaining it for years to come, then you have a dud on your hand, and you can safely eliminate that candidate from your hiring pool. In other words, even if AI was perfect, it's still better to have more human interaction as it brings new fresh ideas due and connects devs with their humanity, which yields a better understanding of customer needs and more creative solutions for their problems. Additionally, a smart candidate would recognize that using AI can be a bug in the requirements because Gen AI is fuzzy by nature while Software Engineers seek sure answers, so attempting to use a Gen AI is the wrong strategy from the get go as it doesn't satisfy the requirements, regardless of what sort of technical proficiency it has. AI can be great for gaming or art with its fuzzy nature, but terrible if a sure correct answer is needed. Furthermore, good candidates would recognize that AI is only as good as its input, so it often learns the answers that the average masses come up with, and even if it learns to provide good answers one day, after it ingests some more bad input for a while, it would unlearn what it learned and yield bad output. AI only provides the most common average solutions, but excellent Software Engineers come up with top-level solutions that are better than what's common, so again, AI limits top-level Software Engineers with that regard. I have observed that top-level engineers in the Software Engineering industry like Linus Torvalds, the creator of Linux, don't really care for AI. Only average devs care for AI. Many devs don't get this, making it easy to rule them out to find out the Software Engineers who are truly the best. By the way, it is OK for devs to use AI if they want to, but only as long as they responsibly do so while being fully aware of all the inherent issues explained above. We don't micromanage devs to either use or avoid AI (companies that micromanage their employees are awful and not maximally effective), but we do expect them to do correct Software Engineering reasoning about AI.
3. Microservices: Just ask a Ruby dev about their opinion of the Microservices architecture. If they claim it is necessary since day 1, you can safely deny the hiring candidate from further steps in your hiring process. If they completely dismiss Microservices and claim that everything can be solved by a Monolith, you can safely reject the candidate as well. The right answer would be a pragmatic "it depends on customer needs", and would describe adopting Microservices incrementally if needed only, while describing the pros, cons, and trade-offs for using different approaches, such as a Monolith, Rails Engines, and Microservices, clarifying that it is OK to adopt a hybrid approach instead of a black and white approach. Bonus points if the candidate recognizes that  "Microservice" is just a silly buzzword for what is more properly called "Web Service", which has been around since the early 2000s. 
4. New Programming Languages: Just ask the Ruby dev what they think of new programming languages like Elixir, Rust, Golang, TypeScript, Scala, and Clojure. If they respond with anything other than noting that the benefits of immutable FP are overhyped by people who have skill issues with OOP and aren't truly useful/necessary in a practical sense given that OOP, the more modern paradigm (FP is 70's style programming), operates just like how we naturally and intuitively think of the real world without having to go through a translation layer that maps everything into "functions", which loses half the battle, then you have a dud on your hand, and you can easily reject that candidate in your interviewing process. They still need to know what FP is useful for, numerical computing, like any sort of mathematical algorithms that truly represent functions in real life mathematics. Also, any sort of iteration over collections, which Ruby supports with its hybrid OOP/FP approach (e.g. using `reduce` or `map`, etc...). That said, also, if they respond with anything other than noting that in about 90% of Business App Development, dynamic typing enables better focus on business domain concerns (kinda like what Matz called driving auto in a recent RubyConf keynote speech) while static typing provides the illusion of better Software Development while actually making you work harder, take longer to finish features, and write more code overall while being distracted by types instead of focusing on business concerns, then you have a dud on your hand. Of course, they should still note where static typing is useful (kinda like what Matz called driving a stickshift at a recent RubyConf keynote). That's in optimizing algorithm performance when needed. Also, the candidate should demonstrate an open mind about being able to follow a polyglot's hybrid approach that relies on a dynamically typed OOP language for most basic features while calling out to a statically typed language for algorithms that need extra optimizations. That's kinda like how Ruby relies on C extensions or JRuby relies on Java. Candidates that fall easily for the hype of new programming languages without having the skills to discern what the pros, cons, and trade-offs are in each can be skipped in the hiring process.
5. React: Just ask a Ruby dev point blank what they think of React.js (and related technologies like Inertia.js). If their reaction is anything but disgust and absolute dismay, you're interviewing a dud that can be rejected safely in the hiring process. That means they don't really understand Ruby well enough to notice all the ways React.js contradicts the Ruby way and destroys Rails productivity, and they don't really know Software Engineering principles and best practices enough to notice where React breaks them, which makes maintainability very complicated and expensive and lowers productivity as a result. Another question that immediately reveals frauds with this regards is "How would you feel if someone invents a better Frontend technology than React that doubles productivity, improves readability, and halves code?" If you notice complete lack of interest or excitement in the candidate, you know you have a dud as well, someone who is attached to technologies for purely emotional non-rational reasons instead of rationally choosing technologies to serve customers in the best way possible.
6. Glimmer DSL for Web (2025 Fukuoka Award Winning Ruby Frontend Framework for Rails): Just describe Glimmer DSL for Web to a hiring candidate and explain how it completely eliminates the need for all JS Frontend Frameworks by enabling Software Engineers to leverage the same great benefits of Ruby that they always loved, but in the Frontend, doubling productivity, improving readability/maintainability significantly, halving Frontend code, halving the workforce (Backend devs can now do Frontend development), and halving Frontend Development costs. If the Ruby dev doesn't jump up and down with excitement or doesn't at least show some curiosity to learn more about the library's possibilities for the customers' benefit, then you know you have a dud on your hand that can be safely dismissed in the hiring process.

The good news is that those same recent developments also help truly skilled Ruby Software Engineers maintain job security very easily. It's ironic that AI didn't actually decrease job security, yet increased it for proper Software Engineers who are the real deal in their profession. Rejoice in these times! Our jobs have gotten much easier while the market got worse as a whole. 

One last note is hire devs with the backbone to say no when the masses are heading in the wrong direction. If a dev who might have noticed that a technology like React was bad at first later on changed their mind and approved of it just because the majority started using that technology, then they are exactly the wrong kind of dev to hire. Never hire spineless pushovers. Even if they come up with very smart solutions sometimes, the quality of their work can always be compromised by their lack of spine to push back against popular yet bad solutions.

I'm happy one of my team's recent hires volunteered to help me with Glimmer DSL for Web open-source work, and another actually complimented me on winning an award for that project and expressed great excitement about joining my team because of that accomplishment and our use of a Ruby Frontend library in our Rails web app.

The Embarrassing Ruby/Rails Subreddit Chronicles 2025-12-02

Welcome to another edition of the Embarrassing Ruby/Rails Subreddit Chronicles! A post was shared in the Rails subreddit about DHH claiming that money is a good reason to cheer for Shopify. I simply stated that no amount of money justifies mean discrimination, and I immediately got downvoted to 0. That proves yet again that there are devs in the Rails subreddit who are OK with mean discrimination if a certain amount of money is made and the subreddit mods are OK with mean discrimination by extension by allowing them into the group. 

Yet another embarrassment for the Ruby on Rails community as it officially admits the belief that mean discrimination is OK if a certain amount of money is gained, throwing MINASWAN out of the window instead of behaving in the ethical and nice Ruby way! This is the truth of the Ruby on Rails community in 2025!

DB GUI 0.3.0 & Glimmer DSL for LibUI 0.13.1 Released

DB GUI 0.3.0 & Glimmer DSL for LibUI (Ruby Desktop Development Cross-Platform Native GUI Library)  0.13.1 have been released. DB GUI now supports remembering multiple database profiles, including which one was last selected. Glimmer DSL for LibUI now supports combobox items data-binding. In the past, it supported combobox selected_item data-binding while assuming that the master items list is static (the older version of the C LibUI library had that limitation). After the last release, it now enables dynamically updating the items of a combobox as needed (the newer version of the wrapped C LibUI library now supports dynamic combobox items). This was useful for implementing the latest version of DB GUI as it will automatically add an item to a combobox's items upon saving a new database profile.

GitHub Projects:

• DB GUI: https://github.com/AndyObtiva/db-gui
• Glimmer DSL for LibUI: https://github.com/AndyObtiva/glimmer-dsl-libui

Ruby Gems:

• db-gui: https://rubygems.org/gems/db-gui
• glimmer-dsl-libui: https://rubygems.org/gems/glimmer-dsl-libui

Screenshots to illustrate the latest changes: 

DB GUI combobox with items data-binding:

combobox { |me|

  label 'Selected Config:'

  items <= [db_presenter, :dbs, on_read: ->(dbs) { dbs.map(&:name) }]

  selected_item <=> [db_presenter, :selected_db_name]

  enabled <= [db_presenter, 'selected_db.connected', on_read: :!]

}

items are data-bound unidirectionally to the names of the database profiles (dbs) in the presenter. That means, if the user fills in the database profile config form and saves, the items of the combobox are automatically amended.

Happy Glimmering!