Today, Valentino dives deep into the world of Ruby development with our special guest, Andy Maleh. They explore innovative advancements in Glimmer DSL for LibUI and Glimmer DSL for Web. Andy talks about his after-hours efforts to improve productivity and maintainability in front-end development, his critiques of current JavaScript frameworks like React, and his preference for utilizing Ruby's simplicity.

Valentino shares his intriguing project, building a robotic arm, and discusses teleoperation technology and practical applications. As they wrap up, we touch on full-stack development benefits, easing the learning curve, and future personal projects. Get ready for insights into integrating Glimmer DSL with Rails, optimizing development workflows, and learning about Andy's past and future contributions to the Ruby community. Stay tuned for an inspiring episode packed with practical advice and visionary ideas!

Socials

Valentino Stoll [00:00:04]:
Hey, everybody. Welcome to another episode of the Ruby Rooks podcast. I'm your host today, Valentino Stoll, and we're joined by a very special guest today, Andy Mala. Did I say that right, Andy?

Andy Maleh [00:00:16]:
Andy Malay. Yep.

Valentino Stoll [00:00:17]:
Malay. Sorry. I should have asked you before.

Andy Maleh [00:00:20]:
No worries. You're welcome.

Valentino Stoll [00:00:21]:
Do you wanna just introduce yourself? And I I'm sure some people, have heard you before on our show here. But just to give everybody an introduction and, know, why you're famous.

Andy Maleh [00:00:32]:
Yeah. Sure. My name is Andy Malle. I have about 20 years of software engineering experience, and I've been programming since I was a kid, really. And, Yeah. I have a bachelor degree in computer science from McGill University in Montreal and a and and a master's degree in software engineering from DePaulo University Chicago. And I guess I became famous when I won the Fukuoka Ruby Award in 2022 for my project, the limiter DSL for LibUI, which I presented at RubyConf 3 times already. I'm gonna present it for the 4th time this year, and I've also spoken at RailsConf twice before.

Andy Maleh [00:01:10]:
That's awesome.

Valentino Stoll [00:01:11]:
Yeah. I didn't know you won the, Fukuoka Ruby award. Congratulations on that.

Andy Maleh [00:01:15]:
I I won one of the awards. This this yeah. A special Fukuoka Ruby award. That's what it was called.

Valentino Stoll [00:01:21]:
Awesome. So what is glimmer?

Andy Maleh [00:01:25]:
So Glimmer started originally as a desktop development GUI library. It was, like, I started it in the mid 2000 as a way of making myself learn Ruby. At the time, I was a Java developer, and I did a lot of Java desktop development work at, like, a couple of companies. And I needed, I heard about Ruby, and I saw Rails, and I thought it was awesome. And I'm like, why don't we do this in on the desktop? Like, the whole like, all the cool things that Ruby offers as far as metaprogramming, as far as building DSLs, and and all of that, we can, like, build GUIs with it on the desktop. So I checked out one of my options at the time that were built by other people, and I saw Shoes, and I saw TK. And, Ruby TK did not have a DSL. It was, like writing code for it was very ugly.

Andy Maleh [00:02:13]:
It felt like I'm writing Java code, so I didn't like working with it. Your shoes was very nice. How but, unfortunately, it was a bit not very well maintained, and it had, bugs, and it would crash randomly. So I built Glimmer originally as a as a Ruby layer on top of the Eclipse SWT library, which is used in the Eclipse IDE because that's what I used at work at the time. So I built it using JRuby because I had to run on top of the JVM. Eventually, the idea proved itself to be interesting and useful enough, to a point where I ended up then covering all the available GUI toolkits in Ruby with Glimmer. So I have a Glimmer DSL for TK now. Glimmer DSL for GTK, for FX Ruby, meaning Fox toolkit.

Andy Maleh [00:02:59]:
For, LibUI started about is a library that's a bit recent. That was one of the more recent glimmers that were built. And the most recent one is w, w x. W x widgets has been covered by Glimmer recently because somebody, built a new binding called wxruby, that replaced the old wxruby, just a couple years ago. So I ended up, also covering it with a glimmer DSL. So but to get back to that question, what happened is eventually, I ended up, last year, coming up with the idea of building Glimmer DSL for web, which is a web version of Glimmer that uses all the innovations for data binding that were used in desktop development, but with building, web user interfaces.

Valentino Stoll [00:03:45]:
So, I mean, the first thing I think of, when I think of, you know, cross platform desktop apps is like Electron. And and maybe, like, maybe I'm just old. I don't really know if that's, like, still used even. Is that a is that a close comparison to what we're talking about?

Andy Maleh [00:04:05]:
So the irony is that Electron is not real desktop. So Electron runs on top of browser embedded browsers.

Valentino Stoll [00:04:13]:
Oh, okay.

Andy Maleh [00:04:14]:
So it's actually you write the app in actually HTML and CSS. So, unfortunately, as a result of that, you forego all the simplicity of desktop, GUI toolkit development because desktop GUIs are usually a lot simpler than web GUIs because they have, limitations that are enforced to comply with operating system standards like on Mac OS or Windows. So, it's a lot faster to build the desktop app with a desktop GUI toolkit than to build it with HTML and CSS. I think so Electron runs on top of a browser. So the the good news is that browsers are a desktop app. Everybody who is doing web development uses desktop apps because the browser is a desktop application, But Electron is not real desktop development. Like, cross platform GUI toolkits are actually a lot simpler to use than Electron.

Valentino Stoll [00:05:04]:
I I see. That makes a ton of sense. I I guess, like, thinking about, like, styling, are you pretty, like, restricted then to, of, like, the, you know, operating systems style limitations for a lot of these components?

Andy Maleh [00:05:19]:
Yeah. So the good news is that it's like the 80 20 rule. In general, you you write very, yeah, very simple, GUIs that comply to the style guidelines, and you can write those GUIs very quickly, very little code using Glimmer. But, 20% of the time when you need to have your own customizations, you you can actually build, completely, custom, user interfaces from scratch if you prefer. But then you have to do a lot more work. So you can actually do things that are the same things that you could do with HTML and CSS, but in desktop. They like, basically, you draw on a canvas. You can do anything with the canvas.

Andy Maleh [00:05:59]:
But in general, it's discouraged in desktop development unless you have an app that's actually drawing diagrams or doing things like visual games, 2 d games, or stuff like that. In general, if if you don't have diagrams or games or anything that's very, like, custom, it's better to stick to the, you know, like, using standard GUI toolkit controls, like text field, list, combo box, etcetera.

Valentino Stoll [00:06:26]:
It's interesting you mentioned gaming aspects, because I know the, you know, the the Ruby gaming engine of choice lately is is Dragon Ruby. I know that kind of, like, evolved from Ruby motion as, like, the de facto, like, desktop builder application. I don't know if that's still maintained or not. Is there any comparison, like, you can make between Glimmer and and Ruby Motion?

Andy Maleh [00:06:51]:
Yeah. Sure. So Ruby Motion has 2 2 parts. There's the Ruby Motion mobile development, aspect of it, and that one supports iOS and Android development use using Ruby code. I've actually tested it to build an like, a demo, like, a proof of concept iOS app, and it works. It's very nice. I might have it might have been last year or the year before it was when I tested it. It still works.

