Video: Glimmer DSL for Web 0.10.5 Before & After Mutations

Release video for Glimmer DSL for Web (Award-Winning Frontend Framework for Ruby on Rails) version 0.10.5 (Before & After Mutations): https://youtu.be/BJ0oSsyddMg

GitHub: https://github.com/AndyObtiva/glimmer-dsl-web

RubyGem: https://rubygems.org/gems/glimmer-dsl-web

Happy Glimmering!

Glimmer DSL for Web 0.10.4 Insert Mutation

Release video for Glimmer DSL for Web (Award-Winning Frontend Framework for Ruby on Rails) version 0.10.4 (Insert Mutation): https://youtu.be/dzAOUKzuvu8

GitHub: https://github.com/AndyObtiva/glimmer-dsl-web

RubyGem: https://rubygems.org/gems/glimmer-dsl-web

Happy Glimmering!

Glimmer DSL for Web 0.10.3 Append & Prepend Mutations

Glimmer DSL for Web 0.10.3 Release Video: https://youtu.be/weLqzmaIUeo

(note: when I mentioned `shift`, I meant `unshift`)

GitHub: https://github.com/AndyObtiva/glimmer-dsl-web

RubyGem: https://rubygems.org/gems/glimmer-dsl-web

Happy Glimmering!

Glimmer DSL for Web 0.10.1 Auto-Conversion of Date/Time Element Values + New Sample

Glimmer DSL for Web 0.10.1 Release Video: https://youtu.be/Tk8mjOzhd5I

GitHub: https://github.com/AndyObtiva/glimmer-dsl-web

RubyGem: https://rubygems.org/gems/glimmer-dsl-web

Happy Glimmering!

RubyConf has joined RailsConf & RailsWorld as another exclusive discriminatory unexcellent conference

RubyConf has joined RailsConf & RailsWorld as another exclusive discriminatory unexcellent conference by discriminating against any speakers who submit talks that cover Frontend Ruby technologies or dethrone React/JavaScript in any way. In 2025, I won an award for a highly innovative and outside-the-box Ruby open-source project at an international Japanese tech competition that Matz, the creator of Ruby himself, presided on in addition to other judges. My project really impressed Matz, who is the reason for all the Ruby-related conferences existing in the first place, but in spite of that, both RailsConf and RailsWorld rejected my talk about my award-winning open-source project in 2025 despite the Ruby on Rails community sorely needing a Frontend Ruby solution that would fill a gap not handled by Hotwire; that is true Frontend Development in Ruby (to build frontend-local apps like a UML Diagrammer for example). Given that I am the most qualified person to talk about Frontend Development in Ruby on Rails using real Ruby in the Browser, and no other Frontend technologies rival my project in either productivity or simplicity/maintainability, the rejections came across as discrimination/exclusion and mediocrity/closed-mindedness/lack of appreciation for excellence. After all, if you reject an open-source project that won an award by Matz, your action is sending everyone the discouraging message that it doesn't matter how hard Software Engineers work to produce a unique innovation; they will stil be rejected because of discrimination and lack of appreciation for excellence if it comes from outside the core group behind Rails and some of their sponsors/friends. The reason this is also discrimination is because I was not rejected due to being unqualified (as I won an award after all) or due to the project not providing great value to the Ruby on Rails community (it impressed Matz) as the project saves Ruby on Rails Software Engineers who previously used JavaScript libraries like React.js/Angular/Vue/Svelte 6 months of Frontend work every year by switching to Frontend Ruby. I don't know many talks at RubyConf in general that can offer the same benefit. And, I am sure that nobody working for either RailsConf or RailsWorld has won a similar award to mine at the same international Japanese tech competition that was judged by Matz (and I have done it one other time previously too in fact). 

