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. I was delivering value to customers that made me indispensable and that guy 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. 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.

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!

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.