Monday, July 08, 2024

Abandoning Immutable Functional Programming Simplified Code Significantly

A Cloud Web Service JavaScript library that I integrated with at work several years ago has released a new version. And, while upgrading it, I noticed they simplified one of its JavaScript APIs significantly by abandoning the Immutable Functional Programming craze that was hyped up mindlessly everywhere over the last 10 years, employing a very sensible Object Oriented Design instead. 

I always knew the recent emphasis on "Immutable Functional Programming" was over-engineering and premature-optimization plus a lack of proper knowledge and understanding of Functional Programming being perfectly OK with mutation given that Lisp supported both mutation and immutability depending on the use-case (you can learn more about that here: as well as the fact that Object Oriented Programming is simply an advanced case of Functional Programming, so it is perfectly OK as an improved application of Functional Programming (you can learn more about that here: 

I am not saying Immutable Functional Programming does not have its place at all. But, applying it everywhere is a premature optimization trade-off that ruins productivity and maintainability due to breaking the 80/20 rule that dictates that we should follow the simplest programming model possible for most of the work and only optimize the few cases that have special performance requirements (like by applying Immutable Functional Programming techniques). 

I am glad many developers are finding out the hard way that I was right all along about "Immutable Functional Programming" not being important in most apps and that it causes awful over-engineering/premature-optimization that slows down productivity and maintainability significantly. 

I guess it is time to say "I told you so!"

Sunday, June 23, 2024

Glimmer DSL for LibUI 0.12.0 Custom Control Component Slots

Glimmer DSL for LibUI (Prerequisite-Free Ruby Desktop Development Cross-Platform Native GUI Library) version 0.12.0 ships with an exciting new feature called Custom Control Component Slots!!! Component Slots are containers that could accept content in different parts of a Custom Control component (e.g. an address_form Custom Control can have a header slot and a footer slot to display extra information about the address being entered, which consumers could fill in with any GUI controls). A new example has been implemented to demonstrate this feature: Class-Based Custom Control Slots

Of course, Glimmer implements Component Slots with the simplest most declarative DSL syntax possible (as with all features of Glimmer), which does not require redundant declarations of slots in advance or a distinction between singular and plural slots, yet all slots are treated uniformly in the simplest way possible. In the past, if you opened a block in front of a Custom Control keyword and shoved content in it (e.g. `address_form { label('some text') }`), it got added to the bottom inside the Custom Control's top-level control (though there was a bug in that feature that was fixed in version 0.11.10). That was a good smart default as it allowed contributing Custom Control content by consumers without having to explicitly/manually specify where to insert `children` in the Custom Control. Glimmer just knew what to do by default. That said, it did not address all needs, like wanting to insert content in arbitrary places deep in a Custom Control's body hierarchy. Now, Software Engineers could allow consumers of Custom Controls to contribute content everywhere inside a Custom Control, not just inside the top-level control, with a very minimalistic declarative DSL syntax that greatly facilitates building highly customizable Custom Controls.

I leave you with the Custom Control Component Slots feature documentation below.

Glimmer on!!!

P.S. In other news, somebody built Go in Ruby using Glimmer DSL for LibUI.

Saturday, June 15, 2024

Todo MVC Ruby Edition Is the One Todo MVC To Rule Them All!!!

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

Happy Glimmering!

Friday, May 31, 2024

Puts Debuggerer 1.0.0 Includes Invoked Class/Method Name

Puts Debuggerer finally goes version 1.0.0, and it now has a very helpful new feature: printing the class name and method name as part of `pd` printouts. For those unfamiliar with Puts Debuggerer, the project was inspired by a blog post by Aaron Patterson titled "I am a puts debuggerer", which jokingly borrows from the wording of the comedy movie Dumb and Dumberer, turning debugger to "debuggerer". The Puts Debuggerer Ruby gem aimed at automating most of the suggestions in that blog post. The project README intro is included below for your information. Happy Puts Debuggerering (make sure to ⭐️ the project on GitHub)!!!

Tuesday, May 28, 2024

Glimmer DSL for XML 1.4.0 HTML To Glimmer Converter

Glimmer DSL for XML (& HTML) 1.4.0 has been released! It includes a new HTML To Glimmer Converter that can automatically convert any legacy HTML code into Glimmer DSL Ruby code. Glimmer DSL for Web (Ruby in the Browser Web Frontend Framework) has been upgraded to include both Glimmer DSL for XML 1.4.0 and Glimmer DSL for CSS 1.4.0 (which also recently included a CSS To Glimmer Converter).

Change Log (1.4.0)

  • html_to_glimmer converter command for automatically converting HTML to Glimmer DSL Ruby code
  • Support p keyword directly within Glimmer DSL for XML (without having to use the custom tag keyword like tag(:_name => "p"))
  • Provide Kernel#pi (puts inspect) alias in case someone needs to use Ruby p inside the xml or html block of Glimmer DSL for XML

Below is the documentation for the new HTML To Glimmer Converter.

Happy Glimmering!

Friday, May 24, 2024

Glimmer DSL for WX 0.1.0 Hello, Data-Binding!

The wxRuby3 Ruby binding for wxWidgets (a very mature native cross-platform GUI toolkit) finally went version 1.0, so Glimmer DSL for WX, which runs on top of wxRuby3, has been upgraded to use version 1.0 by default. Also, a new feature has been added that is already available in most other Glimmer GUI DSLs: Unidirectional/Bidirectional Data-Binding. It enables effortless wiring of Views to Models for automatic data syncing with a single line of Ruby code per wired property, uniquely and intuitively relying on the `<=`  operator for Unidirectional Data-Binding and the `<=>` operator for Bidirectional Data-Binding. A new sample has been added to demonstrate that feature, called "Hello, Data-Binding!".

Hello, Data-Binding! Sample Code:

Glimmer on!!!