Fortunately, this year, my award-winning open-source project got accepted at RubyConf Austria 2026 (30-minute talk) and wroclove.rb 2026 (3-hour workshop). Those conferences are much better run than RailsConf and RailsWorld in welcoming innovation and being inclusive! wroclove.rb 2026 literally says on their website that they "want to confront ideas", in contrast to RailsConf and RailsWorld running away from ideas that don't come from the Rails core devs and some of their sponsors/friends (a form of discrimination). RubyConf Austria & wroclove.rb don't discriminate against Frontend Ruby projects and aren't offended by a talk that dethrones React/JavaScript, especially if already approved by Matz, the creator of Ruby. They welcome the excellence and hard work that went into creating my award-winning open-source Ruby project and winning an award from Matz. In other words, they encourage the Ruby community to be excellent and follow my example in innovation and thinking outside the box. In fact, I met Chad Fowler at RubyConf Austria 2026, and he attended my talk, then told me "good job" afterwards. For those who don't know, Chad Fowler founded RubyConf back in 2001. 

So, I submitted my award-winning open-source project's talk to RubyConf in 2026 thinking they might be less averse to Frontend Ruby, especially if the speaker won an award from Matz, given RubyConf is typically more open-minded about Ruby innovations outside of core Rails. Well, I got rejected despite being accepted by Matz, the creator of the language that conference was founded upon. I asked by email for the reasons for the rejection and for feedback to help improve myself in case they want me to do better before getting accepted (though to be frank, I won an award from the creator of Ruby himself, and there isn't anything that can top that). They never responded. 

I want to clarify that I have supported RubyConf in the past by giving talks/workshops at it and by donating my speaker stipends/hotel-pay (over $1000 or $2000 for all the conferences I spoke at) back to RubyCentral for the benefit of the Ruby community as a whole with everyone in it. So, it's not much to ask for a response as to why I encountered behavior that came across as discrimination when I have gone above and beyond in the past in supporting RubyConf and RubyCentral.

Eventually, I remembered that I have 2 RubyConf/RubyCentral people as LinkedIn connections, Jason Swett and Freedom Dumlao, so I contacted them asking the same question. I also pointed out to them that I am a former RubyConf speaker who donated his speaking stipends from the last 3 RubyConfs back to RubyCentral for the benefit of the Ruby community at large (that's over $1000). So, being treated with respect and non-discrimination is the least I could expect from RubyCentral.

Jason Swett chose the coward's plea and just never responded, which is how true discriminators handle discrimination when it's raised to them. The reason this incriminates him 100% is because if he truly wasn't involved in discrimination, he would have at least responded by saying he sympathizes with me perceiving discrimination and by indicating he is shocked that a project that won an award from Matz (when many other RubyConf talk projects didn't win any awards from Matz) got rejected at RubyConf. Honestly, Jason reminds me of employees that my employers fired in the past. Lack of presence and visibility is usually the sign of an unreliable employee who is never there for others. So, I advise against hiring Jason Swett (unless he responds to me and clears up my experienced discrimination).

Freedom Dumlao didn't respond to my first message, but at least responded to my 2nd follow-up message. He gets some points for that. Otherwise, his response was very weird and defensive. He claimed with a very unfriendly tone that I didn't know him even though him and I met at RubyConf 2024 and sat at the same eating table multiple times while having conversations that eventually led to connecting on LinkedIn. In fact, it sounded like he was trying to get out of responsibility by claiming I did not know him enough (a very unnice unfriendly thing to say from a Rubyist) even though the world is a meritocracy anyways, meaning people are known through their actions in day to day interactions, whether ethical or unethical. The way he said that came across as immature and irresponsible, not the way someone at RubyCentral should be talking. After all, a responsible person would have not focused on that, yet focused on my experience of discrimination and how strange it is that a project that was approved by Matz in a very difficult international competition and got a "good job" remark from Chad Fowler (the founder of RubyConf) got rejected at RubyConf, which would indicate RubyConf's staff are unqualified and do not appreciate excellence, in addition to having discriminatory biases, like the bias against Frontend Ruby and biases for React/JavaScript that cause offense if they are dethroned (shameful at a Ruby conference that is supposed to make Software Engineers feel safe about loving Ruby more than other languages). None of them have won similar awards from Matz, most likely in fact. A person in Freedom's position should have been sincerely concerned and should have noticed the problem and then promised a solution without making any excuses, just like how excellent organizations behave. Given that he didn't respond that way, even if I didn't know him, his reaction told me and everyone everything about him that we need to know about who he really is. He showed that he's part of the problem not the solution.

