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

- React gives me "joy" (regardless of customers losing joy with its use) 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!

- React's creator sounds like a very smart man, so I can safely follow him (blindly without questioning or thinking for oneself). 

- 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

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!