Andy Maleh [00:07:15]:
And then they have a a desktop component where you could but but it it's not cross platform. It's only for the Mac. So that part overlaps a bit with Glimmer, but I would not use it. I would rather use Glimmer because when you build a Glimmer app once, it runs on all platforms. And if you're using one of the native GUI toolkits like libUI, wxwidgets, or SWT, your apps will look native on every platform as well. So, but the mobile aspect of Ruby motion is very cool. Actually, I do wanna explore the idea of building a glimmer DSL for Ruby motion mobile. That would be very cool because then I can write the app in Ruby with a nice DSL, and it would run on macOS and Android.

Andy Maleh [00:07:56]:
But oh, sorry. Not macOS and Android. So that's something, that that would be interesting to explore. But, otherwise, DragonRuby is more optimized for gaming. And, yeah, glimmer glimmer allows you to build games, but it's not optimized for games. It's not about, like, offering you the best performance for games or anything like that. Although its libraries are pretty optimized for performance, like, they do run fast, but it's the library itself is not tailored toward towards gaming. I would still recommend if people wanna build complex games, drag and Ruby stuff into the way to go.

Andy Maleh [00:08:28]:
Or something else like Ruby 2 d or, there are a few other libraries for gaming as

Valentino Stoll [00:08:36]:
well. Yeah. That makes sense. I mean, use the best tool for the the best job. Mhmm. And I I love so, like, thank you for the the backstory and glimmer. And, I mean, we had you on today, to talk about this new, you know, thing you've been working on with, Glimmer Web, which is fascinating to me. Did what what drew you in this direction? Do you wanna describe maybe what the Glimmer DSL for web is? And, it's yeah.

Valentino Stoll [00:09:07]:
Because it's funny you mentioned that, you know, we, as web developers, are really desktop app developers. So you wanna just, like, dive into, you know, how that correlates?

Andy Maleh [00:09:18]:
Yeah. Sure. I mean, I mean, I personally experienced building desktop apps with Glimmr for quite a while now, and it's very quick to build any idea I have. Like, if I like, one day I needed the metronome. I I I actually play drums as a hobby, and, my phone metronome app, got a bug in it after the latest update, so I ended up building my own metronome with Glimmer as a desktop app. And I built it I bet I built the first MVP version in 10 minutes, and it was, like, so amazing because of Ruby. Ruby is so awesome. And, so I noticed that I don't have the same productivity in web front end interface development using JavaScript, not even close.

Andy Maleh [00:10:02]:
Like, JavaScript is so cumbersome. Even the newest versions of JavaScript are so, like, overengineered, and they focus on premature optimizations that are not important whatsoever. So and so because of all of that, like, for example, like, JavaScript makes you worry nowadays about const versus let, which to me, like, as a Rubyist, that's the least of my concerns when I'm building a fitness app. I just wanna focus on the business concerns, not on low level details like that. They also have an import export system, which on the surface sounds great. But in in reality, it's not like, practically in Ruby, we don't it's a lot simpler because we don't have that import export system, and we don't care. Like, it works fine enough for us without it. Ruby works pretty well for us.

Andy Maleh [00:10:44]:
So there are a lot of differences between JavaScript and Ruby as far as productivity. And, there are huge differences. Like, I I mean, I know, like, every once in a while, DHH says online on Twitter or something that he thinks that JavaScript, after they updated it to ECMAScript, has become a great language. Honestly, I don't find it a great language at all. I think he's wrong. I think he's kinda caved into what the popular demand or, sorry, popular choice by people is instead of actually, being a leader and being like, no. We could do even better with Ruby. So that's a a lot of those aspects are what prompted me to explore building a glimmer, using a front end Ruby technology.

Andy Maleh [00:11:25]:
And today in 2024, we do have front end Ruby technologies. Like, we have, Opel Ruby, which just won a Fuqua Okarubi award in 2023. So it's a pretty impressive library that is gives you a Ruby to JavaScript transpiler. I'm sorry. JavaScript to Ruby transpiler. So that way, you can write code that will run as JavaScript in in, like, in your website, and consumers of your website will not know that it's Ruby. But you actually wrote the code in Ruby first, and it got transpiled to JavaScript. So that's the techno that's one technology.

Andy Maleh [00:12:00]:
Another one is Ruby WASM, which, compiles Ruby into, like, WASM, low level code, and it basically gives you bay like, all the features of Ruby 3.1 or 3.2 nowadays, in the browser. And then there's also Ruby to JS. It's a third option, but that one is not as comprehensive as the first two options. I don't think you can build everything with it. But yeah. So I ended up choosing OPAL as a start for, building glimmer DSL for web, because and I I wanted to try the idea out. I tried it out in another project. I had a project called glimmer DSL for OPAL in the past, which which is retired now.

Andy Maleh [00:12:40]:
It's archived. And I was able to prove to myself that I can do everything that Glimmer does on the desktop in a web user interface on the web. And after I proved that idea, I built Glimmer DSL for web, starting last year. And it was, it took that approach of being more, friendly towards people that know HTML very well or know JavaScript or CSS very well. So it has, DSLs that are very close to them, to those languages. So it basically does give you an HTML, DSL, a CSS, DSL, which is optional. If you want to manage CSS separately, you can or you could use it. And then the JavaScript aspect got replaced by Ruby.

Andy Maleh [00:13:21]:
So any or JavaScript logic, code can always be written out with Ruby instead of JavaScript. And anything that you could do in JavaScript, you could do it with, Opal Ruby. So glimmer DSL for web is not limited whatsoever given that, like, I you can integrate with any available JavaScript library out there. For example, I built a sample selector app that lets people visit a Rails app that gives them a bunch of glimmer samples. And then they select 1, and then they see the code syntax highlighted, and then they can launch it in the web because it's a web app. It's it's a web user, like, front end apps, and then they can launch it directly in the in the browser. So the syntax highlighting aspect, I didn't have to implement it myself from scratch. I used a library called highlight JS, and I was able to, like, integrate it very, very quickly.

Andy Maleh [00:14:07]:
Like, it took me just a few, like, minutes or maybe a bit more than 10 minutes. But, so yeah. So, I mean, I was able to, after I experimented with the idea for quite a while, I took a page, like one of the sophisticated pages in my work website. By the way, I work for Lexop, which is a debt collection agency based in Montreal that uses web technology to reach, people that are late at paying their bills, either by email or SMS messages. So, it's a we have a Rails app, basically. We're a Rails shop. And, right now, we're using, like, we've been using React for the last number of years, but, I'm I built a proof of concept where I rewrote a React page that had a table of data with pagination, sorting, and filtering. And, I was able to rewrite it in GlimmerDS software webinar about what in about one day.

Andy Maleh [00:15:00]:
But also the the performance was just fast enough. Like, I didn't feel any, like, I didn't feel like performance was too slow or anything like that. It was fast enough. And, the code is was amazing. Like, I I was able to cut the the total code in about by about half. And also, the main React component was about 500 lines of code. And in Glimmer, it's Glimmer has a very, like, friendly, like, OOP approach of following MVC and MVP patterns. And with MVC and MVP, the the React component mixes a lot of, like, data concerns.