Regarding my donations to RubyCentral that exceed $1000, Freedom tried to deny the value of my donation by saying he donated more to RubyCentral, believe it or not! What a creepy disrespectful way to talk to someone who gave you money for free without being required to. Invalidating a donation is NOT a way to encourage people to continue donating, yet sends the message that donations are discouraged because in the end, they won't matter anyways as "someone else donated more than you". That was the most unhinged unprofessional encounter I've had from someone who is supposed to be a professional! Honestly, it doesn't matter how much he donated. My donations still have the same value in helping RubyCentral and the Ruby community regardless. Other people's donations definitely don't invalidate mine. 

Freedom also proceeded to claim that there was "no discrimination" because all their talks are reviewed anonymously. EXCEPT, my talk was NOT reviewed anonymously, because it mentions a public project on GitHub (which shows the author as soon as one visits it) and a public award (with the winner's name) that the project won from Matz at a public competition. 

I responded to inform him that my proposal submission wasn't anonymous as that was impossible with the talk being about a GitHub project and having won an award. And, I informed him that my donation is definitely NOT invalidated because he donated more. Freedom then chose the coward's plea and didn't respond. I advise against hiring Freedom Dumlao for any jobs or services as a result. He's the kind of selfish irresponsible excuse maker who is only about protecting his own hide while not caring about encouraging and maintaining excellence in a community, nor respecting people who donate to the community without being required to.

You see what I'm dealing with here!? Total trash! These are the kind of people running RubyCentral today! No matter it encountered issues last year with the Mike Perham vs DHH debacle, in addition to stopping RailsConf. The Ruby community is being run by total clowns who are discriminatory, unethical, and unprofessional!

I have ZERO interest in attending RubyConf 2026 as a result. After all, if they rejected a talk by one of the best open-source Ruby projects to come out in 2025 as to win an award by Matz, the creator of Ruby himself, then they probably rejected many other project talks that are top  quality because of the discriminatory biases and lack of qualification of RubyConf staff in 2026. For all we care, we got the dumbest, but most popular, talks in RubyConf 2026, but smart Software Engineers know that popularity is NOT quality. After all, PHP/WordPress is more popular than Rails, but definitely inferior in productivity and maintainability, which is why Ruby on Rails devs don't use those technologies in general. 

In conclusion, RubyConf in 2026 has become an exclusive discriminatory unexcellent conference, which is where people go to become dumber and/or meaner. 

If I had been working for RubyCentral, I would have provided guaranteed speaker slots for winners of the yearly Fukuoka international tech competition that Matz presides on to encourage excellence and innovation in the Ruby community, and I would have provided guaranteed speaker slots or tracks for owners of long-term "pillar" open-source projects in the Ruby community (e.g. Sidekiq, JRuby, Opal, etc...) to respect and support long-term open-source contributors of the Ruby community.

I have covered the topic of covert discrimination in the Ruby community before. What I encountered at the hands of the RubyConf folks is classic covert discrimination. Spread the word to help stop discrimination and unexcellence in the Ruby community! In the meantime, I'll make sure to only attend and speak at Ruby conferences that don't have unprofessional unexcellent discriminatory staff.

P.S. To prove that I'm reasonable and on the right side of this, I will acknowledge that nobody is perfect and everyone makes mistakes. What distinguishes good people from bad people though is that good people will admit their errors and apologize for their mistakes when they are pointed out to them whereas bad people will act aloof and commit more discrimination/exclusion by ignoring you when that happens. If any of the problematic people mentioned in the article change their mind and decide to respond like real men (not by hiding like cowards) to resolve my concerns about discrimination/exclusion/unexcellence for the benefit of the cheated Ruby community that missed out on all the Matz-loved value provided by an award-winning open-source Ruby project that impressed Matz, then I'll delete this blog post. 

Presentation Slides for RubyConf Austria 2026 Talk "Frontend Ruby on Rails with Glimmer DSL for Web"

My talk “Frontend Ruby on Rails with Glimmer DSL for Web” went well at RubyConf Austria 2026. Especially given that after the talk, Chad Fowler (the starter of RubyConf and famous book author of The Passionate Programmer, among other books) told me “good job”, and Obie Fernandez (a famous entrepreneur and book author of The Rails Way, among other books) told me he will try Glimmer DSL for Web because he doesn’t like React.js. 

Presentation Slides for “Frontend Ruby on Rails with Glimmer DSL for Web”:

https://bit.ly/glimmer-rubyconf-at-2026

I ran a poll at the beginning of my talk, and everyone agreed that they love Ruby and that Ruby is superior to JavaScript, plus the majority indicated that they’d like to write less JavaScript and more Ruby during their Rails web development work. Several attendees told me my talk was great after the talk. 

Charles Nutter had me help him with his JRuby workshop afterwards by showcasing my other Glimmer project, Glimmer DSL for SWT, which runs on JRuby. In about 1 minute, I scaffolded a Hello World desktop app from scratch and then packaged it as a native executable on the Mac. Attendees were impressed. So, I’ve participated in presenting 2 events at this conference. 

I am very grateful for having such a great experience at RubyConf Austria 2026 overall, especially given that it uniquely included several classical/neoclassical/jazz concerts in between talks that entertained us and relaxed us. Chad Fowler concluded the conference with a beautiful Jazz piano and sax performance. Shout out to Hans Schnedlitz, Muhamed Isabegovic, and Zuzanna Kusznir (plus everyone who helped out) for organizing and hosting such a special Ruby conference!!!

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. 

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 devs who use React end up with too much competition from the React community

I have observed that Ruby devs who use React often have a hard time finding a job because too many people know React. Well, that's one more reason to learn Glimmer DSL for Web! Not only will you do the work of React devs in half the time or sometimes at 10x productivity in Ruby, but also you will have a unique competitive advantage not many devs have and become indispensable as a result, unlike those disposable React devs that get laid off all the time with the lame excuse that layoffs are a "fact of life". That's not true because layoffs are a sign of not having delivered enough useful value to customers to sustain one's job.

For example, when my company laid off a React dev during an investment freeze by investors 2 years ago, they kept me even though I was the guy against React (because it contradicts the Ruby way and Rails way, lowering productivity/maintainability significantly) and the other guy was for React. My team was rapidly delivering value to customers that made us indispensable and that guy's team was slowly delivering the same old boring incompetence in React that everyone else in the market provided with zero competitive advantage.

And, then I eventually helped migrate our Rails Fintech web app to Glimmer DSL for Web, an award winning Ruby open-source Frontend Development framework. That's a success story for the effectiveness of using innovative Ruby technologies like Glimmer DSL for Web that not many other devs use yet. We are literally able to rewrite React components as Glimmer components in less time than would take us to reuse React components with complicated React code that demands using business-distant-concepts like Hooks and Effects. Views are truly pure of such non-View concerns in Glimmer DSL for Web. Smart Ruby devs would join this new highly innovative Ruby technology community and help contribute to it and grow it!!! And, as a side-effect, they'll become indispensable and separate themselves from everyone else in the job market. The same way devs benefited from joining the Rails community in its early days when it was still very rough and new, yet highly innovative.

Glimmer DSL for Web 0.8.3 Preventing Components from Shadowing HTML Elements

Glimmer DSL for Web (Fukuoka Award Winning Ruby-in-the-Browser Frontend Framework for Rails) had a new release in version 0.8.3, which now raises an exception plus a correction hint if the user attempts to define a component or a component slot with a name that shadows an existing HTML element.

For example, suppose a developer defines a Glimmer Web Component class called `Input`, which would automatically generate the `input` keyword for use in the Ruby HTML DSL:

class Input

  include Glimmer::Web::Component   

  markup {

    h1 { "Hello!" }

  }

}

