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 component that probably took a week or multiple weeks to build in only about 1-2 days tops, 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.

Frontend Ruby on Rails with Glimmer DSL for Web (submitted to an International Ruby conference)

I have submitted this talk to an international Ruby conference. 

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.

Interviewing Ruby Software Engineers Is Easier Than Ever in 2025!

My team's approach to interviewing Ruby Software Engineers involves giving a candidate a small-size Rails web app project to complete over a week (some finish it in much less time), reviewing the solution to check if it follows good Software Engineering principles and practices, and conducting a follow-up interview meeting to ensure that the candidate did solve the project themselves and can answer follow-up questions that test their general Software Engineering skills and specific Ruby on Rails skills.

Regarding the follow-up interview, new developments in recent years have made it super-easy to interview Ruby Software Engineers and tell the good ones from the bad ones in 2025:

1. AI: Just ask a Ruby dev to tell you what they think of the Gen AI movement (e.g. Chat GPT) and its effects on Software Engineering. If they respond with anything other than stating facts like solving the right customer problems has a lot more effect on productivity than generating code, human interactions are more important for producing the best work possible than actually increasing machine interaction by replacing humans, or generating code isn't the bottleneck, yet maintaining it for years to come, then you have a dud on your hand, and you can safely eliminate that candidate from your hiring pool. In other words, even if AI was perfect, it's still better to have more human interaction as it brings new fresh ideas due and connects devs with their humanity, which yields a better understanding of customer needs and more creative solutions for their problems. Additionally, a smart candidate would recognize that using AI can be a bug in the requirements because Gen AI is fuzzy by nature while Software Engineers seek sure answers, so attempting to use a Gen AI is the wrong strategy from the get go as it doesn't satisfy the requirements, regardless of what sort of technical proficiency it has. AI can be great for gaming or art with its fuzzy nature, but terrible if a sure correct answer is needed. Furthermore, good candidates would recognize that AI is only as good as its input, so it often learns the answers that the average masses come up with, and even if it learns to provide good answers one day, after it ingests some more bad input for a while, it would unlearn what it learned and yield bad output. AI only provides the most common average solutions, but excellent Software Engineers come up with top-level solutions that are better than what's common, so again, AI limits top-level Software Engineers with that regard. I have observed that top-level engineers in the Software Engineering industry like Linus Torvalds, the creator of Linux, don't really care for AI. Only average devs care for AI. Many devs don't get this, making it easy to rule them out to find out the Software Engineers who are truly the best.
2. Microservices: Just ask a Ruby dev about their opinion of the Microservices architecture. If they claim it is necessary since day 1, you can safely deny the hiring candidate from further steps in your hiring process. If they completely dismiss Microservices and claim that everything can be solved by a Monolith, you can safely reject the candidate as well. The right answer would be a pragmatic "it depends on customer needs", and would describe adopting Microservices incrementally if needed only, while describing the pros, cons, and trade-offs for using different approaches, such as a Monolith, Rails Engines, and Microservices, clarifying that it is OK to adopt a hybrid approach instead of a black and white approach. Bonus points if the candidate recognizes that  "Microservice" is just a silly buzzword for what is more properly called "Web Service", which has been around since the early 2000s. 
3. New Programming Languages: Just ask the Ruby dev what they think of new programming languages like Elixir, Rust, Golang, TypeScript, Scala, and Clojure. If they respond with anything other than noting that the benefits of immutable FP are overhyped by people who have skill issues with OOP and aren't truly useful/necessary in a practical sense given that OOP, the more modern paradigm (FP is 70's style programming), operates just like how we naturally and intuitively think of the real world without having to go through a translation layer that maps everything into "functions", which loses half the battle, then you have a dud on your hand, and you can easily reject that candidate in your interviewing process. They still need to know what FP is useful for, numerical computing, like any sort of mathematical algorithms that truly represent functions in real life mathematics. Also, any sort of iteration over collections, which Ruby supports with its hybrid OOP/FP approach (e.g. using `reduce` or `map`, etc...). That said, also, if they respond with anything other than noting that in about 90% of Business App Development, dynamic typing enables better focus on business domain concerns (kinda like what Matz called driving auto in a recent RubyConf keynote speech) while static typing provides the illusion of better Software Development while actually making you work harder, take longer to finish features, and write more code overall while being distracted by types instead of focusing on business concerns, then you have a dud on your hand. Of course, they should still note where static typing is useful (kinda like what Matz called driving a stickshift at a recent RubyConf keynote). That's in optimizing algorithm performance when needed. Also, the candidate should demonstrate an open mind about being able to follow a polyglot's hybrid approach that relies on a dynamically typed OOP language for most basic features while calling out to a statically typed language for algorithms that need extra optimizations. That's kinda like how Ruby relies on C extensions or JRuby relies on Java. Candidates that fall easily for the hype of new programming languages without having the skills to discern what the pros, cons, and trade-offs are in each can be skipped in the hiring process.
4. React: Just ask a Ruby dev point blank what they think of React.js. If their reaction is anything but disgust and absolute dismay, you're interviewing a dud that can be rejected safely in the hiring process. That means they don't really understand Ruby well enough to notice all the ways React.js contradicts the Ruby way and destroys Rails productivity, and they don't really know Software Engineering principles and best practices enough to notice where React breaks them, which makes maintainability very complicated and expensive and lowers productivity as a result. Another question that immediately reveals frauds with this regards is "How would you feel if someone invents a better Frontend technology than React that doubles productivity, improves readability, and halves code?" If you notice complete lack of interest or excitement in the candidate, you know you have a dud as well, someone who is attached to technologies for purely emotional non-rational reasons instead of rationally choosing technologies to serve customers in the best way possible.
5. Glimmer DSL for Web (2025 Fukuoka Award Winning Ruby Frontend Framework for Rails): Just describe Glimmer DSL for Web to a hiring candidate and explain how it completely eliminates the need for all JS Frontend Frameworks by enabling Software Engineers to leverage the same great benefits of Ruby that they always loved, but in the Frontend, doubling productivity, improving readability/maintainability significantly, halving Frontend code, halving the workforce (Backend devs can now do Frontend development), and halving Frontend Development costs. If the Ruby dev doesn't jump up and down with excitement or doesn't at least show some curiosity to learn more about the library's possibilities for the customers' benefit, then you know you have a dud on your hand that can be safely dismissed in the hiring process.

