Update 2024-06-29: I am sorry for missing the fact that the Hyperstack Todo MVC, written in Frontend Ruby using the Hyperstack framework, already made the accomplishment of being the one Todo MVC to rule them all (it was not listed on the Todo MVC website, which is why I missed it), albeit the project is out of date and has not had a release in 3 years (2021) as of the time of writing. But, I was still right about Todo MVC Ruby Edition being the One Todo MVC To Rule Them All! And, I suppose this Todo MVC takes its place given that the other one's project is not actively maintained.
Todo MVC is a popular sample that is built in all Web Frontend Frameworks to provide a comprehensive SPA (Single Page Application) example covering all basic Frontend features. As such, it provides Software Engineers with a very good idea of how day-to-day Frontend Development would be with every Frontend Framework, whether in JavaScript, using React, Angular, Ember, or Vue, or in a Compile-to-JavaScript language, using something like Elm, GWT, or Scala.js. I am happy to announce that Todo MVC has just been built using Glimmer DSL for Web with 100% Frontend Ruby code (included in Glimmer DSL for Web version 0.2.7). And, this version's code is easily simpler, more minimalistic, more readable, and more maintainable than all 45+ versions on the Todo MVC website! I checked all of them myself and every one of them fell in one of multiple ways, like by requiring developers to manage code in multiple languages, which adds mental friction and hinders productivity (for example JavaScript and some form of ugly XML/HTML/JSX), having over-engineered overly-complicated code that is not readable at a glance or is mostly imperative instead of being declarative, requiring developers to pollute the code or mix concerns with weird sometimes too-low-level concepts that do not map to any real world domain model concepts (like state hooks and effects, which make code maintainability a lot more complicated than it needs to be and often an absolute hell), or adding a compilation step to do premature optimization when in fact even plain JavaScript performance is good enough for most business apps' simple interaction use cases nowadays. I can confidently say Todo MVC Ruby Edition is the one Todo MVC to rule them all! Thanks to the awesomeness of Ruby in the Browser!!!
One of the most incredible things about the Frontend Ruby version of Todo MVC is that it is the only version that allows writing all code in Ruby instead of being forced to split mental resources between HTML, CSS, and JavaScript (while still having the option to manage CSS in CSS/SCSS files if preferred). That has the huge advantage of making the code a lot more readable and programmable in the minimalistic Ruby syntax than every other Todo MVC version as there is no need to muck with ugly XML/HTML/JSX syntax anymore (no more redundant repetitions of every element's name to open and close). Instead, Glimmer DSL for Web provides a Ruby HTML DSL for the HTML part, a Ruby CSS DSL for the CSS part (although it is also possible to embed basic CSS into components, but I chose to use the CSS DSL to demonstrate it even if CSS programmability is not needed for this sample), and just plain Ruby code for the JavaScript part. And, the code flows very nicely from structure to logic to styling in one language (no need to add `<% %>` or `{ }` anymore) with excellent Object Oriented Design and separation of concerns, thanks to the MVP Architectural Pattern (Model-View-Presenter is a variation on MVC). That pattern includes clean Presenter and Model layers that offload presentation and business domain concerns from the View layer, making the View layer very slim and minimalistic, meaning Glimmer Web Components can get as small as 1/10 the size of React Components. Colocating CSS styling with each component's HTML structure code enables higher productivity and better style maintainability with a similar approach to that of React Styled Components, albeit in much more readable Ruby code. Also, the Fronend-Ruby-to-JavaScript-transpiler that is used by Glimmer DSL for Web supports Ruby 3.1 features (like the Shorthand Hash Syntax), which is totally awesome! This provides the added advantage of being able to reuse Backend Ruby logic in the Frontend as is if needed (which is not possible in any JavaScript framework).
I generated most of the Ruby HTML DSL and CSS DSL code automatically from the HTML/CSS of other Todo MVC versions by using the HTML to Glimmer Converter and CSS to Glimmer Converter. This facilitates rewriting any existing SPA (Single Page Application) in Ruby very quickly without having to do much manual work. But, of course, after the code has been converted into Ruby code, it becomes programmable (e.g. with `if/else` statements and `.each` iterators) and can leverage event listeners (e.g. `onclick`) and advanced data-binding features like Bidirectional/Unidirectional/Content Data-Binding, which are super-cool, unique, and expressive in Ruby given its support for operator overload of `<=>` (for Bidirectional Data-Binding) and `<=` (for Unidirectional Data-Binding).
Check out the Todo MVC Ruby Edition code below, starting with the View layer, moving into the Presenter layer, and ending with the Model layer; and then read the conclusion of the blog post afterwards.
Todo MVC Code
This version of Todo MVC is a very good start, but like most pieces of software, it does have room for improvement. For example, in the future, Glimmer DSL for Web could support a Frontend Routing API natively, it can avoid embedding style elements in body by having Glimmer automatically shove them in head, it can provide simpler syntax for data-binding CSS class inclusion and inline style properties, and more View responsibilities could be pushed down to the Presenter and Model layers by taking more advantage of the Observer Pattern. CSS Rules are verbosely created with the `rule` keyword, but they could have been created with just `r` or `_` instead if Software Engineers would rather avoid the repetition of the `rule` keyword. Additionally, if no programmability is needed (there is no logic in the style code that depends on component variables), then the CSS could be embedded as pure CSS too within the components. There are many other ideas for improvement, so if I update Todo MVC in the future, I will report on that in future blog posts.
Ruby in the Browser enables handling all kinds of interactions that are not possible in Hotwire without JavaScript, albeit with a simpler mental model. After all, it does not require that developers write ugly verbose HTML code (nobody should in 2024 just like nobody writes XML anymore) nor worry too much about element IDs while breaking MVC by making controllers push data to Views (which causes bad coupling that degrades maintainability). Instead, developers could just build smart Views that pull their own data automatically with Data-Binding observers just as per the proper MVC Pattern and they could work with variables/attributes in Ruby the normal way instead of relying on element IDs, simplifying maintainability immensely. A lot of developers avoid Hotwire and default to JavaScript Frameworks like React because Hotwire cannot do everything. They don't have to be stuck with inferior JavaScript technologies like React anymore if they avoid Hotwire. They can write their Frontend code in Ruby much more effectively (200%-10,000% more) in 2024! Meaning, 12 months of work in React take about 3-6 months in Ruby. That's a massive difference that will make and break companies depending on whether they stick with outdated inferior JavaScript technologies or upgrade to awesome superior Ruby technologies. This is the same exponential jump in productivity that happened in the mid-2000 with Rails, but now happening in the Web Frontend.
I think this is easily the future of productive Frontend Development in Rails for smart Ruby Software Engineers as it's not just a 10% or 20% improvement in productivity/maintainability over JavaScript options like React, yet an exponential improvement, meaning 200%, 400%, or even 10,000% better depending on the Frontend app being built. And, it removes the need for Rails shops to hire extra JavaScript developers. Backend Ruby Software Engineers can now do Frontend work in Ruby, thus enabling businesses to cut their hiring budgets in half and scale better (on top of cutting development cost and time-to-delivery in half by writing half the code of JavaScript in Ruby)!!!