This would normally shadow the HTML input element, preventing the user from being able to use HTML input as in this code:

input(type: 'text', id: 'name', placeholder: 'John Doe')

Instead, input now can only be used according to the component definition (which currently defines zero attributes):

input

This renders <h1>Hello!</h1> as per the Glimmer Web Component definition above. Of course, this is a contrived example as normally, an input component would have some form of inputting behavior, but for the sake of this example, let's imagine that it just renders an h1.

In version 0.8.3, Glimmer DSL for Web now raises an exception if the developer attempts to shadow an existing HTML element:

Cannot define the Glimmer::Web::Component class "Input" because it shadows the HTML element "input"! Either rename the class (e.g. "MyAppInput") to avoid conflicting with an existing HTML element name or nest it within a namespace module/class (e.g. "MyApp::Input")!

So, the developer can happily rename the component:

class AcmeInput

  include Glimmer::Web::Component   

  markup {

    h1 { "Hello!" }

  }

}

Or, the developer can happily namespace the component:

module Acme

  class Input

    include Glimmer::Web::Component   

    markup {

      h1 { "Hello!" }

    }

  }

end

That way, the user can now continue to use standard HTML input in addition to the new input components:

div {

  acme_input # the renamed class version

  acme__input # the namespaced class version (double-underscores in place of ::)

  input(type: 'text', id: 'name', placeholder: 'John Doe') # standard HTML input

}

The same sort of safety harness has been implemented for Component Slots as well.

Glimmer on!!! 

Workshop Accepted: "Building Rails SPAs in Ruby using Glimmer DSL for Web" at Wroclove.rb 2026

My 3-hour workshop proposal "Building Rails SPAs in Ruby using Glimmer DSL for Web" was accepted at the Wroclove.rb 2026 Ruby Conference, which takes place April 17-19, 2026 in Wroclaw, Poland. 

Title:

Building Rails SPAs in Ruby using Glimmer DSL for Web

Description:

Glimmer DSL for Web is a Ruby-in-the-Browser Web Frontend Framework for Rails that won an award at the Fukuoka Prefecture Future IT Initiative 2025 competition after getting judged by Matz (the creator of Ruby) and other Fukuoka Prefecture competition judges. Since January of 2025, it has been in use at Eltropy Canada inside the Collection 2.0 Rails web app (a debt collection FinTech platform) as an upgrade from React.js, doubling productivity with much simpler Frontend Ruby code.

This is the missing piece of the Ruby puzzle that bridges the gap between basic Rails Hotwire apps and more sophisticated highly interactive Rails apps that need a lot of Frontend-local interactions that are NOT driven by the Backend via Hotwire. Frontend Ruby removes the need to use JavaScript in those situations and provides an exponential jump in productivity as it cuts down software time-to-release, development cost, and implementation code by half with the language we all love, Ruby, albeit producing much more readable and maintainable code than even the best JavaScript code out there. That saves 6 months of Frontend Development work a year, which is a huge saving that makes and breaks startups and provides a unique competitive advantage to mid/large companies.

In this workshop, attendees will learn how to build Rails SPAs (Single Page Applications) in Frontend Opal Ruby (Fukuoka Ruby 2023 Award Winning Ruby-to-JavaScript Transpiler) with Glimmer DSL for Web. The workshop will walk attendees through writing examples that solve bigger and bigger problems while covering Glimmer DSL for Web features, such as:

• Ruby HTML DSL
• 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
• JavaScript library integration.