Andy Maleh [00:15:37]:
Like, it has state hooks and effects, and it mixes, like, business, concerns with the view present presentation of the view. Whereas when I rewrote it in Glimmer, it shrunk from 500 lines to 50 lines or something like that. So it was a one yeah. It became a tenth of the size, and all of the data management stuff that React lets you do with state hooks and effects got extracted into logic in a presenter or a model. So, like, I had an MVP pattern where there's a a view, a model, and a presenter. The presenter is kinda like a controller. Like, MVP is a a variation on MVC. But, yeah, the code became a lot better because then I can manage the code with standard OOP for anything that is not view related.

Andy Maleh [00:16:19]:
That's just mostly logic or so yeah. So it was, I did a demo of this to my coworkers at work and the CTO, and they were pretty impressed. I'm gonna be doing another demo soon to the, engineering manager of the company and, engineering department manager. Sorry. And, we're gonna be, looking into an idea for rolling it out. If the demo goes well, I hope it would go well. And, like, one idea for rolling it out is it's not a big bang thing. You don't have to do it everywhere at once.

Andy Maleh [00:16:52]:
Like, the nice thing about front ends on the web is that every web page is a self contained front end app in a way. So that means, for any new web page that we build, we could use Glimmer and keep all the older web pages and whatever old technology we had. But but that's not even how we're gonna start with it. What we're gonna do is basically, only internal facing web pages that are in the admin UI, are gonna start using Glimmer. Glimmer DSL for web is is, like, the idea I'm gonna be proposing at the next meeting. And that way we can gradually play around with it in a few admin pages first. I just wanna make sure there aren't any gotchas that I haven't discovered on my own, from building my own sample apps. And after we do that for about, you know, 4 months or 6 months, then we can start, maybe rewriting some admin pages that were in React in Glimmer instead of just adding new pages in Glimmer.

Andy Maleh [00:17:44]:
And then after that, the phase after that, phase 3 would be start start writing new pages on on the public facing website, with Glimmer. And then finally, the last phase would be to rewrite React, components with Glimmer if we feel like it is needed. It's completely optional, but it's it could be useful because, you know, Glimmer Ruby code is a lot lot more maintainable than React JS code. Way more like, in my experience, at least double as maintainable.

Valentino Stoll [00:18:14]:
I'm this is really interesting because, we are kind of missing a, you know, a hard stance on front end in in the Rails community at least, but definitely in Ruby as well. And Opal has been kind of the closest thing I've seen. It's interesting you've built kind of, like, on top of Opal. I know we've had, Elia on here before, talking about Opal, and it's, like, a really great work. Just so smooth of a process. And I love your the the DSL you have here, in your to do list app that you've made, which is, like, so simple and easy to read. We'll share it here in our our show notes. That's good.

Valentino Stoll [00:18:58]:
Thanks. So I'm, like, really curious. A lot of this looks, similar to kind of, like, the flex markup for those familiar with, you know, Joel Draper's, flex project, where they have, like, a DSL for kinda building up, the DOM elements and mutating them. I'm curious, like, you know, now that you've been, like, kind of reworking, even, like, React stuff, like, what is as a Ruby developer, like, I I am assuming that you've developed in rails.

Andy Maleh [00:19:35]:
That I've developed in Rails? What do you mean? Sorry. Oh,

Valentino Stoll [00:19:37]:
yeah. Like, you've used Rails before.

Andy Maleh [00:19:39]:
Right? 8 or 2,007.

Valentino Stoll [00:19:42]:
Yeah. Okay. Yeah. I mean, so, like, what's what's been your experience overall experience, like, as far as, like, you know, why why move to Glimmer as an example?

Andy Maleh [00:19:58]:
Oh, got it.

Valentino Stoll [00:19:59]:
You know, like, is it is it kind of straightforward if, like, a a team that hasn't seen Glimmer before to, like, make the transition pretty easily? I guess you'll find out.

Andy Maleh [00:20:12]:
There might be a slight misunderstanding. Glimmer is only the front end part. Glimmer integrates with Rails. Glimmer is a Rails library, by the way. It's also it's it's not just an Opal Ruby library. It's also a it's a Rails gem. It integrates with Rails apps and enables you to suddenly, in any Rails app, be able to write the front end in Ruby. That's it.

Andy Maleh [00:20:32]:
Except

Valentino Stoll [00:20:33]:
That's really cool.

Andy Maleh [00:20:33]:
Except, let's rewrite the front end in Ruby using a nice glimmer DSL. Like, without glimmer, if I use Opal Ruby alone, you can just write Ruby code in the front end. That's it. But you don't have any support for building frameworks or components or data binding or any of that. Glimmer adds the extra layer that is missing that enables you to do anything you could do with data binding, for example, using, like, same it has the same data binding features as Glimmer desktop libraries, but all of those data binding features were are actually, predate Glimmer. They come from Microsoft technologies that were used in visual basic, I believe, and other Microsoft products. They were also used by some Mac, GUI building, products as well. So those same ideas got adopted by Vue.

Andy Maleh [00:21:22]:
Js and Svelte. So it the same sort of data binding features that people know from Svelte and Vue. Js are available in Glimmer.

Valentino Stoll [00:21:31]:
Oh, cool.

Andy Maleh [00:21:32]:
Except in Glimmer, it's a lot nicer because you write Ruby code instead of JS code, and it and it also doesn't have the separation between markup as an HTML and logic is in JavaScript. In Ruby, everything is Ruby. The nice thing is for HTML, you have an HTML DSL. The CSS, there's the CSS, DSL, and for logic, there's just Ruby. So everything is in one language, so it fits in, a lot so that eliminates the friction between multiple languages, which actually creates a drag on productivity. A lot of people are kinda like the pragmatic book metaphor of, the boiled frogs. Have you heard of the boiled frog story from the pragmatic programmer book?

Valentino Stoll [00:22:11]:
No. I'm not familiar.

Andy Maleh [00:22:12]:
I can repeat it. It's basically like, it's a very interesting book that I highly recommend reading to anyone working in the soft in the software development industry, but, they're basically saying that, like, one risk that people get into is becoming boiled frogs. What what they mean is, like, they say if you take a frog and put it in a pot with boiling water, the frog will jump out right away of the of the pot as a reaction as a like, a wave of a react like a yeah. As a reactive, basically, reactive behavior. It'll jump right away just to protect its life. But if you put a frog in a pot with water that is cold and then you raise the heat, very gradually, like, you turn on the you turn on the the heat and then you raise it very, very gradually, you can boil the frog without it knowing because it'll boil very, very gradually. So it will not know that it is boiling, but eventually it will boil. So they they mentioned that a lot of developers end up in that situation where they they use technologies at work that put a drag on their productivity, and they get used to them.

Andy Maleh [00:23:23]:
And getting used to things is, like, one of the biggest risks in adopting bad practices in software engineering. So people might, like, use JavaScript, which has very contradictory paradigms to Ruby with a a Rails application for years and think they're doing the best they could, but in fact, they're actually not doing the best they could. They're they're creating a like, a drag on productivity because they have multiple languages that have different paradigms. And they they're also in their head, their context switching between the two languages all the time. So I personally noticed like, I I pay a lot of attention because of reading that story in the pragmatic programmer book. And at first, I fell for that trap too. I used JavaScript for many years thinking it was the best thing. But eventually, I realized, like, I like I mentioned, I used Glimmer for building desktop apps a lot.

