Friday, May 17, 2024

Glimmer DSL for Web Ruby Integration with JavaScript Libraries

Glimmer DSL for Web is a Ruby-in-the-Browser Web Frontend Framework that enables Rubyists to finally have Ruby productivity and happiness in the Frontend via a simpler, more intuitive, more straightforward, and more productive library than all JavaScript libraries like React, Angular, Ember, Vue, Svelte, etc.... Glimmer DSL for Web's Rails sample app "Sample Selector" has been upgraded with Code Syntax Highlighting by integrating with highlight.js. It demonstrates how to integrate with JavaScript libraries, how to build Glimmer Web Components in the Frontend, and how to make HTTP calls from a Ruby Frontend to a Ruby Backend in a Rails application, among other things.




The Sample Selector Rails app enables users to list all samples that ship with the glimmer-dsl-web Ruby gem, show each sample's entry point code, and run the sample in the browser. 

Here is a breakdown of the code:

The Rails layout includes links to the highlight.js javascript CDN URLs:

The Rails View renders a Glimmer Web Component using the `glimmer_component` Rails helper (this is meant to be a drop-in replacement for JS solutions like `react_component`):

The Sample Selector Top-Level Glimmer Web Component is the entry point to the Frontend application, which simply consists of 2 other Glimmer Web Components, the Samples Table (samples_table) and the Highlighted Code (highlighted_code). It is as simple as the code could get, and way simpler and lighter than alternative JavaScript library approaches like React, thus cutting down on maintainability cost and time to delivery significantly, for both small and large apps alike:

The Highlighted Code Glimmer Web Component declaratively handles loading sample code into an HTML View innerHTML through unidirectional data-binding to the Sample Model code attribute, applying syntax highlighting using highlight.js after reading from the Model whenever updates happen to the View. The code has an excellent separation of concerns between the View and Model, and is a lot simpler than equivalent React code, thus much easier to reason about. Additionally, some CSS was written directly in a Ruby DSL:

The Samples Table lists all the samples that are included in the `glimmer-dsl-web` Ruby gem, and provides the ability to select a sample and run it. It also interacts with a Sample API Web Service to pull sample code data from the Rails backend, thus ensuring a proper separation of concerns for maximum maintainability. Some CSS is added with a Ruby DSL as well:

The Back Anchor provides a back-link to enable going back to the main page from any run sample:

The Sample Selector Presenter provides all the data and actions that the Sample Selector View needs, including how to present sample names, the attribute for storing the selected sample, and the method for running a sample, which delegates to the Sample Model to keep concerns better separated for higher maintainability:

The Sample Model stores sample specific data like the code and ID, enables fetching sample code from the Rails Backend using a Sample API Web Service, and provides and the ability to run a sample by loading the associated sample Ruby file:

The Sample API Web Service simply makes HTTP calls to the Rails backend to grab data:

In conclusion, we demonstrated in the Sample Selector app a Rails Frontend application that is written fully in Ruby with Ruby DSLs in place of HTML/CSS/JavaScript, is following the Model-View-Presenter pattern (a variation on MVC), includes HTTP calls to a Rails Backend to demonstrate real Business Use-Cases of Frontend/Backend interaction, and integrates with an external JavaScript library (highlight.js) for Code Syntax Highlighting. 

As a result, Rails Software Engineers do not have to be split anymore between those who are afraid of Frontend Development because of JavaScript, and those who prefer to do Frontend Development in spite of JavaScript's pitfalls. Instead, there is a 3rd better way that unites all Rails Software Engineers! Just write the Frontend in the same language you love so much in the Backend due to offering maximum productivity and maintainability: Ruby! This should become the no-brainer future of all Frontend development in Rails!!!

I will leave you with the Glimmer DSL for Web introduction from the project README on GitHub:

"You can finally have Ruby developer happiness and productivity in the Frontend! No more wasting time splitting your resources across multiple languages, using badly engineered, over-engineered, or premature-optimization-obsessed JavaScript libraries, fighting JavaScript build issues (e.g. webpack), or rewriting Ruby Backend code in Frontend JavaScript. With Ruby in the Browser, you can have an exponential jump in development productivity (2x or higher), time-to-release (1/2 or less time), cost (1/2 or cheaper), and maintainability (~50% the code that is simpler and more readable) over JavaScript libraries like React, Angular, Ember, Vue, and Svelte, while being able to reuse Backend Ruby code as is in the Frontend for faster interactions when needed. Ruby in the Browser finally fulfills every highly-productive Rubyist's dream by bringing Ruby productivity fun to Frontend Development, the same productivity fun you had for years and decades in Backend Development."

Saturday, May 11, 2024

Ruby on Rails Developers Choose Technologies To Do The Best Job Possible For Customers

Ruby on Rails developers who say things like "Oh! It is OK to use any programming language you like! Whatever strikes your fancy is good! JavaScript is OK if that's what you like. If you prefer TypeScript, go for it!" are some of the dumbest people around and the biggest enablers of mediocrity in the Ruby on Rails community. 

Telling others to use anything means those people do not really use Ruby for the Software Engineering objective pros/cons/trade-offs that it has against other programming languages in specific project related situations, and do not really get the full unique benefits of Ruby that are not available in most other programming languages. As such, instead of using Ruby as a smart well-thought-out Software Engineering decision, they use Ruby as merely a personal preference without much understanding of how using other programming languages instead of Ruby might negatively impact customers and team work in software project development. In other words, those people are Fake Rubyists, not Real Rubyists or real Software Engineers who truly understand Ruby to begin with.

I know it sounds "nice" and "agreeable" to tell others that they could use any programming language that strikes their fancy, but in fact, it is unnice to customers to have them get their projects delivered later and with more potential for bugs and slower productivity for adding features due to using objectively unsound programming languages for certain customer project situations. The nicest thing someone could do for customers is to guide others towards using the most excellent technologies for their project situations to deliver the best solutions possible. Being nice is delivering the best quality to customers. Also, being "agreeable" is not what customers pay you for. They pay you to deliver the best work possible. Teamwork is what matters the most, not being "agreeable", and the best teamwork is facilitated by being 100% honest and disagreeing when there is a big elephant in the room, thus getting rid of it, and delivering the best quality work possible instead of being slowed down by bad technologies just to be "agreeable".

In conclusion, telling others it is OK to use any technologies just for personal preferences is a lie! It is NOT OK as using the wrong technology for a certain project will yield slower productivity, worse teamwork, and complicated maintainability that raises costs and time for delivery significantly for customers.