Bio:

Andy Maleh has won a Fukuoka Prefecture Future IT Initiative 2025 Award for his open-source gem Glimmer DSL for Web and a Fukuoka Ruby 2022 Special Award for his open-source gem Glimmer DSL for LibUI after his gems were judged by Matz, the creator of Ruby. He has spoken at RailsConf (2012/2014), RubyConf (2008/2022/2023/2024), MountainWest RubyConf 2011, MagicRuby 2011, and AgileConf 2008. Andy is currently a Senior Full Stack Engineer at Eltropy Canada. He has an M.S. in Software Engineering from DePaul University, Chicago, and a B.S. in Computer Science from McGill University, Montreal. In his free time, he drums in a rock band, snowboards, curls, plays Softball, and watches Red Sox/Canadiens/Alouettes/Warriors sports games.

Glimmer DSL for Web 0.8.2 HTML Value-less Boolean Attributes

Glimmer DSL for Web (Fukuoka Award Winning Ruby-in-the-Browser Frontend Framework for Rails) had a new release in version 0.8.2, which now supports HTML Value-less Boolean Attributes, simplifying the Ruby HTML DSL when using HTML boolean attributes like 'required', 'autofocus', and 'disabled'. There is no need to pass them in a hash with value true anymore. They could now be just passed as Ruby Symbols in HTML element arguments, ahead of hash attributes.

For example, instead of writing this:

input(type: 'text', id: 'name-field', required: true, autofocus: true)

You can now write this instead:

input(:required, :autofocus, type: 'text', id: 'name-field')

That would generate the following HTML upon rendering a Glimmer component:

<input type="text" id="name-field" required autofocus>

Happy Glimmering!

P.S. Glimmer DSL for Web will be presented at the following conferences in 2026:

• APRIL 17, 2026 3-hour Workshop: "Building Rails SPAs in Frontend Ruby with Glimmer DSL for Web" at the wroclove.rb 2026 Ruby Conference, in Wroclaw, Poland
• MAY 30, 2026 Talk: "Frontend Ruby on Rails with Glimmer DSL for Web" at RubyConf Austria 2026, in Vienna, Austria

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!

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.

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!

Glimmer DSL for Web Component Attribute Listener & Component Attribute Data-Binding

Glimmer DSL for Web (Fukuoka Award Winning Frontend Framework for Ruby on Rails) versions 0.7.2 & 0.7.3 add new samples to demonstrate the newly added features of Component Attribute Listener and Component Attribute Data-Binding. So, not only could we listen to HTML element events like a select element's onchange event, but now, if you add any attribute to a component, it automatically supports having consumers listen to that attribute's updates by hooking into `on_attributename_update` by convention (this is the Rails Convention Over Configuration principle at play). Additionally, consumers could even automatically data-bind that attribute to a model attribute by using the typical Glimmer approach of <=> for bidirectional data-binding and <= for unidirectional data-binding.

Suppose we have an address type select box.

The address_type_select component code would be something like this:

Now, we can attach a listener to the selected_address_type component attribute without the developer of the component doing anything extra by writing this consumer code:

address_type_select(address_types: ['Home', 'Work', 'Other'], 

                    selected_address_type: 'Home') {

  on_selected_address_type_update do |selected_address_type|

    # Do something

  end

}

Alternatively, we could data-bind the component attribute to a model attribute:

address_type_select(address_types: ['Home', 'Work', 'Other']) {

  selected_address_type <=> [address_type_presenter, :selected_address_type]

}

That opens the door for building higher concepts with components and being able to listen to their attribute changes and data-bind them as if they are basic HTML elements.

New samples:

• Hello, Component Attribute Listeners! 
• Hello, Component Attribute Data-Binding!

Happy Glimmering!

Glimmer Web Components (+ Championship Win & General Recipe for Success)

