Glimmer DSL for Web 0.9.1 Hello, Modal!

Glimmer DSL for Web (Matz Approved Fukuoka Award Winning Frontend Framework for Rails) had a new release in version 0.9.1 that includes a new sample called Hello, Modal! to teach how to create modals in Glimmer DSL for Web in the Frontend of Ruby on Rails web applications. By the way, rendering modals has been supported since the beginning in Glimmer DSL for Web, but there were no samples that demonstrated it before. I added a modal in the proof-of-concept branch of the Glimmer Commerce workshop app that was developed at the wroclove.rb 2026 Ruby conference 3-hour workshop regarding "Building Rails SPAs in Frontend Ruby with Glimmer DSL for Web", so I figured I'd add an official sample to Glimmer DSL for Web too that teaches how to render modals.

You can play around with the sample in the Sample Selector Rails web app (click to visit GitHub repo):

https://sample-glimmer-dsl-web-rails7-app-black-sound-6793.fly.dev/

GitHub of Glimmer DSL for Web: https://github.com/AndyObtiva/glimmer-dsl-web

RubyGem of Glimmer DSL for Web: https://rubygems.org/gems/glimmer-dsl-web

GreetingPerson Model code (holds the name of the greeted person):

GreetingModal View component code:

(the style could have been placed anywhere by the way, but I chose to put it in the component; albeit it could have lived in CSS/SCSS files outside the component too)

HelloModal View component code (entry point to the sample):

Rendering modals is very simple; this is all that is needed to learn:

• ComponentClassName.render(**kwargs) # renders any component (e.g. modal component) anywhere on the page. kwargs is any custom attributes that the component supports. If kwargs include a `parent` argument though (a reserved argument name), then its value is a CSS selector for where to place the rendered component. If `parent` is unspecified, then the smart default is `body` by convention.
• markup_root.remove # this is invoked inside a component class to remove the modal element from the page, in other words, closes the modal (e.g. upon clicking a close button or performing some operation)

Happy Glimmering!!!

P.S. To learn more about Glimmer DSL for Web, come see me speak at RubyConf Austria 2026 about "Frontend Ruby on Rails with Glimmer DSL for Web". You can ask me any questions in person at the conference about how to do Frontend Development in Ruby much more effectively than in JavaScript. 

P.S.2 Glimmer DSL for Web is a 100% free and open-source Ruby gem. I make $0 off of it as I only built it through many nights and weekends to solve my work Frontend maintainability and productivity problems that were caused by using React.js and to help the Ruby on Rails community as a whole  evolve towards better Frontend solutions. This Ruby gem finally enables Rails Software Engineers to use Ruby in the Frontend and Backend while being able to share Ruby logic between both sides of a web application to save time and provide more responsive web UIs. That eliminates all usecases for React/Angular/Ember/Vue/Svelte as Glimmer DSL for Web provides a much more productive, maintainable, and elegant Ruby solution that doubles productivity at least (sometimes enabling devs to go 10x) compared to using React.js. If you like Ruby, you'll love Ruby in the Frontend via Glimmer DSL for Web. It won an award by Matz himself, the creator of the Ruby programming language. 

DB GUI 0.4.0 Remember SQL Command History (useful w/ Ruby on Rails DBs)

DB GUI is a Database querying desktop app built in Ruby. It supports PostgreSQL to start. Version 0.4.0 added support for remembering SQL command history. I needed that feature at my job to be able to easily re-run certain SQL queries in our Rails web application, so I added it very quickly, thanks to the awesomeness of Ruby!

GitHub: https://github.com/AndyObtiva/db-gui

RubyGem: https://rubygems.org/gems/db-gui

Here is an animated gif demonstrating how the app works (by the way, you only need to configure the database settings once; afterwards, the app remembers the db config every time you start it, and now also remembers your SQL command history):

