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..."

Competent vs Incompetent Ruby Devs When Encountering React

Incompetent Ruby devs when encountering React:

- This language is used by Facebook, so it must be great (regardless of the fact that Facebook always suffers from tons of bugs and is an unethical company that has spied on its own users)!

- React is used by many rich large companies, so it must be a very good technology (regardless of the fact that often, rich large companies are unagile, unethical, and can afford bad technologies and bad practices).

- I met "very cool devs" at a tech event who told me they use React, so the technology must be "cool"!!! (when in fact customers don't pay devs for "cool", yet for business value, so getting distracted by "cool" things gets in the way of doing the best job possible)

- React gives me "joy" (regardless of customers losing joy with its use when features take longer to build while ending up with weird bugs due to terrible React code) by making me look so "clever" whenever I successfully write very complicated code using React (meaning React is overcomplicated).

- React is very popular, so it can't be a bad technology! (when in fact, excellence is unpopular, so popularity isn't quality, yet an indictment)

- React's creator sounds like a very smart man, so I can safely follow him (blindly without questioning or thinking for oneself, let alone the fact that he's uneducated, he desperately lies to justify use of React when it does not present the most agile or sensible approach, and is wrong about many things). 

- React is very fast, so it must be the best technology out there (regardless of how unmaintainable/unproductive its code is and how React's premature optimization isn't even useful at all for 99% of business use cases)

Competent Ruby devs when encountering React:

- React runs in JavaScript, a confusing programming language that is inferior to languages like Ruby and Python.

- React is regressing to older styles of programming from the 70's with functional programming, so it is very outdated with JS lipstick on a pig.

- React mixes multiple languages in the same file in JSX files, causing cognitive dissonance that creates mental friction, which slows down productivity.

- Hooks and Effects drop down thinking to lower levels of thinking that distance developers from the business domain and customer concerns, losing them half the battle from the get go.

- React's premature optimization is unnecessary in 99%+ of our business use cases, complicating development with inferior paradigms while being useless/hurtful of satisfying customer needs.

- React's maintainability is so terrible, it kills productivity and hurts teamwork and collaboration very badly (making devs deliver in double the time or longer and with double the cost or more).

- React's style of programming encourages the anti-pattern of devs writing "clever code" instead of code that is readable/maintainable by others without an unnecessary learning curve.

- Ruby provides infinitely simpler ways of Frontend Development than React's, like via the Fukuoka-award-winning Glimmer DSL for Web, which runs on the Opal JavaScript-to-Ruby transpiler. Code doesn't lie. Frontend Ruby is much simpler and more readable than Frontend JavaScript. The matter isn't really open for debate.

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