Before I get into the blog post's main subject, I'd like to mention that I recently won the 2024-2025 TGIF Curling League championship with my Curling team (Brooms Up) at the Royal Montreal Curling Club. I brought a championship trophy back home as a result. 

Team "Brooms Up" celebrating the championship win!

Andy Maleh (me) holding the TGIF League Curling Championship trophy (and a Hockey stick beer mug)!

Andy Maleh (me) tossing cheers with others at the Curling club!

It is interesting to note that I only learned the sport of Curling 2.5 years ago (though I've known it as a weird sport that shows up on TV for many years before). So, to win a league championship in Curling this soon (finishing as the 1st team in 14) is a testament to having been able to transfer my general recipe for success from Software Engineering into Sports! In fact, as a result of this recent success in Sports, I have spent the last 3 months learning a new sport that I have always loved, but never played much (I only did a couple of leagues in it over 20+ years) and never played well: Baseball. Hitting a ball in Baseball is known as the most difficult thing to do in sports! I have been very busy the last few months taking classes and participating in a summer league for the easy version of Baseball known as Softball. Yesterday, I caught my first fly out ever! A few weeks ago, I caught my first pop out ever! Before that, I was able to hit my first line drive ever! 

To summarize my "General Recipe for Success" (whether in Sports or Software Engineering):

• Learn the basics from the experts by taking classes with them (including doing any assigned homework): In Sports, I simply took classes at a Curling club to learn Curling and classes at a Batting Cage / Softball / Baseball Store to get started with Softball. In Software Engineering, I did a 4-year Bachelor's degree in Computer Science and a 2-year Master's degree in Software Engineering.
• Practice alone: In Curling, my alone practice happened by arriving early to games or booking practice sessions at the Curling club, and spending time practicing the Curling delivery stance and Curling shots. In Softball, my alone practice has been happening by arriving 45 minutes early to every game and spending that time practicing the batting stance and flow, batting with a batting tee, and throwing a Softball up vertically to practice catching pop ups at different locations. In Software Engineering, my alone practice happened by building open-source software projects while exploring interesting Software Engineering ideas that I wished existed, and by testing my learnings from my university education by building my own computer programs to satisfy some of my own needs (e.g. in college, I built a calculator that figured out when future level-ups would happen in an RPG video game based on experience points by looking at past level-ups).
• Practice with others while humbly asking them for feedback and help: In Curling, I practiced with other people on my league Curling team by booking a Curling practice session together and having the team's "Skip" (best player on the team who plays the most difficult position) watch us and correct us while we tried various Curling shots and sweeping methods. In Softball, I practice with others by arriving early to games to play catch with others, practice fielding, and practice pitching and/or batting. I let experienced players watch my errors and correct them during practice, humbly accepting their feedback and deferring to their expertise. In Software Engineering, I practiced with others by collaborating with other people on open-source software projects, doing book clubs and experimenting with book learnings in code, and asking coworkers for feedback in code reviews while accepting correction and learning from it. In my early years as a Junior Software Developer, I asked experienced Developers to teach me practical principles in computer programming.
• Watch the experts: In Curling, I watch every Curling competition on TV that I could think of (in Canada, it's the Grand Slam of Curling, which happens 5 times a year, the Brier's, which happens once a year, and the World Curling Championship) and I watch Curling games at my local Curling club played by other members. In Baseball, I watch every season's Major League Baseball games on TV (Let's Go Red Sox) and I sometimes watch Softball games in my Softball league that happen before my team's games or afterwards. In Software Engineering, I read open-source software code online and I read old legacy code written by experts at my company to learn from it. I also observe the features of various pieces of Software that I use, including paying attention to the usability and user experience.
• Communicate and collaborate well with your team (including having retrospectives about team performance): As they say, Teamwork Makes the Dream Work! In Curling, our Skip (i.e. captain) gave us very clear instructions for what to do every game. Additionally, he discussed what went right and wrong after every game so that we would all learn from our mistakes and do better next time. In Softball, my team captain and 1st base / 3rd base coaches give us clear instructions of how to play every game. Moreover, after games are done, we have retrospectives about what went wrong and what could be improved by next game. In Software Engineering, my teams favour over-communication instead of stingy communication because saving a few seconds here and there could result in days, weeks, or months that are wasted due to miscommunication. Additionally, we hold regular retrospectives in which we discuss what went right and wrong since the last retrospective. And, we often hop into impromptu meetings when extra communication is needed to ensure better work on a problem.