The good news is that those same recent developments also help truly skilled Ruby Software Engineers maintain job security very easily. It's ironic that AI didn't actually decrease job security, yet increased it for proper Software Engineers who are the real deal in their profession. Rejoice in these times! Our jobs have gotten much easier while the market got worse as a whole. 

One last note is hire devs with the backbone to say no when the masses are heading in the wrong direction. If a dev who might have noticed that a technology like React was bad at first later on changed their mind and approved of it just because the majority started using that technology, then they are exactly the wrong kind of dev to hire. Never hire spineless pushovers. Even if they come up with very smart solutions sometimes, the quality of their work can always be compromised by their lack of spine to push back against popular yet bad solutions.

I'm happy one of my team's recent hires volunteered to help me with Glimmer DSL for Web open-source work, and another actually complimented me on winning an award for that project and expressed great excitement about joining my team because of that accomplishment and our use of a Ruby Frontend library in our Rails web app.

The Embarrassing Ruby/Rails Subreddit Chronicles 2025-12-02

Welcome to another edition of the Embarrassing Ruby/Rails Subreddit Chronicles! A post was shared in the Rails subreddit about DHH claiming that money is a good reason to cheer for Shopify. I simply stated that no amount of money justifies mean discrimination, and I immediately got downvoted to 0. That proves yet again that there are devs in the Rails subreddit who are OK with mean discrimination if a certain amount of money is made and the subreddit mods are OK with mean discrimination by extension by allowing them into the group. 