Andy Maleh [00:24:10]:
I'm like, that's not even like, JavaScript development is not even close to that. And, so, basically, a lot of people are bold boiled frogs in a way. They're not realizing how much productivity they're losing. In my experience, I would like, I think glimmer DSL for web would cut down the work in half, in half in general. So, like, if you have 12 months of front end development work in JavaScript and React, you could do it in 6 months in Ruby and glimmer DSL for web. So so that's part of the reason why I I'm actually using it with the Rails, not against it's not like, I still use Rails for the back end, but, Glimmer is kinda like providing a drop in replacement for your JavaScript libraries that you're adding to Rails. So if you're using Vue. Js or Amber or Svelte or Angular or React, any, like, Glimmer can do a lot better than any of those in my experience as far as productivity.

Andy Maleh [00:25:05]:
Assuming, you know, like, it has fast enough performance. Like, for my work app, the largest, sorry, the web page with the most elements has only 1200 elements. And I, like, I discovered they render fast enough at Plimmer. I don't even need any of the, like, performance, like, advertisements of, like, React or Svelte for that. Like, Ruby Apple Ruby is fast enough in my experience. So in general, I think we can follow the 80 20 rule where we can avoid premature optimization because people tell you, you know, it's the root of all evil in software engineering because it makes people complicate their codes unnecessarily. Like, React code is unreadable compared to Ruby code or, like, especially, like, Rails back end code, for example. So, like, why are we using it in a Rails app? Like, that's contradictory.

Andy Maleh [00:25:52]:
So I'm trying to provide a way for people to use, Ruby on the front end just like the back end. And that way, that opens the door to things like being able to reuse back end Ruby logic in the front end directly. So for example, if I have a few pieces of logic that are validating taxes for payments or calculating, sorry, taxes for, like, an order, I can actually ship that code to the front end assuming it has no security requirement restriction requirements on it and, reuse it in the front end directly. So that way, I don't have to write in a REST API to reuse it. A lot of developers waste time writing REST APIs to connect j JS code to the back end or they waste time rewriting the back end code in JS. That's another, like, performance waste or drain. Sorry, not productivity drain. So Opel Ruby also saves saves us from having to do that.

Andy Maleh [00:26:45]:
Then I can, like, reuse back end Ruby code directly in the front end where needed. So any secure code remains back end only and not everything will be opened up to the front end. But things that are reusable on the front end and don't have any security restriction requirements, you can actually reuse them directly in the front end. So, I mean, to answer your question, like, I'm using Glimmer to actually improve my productivity in Rails app development, and I would say double it as far as front end development in Rails apps. One other thing you mentioned was the flex. One thing to clarify about flex is flex is only about 2 years old, and the approach they use is actually not different from what Glimmer had for years on the desktop. They let you build components with markup with sorry, with a d a Ruby DSL that lets you build the HTML. But, Glimmer desktop libraries lets you do the same thing with components.

Andy Maleh [00:27:38]:
But instead of using HTML markup in the DSL, you use the desktop, control, DSL, which, like, you know, would give you desktop widgets like list or combo box or text field, etcetera. So I would say that, like, whatever they came up with like, they came after Glimmer. They're not the flex approach is not what Glimmer copied. Glimmer just copied its own its older desktop self. But Flex, thankfully, is another library that is exploring the same ideas for Glimmer, but only on the back end. Like, they're doing it at least for now, they're mainly exploring things on the back end, whereas Glimmer, the software web is just doing it on the front end. Yep. But both of them, to to be more fair, both Glimmer and Flex borrowed the idea of writing a a DSL for the GUI or the user interface, whether it's using HTML markup or desktop controls.

Andy Maleh [00:28:35]:
They borrowed that from much older technologies like Shoes or Markabi. Markabi was one of the first DSLs in Ruby, I believe, that allowed people to write HTML in Ruby. So so, yeah, I just wanted to clarify the history of it. That's all.

Valentino Stoll [00:28:49]:
Yeah. Super interesting. There's been so much work, and to be honest, so many failed attempts as well along the way. But I think we're we're finally getting somewhere. I looking at, your example Rails app here, you have a sample glimmer DSL, web app for Rails. People can check out as well. It definitely makes a lot more sense now, as you're been explaining it. Seeing it, as as, like you said, the data binding aspect of connecting the front end components to the back end.

Valentino Stoll [00:29:24]:
And it makes a lot of sense. And I it's it's definitely, like, we are getting closer here. So I think we're we're

Andy Maleh [00:29:31]:
That's okay. That's okay because that's exactly how Ruby started. So Ruby started in in the nineties mid nineties, and it took it 10 years before Rails came to fruition. So it wasn't till the mid 2000s that Ruby became very viable on the back end. And now the front end is it has a similar story. Opel Ruby started in the mid 20 tens. Like, it might have been 2012 was the first first alpha version of it. And it it it took about 10 years as well to figure out what to do with Opel Ruby on the front end before we arrive at what we think is, like, the most practical solution.

Andy Maleh [00:30:07]:
So I I agree with you, and I think that's okay. Like, it takes time sometimes to figure out how to do things the best way possible.

Valentino Stoll [00:30:15]:
Yeah. Totally. And so, like, I wanted to dig in here a little bit because, what we're talking about is kind of like componentizing, like, these front end pieces into a more modular way, that can be reused and, encapsulated in more of the Ruby way, and trying to keep it to Ruby as much as we can, right, without, like, degradation the front end performance too much. And so I I wanna talk about that componentization, like creating these web things. Right? Like, if I have a form, can I make a form component? Is that, like, straightforward to do with the glimmer DSL? What what is your been your experience with, like, encapsulation there?

Andy Maleh [00:30:57]:
Yeah. So, to start, the glimmer HTML DSL gives you access to, using any HTML tag, including SVG tags as well. So if you wanna use a form tag, you can use it. It's already supported. Every every tag that is in HTML is supported by Glimmer right now, at Glimmer DSL for web. So, you could just use any basic HTML tags out of the box. Now if you wanna build your own components, it also supports that completely right now. So I for example, if I wanna build a name and address form because that's a very common form that could be used on multiple pages on the website, like for payment, like for shipping, like for many different things.

Andy Maleh [00:31:41]:
You could definitely do that today. In fact, one of the samples or multiple of the samples, include an name and address form or an address form at least. So it basically abstracts or, like you mentioned, encapsulates, all the things related to displaying an address form into a component. And, it it basically will expect you then to provide it an address model. So that way when you work with it, you don't even have to worry about working with the GUI directly. You just work with the address model. And when you update the address model, because of bidirectional data binding, it'll automatically show updates on the form on the screen. So it'll save developers a lot of work.

Andy Maleh [00:32:20]:
Like, this approach saves developers a lot of work because they don't have to if you have components that are very well encapsulated, you can just work with their data, and their data will automatically reflect in the GUI because of data binding.