Now, let's get into the main topic of the blog post. I would like to announce glimmer-web-component as a new Ruby gem that provides a collection of reusable Glimmer Web Components for Glimmer DSL for Web (Ruby on Rails Web Frontend Framework), which were extracted from real Rails web applications. Of course, they are fully customizable with component options and standard CSS/SCSS. 

Version 0.1.0 of the Ruby gem ships with the first Glimmer Web Component: Multi Checkbox Dropdown. It was extracted from my current work Rails web app at Eltropy Canada (formerly Lexop, which got acquired by Eltropy in 2025).

GitHub: https://github.com/AndyObtiva/glimmer-web-components 

Using the Multi Checkbox Dropdown is as easy as utilizing the Ruby keyword `multi_checkbox_dropdown` in the Ruby HTML DSL. At minimum, it takes a `values` keyword argument to figure out what options to display to the user.

Of course, to be able to do anything useful with the user selection, one would have to hook into the `on_change` listener, which takes a Ruby block that receives `selected_values`. 

But, it's even simpler to just rely on bidirectional data-binding. selected_values are automatically pre-populated from @some_presenter.status_filters and stored back on @some_presenter.status_filters upon user selection.

Finally, it is possible to customize the component with many options:

Below is the full list of options, which are defined in the `multi_checkbox_dropdown` Glimmer Web Component code:

Happy Glimmering!

Glimmer DSL for Web Wins in Fukuoka Prefecture Future IT Initiative 2025 Competition

Glimmer DSL for Web (Ruby Web Frontend Framework) won an award in the Fukuoka Prefecture Future IT Initiative 2025 competition after I presented it to Yukihiro Matsumoto (the creator of Ruby) and other Fukuoka competition judges earlier this week on January 21, 2025! It's official! Matz approves of Glimmer DSL for Web!!!

Award Announcement: https://digitalfukuoka.jp/news/info/528/

MoneyForward Award Certificate:

Personal Letter from Matz (the creator of Ruby):

GitHub Repository for Glimmer DSL for Web (Ruby Web Frontend Framework): 

https://github.com/AndyObtiva/glimmer-dsl-web

Slides for Glimmer DSL for Web Fukuoka Prefecture Future IT Initiative 2025 Presentation (10-min):

https://docs.google.com/presentation/d/e/2PACX-1vQ8_DEsug8pIaHTKtVM1lye0I22gU-tatPT1B5WEwp6uRXkfmlQ9SSmdmCTHvXuPDb749wvPzBUmqRz/pub

Thanks to the maintainers of Opal Ruby (Fukuoka Ruby 2023 Award Winner) for making it possible to build something as amazing as Glimmer DSL for Web today! You guys totally rock!!!

Thanks to everyone who attended my first talk about Glimmer DSL for Web at the Montreal.rb Ruby Meetup on March 6, 2024 last year as you guys literally witnessed history in the making! This is similar to discovering Ruby in the early days of Rails in the mid-2000s, but on the Frontend instead of the Backend. A couple of weeks ago, I got approval by my managers at work to start using Glimmer DSL for Web in my work Rails web app and to explore it as a replacement for React.js. So far, the results have been absolutely amazing! Truly, I feel a 200% improvement in productivity, maintainability, simplicity, and code readability in Ruby Frontend code compared to using plain JavaScript or React.js. I look forward to the bright future of Ruby in Frontend Development of Rails web applications, as enabled by Glimmer DSL for Web, now a Fukuoka Award Winning project!