Yet another embarrassment for the Ruby on Rails community as it officially admits the belief that mean discrimination is OK if a certain amount of money is gained, throwing MINASWAN out of the window instead of behaving in the ethical and nice Ruby way! This is the truth of the Ruby on Rails community in 2025!

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!

How did the Ruby community go from Great to Garbage?

Only 10 years ago, the Ruby community was great! It was a highly innovative and outside-the-box thinking community that explored ideas independently from the rest of the Software Engineering industry, often innovating novel open-source projects not possible in any languages other than Ruby. Also generally, I was treated with dignity and respect in the Ruby community, and it was the common default that Rubyists would support me in whatever new ideas I explored in Ruby open-source projects. 

So, how did the Ruby community go from great to garbage!?!!

- Many devs entered the Ruby community unethically just for the money or "cool" association factor, cheating clients by not offering them the best Software Engineering work possible in Ruby/Rails.

- Many Rubyists were pushovers that were easy to influence and manipulate by inferior non-Rubyists and fake or unethical Rubyists due to lazy complacency and lacking a backbone to say no when needed. Such Rubyists were often too afraid to address the big elephant in the room.

- The Ruby community has become mean by practicing covert discrimination and open discrimination against certain members of the community that are not deemed part of the "cool crowd" even if they had 100% merit, ethical conduct, great education, smart open-source projects, excellent accomplishments, and valid novel Ruby ideas. This kind of behavior started mostly at companies like Shopify when Shopify started becoming big and evil, and then eventually spread through the rest of the Ruby community. DHH and some members of 37Signals seem to more recently practice that sort of mean behavior and covert discrimination as well.

- Many Rubyists had a selfish attitude of "if this discrimination/hate/meanness doesn't affect me directly, then I don't really care about it even if it affects others! I just care about what I'm getting out of the community!", without caring to realize that some of what they are getting out of the community is coming from pushing some community members down, meaning stolen goods. I've even encountered Ruby/Rails subreddit mods and public speakers who didn't care whatsoever about the discrimination happening in the community by large Ruby shops like Shopify, just because they had friendships with some of the people at Shopify. They didn't even bother to investigate the discrimination or at least show sympathy and ask more about it. I mean if my friends practiced discrimination, they wouldn't be my friends anymore, and I would definitely investigate if they did practice discrimination. This just goes to show that some Ruby/Rails subreddit mods and public speakers are unethical awful people who are part of the problem, not the solution.

- Some leaders of the Ruby/Rails community like DHH simp to non-Rubyists like JavaScript devs while desperately seeking their approval, which doesn't make sense given that their technologies are inferior to Ruby. Instead, such bad leaders should be leading non-Rubyists towards better ways of Software Development using Ruby when Ruby offers the best possible potential solutions in certain areas of Software Development. It doesn't hurt to learn other technologies too, but when it's obvious a technology like JavaScript is inferior to Ruby, using JavaScript would not be using the best potential tool for the job, so it would be unintelligent to desperately seek the approval of its users instead of leading them towards better Software Development approaches in Ruby.

- Some Rubyists have a "my way or the highway" attitude and insist on using one "golden hammer" for all problems. Like, DHH believing everything must be handled by Hotwire and a Monolith instead of having the correct Software Engineering attitude of having many tools in the tool belt to address a spectrum of problems and using the right tool for the job depending on each client's situation and requirements. Devs who believe Hotwire solves everything are just as bad as devs who believe React solves everything. They're not any different or better as they close the door on any potential other innovations that could rival both solutions.

- Ruby/Rails subreddit mods tolerate hate, mistreatment, and unkind behavior towards well-accomplished Rubyists in the Ruby community who have much better ethics and much better accomplishments in the Ruby community than the unethical hateful devs who mistreat them. They also allow in devs who don't pass the minimum bar of respectful conduct for being hired at any respectable business, which makes no sense. Lastly, the subreddit mods practice discrimination against certain members of the Ruby community, treating them as if it doesn't matter at all whether they receive mistreatment, discrimination, or hate. That paints the mods as hypocrites and discredits all their words about stopping hate. If you discriminate in who you stop hate for, you are practicing discrimination and hate, and everything you say about stopping hate is a lie and doesn't have any weight anymore. 