Valentino Stoll [00:32:33]:
Yeah. That's really cool. And I, I mean, I think that's been one thing that's caused the divide too, to be honest, in that, you know, people like to stylize and make their own web components with React or whatever framework that they've, you know, that they've chosen and handle all their, you know, front end interactions and stuff. But then, you know, have to request that the back end team, like, help supply that data or new I guess, data changes, like, how do you add and adjust to the component without, you know, the data being there on the back end? And so you have this, like, dual edge coupling. And if we have that coupling anyway, why not have it all in the same place? I I think makes a lot of sense to to me personally. So how I'm wondering, like, you know, does this also, like, appease, like, teams that grow in skies and, like, have devoted front end teams? Like, is there still kind of that, is this, like, trying to, like, consolidate the team structure, or is it also, like, supporting the idea of, okay. We're gonna have front end people that are gonna be focusing specifically on styling and adjusting the components. Like, is it still kind of a straightforward process of, like, HTML, CSS kind of manipulation, for front end styling of the components, or is it take more of, like, a, I need to learn Glimmer DSL, you know, aspect of things?

Andy Maleh [00:34:11]:
Yeah. So, one thing to clarify is that, yeah, glimmer DSL for web in the end generates real JavaScript, real HTML, and real CSS. So, like, when you use it, you will generate, like, standard HTML CSS JavaScript. So people have concerns about testing, like, the front end user interfaces. They they can just test them as basic HTML. They don't have to even be involved in the Ruby part. If, people are back end developers that know back end Ruby and they use it with Rails, now this opens the door completely for them to use, Glimmer on the front end. So that actually, in my experience, improves productivity in a number of ways.

Andy Maleh [00:34:59]:
Usually, it's recommended to do full stack development, not back end, front end. At least on my company, we definitely and a few other companies I worked at in the past, that's definitely the approach we adopted because, then the developer is aware of the full value being offered to the customer end to end from the user interface all the way down to the database and then back. So then they can optimize the code or simplify the code as with, a better understanding of, like, the holistic view of everything and be able to provide a better product to customers in general. And also, in my experience, results in less work and less communication overhead. When there are front end and back end developers, there's communication overhead. There's more work about translating things from the back end to the front end and vice versa. And if there are multiple languages, that's even worse than, like, there's even more translation going on. So this enables now back end developers to just do finding work and not worry anymore about that.

Andy Maleh [00:35:59]:
So in a way, it saves companies from actually, it cut it cuts down the hiring costs. Just companies that have back end developers, they don't even need like, if there's a startup that wants to be as efficient as possible, as productive as possible, they don't even have to hire front end developers anymore, but they have solid, back end Ruby developers. So that's a very big win. But on the other hand, if there are companies that have back end, front end developers, front end developers would learn this just like learning any other front end library. Because, for example, React definitely had a very large like, a big, learning curve in a sense because they had g s JSX, which was not a normal tech based it's not a standard technology. JSX is actually not standard HTML, not standard CSS, not even standard JavaScript, so it's very weird. And, like, React has a lot of weird things that, in my opinion, like, waste a lot of productivities to learn. Like, why why are we working low level states when we actually have object oriented programming languages that are way more advanced? They have the same idea.

Andy Maleh [00:36:58]:
So in my mind, React reinvents OOP in a different way and give it a diff gives it a different name. Like, basically, object attributes are called states, hoax, and react. And, object observers, they call them effects in react, and that's it. Like, react is not really it's it's just reinventing things. It's not really as modern and new as people think it is. For people that have been software engineering for a long time, they they they could tell that it like, react React's ideas have been around since the nineties, at least. Like, the idea of components has been around since the nineties from Visual Basic, for example. So, anyways, don't so, in the end, I found it more productive to, like and we actually have to open weird curly braces to mix, logic with view concerns.

Andy Maleh [00:37:50]:
So if I wanna say this, do this. If that, do that. It's a bit weird opening the curly braces. It's very hard to integrate the logic with the view, whereas in, Ruby and GlimmerDS software web, you are in Ruby already. You're just using a Ruby DSL. You can actually write if and that immediately in the same language. And also, it's even better than ERB as well because ERB lets you requires that developers open scriptlets to mix, logic with view, like, concerns. Sorry.

Andy Maleh [00:38:22]:
Not the concerns, but more it's it's actually presentation logic. It's not really it is view logic. But, yeah, to mix it with view structure, you have to open, scriptlets, which can get really annoying after a while, and over a year adds up so much that it would actually present a drag on productivity, which goes back to that boiled frog metaphor that I spoke of earlier. So in a way, I I would say, JavaScript developers that are worth their salt, that are actually smart, solid software engineers should be able to pick up Glimmer DSL for web in no time and then be more productive in it than using JavaScript.

Valentino Stoll [00:38:57]:
I see. Yeah. I mean, that makes a lot of sense. Looking at more of these examples in this Rails, sample, You're using, like, an external code highlighter, which is really cool, and it's just, like, all in Ruby. Mhmm. Yeah. Really, really cool. So I'm curious.

Valentino Stoll [00:39:17]:
What is the, like, is it is what's the deploy process look like for, this stuff? Like, is it the same as, you know, any Rails app, any Ruby app? What's that look like?

Andy Maleh [00:39:31]:
So, I'm using the Opal Rails, gem, which is, 100% compliance with the Rails classic asset pipeline. So it it runs on top of sprockets. So it's actually very simple. It it brings us back to the old simple days of CoffeeScript and older JavaScript before we had to start using crazy bundlers like webpack. I mean, in my opinion, that's a benefit because webpack like, at my job, maintaining webpack is like, webpack is such a monstrosity with it with all its options and configuration settings that, like, upgrading it is a very difficult process. Like, we I recently upgraded it from an old version to a newer one, and it was absolute hell. It took more than a month to finish the work. So, this just whereas this just runs on top of, sprockets.

Andy Maleh [00:40:25]:
So meaning, you just do a rails asset precompile when you deploy production, and it generates JavaScript files and that's it. And then you put the JavaScript files in a CDN so then people download them with instant, like, download speeds. And the website will be very, like, high performance as a result of that. And locally on my machine, there's no bundler again. There's just Opal rails, the the gem. So what that means is, every time I had a web hit a web page, the OPAL code gets compiled on the spot in development. So that way as I update the code and I refresh the web page, it it picks up the newer changes. That said, I heard from the OPAL people that they are working on, like, a way to integrate, OPAL with bundlers like Webpack, and they might already have I believe they already have, like, proofs of concepts of it or maybe even working versions, but I'm personally not interested in using them.

Andy Maleh [00:41:27]:
In my mind, like, a big benefit is avoiding webpack because, like, my my way of doing things, I would say, with this is to not use a bundler. I would in any, third party libraries, I would link to their CDNs. That's fast enough and good enough. I I realized that bundlers give you chunking and other features that people people will say will give you even better performance, but, like, for most apps that are smaller startup, rails apps, or midsized apps, just what rails is used for the most. I'd rather not use a bundler. I'd rather just have things bundled, rails asset precompile, on deploy, and locally, it would just compile live, when I'm doing development.

Valentino Stoll [00:42:10]:
Yeah. Totally. And thinking more about, like, the the bundler aspect of it, it makes me think of, was it rails assets, if you are familiar with that, where you Rails assets was like a basically just a gem format where you could pull in node related NPM packages into your, Rails asset pipeline, which was, to me, like, super great. Didn't require any of the, you know, JavaScript packaging systems or or extra dependencies like that. And it worked great, and you just bundle install, and it included all of the assets that you needed and handled all that. And I do miss that. And so I'm I'm hopeful with this, kind of, push here that we can kind of get back to something like that, which makes brings me to my next topic, of, turbo. What are what are your feelings on turbo and, like, the HTML over the wire aspects of rails?