You can always open the app code if you are curious how it was built in Ruby (below is a link to the app's entry point View component):

https://github.com/AndyObtiva/db-gui/blob/master/app/db_gui/view/db_gui_application.rb

P.S. I am aware there are countless DB desktop apps out there. I have used many in the past. This project started as a fun learning exercise in Ruby, but now I maintain it to provide examples for others of how to build desktop apps in Ruby, and I like the challenge of extending it. 

Ruby Memes 2026-05-03: The Popularist

The Popularist (see the meme below first) ceases to question things, stops thinking for themself, and throws all their principles out of the window as soon as a bad technology becomes popular, due to The Popularist lacking the courage and backbone needed to say no when many devs head in the wrong direction.

Do you know Software Engineers who behave like "The Popularist", making it impossible to trust them with guarding the quality of your team's software? Popularity isn't quality after all. For example, many more devs use PHP, and yet Ruby on Rails devs choose their stack as a higher quality solution for productivity and maintainability. Intelligence and quality are scarce, so in fact, popularity is an indictment, as it means something is low quality enough to be used by the least common denominator majority who are not as intelligent as the top 10%. By the way in case it isn't obvious, React.js is NOT a good technology (learn more by clicking this link). 

Ruby Gem Discovery: HighLine

I recently stumbled upon a Ruby gem called HighLine that simplifies basic command line input/output via an `ask` method and supports validation, conversion, and multi-choices:

https://github.com/JEG2/highline

Here is an IRB session going through HighLine examples from the project README:

What took 1.5 months to build in React JS code took 1.5 days in Glimmer DSL for Web Ruby code

When I reimplemented a React component as the first Glimmer DSL for Web Component in my job's Fintech Rails web app, I thought I did what would have taken 1 week in React in 1.5 days in Glimmer, which seemed like a great improvement in productivity at the time (333.33% the productivity if we count 1 week of React as 5 business days). I recently inspected the Git timeline of the original React component, and discovered that it actually took 1.5 months to develop initially!!! That's compared to 1.5 days to develop in Glimmer DSL for Web! CAN YOU BELIEVE IT!!!?!!! Glimmer's productivity benefits over React are turning out to be bigger than what I initially expected!!! 

If you haven't started exploring the innovations of Frontend Ruby in your Rails Frontend Development stack, you're missing out big time while losing a huge competitive advantage to devs who are exploring those innovations. There is a huge gap in productivity between devs who write their Frontends 2016-style in JavaScript (e.g. React) and those who have moved on to greener pastures like Frontend Ruby, which provides exponential productivity improvements. Thousands of Ruby on Rails devs are wasting their time by using React.js in 2026 when Glimmer DSL for Web provides exponential productivity improvements. You owe it to yourself to put in the time to learn Glimmer DSL for Web, which is honestly highly interesting, intriguing, and exciting to learn for anyone who fancy themselves as Rubyists. No wonder it won an award by Matz, the creator of the Ruby programming language, at the Fukuoka Prefecture Future IT Initiative 2025 international tech competition in Japan.

I can help Ruby on Rails devs figure out how to solve any React.js Frontend problem in much simpler Ruby code using Glimmer DSL for Web. Just hit me up at the Glimmer Gitter chat:

https://gitter.im/AndyObtiva/glimmer?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge

If you are skeptical about Glimmer DSL for Web being simpler than React.js, contact me and let me show you a better and simpler way in Frontend Ruby. Code doesn't lie! Glimmer components are often 1/2 or even 1/10 the size of React components. Everyone knows that Ruby code is simpler, more readable, and more expressive than JavaScript code. And, the benefits compound when tackling Frontend Development problems with the superiority of the Ruby programming language.  

Also, I am able to have AI generate 100% working Glimmer Web Components automatically, let alone AI consumes less credits when generating Ruby code compared to other languages. So, Glimmer DSL for Web is definitely a great choice in the AI age too!

The easiest way to get started with Glimmer DSL for Web is to jump into the exercises of my recent wroclove.rb 2026 Ruby conference workshop "Building Rails SPAs in Frontend Ruby with Glimmer DSL for Web".

Exercises for the wroclove.rb 2026 Ruby conference workshop "Building Rails SPAs in Frontend Ruby with Glimmer DSL for Web"

I recently published a GitHub repo containing the exercises of the wroclove.rb 2026 Ruby conference workshop "Building Rails SPAs in Frontend Ruby with Glimmer DSL for Web":

https://github.com/AndyObtiva/glimmer_commerce

This GitHub repo provides the simplest and fastest way to learn Glimmer DSL for Web (the Ruby-in-the-Browser Rails Frontend Framework that gained Matz's approval by winning a Fukuoka Prefecture Future IT Initiative 2025 award). You don't have to configure it in a Rails web app yourself. You just clone the Glimmer Commerce Rails web app (an e-commerce example) that already has Glimmer DSL for Web and Opal (Ruby-to-JavaScript transpiler) configured, bundle & setup the Rails DB, and you're good to go with Glimmer Frontend Ruby awesomeness!!! The workshop includes 11 exercises that can be completed step by step following an agile incremental approach for building the product listing page of an e-commerce Rails web app. Glimmer DSL for Web is a highly innovative Frontend Framework that employs highly novel outside-the-box solutions that are only possible in Ruby. It is as different from traditional Frontend Development libraries as Rails was different from traditional Backend Development libraries when it first came out, so learning Glimmer DSL for Web requires humility and keeping an open-mind. 

And, just in time for wroclove.rb 2026, Glimmer DSL for Web now has official Rails 8 setup instructions.

I am very grateful for having had the opportunity to conduct a workshop at wroclove.rb 2026, and I am very appreciative of their mission "We want to confront ideas" as they lived up to it 100%! This is a very good example of how a Ruby conference oughta be (not an echo chamber that runs away from any ideas that threaten the Rails Frontend Development status quo)! I thank the wroclove.rb 2026 staff for the nice letter and cookies they shared with me at the conference.

Feedback at the end of the workshop was all positive. Attendees were very excited for the simplicity and productivity benefits of Glimmer DSL for Web and Frontend Ruby over JavaScript! One attendee described the project's Ruby Frontend approach as very promising. Another attendee mentioned that he thinks React.js is absolutely horrible and normally uses Vue.js, but is happy to have discovered a Ruby Frontend alternative that is better than both React.js and Vue.js. 

That said, after the workshop, I received one piece of negative feedback from an attendee who tried to set up Glimmer DSL for Web in a new Rails web app. He said that Glimmer DSL for Web was difficult to set up in a Rails web app as it requires about 10 manual steps. I heard you loud and clear! I will work on automating setup instructions behind a single Rails generator command before releasing version 1.0.0. In the meantime, if anyone wants this to be ready sooner, you are welcome to contribute the solution in a GitHub Pull Request.

Note that in real projects, I recommend that Ruby devs try to solve their problems pragmatically by exploring a spectrum of solutions instead of immediately jumping into a Frontend Development approach, but we are intentionally building everything as a Frontend solution in this workshop for learning purposes. 

Normally, I recommend that Ruby devs explore these solutions by order of sophistication:

1. Pure Rails Backend with Turbo if there are no Frontend interactions
2. Pure Hotwire if there are a few Frontend interactions that can be driven completely from the Backend
3. Hotwire + Stimulus if there are only a few custom Frontend interactions on top of basic Hotwire behavior, no more than 10 Frontend interactions.
4. Glimmer DSL for Web when there is a need to build many Frontend interactions (over 10), build Frontend-local interactions that are NOT driven by the Backend (e.g. a painting app, a diagraming app, a very elaborate Frontend-heavy configuration app that does NOT need intermediate configuration steps to be driven by the Backend, etc...), or build Frontend interactions that are so sophisticated that they warrant reaching for a JS library like Angular/React/Vue/Svelte/Ember (Glimmer DSL for Web enables Ruby devs to build any React/JS feature in half the time or less and with about half the code, albeit much simpler Ruby code)

By the way, Glimmer DSL for Web is 100% free and open-source. I make $0 on this project. I spent many nights and weekends working on this project to solve Frontend code maintainability and productivity problems at my job and to offer a free contribution to the Ruby community that rescues it from dependence on JS libraries like React.js and enables it to go Ruby all the way in both the Frontend and Backend. If one truly believes Ruby is the best dynamically typed language out there (e.g. compared to Perl, Python, JavaScript, etc..), then they oughta demonstrate that belief with actions, not just words (words are a dime a dozen). That's by using Ruby everywhere it has the potential to offer the best solution possible for customers. 

Happy learning!

Ruby Memes 2026-04-14: The Ruby Hypocrite

"Oh Ruby, you're the most elegant and beautiful language ever! I just love you so much..."