- Some Rubyists betrayed the Ruby community by giving the false privilege of being considered Rubyists to unethical unqualified unintelligent devs who hate Ruby in certain parts of Software Development and don't pass the minimum bar of respectable conduct for hiring even though they don't really get Ruby and actually hate it in certain areas of Software Development while preferring extremely contradictory and dumb inferior technologies to it like React.js. They also betrayed customers who receive 1/2 or 1/4 of the business value they pay for due to Rubyists using React.js and other inferior technologies instead of using Ruby.

- Many Ruby/Rails conferences discriminate against certain topics in Ruby. For example, they reject all talks relating to Frontend Ruby no matter how qualified/upstanding the speaker is, how well-rehearsed the talk is when already given in local Ruby meetups, and how useful the technology is when already in use at a business. Also, some of their organizers are not upfront and humble about the fact they are less qualified in Ruby Software Engineering skills than the speakers they are judging, meaning they either shouldn't be in their position and allow someone better to judge talks or they should accept the expertise of more competent Ruby Software Engineers and accept their interesting novel talks without discrimination. What's most embarrassing is I have encountered some judges at Ruby conferences who were "hurt" by the fact that a Frontend Ruby technology is unseating React.js or some other JS/non-Ruby technology they are strongly attached to, demonstrating they are fake Rubyists and fake Software Engineers who don't put customers first along with the benefits they might receive from superior Ruby technologies, aren't committed to Ruby, and don't really get Ruby's benefits, yet are just shams/frauds that shouldn't be presiding over any conference. 

- Many Rubyists have lack of humility and honesty, especially regarding admitting lack of skills, lack of experience, and/or lack of qualifications in Ruby as to address that effectively. They bluff their way through the Software Engineering industry by mindlessly repeating "intelligent-sounding words" they heard from big names in the industry without truly understanding them, which might trick the untrained eye and gullible Rubyists, but is seen for what it is from a mile away by all competent Rubyists. Some Ruby/Rails subreddit members who have no degrees, no work accomplishments, no open-source projects, no conference presentations, and no ethical conduct act as if they're the gods of Ruby/Rails, which is very laughable.

- Many Rubyists don't respect the excellent accomplishments of more accomplished and/or more senior Software Engineers (sometimes out of unconscious or conscious discrimination). When a Rubyist doesn't respect excellence, that immediately tells everyone that they are NOT excellent. After all, excellent people always appreciate excellence in others, including excellent accomplishments.

- Many Rubyists lack skill in general Software Engineering principles and best practices, often doing Software Development in a Monkey-See-Monkey-Do fashion by following big names in the industry without thinking for themselves. And, they lack Software Engineering curiosity and interest in exploring Ruby in unexplored areas or learning more about outside-the-box novel Ruby open-source projects. More often than not, this is a side effect to not having any university degrees in computing, and instead having very shallow knowledge from reading a few books or going through an insufficient short bootcamp. 

- Many Rubyists do not match their words with actions and often make lame excuses instead of taking responsibility. Some will make a million excuses for not wanting to check out a new novel Ruby open-source project even if it only takes 10 minutes to an hour to check it out and the project won an award and is in successful use in production at a business. Sometimes, this happens out of unconscious or conscious discrimination. Either way, it's bad. It's known that anyone who makes excuses is incompetent by definition. No great accomplishments ever happened through excuses.

- Many Rubyists are unsupportive towards open-source project authors that implement highly novel outside-the-box disruptive ideas either due to closed-mindedness or due to being too attached to older less effective technologies, including ones in other languages, like React.js, instead of correctly being attached to serving customers in the best way possible above all else.