Andy Maleh [00:43:17]:
So, Turbo is nice if I have a very simple business app, and I need very, very few, like, front end, front end e interactions, without writing front end code. I can use turbo for that, like, where it would update certain parts of the screen automatically based on back end directives from a controller action. So I think for simpler apps, it works fine. For more sophisticated apps, it doesn't do everything. And that's the reason why a lot of Rubyists nowadays reach for React and other JavaScript libraries like Svelte and Vue JS is because they they, at one point, hit a wall or feel like it's too complicated to manage turbo from controllers on the back end than to actually just write front end code. Like and I think, a bit like, I think turbo, in a way is a bit, like, written in, with the approach of being, a bit aversive to writing front end front end JavaScript code, because JavaScript code is not nice. But if but if we had the front end language that was nice, and we do now in 2024, which is Ruby using Opel or Wasm, then there's no reason for me to consider turbo in that case. I would rather just write front end Ruby code the normal way and, like, following an MVC pattern, and that should be good enough.

Andy Maleh [00:44:38]:
Like, I don't feel and I can just make the rest API calls. I mean, at my job, people do that anyways with React right now. They they connect React to the back end of the rest API calls. So, I mean, I feel like that's simple enough, and a lot of people are comfortable with that model. One thing about Turbo is it has a a bit of a learning curve and because its model is a bit, like, out of the normal, out of the ordinary, the mental model. So people have to think a lot about IDs on elements in HTML. So in my experience, I feel like writing features in glimmer DSL for web is simpler because I'm just writing basic Ruby code. I don't have to worry about IDs.

Andy Maleh [00:45:19]:
You can just use variables the normal Ruby way, and variables will identify elements. You can grab elements by variable instead of by ID, in general. Like, in general, you don't have to refer to IDs and elements. So it's even it's simpler than jQuery. It's simpler than, in my mind, a bit than the mental model of turbo. And it can do things that are fully, like, just front end only interactions that are that don't even talk to the back end. So I as far as I know, turbo is usually augmented by stimulus. I find stimulus as code a bit, boilerplate ish and, because it requires people to write controllers.

Andy Maleh [00:45:56]:
I find that a bit too verbose, personally. I feel like it's not dry enough. It could be drier, but also it's written in JavaScript, which is very ugly compared to back end Ruby code. Like, even even if I'm writing a tiny bit of sprinkles in JavaScript, if if I can write them in Ruby, it would be even better.

Valentino Stoll [00:46:15]:
Yeah. I agree with you there. Definitely go and having the context switch constantly between the 2, definitely slows down the development. For me, personally, I I I don't wanna speak for everyone. But, yeah. I mean, I I feel like we've been driving like, we keep talking about this. We keep driving toward, like, a more, like, view component style, like, in a application development process that is getting closer. And this seems to be, like, crossing that bridge of the missing pieces too of, well, we still need JavaScript.

Valentino Stoll [00:46:49]:
JavaScript libraries are still helpful. Like, how do we use them in the context of our application but not have to just use JavaScript to cut to couple our our back ends? And so this is

Andy Maleh [00:47:04]:
Yeah. One of the issues with previous attempts of providing, front end, development, library for, that that would use Ruby, like Opel Ruby, for example. For example, there was a much older framework called Vault that was a bit popular around 2015 or 2016. Vault was basically providing people with a full isomorphic approach to, development on the web so that you write the front end with Vault using the Ruby, and they might have had a DSL. And then on the back end, they basically have models that can establish connections to the back end directly without you writing controllers or writing REST APIs on the back end if I remember right. So it was a very innovative approach. It had very good ideas. The issue with it was that it required it forced people to change their mental model for mails too much, and that's a problem.

Andy Maleh [00:47:59]:
Like, if somebody wrote a Rails app that's just doing very good for their business and it's been around for 5 years, it might be too much to ask for them to change their entire app's approach right away to something like Vault. So Glimmer is aiming aiming to intentionally provide the simplest possible, thing thing, that you could use to augment your Rails app with something better on the front end and and no more than that. So I intentionally just provide a a drop in replacement for your JavaScript library on the front end. And the nice thing about it is JavaScript front ends like, sorry, front end apps are every page has its own app. So if you have older things built with jQuery or or React in the past, it doesn't matter. You can start any new pages with using Glimmer, and it's very easy to add it and you can get started very quickly. My plan behind that is it it would expand gradually in the future so that more and more pieces can be added if people want to optionally. So the second so you mentioned that now things are coming together in a way, because finally, like, on the back end, we have things like flex or view component.

Andy Maleh [00:49:06]:
And on the front end, there's, you know, Glimmer DSL for web. My my idea is to actually extend glimmer support to the back end as well. So eventually, you write your glimmer web components on the front end, and then you, I I wanna support server side rendering of them on the back end. So that way on the back end, you don't have to use PRB anymore. You drop PRB, and replace it with a much simpler glimmer DSL. But you would basically it would work kinda like view component reflects. Like, the back end controller actions will just render glimmer components. And if you render them from the back end on first hits of the website, they will, you know, first render the HTML, and then they will hydrate and add the JavaScript layer on top of that.

Andy Maleh [00:49:49]:
So there will be a bit of work to explore that idea, but that idea is on the horizon. Another idea I had in mind was to actually replace ERB files with a simpler solution, called GRB. So GRB would be glimmer RB, which is basically a files that look like ERB except instead of using, templates style like scriptlet, syntax, you would use the glimmer DSL directly in them. So that's another idea I have. So I have, I have a few ideas on the horizon to enable people to more and more, like, improve their rails way of rendering views and componentizing their views. And and and hopefully, eventually, once I add more and more of those ideas I guess the 4th idea would be to do what Vault was doing, which is to have, front end models act as proxies for back end models. If you do that, then Rails developers don't even have to write controllers anymore. You don't have to worry about so you're gonna like, I can remove all of the boilerplate code of writing controllers out, and then I can remove all the boilerplate plate code of writing, JavaScript services out, like a REST services.

Andy Maleh [00:50:55]:
And that way I can connect JavaScript front end models directly to active record or or back end models in Rails, which is kinda like what Vault and also Hyperstack, which is another open Ruby library, does. Unfortunately, both both of them are no longer maintained or at least Hyperstack hasn't had their release in 3 years. May I don't know if it is maintained still, but either way, that's so that's I think that's a very important thing in software engineering is incremental development, like iterative incremental development. In a in a way, Glimmer is adopting that approach for rolling out its features where people can start with a, you know, drop in replacement for their JavaScript front end library, then move on to a back end technology like either GRB or rendering front end components on the back end directly. And finally, it would be like replacing, their controller layer completely with, like, a a model proxy layer that would bypass the whole REST API thing, or it it it would basically automate it so that I don't have to write to REST code myself directly. So, yeah, these are some of the ideas in the pipeline for Glimmer DSL for web.

Valentino Stoll [00:52:00]:
Yeah. Very awesome. I'm looking forward to to seeing that, come together. I'm sure I'm not the only one.

Andy Maleh [00:52:07]:
Yeah. Me too.

Valentino Stoll [00:52:09]:
So, like, this brings me to my, like, last kind of question, I guess, is, like, the you know, how does are are there any plans to bridge the gap of consolidating the application development to allow automatically creating both for web and desktop and mobile and x y z? Like, is that a desirable future, or is that better to keep things separate still?

Andy Maleh [00:52:42]:
I so I explored that idea with my older, Glimmer web library. It was called Glimmer DSL for Opal. It was just the library that would explore that was exploring using Opal to build to render user interfaces. And the approach of that library actually was very different from Klimmer DSL for web. Its approach was actually to hide the HTML and CSS completely from developers so that they actually work with, a GUI mental model that was similar to the desktop. It even used the same widget or control names, like, you could say tag names that were used for building the Eclipse SWT library. So it was trying to match the syntax of glimmer DSL for SWT. What that enabled is basically, I could took take any desktop live game or app that was built with GlimmerDSL for SWT and run its codes in GlimmerDSL for web, without writing HTML or CSS.

Andy Maleh [00:53:35]:
Like, I would just keep the same exact desktop codes in Ruby, and it would run the app, in the browser. So I was able to run Tetris, for example, that way. I built it for the desktop, and it ran on the web with the same exact code, which is pretty impressive. But in my ex however, practically speaking from a, like, a business web development point of view, I don't think it's a very practical idea. I think most developers want to know about HTML and CSS, and, they want to do things following more the web way. And if I hide HTML CSS from them, I don't think they'd be pleased. But, also, if I were to take the other approach, which is use HTML CSS on the desktop, that causes the other, like, issue, which is, like, desktop developers like to lot less code because they don't have to mock with HTML, CSS. Desktop, GUI libraries are usually simpler than web stuff.

Andy Maleh [00:54:28]:
So so I think it's better to just keep, the 2 technologies in a way separate with their DSLs because I I I believe web, requirements are different from desktop requirements.

Valentino Stoll [00:54:44]:
Yeah. That makes sense. I know having worked with, like, React Native, it is painful even just between, like, you know, separate provider platforms of iOS and Android and having to do Windows and Linux and managing that. You know, I I can't imagine that's helpful to have to do for for everything.

Andy Maleh [00:55:11]:
Yeah. This is one of those ideas that sound good on paper, but when you start actually following them in practice, they're not very practical. Like, I I know people yeah. I mean so yeah. I guess that's my answer.

Valentino Stoll [00:55:26]:
Well, this is awesome. I I love seeing this work happening, and you have so many great examples here. That that brings me to, kind of like, you know, before the show we were talking about, you know, you're gearing up for your RubyConf, talk and workshop. You know, do you wanna shed some light on on the workshop that you're doing and, maybe how people can start to get involved in a lot of this glimmer stuff you're building?

Andy Maleh [00:55:58]:
Yeah. Sure. This year, so I'll be presenting a newer version of the same workshop I conducted last year. It was a 2 hour workshop called, how to build desktop applications in Ruby in 2023. In 2024, it's gonna be how to build basic desktop applications in Ruby. This one is gonna be, limiting the workshop content, to, the basics of desktop development so that it gives people more time to breathe and also digest the ideas related to MVC pattern, MVP, and, bidirectional and unidirectional data binding. So, it will give people a lot more time to be able to play around and, learn a desktop version of Glimmer. So the the version used is gonna be the Fukuoka Ruby award.

Andy Maleh [00:56:45]:
The one, sorry, the one that won the Fukuoka Ruby award. It'll be glimmer DSL for lib UI. This library, actually, the nice thing about it is that you just install the Ruby gem, and you're good to go. So I actually do include in the workshop description, events to actions. Like, I tell people just install the Ruby Gem and then run a sample to make sure it works, and you're good to go. So I'll I'll be basically using that library as an educational library for building very small desktop app. So glimmer DSL for LibUI, what's good about it is it it's very good for very simple apps. You can build them very quickly.

Andy Maleh [00:57:25]:
And, also, it's good for apps that are mostly tools or productivity tools, or development related tools that can help with your day to day work because, it's it's it's a very good library for packaging apps as gems. So you can package anything with like, you can scaffold an app with it. It supports scaffolding features similar to Rails, but for desktop apps. And then you can package your scaffolded app as a gem very quickly, and then you can give it to others. Some people just install the gem and use it. So I I would recommend this library the most for people that wanna build productivity tools for, day to day work. If you wanna package your app as a Mac app or a Windows app, this library does have 2 options for doing it, and its Windows option works very well. Its Mac option is very new.

Andy Maleh [00:58:11]:
There's a guy that patched it on the Mac just a few months ago, and I documented what he did. He he actually documented what he did in a blog post that I linked to. So it does offer some packaging options, but they're not the most complete or comprehensive today. I have other libraries like LumaDSL for SWT. Let's see package your apps as real native apps with, like, an EXE or MSI on installer on Windows or DMG file or PKG file on Mac, or even Debian files on Linux or RPM. So that one, if people wanna build a more serious app, I would recommend glimmer DSL for SWT. But if they're building a very quick productivity app or small app that will show a table that is summarizing data from a database, I would recommend, glimmer DSL for LibUI.

Valentino Stoll [00:58:56]:
Yeah. I was looking at their, read me with all the examples. It's pretty slick. You know, it has, like, all of the major components that, you know, you'd wanna use to build a simple desktop app, from the first glance. So very cool.

Andy Maleh [00:59:11]:
Yeah. One one cool thing that I've been doing is actually whenever I add features to, say, Glimmer DSL for Lib UI that I think are useful, I end up also adding them to Glimmer DSL for web. Like, one such a feature is component slots. So now if I build, for example, a name and address form like I mentioned earlier as an example, I can provide add slots in it and people can contribute, tags or like markup inside those slots. In a desktop app, it would be they would be contributing controls. So that way people can, for example, add a message at the top of the name and address form between the name and the address that can inform people of something, or they can add another form like a nested form within it, or, do stuff like that. So, I mean, this this feature is called component slots. It's borrowed from the web component slots, standard.

Andy Maleh [01:00:02]:
Like, on the web in the HTML web component standard, they do have the idea of slots. And it works very well because then it enables any like, if you take any component, you're not limited by what the people who built the component did in it. You can actually open it up and like, it's it it on it follows the opened sorry. The open close principle. You can open any, like, component up, without touching its code. So it's closed for modification, but it's open for extension, and you can add anything to that component, in the in the slots that are designated for for the changes for anything to

Valentino Stoll [01:00:52]:
add. Yeah. Very cool. I love to see all the examples here. How do you find time for all this?

Andy Maleh [01:01:02]:
Nights and weekends, Especially long weekends like Labor Day weekend or whatever. Any long weekends.

Valentino Stoll [01:01:09]:
Yeah.

Andy Maleh [01:01:10]:
End up using them for this, but, I would so fun. It's, it's my passion project. And, also, in my opinion, I really, really think the current front end development development experience in Rails is very, very bad. Like, when I every time I receive a PR on a React component at work, I'm like, wow. This code is absolutely awful. And it's the best code they could write, by the way. I'm not faulting any whoever wrote the code. It's it's the React way, but it, like, it React's code is so absolutely awful.

Andy Maleh [01:01:42]:
And, I mean, I'm, so I I dabbled with other approaches. Like, I was gonna consider recommending Svelte or Vue JS network, but then that's when I, like, that's when I thought about Glimmer and Ruby, and I'm like, wow. I could even do better than Svelte and Vue. And in my opinion, I I succeeded at that. So, I think part part of it is passion. Like, I'm very passionate about Ruby open source projects. The other part of it is also thinking seriously about how to improve our development productivity for customers because this is a game changer. If you can save 6 months, a year of development work, because you're using front end Ruby instead of JavaScript, that's an absolute game changer.

Andy Maleh [01:02:20]:
And that code is also gonna be more maintainable for years to come, so it'll be cheaper to maintain for years to come as well. And on top of it, like, basically, it pays for itself. So, like like, if people try to say give you an excuse of, oh, I don't have time to check out this library or try it out. I'd be like, no. You don't have time not to check it out. Because right now you're spending 6 months more every year using another library. If you spend only 2 or 3 weeks learning this library, you're gonna save, like, 5 weeks and a and a half or so. So it's actually paying for its own investment automatically, like, just by exploring this library.

Andy Maleh [01:02:59]:
So in my opinion, that so that's another reason why I'm I'm into it. Like, I believe it's gonna enhance my work experience significantly, if we adopted in my company right now.

Valentino Stoll [01:03:12]:
Yeah. Totally. I could see that for sure. And I I would love to see somebody, maybe ingesting some of these examples to AI to help with, you know, get adjusting to the DSL because, that's probably one of the biggest, aspects of learning, new new frameworks, to me personally at least.

Andy Maleh [01:03:33]:
We're not saying glimmer DSL for web as much because it intentionally honors the HTML markup language almost exactly as is. So for example, if you wanna use an on click listener, any any on any on click attributes or on change or on anything, they're all supported automatically in Glimmer. So, like, all your knowledge will be you'll be able to transfer it to Glimmer, but following a different way, you just have to write the code with less code. Like, instead of opening and closing every tag, you don't have to open and close the tags anymore. You can just put the tag name and then open a block with curly braces and then close-up curly braces and you're done. So it's it's more dry. Like, people who write HTML don't write don't write dry codes because HTML itself is not dry. I mean, that's part of the reason why XML became obsolete and people started using JSON because JSON is a lot drier than XML.

Andy Maleh [01:04:22]:
But unfortunately, in web view development, like, people haven't made that transition yet. So the this approach is, like, one one key reason for the design of Glimmer DSL for web being different from Glimmer DSL for Opal was to enable people to not have much of a learning curve. They can just transfer their HTML skills, as is. So, like, any attributes you know on any, elements are supported by Glimmer DSL for web, and any listeners are supported, and any, and all and then all the same tags are supported by their same name. It's just with a slightly different syntax that's actually less code than HTML.

Valentino Stoll [01:05:00]:
That's awesome. Yeah. I'm gonna have to play with this around, myself because, it looks like a lot of fun. Alright. We're kind of getting to the the time here. Is there anything else you wanted to to share or talk about, before we wind down to, fix?

Andy Maleh [01:05:20]:
I don't think so. I think we covered everything.

Valentino Stoll [01:05:22]:
Yeah. I mean, you're you're you're doing it all, it seems. I love to see all of the, you know, the options that people have even within the the Glimmer ecosystem. It's really, you know, please keep keep it up because, I think you're heading in the right way. So let's, let's move to PIX. Do you do you have anything or you want me to go first? I can give you some time.

Andy Maleh [01:05:52]:
I I don't think I have anything, to be honest. I think, like, the the topic of this podcast will give people a lot of stuff to check out already. So, like, I would recommend checking out, you know, the glimmer DSL for web GitHub project. Run, like, the online hosted sample and play around with it. It has a bunch of samples written in Ruby. And then lastly, I would recommend, obviously, for everyone to take out like, build a Rails like, a new Rails app from scratch and then integrate Glimmer via software web into it and then play around with it.

Valentino Stoll [01:06:26]:
Yeah. Totally. That's that's the path I'm gonna take. So I well, I I don't really have, too much to share here other than, I'm building a robot arm. Cool. It by, hugging face. It's called LeRobot, and you can train it to do things. It has, like it's 2 arms, but it has, like, a follower arm and, you know, a leader arm.

Valentino Stoll [01:06:53]:
And so you can lead the other one and tell show it how to pick up things and push buttons. And I hope that one day I could get it to, like, type on the keyboard and, like, look at my screen and then just, like, work for me. But, it's a lot of fun. I I'm just to the assembly phase. I completed that, and it's been, it's been a lot of fun. So I'm looking forward to diving.

Andy Maleh [01:07:14]:
Leader arm, do you control the leader arm directly, or do you give it voice commands, or or does it follow your arm using a camera with AI, like, like, AI vision?

Valentino Stoll [01:07:25]:
So this this particular one, they have, like, a a couple different versions, of the arms, but this one, it had they have, like, you basically have, like, 2 of the same kind of arm, and you can move one of them that moves the other, in the same ways. So it mirrors it. They call it teleoperation. But they have, like you know, you can have multiple robot arms. So, like, you can have multiple leaders, multiple followers. And so, there is a camera aspect that lets you train and learn kind of what is happening that way. And so I think maybe in the future, it will get to the point where you could just use your own arms and hands. But I think right now, it's just like, because the dexterity is not there yet.

Valentino Stoll [01:08:10]:
It's just 2 arms and you train 1 with the other kind of thing.

Andy Maleh [01:08:14]:
So what are some applications of this robot's arm? Like, what did you use it for that you think could be

Valentino Stoll [01:08:19]:
So right away, I had a bunch of screws that were all different sizes that came in the same package, and I want to just sort it rather than me sort the the screws. So, like, that will probably be my first one because it's like they're tiny screws and then they're hard to sort and, like, that should be something easy or not easy, but, like, straightforward to train the arm to do. But their their examples that they have are, like, Lego sorting, right, finding the right colors. Like, I think they had one example where they're, you know, pushing buttons on something else. So I I don't really know what I'm gonna do with it yet. It's mostly just fun to explore, all of this real world, AI aspect stuff. So Yeah. Definitely.

Valentino Stoll [01:09:04]:
Yeah. So check that out if you're interested, the robot. Well, it's been, awesome talking to you, Andy. I appreciate you coming on again and, all the work you're doing in this space because, you know, we need it. And I love to do more Ruby than anything else. So, I appreciate it. And, yeah, if, people wanna reach out to you or or find you on the Internet, how do they do that?

Andy Maleh [01:09:34]:
They can find me on LinkedIn. I'm just Andy Malley on LinkedIn. Or, I I mean, I have a Twitter. It's called Andy Optiva at Andyobtiva. And, what else? And then they if they need to reach out to me about Glimmer directly, if they visit the GitHub project, there's a Gitter chat link. So they can click on the Gitter chat link, and that would take them to a chat room that is all about Blender.

Valentino Stoll [01:10:07]:
Awesome. Well, thanks again for coming on, and, thank you for listening, everybody. Yeah. And, you know, until next time, more Ruby on

Andy Maleh [01:10:20]:
the way.