As such, I never trust anyone who tells others it is OK to use any technologies they like as those people are compromised by peer pressure to please other developers instead of doing the best job possible for customers (what they are paid to do). Even some Rubyists with weak personalities (e.g. DHH) caved in to peer pressure just because "everyone is now doing it (e.g. using JavaScript), so it must be OK now to do it too" or because "Some technology [e.g. JavaScript] caught critical mass, so it must be better to go with the flow", forgetting that when Rails started, everyone was doing something completely different too and J2EE had caught critical mass back then, and yet we did NOT cave in to pressure and choose what was most popular, yet we chose Rails instead as a very bold Software Engineering decision to do the best work possible for customers. As such, they limited themselves inside the box of what is liked for personal preference reasons instead of thinking outside the box with the best possible Software Engineering solutions for customers (e.g. using Ruby in the Browser to bring Ruby's awesome productivity/maintainability to the Frontend, which not even the 2020+ versions of JavaScript come close to matching).

Getting something working with bad technologies does NOT mean you did the best job possible for customers. Sure, anyone can get anything working with almost any technologies. But, did you get it working with the highest productivity, simplest maintainability, and most enablement of teamwork? Did you cut down costs and time to delivery by using the best technology for the project situation? 

We serve the customers! The customers do NOT serve us! That means developers use the best technologies for customers depending on their specific project situations. Customers do not serve developers by accepting a negative hit on their project timeline or code quality just so that some selfish developers might get to "enjoy React" or whatever BS you hear from mediocre developers who are cheating their customers nowadays. 



Thursday, May 02, 2024

Simple Test for Revealing Fake Rubyists in the Rails Community

Here is a very easy test for figuring out if someone in the Rails community is a Real Rubyist who truly gets Ruby and its unique benefits 100% compared to other programming languages or a Fake Rubyist who is just riding the Ruby on Rails bandwagon because it is "cool" or because they heard about it from an acquaintance without thinking for themselves.

Tell that Rubyist that they can now use Ruby in the Frontend in place of React and other JavaScript technologies to enable all of Ruby's productivity, readability, and maintainability benefits in the Frontend, meaning doubling productivity (at minimum), cutting down development cost and time by half with acceptable-performance/small-download-size for most business apps, writing very highly readable and understandable code that is truly fun and makes developers happy, and enabling reuse of Backend Ruby in the Frontend, thus enabling maximum teamwork, which could result in more than 2x productivity improvement, potentially 10x for the entire team! 

If that does not excite that Rubyist to the max, they are as Fake as they come!!! Such people do not really understand Ruby and use it more in a Monkey-See-Monkey-Do fashion. After all, if someone truly gets Ruby 100% and cares for their customers 100%, then by logical deduction, they would be insanely excited about using Ruby in the Frontend to multiply productivity by many folds for their customers while delivering the best value possible to them.

Fortunately, I have encountered many Real Rubyists who passed this test as they had a super high level of awesome excitement about using Ruby in the Frontend due to caring about their customers and wanting to deliver the best solutions imaginable to them.

But, also with this test, I have been able to reveal many Rubyists as Fake Rubyists who are cheating their customers by bleeding 200%-1000% in wasted work productivity/cost/time with inferior inside-the-box JavaScript technologies (e.g. React) just because "everybody does it, so we should do it too". I would say they make up about 50% of today's Ruby on Rails user community unfortunately. Such Fake Rubyists turned out to be mindless people who follow what the popular "fashion" of the industry is and what "Large Company XYZ" uses to determine their decisions instead of thinking for themselves or doing their own Software Engineering Pros/Cons/Trade-offs analyses to determine what provides the best value for their customers. Ironically, that goes 100% against how Rails came to being as it was a highly contrarian technology when it came out in the mid-2000's that thought outside the box of what was popular because it cared about delivering the most value to customers instead of wasting time using over-engineered bloated technologies. Fake Rubyists not only stand in the way of innovation and progress due to being attached to inferior technologies (e.g. React) just for personal biases and emotional attachments that are not grounded in any correct Software Engineering analyses, but they also work half as productively as Real Rubyists if not much slower. That is because they produce highly over-engineered bloated JavaScript code that is much more expensive to maintain (in addition to maintaining its build, like webpack), is difficult to reason about compared to Ruby code, does not follow good Software Engineering best practices, creates friction against the Ruby Way and Rails Way, has bad separation of concerns that do not map directly to business domain concepts (e.g. using weird low-level concepts, like React state hooks and effects), forces rewriting Backend Ruby code in Javascript to reuse directly in the Frontend, and has awful trade-offs that favor premature optimizations despite the business apps being built having only a few Frontend interactions or a few elements that do not need optimizations, but need more maintainable code. You can learn more about issues related to using React specifically in this blog post: "Over-Engineering, Bad Teamwork, and Unethical Behavior in React Developers".

For Real Rubyists who do want Ruby developer happiness and amazing fun in the Frontend while multiplying their productivity and savings in cost/time for their customers, check out this very recent 2024 talk about the topic: Frontend Ruby with Glimmer DSL for Web. It mentions how a sophisticated React.js page in a real business application got re-written via Ruby in the Frontend, cutting code down to about ~50% the old code, but with much more readable and understandable Ruby code, causing the main React component to shrink by 10x as Ruby enabled a much better Software Design and separation of concerns. If you are completely new to Ruby in the Frontend, check out the talk: Intro to Ruby in the Browser.

Over-Engineering, Bad Teamwork, and Unethical Behavior in React Developers

I have observed that most React developers tend to over-engineer their solutions, tend to not-respect other people's opinions if they disagreed with theirs (bad for teamwork), and tend to be unethical, lying a lot about the weaknesses of React, thus very negatively impacting teamwork, slowing down productivity, and cheating customers with higher development costs. That is in spite of React weaknesses being very glaring and embarrassing, like the Fetch Waterfall issue, among many others, which any smart well-grounded Software Engineers saw from a mile away when they heard of the unsound design of React. And, due to that unsound design, every time React comes up with a new solution to one of their embarrassing problems, they end up being very over-engineered solutions that would not be needed in the first place if React had better design. 

Also, as part of lying a lot, many React folks claim that React code is "modern" and "easier to reason about" when in fact React code follows techniques that were known from the 70's in languages like Lisp, and is much much much more complex to reason about given it mixes concerns badly inside low-level mathematical functions that force developers to think about the whole scope of a page consisting of a hierarchy of highly-coupled functions instead of following much superior techniques that make us think about code exactly the same simple way we naturally think about the world outside of software at a high-level, which were invented during the Lisp days as an advanced form of Functional Programming called Object Oriented Programming (contrary to popular myth, OOP is part of FP, not apart from it; as OOP is simply smart data that knows its own functions). React folks try to re-invent weird complicated ways of writing code (like state-hooks/effects & nesting functions within functions within functions) just to show off how "clever" they are instead of simply adopting the simple ways that are proven to facilitate better teamwork in the Software Engineering community.

I think many React developers lie partly because they do not really understand the Software Design decisions behind React and just like to repeat what they hear from its creators without thinking for themselves, just because the sayings they repeat were said by what they deem as "important people at important companies", assuming they are infallible people who never make mistakes. Like for example the saying "easier to reason about", which if they thought for themselves with an objective analysis, they would realize right away that it is not true whatsoever about React, which tends to mix business data/logic concerns with presentation and view concerns. A lot of React folks will then try to show off how "clever" their techniques are, despite the fact that "clever code" is known as a Software Engineering Anti-Pattern. 

The lack of ethics in many React developers and in the React creators is not surprising about React given it comes from Facebook, an unethical company that is known for spying on its own users. Just for the lying alone being very common in the React community, I would pass on using React in any new projects involving Frontend interactions given that it encourages unethical behavior in developers. 


Thursday, March 07, 2024

Montreal.rb March 2024 Frontend Ruby with Glimmer DSL for Web

The talk video and slides have been posted for the Montreal.rb March 2024 talk "Frontend Ruby with Glimmer DSL for Web".

YouTube Video: 

https://www.youtube.com/watch?v=rIZ-ILUv9ME&list=PLRAf4zt5oEjc2mqmEN9m_O0JovQCXxvxt&index=11

Google Slides:

https://docs.google.com/presentation/d/e/2PACX-1vQVihtMktOEJ-AJWb1a-uyJfpyn7q92xstcx7QLIUOFONzG5TmKD7_2hSLdwijgw-l6LdK6OLbQPP61/pub?start=false&loop=false&delayms=60000

Talk Description:

Rubyists would rather leverage the productivity, readability, and maintainability benefits of Ruby in Frontend Web Development than JavaScript to cut down development cost and time by half compared to using popular yet inferior JavaScript frameworks with bloated JavaScript code as per Matz's suggestion in his RubyConf 2022 keynote speech to replace JavaScript with Ruby. Fortunately, this is possible in 2024!

This talk is a continuation of the previous Montreal.rb talk "Intro to Ruby in the Browser", which ended by promising a new way in the future for developing Web Frontends that would completely revolutionize the way we think about and do Frontend Development using Ruby instead of JavaScript. The future is now!!! The simplest, most intuitive, most straight-forward, and most productive Frontend Framework in existence is here! It is an open-source Ruby gem called Glimmer DSL for Web.

Think of Glimmer DSL for Web as the Rails of Frontend Frameworks. With it, you can finally live in Rubyland in both the Frontend and Backend on the Web! That opens up the door to ideas like rendering Frontend Components in the Backend as Server Components in the future, eliminating the conflict between ERB and JS frontend rendering technologies by leveraging highly readable, maintainable, and productive Ruby code isomorphically.

Friday, February 23, 2024

Upcoming March 2024 Montreal.rb Talk "Frontend Ruby with Glimmer DSL for Web"

I will be giving a Montreal.rb Ruby meetup talk titled "Frontend Ruby with Glimmer DSL for Web" on Wednesday, March 6 2024 at 7pm ET (doors open at 6:15pm ET). The event will be hosted at Lexop (506 McGill St Suite 400, Montreal, Quebec, Canada). The talk description is below. In my opinion, this is the most exciting Ruby topic in 2024 for doubling productivity and halving cost and time in developing and maintaining Rails Frontends compared to using inferior JS technologies like React, Angular, Vue, Svelte, etc... I strongly believe this will be the most important Ruby investment in 2024. Anyone who ignores it will be stuck in what is like the Ice Age of Frontend Development by comparison, kinda like riding horse carriage compared to driving a Ferrari.

RSVP: 

https://www.meetup.com/montrealrb/events/298445180/

Talk Description:

"Rubyists would rather leverage the productivity, readability, and maintainability benefits of Ruby in Frontend Web Development than JavaScript to cut down development cost and time by half compared to using popular yet inferior JavaScript frameworks with bloated JavaScript code as per Matz's suggestion in his RubyConf 2022 keynote speech to replace JavaScript with Ruby. Fortunately, this is possible in 2024!

This talk is a continuation of the previous Montreal.rb talk "Intro to Ruby in the Browser", which ended by promising a new way in the future for developing Web Frontends that would completely revolutionize the way we think about and do Frontend Development using Ruby instead of JavaScript. The future is now!!! The simplest, most intuitive, most straight-forward, and most productive Frontend Framework in existence is here! It is an open-source Ruby gem called Glimmer DSL for Web.

Think of Glimmer DSL for Web as the Rails of Frontend Frameworks. With it, you can finally live in Rubyland in both the Frontend and Backend on the Web! That opens up the door to ideas like rendering Frontend Components in the Backend as Server Components, eliminating the conflict between ERB and JS frontend rendering technologies by leveraging highly readable, maintainable, and productive Ruby code isomorphically."

Friday, February 16, 2024

Ruby Dev Summit 2024 Interview w/ Andy Maleh

Recently, I was interviewed for the 2024 Ruby Dev Summit, and a video podcast of the interview was just posted online and is available to watch for free for the next 24 hours (Fri, Feb 16 3pm ET till Sat, Feb 17 3pm ET). Click the "Watch Now" link under my name (Andy Maleh) to see the interview: 

https://topenddevs.com/summits/ruby-dev-summit-2024

Here is a direct link to my 2024 Ruby Dev Summit interview video (if you missed the 24h free period to watch the video, click on the free Apple Podcast link or Google Podcast link to listen to the interview for free):

https://topenddevs.com/summits/ruby-dev-summit-2024/interviews/andy-maleh


My 2024 Ruby Dev Summit interview was also published on the free podcast, Ruby Rogues:

https://topenddevs.com/podcasts/ruby-rogues/

Ruby Rogues Apple Podcast link for my 2024 Ruby Dev Summit interview:

https://podcasts.apple.com/ca/podcast/ruby-dev-summit-andy-maleh/id1237406856?i=1000645630465

Ruby Rogues Google Podcast link for my 2024 Ruby Dev Summit interview:

https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5yZWRjaXJjbGUuY29tL2M1NWNmMDJjLTdiMzYtNGY3My1iYjU2LTQ4Y2M1ZmMxODRhMA/episode/Nzg2NjY4YTUtOWM0My00ZmU2LWFhNTItZjA2Mzk0NGUyOGNi?sa=X&ved=0CAIQuIEEahcKEwiw5_Dn5reEAxUAAAAAHQAAAAAQNg

Here is a list of links for topics mentioned during the interview as well as how to find me: