Speaker 1: Hey, everybody, Welcome to another episode of the Ruby Rokes podcast.
Speaker 1: I'm your host today, Valentino Still, and we're joined by
Speaker 1: a very special guest today, Andy Mala. Did I say
Speaker 1: they're ready?
Speaker 2: Andy, Andy Malay?
Speaker 1: Yep, Maale. Sorry I should have asked you before. We're welcome.
Speaker 1: Do you want to just introduce yourself? And I'm sure
Speaker 1: some people have heard you before on our show here,
Speaker 1: but just give everybody an introduction and you know why
Speaker 1: you're famous?
Speaker 2: Yeah? Sure. My name is Andy Malay. I have about
Speaker 2: twenty years of software engineering experience, and I've been programming
Speaker 2: since I was a kid. Really and yeah, I have
Speaker 2: a bachelor degree in computer science from McGill University in
Speaker 2: Montreal and a master's degree in software engineering from DePaul University, Chicago.
Speaker 2: And I guess I became famous when I won the
Speaker 2: Ruby Award in twenty twenty two for my project wimer
Speaker 2: DSL for Libui, which entered at Ruby Comp three times already.
Speaker 2: I'm going to present it for the fourth time this year.
Speaker 1: Uh.
Speaker 2: And I've also spoken at rails Comp twice before.
Speaker 1: That's awesome. Yeah, I didn't know you won the Ruby
Speaker 1: Awards on that.
Speaker 2: I won one of the awards. The Yeah, a special
Speaker 2: Ruby award, That's what it was called.
Speaker 1: Awesome A. So what is glimmer? Uh?
Speaker 2: So Glimmer started originally as a desktop development goouey library.
Speaker 1: Uh.
Speaker 2: It was like I started it in the mid two
Speaker 2: thousands as a way of making myself learn Ruby. At
Speaker 2: the time, I was a Java developer and I did
Speaker 2: a lot of Java desktop development work at like a
Speaker 2: couple of companies, and I needed I heard about Ruby,
Speaker 2: and I saw rails, and I thought it was awesome,
Speaker 2: and I'm like, why don't we do this on the
Speaker 2: dusk stop like the whole like all the cool things
Speaker 2: that Ruby offers, as far as metaprogramming, as far as
Speaker 2: building dsls uh and and all of that, we can
Speaker 2: like build gooy's with it on the desktop. So I
Speaker 2: checked out what are my options at the time that
Speaker 2: were built by other people, And I saw Shoes and
Speaker 2: I saw TK and Ruby. TK did not have a DSL.
Speaker 2: It was like writing code for it was very ugly.
Speaker 2: It felt like I'm writing Java code, so I didn't
Speaker 2: like working with it. Shoes was very nice, but unfortunately
Speaker 2: it was a bit not very well maintained and it
Speaker 2: had bugs and it would crash randomly. So I built
Speaker 2: Glimmer originally as a Ruby layer on top of the
Speaker 2: Eclipse SWT library, which is used in the Eclipse ID
Speaker 2: because that's what I used at work at the time.
Speaker 2: So I built it using j Ruby because I had
Speaker 2: to run on top of the JVM. Eventually, the idea
Speaker 2: proved itself to be interesting and useful enough to a
Speaker 2: point where I ended up then covering all the available
Speaker 2: gooey toolkits and Ruby with Glimmer. So I have a
Speaker 2: Glimmer DSL for TK now Glimmer DSL for GTK for
Speaker 2: FX Ruby meaning Fox Toolkit for Libyu I started about
Speaker 2: is a library that's a bit recent that was one
Speaker 2: of the more recent Glimmers that were built, and the
Speaker 2: most recent one is w wx wx Widgets has been
Speaker 2: covered by Glimmer recently because somebody built a new binding
Speaker 2: called w x ruby that replaced the old wx Ruby
Speaker 2: just a couple of years ago, so I ended up
Speaker 2: also covering it with the Glimmer DSL. So but to
Speaker 2: get back to that question, what happened is eventually I
Speaker 2: ended up last year coming up with the idea of
Speaker 2: building Glimmer DSL for web which is a web version
Speaker 2: of Glimmer that uses all the innovations for data binding
Speaker 2: that were used in desktop development, but building web user interfaces.
Speaker 1: So, I mean, the first thing I think of when
Speaker 1: I think of what you know cross platform desktop apps
Speaker 1: is like Electron and maybe like maybe I'm just old,
Speaker 1: I don't really know if that's like still used, then
Speaker 1: is that is that a close comparison to what we're
Speaker 1: talking about.
Speaker 2: So the irony is that Electron is not real desktop.
Speaker 2: So Electron runs on top of browser embedded browsers, so
Speaker 2: it's actually you write the app and actually HTML and CSS.
Speaker 2: So unfortunately, as a result of that, you forego all
Speaker 2: the simplicity of desktop guy toolkit development because desktop guys
Speaker 2: are usually a lot simpler than web guys because they
Speaker 2: have limitations that are enforced to comply with operating system
Speaker 2: standards like on macOS or Windows. So it's a lot
Speaker 2: faster to build a desktop app with a desktop guy
Speaker 2: toolkit than to build it with HTML and CSS. I think.
Speaker 2: So Electron runs on top of a browser, and so
Speaker 2: the good news is that browsers are a desktop app.
Speaker 2: Everybody who is doing web development uses desktop apps because
Speaker 2: the browser is a desktop application, But Electron is not
Speaker 2: real desktop development like a cross platform. We toolkits are
Speaker 2: actually a lot simpler to use than Electron.
Speaker 1: I see that makes a ton of sense. I guess,
Speaker 1: like thinking about like styling, are you pretty like restricted
Speaker 1: then to of like the you know, operating systems style
Speaker 1: limitations for a lot of these components.
Speaker 2: Yeah, So the good news is that it's like the
Speaker 2: eighty twenty rule. In general, you you write very yeah,
Speaker 2: very simple guys that comply to the style guidelines, and
Speaker 2: you can write those guys very quickly, very little code
Speaker 2: using glimmer. But twenty percent of the time when you
Speaker 2: need to have your own customizations, you can actually build
Speaker 2: completely custom user interfaces from scratch if you prefer, But
Speaker 2: then you have to do a lot more work. So
Speaker 2: you can actually do things that are the same things
Speaker 2: that you could do with HTML and CSS, but in
Speaker 2: dusktop they could Like basically, you draw on a canvas,
Speaker 2: and you can do anything with a canvas. But in general,
Speaker 2: it's discouraged in desktop development unless you have an app
Speaker 2: that's actually drawing diagrams or doing things like visual games,
Speaker 2: two D games or stuff like that. In general, if
Speaker 2: you don't have diagrams or games or anything that's very
Speaker 2: like custom it's better to stick to the you know,
Speaker 2: like using standard do we too get controls like text, field, list,
Speaker 2: combo box, et cetera.
Speaker 1: That's interesting you mentioned gaming aspects because I know that,
Speaker 1: you know, the Ruby gaming engine of choice lately is
Speaker 1: Dragon Ruby. I know that kind of like evolved from
Speaker 1: Ruby Motion as like the de facto like desktop builder application.
Speaker 1: I don't know if that's still maintained or not. Is
Speaker 1: there any comparison like you can make between glimmering and
Speaker 1: Ruby Motion.
Speaker 2: Yeah? Sure. So ruby Motion has two parts. There's the
Speaker 2: Ruby Motion mobile development aspect of it, and that one
Speaker 2: supports IOEA, an Android development using Ruby code. I've actually
Speaker 2: tested it to build a like a demo, like a
Speaker 2: proof of concept iOS app, and it works. It's very nice.
Speaker 2: I might have it might have been last year or
Speaker 2: the year before it was when I tested it. Uh,
Speaker 2: it still works. Uh. And then they have a desktop
Speaker 2: component where you could but but it's not cross platform.
Speaker 2: It's only for the Mac. So that part overlaps a
Speaker 2: bit with glimmer, but I would not use it. I
Speaker 2: would rather use Glimmer because when you build a Glimmer app.
Speaker 2: Once it runs on all platforms, then if you're using
Speaker 2: one of the native guy toolkits like LIBYUI, wx widgets
Speaker 2: or SWT, your apps will look native on every platform
Speaker 2: as well. So uh, but the mobile aspect of Ruby
Speaker 2: Motion is very cool. Actually, I do want to explore
Speaker 2: the idea of building a Glimmer DSL for Ruby Motion Mobile.
Speaker 2: That would be very cool because then I can write
Speaker 2: the app and Ruby with a nice DSL and it
Speaker 2: would run on mac os and Android or sorry not
Speaker 2: macro iOS and Android. So that's something up that that
Speaker 2: would be interesting to explore. But otherwise Dragon Ruby is
Speaker 2: more optimized for gaming. Uh And yeah Glimmer. Glimmer allows
Speaker 2: you to build games, but it's not optimized for games.
Speaker 2: It's not about like offering you the best performance for
Speaker 2: games or anything like that. Although it's libraries are pretty
Speaker 2: optimized for performance, like they do run fast, but it's
Speaker 2: the library itself is not tailored toward towards gaming. I
Speaker 2: would still recommend if people want to build complex games,
Speaker 2: Dragon rubies definite take the Way to Go or something
Speaker 2: else like Ruby two D or there are a few
Speaker 2: other libraries for gaming as well.
Speaker 1: Yeah, that makes sense. I mean, he's the best tool
Speaker 1: for the best job, and I love so like thank
Speaker 1: you for the backstory and Glimmer, And I mean we
Speaker 1: had you on today to talk about this new uh
Speaker 1: you know thing you've been working on with Glimmer Web,
Speaker 1: which is fascinating to me. Did what what drew you
Speaker 1: in this direction? You want to describe maybe what the
Speaker 1: Glimmer DSL for web is, And it's because it's funny
Speaker 1: you mentioned that, you know, we as web developers are
Speaker 1: really desktop app developers, so you want to just like
Speaker 1: dive into you know how that correlates.
Speaker 2: Yeah, sure, I mean, I mean I've personally experienced building
Speaker 2: desktop apps of Glimmer for quite a while now, and
Speaker 2: it's very quick to build any idea I have, Like
Speaker 2: if I like, one day I needed the metronome. I
Speaker 2: actually played drums as a hobby, and my phone metronome
Speaker 2: app got a bug in it after the latest update.
Speaker 2: So I ended up building my own metronome with Glimmer
Speaker 2: as a desktop app, and I built it. I bet,
Speaker 2: I built the first MVP version in ten minutes, and
Speaker 2: it was like so amazing because Ruby, Ruby is so awesome,
Speaker 2: and so I noticed that I don't have the same
Speaker 2: productivity in web front and interface developm using JavaScript, not
Speaker 2: even close. Like JavaScript is so cumbersome. Even the newest
Speaker 2: versions of JavaScript are so like over engineered, and they
Speaker 2: focus on premature optimizations that are not important whatsoever. So
Speaker 2: because of all of that, like, for example, like JavaScript
Speaker 2: makes you worry nowadays about const versus let, which to me,
Speaker 2: like as a Rubist, that's the least of my concerns
Speaker 2: when I'm building a business app. I just want to
Speaker 2: focus on the business concerns and not on low level
Speaker 2: details like that. They also have an import export system,
Speaker 2: which on the surface sounds great, but in reality it's not.
Speaker 2: Like practically in Ruby, we don't it's a lot simpler
Speaker 2: because we don't have that important export system and we
Speaker 2: don't care. Like it works fine enough for us without it.
Speaker 2: Ruby works pretty well for us. So there are a
Speaker 2: lot of differences between JavaScript and Ruby as far as productivity,
Speaker 2: and there are huge differences. Like I mean, I know,
Speaker 2: like every once in a while dhh and says online
Speaker 2: on Twitter or something that he thinks that JavaScript after
Speaker 2: they updated it to act script has become a great language.
Speaker 2: But honestly, I don't find it a great language at all.
Speaker 2: I think he's wrong. I think he's kind of caved
Speaker 2: into what the popular demand or sorry, popular choice by
Speaker 2: people is instead of actually being a leader and being like, no,
Speaker 2: we could do even better Ruby. So that's a lot
Speaker 2: of those aspects are what prompted me to explore building
Speaker 2: a glimmer using a front end Ruby technology. And today
Speaker 2: in twenty twenty four, we do have front end Ruby technologies,
Speaker 2: like we have opal Ruby, which just won a fuko
Speaker 2: Ka Ruby Award in twenty twenty three, so it's a
Speaker 2: pretty impressive library that gives you a Ruby to JavaScript transpiler, sorry,
Speaker 2: JavaScript to Ruby transpiler, so that way you can write
Speaker 2: code that will run as JavaScript like in your website,
Speaker 2: and consumers of your website will not know that it's Ruby,
Speaker 2: but you actually wrote the code in Ruby first and
Speaker 2: it got transpiled to JavaScript. So that's that's technology. That's
Speaker 2: one techno. And another one is Ruby WOSM, which compiles Ruby
Speaker 2: into like quasim low level code and it basically gives
Speaker 2: you like all the features of Ruby three point one
Speaker 2: or three point two nowadays in the browser. And then
Speaker 2: there's also Ruby two JS is the third option, but
Speaker 2: that one is not as comprehensive as the first two options.
Speaker 2: I don't think you can build everything with it. But yeah,
Speaker 2: so I ended up choosing Opal as a start for
Speaker 2: building Glimmer DSL for Web because and I wanted to
Speaker 2: try the idea out. I tried it out in another project.
Speaker 2: I had a project called Glimmer DSL for Opal in
Speaker 2: the past, which which is retired now it's archived, and
Speaker 2: I was able to prove to myself that I can
Speaker 2: do everything that Glimmer does on the desktop in a
Speaker 2: web user interface on the web. And after I proved
Speaker 2: that idea, I built Blimmer DSL for Web starting last year,
Speaker 2: and it was it took that approach of being more
Speaker 2: friendly towards people that know HTML very well or no
Speaker 2: JavaScript or CSS very well. So it has the dsls
Speaker 2: that are very close to them to those languages. So
Speaker 2: it basically does give you an HTML DSL a CSSDSL
Speaker 2: which is optional. If you want to manage CSS separately,
Speaker 2: you can or you could use it. And then the
Speaker 2: JavaScript aspect got replaced by Ruby, so any or JavaScript
Speaker 2: logic code can always be written now with Ruby instead
Speaker 2: of JavaScript, and anything that you could do in JavaScript.
Speaker 2: You could do it with opal Ruby. So Glimmer DSL
Speaker 2: for web is not limited whatsoever given that, like, you
Speaker 2: can integrate with any available JavaScript library out there. For example,
Speaker 2: I built a sample selector app that lets people visit
Speaker 2: a rails app that gives them a bunch of Glimmer
Speaker 2: samples and then they select one and then they see
Speaker 2: the code syntax highlighted, and then they can launch it
Speaker 2: in the web because it's a web apps, it's a
Speaker 2: web user like front end apps, and then they can
Speaker 2: launch it directly in the in the browser. So the
Speaker 2: syntax highlighting aspect, I didn't have to implement it myself
Speaker 2: from scratch. I used the library called highlight JS, and
Speaker 2: I was able to like integrate it very very quickly,
Speaker 2: Like it took me just a few minutes, or maybe
Speaker 2: a bit more than ten minutes, but so yeah, So
Speaker 2: I mean I was able to after I experimented with
Speaker 2: the idea for quite a while, I took a page
Speaker 2: like one of the sophisticated pages in my work website.
Speaker 2: By the way, I work for lek Stop, which is
Speaker 2: a death collection agency based in Montreal that uses web
Speaker 2: technology to reach people that are late at paying their
Speaker 2: bills either by email or SMS messages. So we have
Speaker 2: a rails app. Basically we're a rail shop and right
Speaker 2: now we're using like we've been using React for the
Speaker 2: last number of years. But I built a proof of
Speaker 2: concept where I rewrote a React page that had a
Speaker 2: table of data with passionation, sorting and filtering, and I
Speaker 2: was able to rewrite it and Glimmer DSTL for a
Speaker 2: weapon in about one day. But also the performance was
Speaker 2: just fast enough, Like I didn't feel any like I
Speaker 2: didn't feel like performance was too slow or anything like that.
Speaker 2: It was fast enough, and the code was amazing, like
Speaker 2: I was able to cut the total code in about
Speaker 2: by about half. And also the main React component was
Speaker 2: about five hundred lines of code. And in Glimmer. Glimmer
Speaker 2: has a very like friendly like op approach of following
Speaker 2: MVC and MVP patterns and with NBC and MVVP. The
Speaker 2: the React component mixes a lot of like data concerns,
Speaker 2: like it has tate hooks and effects, and it mixes
Speaker 2: like business concerns with the view present presentation of the view.
Speaker 2: Whereas when I rewrote it in Glimmer, it shrunk from
Speaker 2: five hundred lines to fifty lines or something like that.
Speaker 2: So it was the one. Yeah, it became a tenth
Speaker 2: of the size, and all of the data management stuff
Speaker 2: that REACT let's you do with state hooks and effects
Speaker 2: got extracted into logic in a presenter or a model.
Speaker 2: So like I had an MVP pattern where there's a view,
Speaker 2: a model, and a presenter. The presenter is kind of
Speaker 2: like a controller, Like MVP is a variation on MVC.
Speaker 2: But yeah, the code became a lot better because then
Speaker 2: I can manage the code with standard op for anything
Speaker 2: that is not view related that's just mostly logic or so. Yeah,
Speaker 2: so it was I did a demo of this to
Speaker 2: my coworkers at work and the CTO and they were
Speaker 2: pretty impressed. I'm going to be doing another demo soon
Speaker 2: to the engineering manager of the company and engineering department manager. Sorry,
Speaker 2: and we're gonna be looking into an idea for rolling
Speaker 2: it out if the demo goes well. I hope it
Speaker 2: would go well. And like one idea for rolling it
Speaker 2: out is it's not a big bang thing. You don't
Speaker 2: have to do it everywhere at once. Like the nice
Speaker 2: thing about front ends on the web is that every
Speaker 2: web page is a self contained fun end app in
Speaker 2: a way. So that means for any new web page
Speaker 2: that we build, we could use Glimmer and keep all
Speaker 2: the older web pages and whatever old technology we had.
Speaker 2: But that's not even how we're going to start with it.
Speaker 2: What we're gonna do is basically only internal facing web
Speaker 2: pages that are in the admin UI are going to
Speaker 2: start using Glimmer. Glimmer dssel for web is like the
Speaker 2: idea I'm going to be proposing at the next meeting. Uh.
Speaker 2: And that way, we can gradually play around with it
Speaker 2: in a few admin pages first, and I just want
Speaker 2: to make sure there aren't any gotchas that I haven't
Speaker 2: discovered on my own from building my own sample apps. Uh.
Speaker 2: And after we do that for about you know, four
Speaker 2: months or six months, then we can start, uh maybe
Speaker 2: rewriting some admin pages that we're in React in Glimmer
Speaker 2: instead of just adding new pages in Glimmer. And then
Speaker 2: after that the phase after that, Phase three would be
Speaker 2: start start writing new pages on the public facing website
Speaker 2: with Glimmer. And then finally the last phase would be
Speaker 2: to rewrite React components with Glimmer. If we feel like
Speaker 2: it is needed, it's completely optional, but it's it could
Speaker 2: be useful because Glimmer Ruby code is a lot a
Speaker 2: lot more maintainable than we are JS codes, way more like,
Speaker 2: in my experience at least double as maintainable.
Speaker 1: This is really interesting because we are kind of missing
Speaker 1: a you know, a hard stance on front end and
Speaker 1: in the rails community at least, but definitely in Ruby
Speaker 1: as well. And Opal has been kind of the closest
Speaker 1: thing I've seen. It's interesting you've built kind of like
Speaker 1: on top of OPEL. I know we've had Elli on
Speaker 1: here before talking about Opel, and it's like a really
Speaker 1: great work, just so smooth of a process. Uh. And
Speaker 1: I love your the DSL you have here in your
Speaker 1: to do list app that you've made, which is like
Speaker 1: so simple and easy to read. We'll share it here
Speaker 1: in our show notes. So I'm like really curious. A
Speaker 1: lot of this looks similar to kind of like the
Speaker 1: Flex markup for those familiar with uh uh, you know
Speaker 1: Joel Draper's Flex project where they have like a DSL
Speaker 1: for kind of building up the dom elements and mutating them.
Speaker 1: I'm curious, like, uh, you know now that you've been
Speaker 1: like kind of reworking even like react stuff, Like what
Speaker 1: is as a Ruby developer, Like I am assuming that
Speaker 1: you've developed in reels.
Speaker 2: Uh, that I've developed in Rails. What do you mean? Sorry? Yeah,
Speaker 2: like you've used reels before eight two thousand and seven.
Speaker 1: Yeah, okay, yeah, I mean so, like, what's what's been
Speaker 1: your experience overall experience? Like uh as far as like
Speaker 1: you know, why why move to Glimmer as an example,
Speaker 1: you know, like is it is? It kind of straightforward.
Speaker 1: It's like a team that hasn't seen Glimmer before to
Speaker 1: like make the transition pretty easily. I guess you'll find
Speaker 1: out there.
Speaker 2: Might be a like misunderstanding. Glimmer is only the front
Speaker 2: end part. Glimmer integrates with Rails. Glimmer is a Rails
Speaker 2: library by the way. It's also it's not just an
Speaker 2: open Ruby library. It's also a it's a Rails gem.
Speaker 2: It integrates with Rails apps and enables you to suddenly,
Speaker 2: in any Rails app be able to write the fun
Speaker 2: end in Ruby. That's it, except let's to ride the
Speaker 2: fun end and Ruby using a nice Glimmer DSL. Like
Speaker 2: without Glimmer, if I use open Ruby alone, you can
Speaker 2: just write Ruby code in the fun end. That's it,
Speaker 2: but you don't have any support for building frameworks or
Speaker 2: components or data binding or any of that. Glimmer adds
Speaker 2: the extra layer that is missing that enables you to
Speaker 2: do anything you could do data binding, for example using
Speaker 2: like same. It has the same data binding features as
Speaker 2: Glimmer desktop libraries. But all of those data binding features
Speaker 2: we are actually pre date Glimmer. They come from Microsoft
Speaker 2: technologies that were used in Visual Basic, I Believe and
Speaker 2: other Microsoft products. They were also used by some mac
Speaker 2: Gooey building products as well, so those same ideas got
Speaker 2: adopted by view js and Veldt. So the same old
Speaker 2: sort of data binding features that people know I from
Speaker 2: Veldt and viewjs are available in Glimmer. Accepting Glimmer it's
Speaker 2: a lot nicer because you write Ruby code instead of
Speaker 2: JS code, and it also doesn't have the separation between
Speaker 2: markup is in HTML and logic is in JavaScript and Ruby.
Speaker 2: Everything is Ruby. The nice thing is for HTML we
Speaker 2: have an HTML DSL, the CSS there's the CSSDSL, and
Speaker 2: for logic that's just Ruby. So everything is in one
Speaker 2: language so it fits in a lot, so that eliminates
Speaker 2: the friction between multiple languages. Which actually creates a rag
Speaker 2: on productivity. A lot of people are kind of like
Speaker 2: the Pragmatic book metaphor of the boiled frogs. Have you
Speaker 2: heard of the boiled frogs story from the Pragmatic Programmer book?
Speaker 1: No, I'm not familiar.
Speaker 2: Repeat it. It's basically like, it's a very interesting book
Speaker 2: that I highly recommend reading to anyone working in the
Speaker 2: soft in the software development industry. But uh, they're basically
Speaker 2: saying that, like one risk that people get into is
Speaker 2: becoming boiled frogs. What they mean is, like they say,
Speaker 2: if you take a frog and put it in a
Speaker 2: pot with boiling water, the frog will jump out right
Speaker 2: away of the of the pot as a reaction, as
Speaker 2: a like a wave of a react like a yeah,
Speaker 2: as a reactive basically reactive behavior. It will jump right
Speaker 2: away just to protect its life. But if you put
Speaker 2: a frog in a pot with water that is cold,
Speaker 2: and then you raise the heat very gradually like you
Speaker 2: turn on you turn on the heat, and then you
Speaker 2: is it very very gradually, you can boil the frog
Speaker 2: without it knowing, because it will boil very very gradually,
Speaker 2: so it will not know that it is boiling, but
Speaker 2: eventually it will boil. So they mentioned that a lot
Speaker 2: of developers end up in that situation where they use
Speaker 2: technologies at work that put a drag on their productivity
Speaker 2: and they get used to them, and getting used to
Speaker 2: things is like one of the biggest risks in adopting
Speaker 2: bad practices and software engineering. So people might like use JavaScript,
Speaker 2: which has very contradictory paradigms to Ruby with a rail's
Speaker 2: application for years and think they're doing the best they could,
Speaker 2: but in fact they're actually not doing the best they could.
Speaker 2: They're creating it like a drag on productivity because they
Speaker 2: have multiple languages that have different paradigms, and they're also
Speaker 2: in their head their context switching between the two languages
Speaker 2: all the time. So I personally noticed, like I pay
Speaker 2: a lot of attention because of reading that story and
Speaker 2: the Pragmatic Programmer book, And at first I felt for
Speaker 2: that trap too. I used JavaScript for many years thinking
Speaker 2: it was the best thing, but eventually I realized, like I,
Speaker 2: like I mentioned, I used glimmer for building desktop apps
Speaker 2: a lot, and like that's not even like JavaScript development's
Speaker 2: n even close to that. And so basically a lot
Speaker 2: of people are bold boiled frogs in a way, they're
Speaker 2: not realizing how much productivity they're losing. In my experience,
Speaker 2: I would like I think Glimmer DSL for a web
Speaker 2: would cut down the work in half in half in general,
Speaker 2: so like if you have twelve months at front end
Speaker 2: development work and JavaScript and React, you could do it
Speaker 2: in six months in Ruby and Glimmer DSL for web.
Speaker 2: So that's part of the reason why I'm actually using
Speaker 2: it with rails, not against It's not like I still
Speaker 2: use rails for the back end, but Glimmer is kind
Speaker 2: of like providing a drop in replacement for your JavaScript
Speaker 2: libraries that you're adding to Rails. So if you're using
Speaker 2: VIEWJS or Amber or SVELT or Angular or react any,
Speaker 2: Glimmer can do a lot better than any of those
Speaker 2: in my experience as far as productivity, assuming you know,
Speaker 2: like it has fast enough performance. Like for my work
Speaker 2: app the largest sorry the web page with the most
Speaker 2: elements has only twelve hundred elements, and like I discovered
Speaker 2: they were render fast enough with Glimmer, I don't even
Speaker 2: need any of the like performance like advertisements of like
Speaker 2: React or Velt for that like uppa, Ruby's fast enough
Speaker 2: in my experience, So in general, I think we can
Speaker 2: follow the eighty twenty rule where we can avoid premature
Speaker 2: optimization because people tell you know, it's the root of
Speaker 2: all evil and software engineering, because it makes people complicate
Speaker 2: their code unnecessarily, like React code is unreadable compared to
Speaker 2: Ruby code, or like especially like Rails back end code
Speaker 2: for example, so like why are we using it in
Speaker 2: a Rails app? Like that's contradictory. So I'm trying to
Speaker 2: provide a way for people to use Ruby on the
Speaker 2: front end just like the back end, and that way
Speaker 2: that opens the door to things like being able to
Speaker 2: reuse back end Ruby logic in the front end directly.
Speaker 2: So for example, if I have a few pieces of
Speaker 2: logic that are validating taxes for payments or calculating story
Speaker 2: taxes for like an order, I can actually ship that
Speaker 2: code to the front end, assuming it has no security
Speaker 2: requirement restriction requirements on it, and reuse it in the
Speaker 2: fund directly. So that way I don't have to write
Speaker 2: in rest EPI to reuse it. A lot of developers
Speaker 2: waste time writing rest APIs to connect JS code to
Speaker 2: the back end, or they waste time rewriting the back
Speaker 2: end code and JS. That's another like performance waste or drain,
Speaker 2: sorry not productivity drain. So open Ruby also saves us
Speaker 2: from having to do that. Then I can like reuse
Speaker 2: back end Ruby code directly in the fun end where needed,
Speaker 2: So any secure code remains back and only not everything
Speaker 2: will be opened up to the fun end. But things
Speaker 2: that are reusable on the front end and don't have
Speaker 2: any security restriction requirements, you can actually reuse them directly
Speaker 2: in the fun end. So I mean to answer your
Speaker 2: question like, I'm using Glimmer to actually improve my productivity
Speaker 2: and rails app development, and I would say double it
Speaker 2: as far as front end development and rails apps. One
Speaker 2: other thing you mentioned was that Flex. One thing to
Speaker 2: clarify about Flex is Flex is only about two years
Speaker 2: old and the approach they use is actually not different
Speaker 2: from what Glimmer had for years. On the dusktop they
Speaker 2: let you build components with markup with sorry, with a
Speaker 2: Ruby DSL that lets you build the HTML. But Glimmer
Speaker 2: Desktop Libraries lets you do the same thing with components,
Speaker 2: but instead of using HTML markup and the DSL used
Speaker 2: the Desktop Control DSL, which like you know, will give
Speaker 2: you dustop widgits like list or Combo box or text field,
Speaker 2: et cetera. So I would say that like whatever they
Speaker 2: came up with, they came after Glimmer, They're not. The
Speaker 2: Flex approach is not with Glimmer copied. Glimmer just copied
Speaker 2: its own. It's older the stop self. But Flex, thankfully
Speaker 2: is another library that is exploring the same ideas for Glimmer,
Speaker 2: but only on the back end, like they're doing it
Speaker 2: at least for now, they're mainly exploring things on the
Speaker 2: back end, whereas Glimmer, the estolf for webs is doing
Speaker 2: it on the front end. Both of them, to be
Speaker 2: more a fair both Glimmer and Flex borrowed the idea
Speaker 2: of writing a DSL for the guy or the user interface,
Speaker 2: whether it's using HTML, markup or desktop controls. They borrowed
Speaker 2: that from much older technologies like Shoes or mark Cobby
Speaker 2: Markabby was one of the first dsls and Ruby. I
Speaker 2: believe that allowed people to write HTML and Ruby. So
Speaker 2: so yeah, I just wanted to clarify the history of it.
Speaker 1: Yeah, super interesting. There's been on so much work, and
Speaker 1: to be honest, so many failed attempts as well along
Speaker 1: the way. But I think we're finally getting so where
Speaker 1: I looking at your example rails app here you have
Speaker 1: a sample glimmer DSL where that for rails people can
Speaker 1: check out as well. It definitely makes a lot more
Speaker 1: sense now as you've been explaining it, seeing it as
Speaker 1: like you said, the data binding aspect of connecting the
Speaker 1: front end components to the back end, and it makes
Speaker 1: a lot of sense, and it's definitely like we are
Speaker 1: getting closer here.
Speaker 2: So I think that's okay. That's okay, because that's exactly
Speaker 2: how Ruby started. So Ruby started in the nineties, mid nineties,
Speaker 2: and it took it ten years before Rails came to fruition.
Speaker 2: So it wasn't until the mid two thousands that Ruby
Speaker 2: became very viable on the back end, and now the
Speaker 2: front end has a similar story. Opal Ruby started in
Speaker 2: the mid twenty tens, like it might have been twenty twelve,
Speaker 2: was the first first alpha version of it, and it
Speaker 2: took about ten years as well to figure out what
Speaker 2: to do with opal Ruby on the front end before
Speaker 2: we arrive at what we think is like the most
Speaker 2: practical solution. So I agree with you and I think
Speaker 2: that's okay. Like it takes time sometimes to figure out
Speaker 2: how to do things. The best way possible.
Speaker 1: Yeah, totally, And so like I wanted to dig in
Speaker 1: here a little bit because what we're talking about is
Speaker 1: kind of like componentizing like these front end pieces into
Speaker 1: a more modular way that can be reused and encapsulated
Speaker 1: more of the Ruby way and trying to keep it
Speaker 1: to Ruby as much as we can, right without like
Speaker 1: degrading degradating the front end performance too much. And so
Speaker 1: I want to talk about that componentization, like creating these
Speaker 1: web things, right, Like, if I have a form, can
Speaker 1: I make a form component? Is that like straightforward to
Speaker 1: do with the Glimmer DSL. What is your been your
Speaker 1: experience with like encapsulation there?
Speaker 2: Yeah, So to art the Glimmer HTML DSL gives you
Speaker 2: access to using any HTML tag including SVG tags as well.
Speaker 2: So if you want to use a form tag, you
Speaker 2: can use it. It's already supported. Every tag that is
Speaker 2: in HTML is supported by Glimmer right now, a Glimmer
Speaker 2: DSL for web, so you could just use any basic
Speaker 2: HTML tags out of the box now if you want
Speaker 2: to build your own components, it also supports that completely
Speaker 2: right now. So for example, I found and they build
Speaker 2: a name and address form because that's a very common
Speaker 2: form that could be used on multiple pages on the website,
Speaker 2: like for payment, like for shipping, like for many different things.
Speaker 2: You could definitely do that today. In fact, one of
Speaker 2: the samples or multiple of the samples to include a
Speaker 2: name and address form or an address form at least,
Speaker 2: so it basically abstracts or like you mentioned, encapsulates all
Speaker 2: the things related to displaying an address form into a component,
Speaker 2: and it basically will expect you then to provide it
Speaker 2: an address model, so that way, when you work with it,
Speaker 2: you don't even have to worry about working with the
Speaker 2: guy directly. You just work with the address model, and
Speaker 2: when you update the address model, because of bidirectional data binding,
Speaker 2: it will automatically show updates on the form on the screen.
Speaker 2: So it'll save developers a lot of work. Like this
Speaker 2: approach saves developers a lot of work because they don't
Speaker 2: have to If you have components that are very well encapsulated,
Speaker 2: you can just work with their data and their data
Speaker 2: will automatically reflect on the GUI because of data binding.
Speaker 1: Yeah, that's really cool, and I mean I think that's
Speaker 1: been one thing that's caused the divide too, to be honest,
Speaker 1: in that you know, people like to stylize and make
Speaker 1: their own web components with the ACT or whatever framework
Speaker 1: that they you know, that they've chosen and handle all
Speaker 1: their you know, front end interactions and stuff. But then
Speaker 1: you know, I have to request that the back end
Speaker 1: team like help supply that data or new like as
Speaker 1: data changes, Like how do you add and adjust to
Speaker 1: the component without you know, the data being there on
Speaker 1: the back end. And so you have this like dual
Speaker 1: edge coupling. And if we have that coupling anyway, why
Speaker 1: not have it all in the same place. I think
Speaker 1: it makes a lot of sense to me personally. So
Speaker 1: how I'm wondering, like, you know, does this also like
Speaker 1: appease like teams that grow in skies and like have
Speaker 1: devoted front end teams, Like is there still kind of
Speaker 1: that is this like trying to like consolidate the team structure,
Speaker 1: or is it also like supporting the idea of Okay,
Speaker 1: we're gonna have front end people that are going to
Speaker 1: be focusing specifically on styling and adjusting the components, Like
Speaker 1: is it still kind of a straightforward process of like
Speaker 1: HTML CSS kind of ulation for front end styling of
Speaker 1: the components, or is it take more of like I
Speaker 1: need to learn Glimmer DSL, you know, aspect of things.
Speaker 2: Yeah, so one thing to clarify is that, yeah, glimmer
Speaker 2: DSSEL for web in the end generates real JavaScript, real HTML,
Speaker 2: and real CSS, so like when you use it, you
Speaker 2: will generate like standard ahtmail CSS JavaScript. So if people
Speaker 2: have concerns about testing like the fund end user interfaces,
Speaker 2: they can just test them as basic HTML. They don't
Speaker 2: have to even be involved in the Ruby part. If
Speaker 2: people are back end developers that know back end Ruby
Speaker 2: and they use it with rails, now this opens the
Speaker 2: door completely for them to use glimmer on the front end.
Speaker 2: So that actually, in my experience, improves productivity in number
Speaker 2: of ways. Usually it's recommended to do full stack development,
Speaker 2: not back in front end, at least in my company
Speaker 2: we definitely and a few other companies I worked out
Speaker 2: in the past, that's definitely the approach we adopted, because
Speaker 2: then the developer is aware of the full value being
Speaker 2: offered to the customer end to end from the user
Speaker 2: interface all the way down to the database and then back,
Speaker 2: so then they can optimize the code or simplify the
Speaker 2: code as with a better understanding of like the holistic
Speaker 2: view of everything and be able to provide a better
Speaker 2: product customers in general, and also in my experience, results
Speaker 2: in less work and less communication overhead. When there are
Speaker 2: fun end and back end developers, there's communication overhead, there's
Speaker 2: more work about translating things from the back endto the
Speaker 2: front end and vice versa. And if there are multiple
Speaker 2: languages that's even worse then, like there's even more translation
Speaker 2: going on. So this enables now back in developers to
Speaker 2: just do fund work and not worry anymore about that
Speaker 2: a way, it saves companies from actually it cuts down
Speaker 2: the hiring costs because companies that have back end developers
Speaker 2: they don't even need, Like if there's a startup that
Speaker 2: wants to be as efficient as possible, as productive as possible,
Speaker 2: they don't even have to hire fun and developers anymore
Speaker 2: if they have solid back end Ruby developers. So that's
Speaker 2: a very big win. But on the other hand, if
Speaker 2: there are companies that have back in front end developers,
Speaker 2: front end developers would learn this just like learning any
Speaker 2: other fund in library. Because for example, React definitely had
Speaker 2: a very large, like a big learning curve in a
Speaker 2: sense because they had JSX, which was not a normal base.
Speaker 2: It's not a standard technology. JSX is actually not standard HDML,
Speaker 2: not standard CSS, not even standard JavaScript. So it's very weird,
Speaker 2: and like React has a lot of weird things that,
Speaker 2: in my opinion, like waste a lot of productivities to learn,
Speaker 2: Like why are we working low level state when we
Speaker 2: actually have objects oriented programming languages that are way more advanced.
Speaker 2: They have the same idea. So in my mind, React
Speaker 2: reinvents op in a different way and give it a
Speaker 2: different gives it a different name, Like basically object attributes
Speaker 2: are cold states, hoax and react and object observers they
Speaker 2: call them effects and react and that's it. Like React
Speaker 2: is not really it's just reinventing things. It's not really
Speaker 2: as modern and new as people think it is. For
Speaker 2: people that have been software engineering for a long time,
Speaker 2: they could tell that it like React reacts ideas have
Speaker 2: been around since the nineties at least, like the idea
Speaker 2: of components has been around since the nineties, from visual
Speaker 2: Basic for example. So anyways, so in the end, I
Speaker 2: found it more productive to like and reactually have to
Speaker 2: open weird curly braces to mix logic with view concerns.
Speaker 2: So if I want to say if this, do this,
Speaker 2: if that, do that. It's a bit weird opening the
Speaker 2: curly braces. It's very hard to integrate the logic with
Speaker 2: a view. Whereas in Ruby and glimmer Da steltw for Web,
Speaker 2: you are in Ruby already, you're just using a redsl
Speaker 2: You can actually write if in that immediately in the
Speaker 2: same language. And also it's even better than ERB as well,
Speaker 2: because ERB lets you requires that developers open scriptlets to
Speaker 2: mix logic with a view like concerns. Sorry, not the concerns,
Speaker 2: but more it's actually presentation logic. It's not really it
Speaker 2: is view logic. But yeah, to mix it with view
Speaker 2: structure you have to open u scriptlets, which can get
Speaker 2: really annoying after a while, and over a year adds
Speaker 2: up so much that it would actually present a dragon productivity,
Speaker 2: which goes back to that world frog metaphor that I
Speaker 2: spoke of earlier. So in a way, I would say
Speaker 2: JavaScript developers that are worth their salt, that are actually smart,
Speaker 2: solid software engineers should be able to pick up glimmer
Speaker 2: Da stelf for Web in no time and then be
Speaker 2: more productive in it than using JavaScript.
Speaker 1: I see, yeah, I mean that makes a lot of sense.
Speaker 1: Uh looking at more of these examples in this Rails sample,
Speaker 1: you're using like an external code highlighter, which is really cool.
Speaker 1: Uh And it's just like all in Ruby. Yeah, really
Speaker 1: really cool. Uh So I'm curious what is the like
Speaker 1: it is what's the deploy process look like for uh?
Speaker 1: This stuff? Like is it the same as you know,
Speaker 1: any Rails app, any Ruby app? What's that look like?
Speaker 2: Uh so? Uh, I'm using the opal Rails gem, which
Speaker 2: is compliance with the Rails Classic Asset pipeline. H So
Speaker 2: it runs on top of crockets, so it's actually very simple.
Speaker 2: It brings us back to the old simple days of
Speaker 2: coffee script and older JavaScript before we have to start
Speaker 2: using crazy bundlers like Webpack. I mean, in my opinion
Speaker 2: that's a benefit because Webpack, like at my job, maintaining
Speaker 2: Webpack is like wetpack is such a monstrosity with it
Speaker 2: with all its options and configuration settings that like upgrading
Speaker 2: it is a very difficult process. Like we I recently
Speaker 2: upgraded it from an old version to anywhere one and
Speaker 2: it was absolute hell and it took more than a
Speaker 2: month to finish the work. So uh, this just where's
Speaker 2: this just runs on top of sprockets. So meaning you
Speaker 2: just do a rail's asset precompile when you deployed production
Speaker 2: and it generates JavaScript files and that's it. And then
Speaker 2: you put the JavaScript files in a cd N so
Speaker 2: then people download them with instant like download speeds. Uh
Speaker 2: and uh the website will be very like high performance
Speaker 2: as a result of that. And locally on my machine,
Speaker 2: there's no bundler again, there's just ople rails uh the gem.
Speaker 2: So what that means is every time I had a
Speaker 2: web hit a web page, uh, the OPAL code gets
Speaker 2: compiled on the spot and development. So that way as
Speaker 2: I update the code and I refresh the web page,
Speaker 2: it picks up. Then you or changes that said, I
Speaker 2: heard from the Opole people that they are working on
Speaker 2: like a way to integrate Opole with bundlers like wetpack,
Speaker 2: and they might already have I believe they already have
Speaker 2: like proofs of concepts of it or maybe even working versions,
Speaker 2: but I'm personally not interested in using them. In my mind,
Speaker 2: like a big benefit is avoiding wetpack. Is like my
Speaker 2: way of doing things I would say with this is
Speaker 2: to not use a bundler. I would in any third
Speaker 2: party libraries, I would link to their CDNs. That's fast
Speaker 2: enough and good enough. I realized that bundlers give you
Speaker 2: chunking and other features that people will say will give
Speaker 2: you even better performance. But like for most apps that
Speaker 2: are smaller startup rails apps or mid sized apps, just
Speaker 2: what Rails is used for the most I'd rather not
Speaker 2: use a bundler. I'd rather just have things bundled with
Speaker 2: rails assets pre compile on deploy and locally would just
Speaker 2: compile live when I'm doing development.
Speaker 1: Yeah, totally. And thinking more about like the bundle or
Speaker 1: aspect of it, it makes me think of was it
Speaker 1: Rails of assets if you were familiar with that, where
Speaker 1: you Rail's assets was like a basically just a gem
Speaker 1: format where you could pull in node related MPM packages
Speaker 1: into your Reil's asset pipeline, which was to me like
Speaker 1: super great. It didn't require any of the you know,
Speaker 1: JavaScript packaging systems or extra dependencies like that, and it
Speaker 1: worked great and just bundle install and it included all
Speaker 1: of the assets that you needed and handled all that.
Speaker 1: And I do miss that, And so I'm hopeful with
Speaker 1: this kind of push here that we can kind of
Speaker 1: get back to something like that, which makes brings me
Speaker 1: to my next topic, Uh Turbo. What what are your
Speaker 1: feelings on Turbo? And like the HTML over the wire
Speaker 1: aspects of rails.
Speaker 2: So, uh Turbo is nice if I have a very
Speaker 2: simple business app and I need very very few like
Speaker 2: front end uh front end E interactions without writing front
Speaker 2: end code. Uh, I can use Turbo for that, like
Speaker 2: where it would update certain parts of the screen automatically
Speaker 2: based on back end directives from a controller action. So
Speaker 2: I think for simpler apps it works fine. For more
Speaker 2: sophisticated apps, it doesn't do everything. And that's the reason
Speaker 2: why a lot of Rubists nowadays reach for React and
Speaker 2: other JavaScript libraries like svelt and viejss is because they
Speaker 2: they at one point hit a wall or feel like
Speaker 2: it's too complicated to manage Turbo from controllers in the
Speaker 2: back end then to actually just write front end code.
Speaker 2: And I think a big like I think Turbo in
Speaker 2: a way is a bit like written and with the
Speaker 2: approach of being a bit aversive to writing front end
Speaker 2: JavaScript code because JavaScript code is not nice. But if
Speaker 2: we have the front end language that was nice, and
Speaker 2: we do now in twenty twenty four, which is Ruby,
Speaker 2: using Opal or Rosen, then there's no reason for me
Speaker 2: to consider Turbo. In that case, I would rather just
Speaker 2: write front end Ruby code the normal way and like
Speaker 2: following an NBC pattern, and that should be good enough.
Speaker 2: Like I don't feel and I can just make the
Speaker 2: rest API calls. I mean, on my job, people do
Speaker 2: that anyways with React right now they connect React to
Speaker 2: the back end with the rest API calls. So I mean,
Speaker 2: I feel like that's simple enough, and a lot of
Speaker 2: people are comfortable with that model. One thing about Turbo
Speaker 2: is that has a bit of a learning curve and
Speaker 2: because its model is a bit like out of the normal,
Speaker 2: out of the ordinary, the mental model, so people have
Speaker 2: to think a lot about IDs on elements in HTML.
Speaker 2: So in my experience, I feel like writing features in
Speaker 2: Glimmer the Alpha Web is simpler because I'm just writing
Speaker 2: basic Ruby code. I don't have to worry about IDs.
Speaker 2: You can just use variables the normal Ruby way, and
Speaker 2: variables will I defy elements. You can grab elements by
Speaker 2: variable instead of by ID in general, like generally you
Speaker 2: don't have to refer to IDs and elements, so it's
Speaker 2: even it's simpler than JQuery's simpler than my mind, a
Speaker 2: bit than the mental model of Turbo, and it can
Speaker 2: do things that are fully like just front end only
Speaker 2: interactions that don't even talk to the back end. So,
Speaker 2: as far as I know, Turbo is usually augmented by stimulus.
Speaker 2: I find stimulus is code a bit boilerplate ish, and
Speaker 2: because it requires people to write controllers, I find that
Speaker 2: a bit too verbose. Personally, I feel like it's not
Speaker 2: dry enough. It could be drier, but also it's written
Speaker 2: in JavaScript, which is very ugly compared to back end
Speaker 2: Ruby code. Like even even if I'm writing a tiny
Speaker 2: bit of sprinkles in JavaScript, if I can write them
Speaker 2: in Ruby would be even better.
Speaker 1: Yeah, I agree with you. There definitely going and having
Speaker 1: the context switch constantly between the two definitely slows down
Speaker 1: the development for me personally. I don't want to speak
Speaker 1: for everyone, but uh yeah, I mean I feel like
Speaker 1: we've been driving, like we keep talking about this, we
Speaker 1: keep driving toward like a more like view component style,
Speaker 1: like in an applic application development process that is getting closer,
Speaker 1: and this seems to be like crossing that bridge of
Speaker 1: the missing pieces too. Of well, we still need JavaScript.
Speaker 1: JavaScript libraries are still helpful, like how do we use
Speaker 1: them in the context of our application, but not have
Speaker 1: to just use JavaScript to couple our our back ends.
Speaker 2: And now, yeah, one of the issues with previous attempts
Speaker 2: at providing fun end development library for that would use
Speaker 2: Ruby like oprah Ruby for example. For example, there was
Speaker 2: a much older framework called Vault that was a bit
Speaker 2: popular around twenty fifteen or twenty sixteen. Vault was basically
Speaker 2: providing people with a full isomorphic approach to development on
Speaker 2: the web, so that you write the front end with
Speaker 2: Vault using the Ruby and they might have had a DSL,
Speaker 2: and then on the back end they basically have models
Speaker 2: that can establish connections to the back end directly without
Speaker 2: you writing controllers or writing recpis on the back end
Speaker 2: if I remember right. So it was a very innovative approach.
Speaker 2: It had very good ideas. The issue with it was
Speaker 2: that it required it forced people to change their mental
Speaker 2: model for males too much. And that's a problem. If
Speaker 2: somebody wrote to a rails app that is doing very
Speaker 2: good for their business and it's been around for five years,
Speaker 2: it might be too much to ask for them to
Speaker 2: change their entire apps approach right away to something like Vault.
Speaker 2: So Glimmer is aiming to intentionally provide the simplest possible
Speaker 2: thing that you could use to augmentary your rails app
Speaker 2: with something better on the front end, and no more
Speaker 2: than that. So I intentionally just provide a drop in
Speaker 2: replacement for your JavaScript library on the front end, and
Speaker 2: thee nice thing about it is JavaScript funends. Like sorry,
Speaker 2: front end apps are. Every page is its own app,
Speaker 2: So if you have older things built with j Query
Speaker 2: or React in the past, it doesn't matter. You can
Speaker 2: start any new pages with using Glimmer and it's very
Speaker 2: easy to add it and you can get started very quickly.
Speaker 2: My plan behind that is it would expand gradually in
Speaker 2: the future so that more and more pieces can be
Speaker 2: added if people want to optionally. So the second so
Speaker 2: you mentioned that now things are coming together in a
Speaker 2: way because finally, like on the back end we have
Speaker 2: things like flex or view component and on the front
Speaker 2: end there's you know, Glimmer dslf web. My idea is
Speaker 2: to actually extend Glimmer support to the back end as well.
Speaker 2: So eventually you write your glimmer web components on the
Speaker 2: front end and then you I want to support server
Speaker 2: side rendering of them on the back end, so that way,
Speaker 2: on the back end you don't have to use R anymore.
Speaker 2: You drop the RB and replace it with a much
Speaker 2: simpler glimmer DSL, but you would basically it would work
Speaker 2: kind of like view component or flex. Like the back
Speaker 2: end controller actions will just render glimmer components and if
Speaker 2: you render them from the back end on first hit
Speaker 2: of the website, they will, you know, first render the
Speaker 2: HTML and then they will hydrate and add the JavaScript
Speaker 2: clayer on top of that. So there will be a
Speaker 2: bit of work to explore that idea, but that idea
Speaker 2: is on the horizon. Another idea I had in mind
Speaker 2: was to actually replace E R E files with a
Speaker 2: simpler solution called GRB. So GRB would be glimmer RB,
Speaker 2: which is basically files that look like RB, except instead
Speaker 2: of using template style like scriptlet syntax, you would use
Speaker 2: the glimmer DSL directly in them. So that's another idea
Speaker 2: I have. So I have I have a few ideas
Speaker 2: on the horizon to enable people to more and more
Speaker 2: like improve their rails, wave rendering views and componentizing their views.
Speaker 2: And hopefully eventually once I add more and more of
Speaker 2: those ideas, I guess The fourth idea would be to
Speaker 2: do what Vault was doing, which is to have front
Speaker 2: end models act as proxies for back end models. If
Speaker 2: you do that, then rails developers don't even have to
Speaker 2: write controllers anymore. You don't have to worry about so
Speaker 2: you're gonna like I can remove all of the boilerplate
Speaker 2: code of writing controllers out, and then I can remove
Speaker 2: all the boiler plate code of writing JavaScript services out
Speaker 2: like rest services, and that way I can connect JavaScript
Speaker 2: fund and models directly to active record or or back
Speaker 2: end models in Rails, which is kind of like what
Speaker 2: Vault and also Hyperstack, which is another open Rugby library does. Unfortunately,
Speaker 2: both both of them are no longer maintained, or at
Speaker 2: least Hyperstack hasn't had their released in three years. Maybe
Speaker 2: I don't know if it is maintained still, but either way,
Speaker 2: that's so that's I think that's a very important thing
Speaker 2: in software engineering is incremental development, like iterative incremental development,
Speaker 2: and in a way, Glimmer is adopting that approach for
Speaker 2: rolling out its features, where people can start with a
Speaker 2: you know, droping replacement for their job ASCRIPT fundend library
Speaker 2: and then move on to a back end technology like
Speaker 2: either GRB or rendering front end components on the back
Speaker 2: end directly. And finally, it would be like replacing their
Speaker 2: controller layer completely with like a model proxy layer that
Speaker 2: would bypass the whole rest API thing, or it would
Speaker 2: basically automate it so that I don't have to write
Speaker 2: to rest code myself directly. So yeah, these are some
Speaker 2: of the ideas and the pipeline for Glimmer DASELF for Web.
Speaker 1: Yeah, very awesome. I'm looking forward to seeing that come together.
Speaker 1: I'm sure I'm not the only one. So, like, this
Speaker 1: brings me to my like last kind of question I
Speaker 1: guess is like the you know, how, does are there
Speaker 1: any plans to bridge the gap of consolidating the application
Speaker 1: development to allow automatically creating both for web and desktop
Speaker 1: and mobile and x y Z, Like is that desirable
Speaker 1: future or is that better to keep things separate?
Speaker 2: Still, So I explored that idea with my older Glimmer
Speaker 2: Web library. It was called Glimmer DSL for Opal. It
Speaker 2: was just the library that would explore that was exploring
Speaker 2: using Opal to render user interfaces, and the approach of
Speaker 2: that library actually was very different from Glimmer DSL for Web.
Speaker 2: Its approach was actually to hide the HTML and CSS
Speaker 2: completely from developers so that they actually work with a
Speaker 2: GUI mental model that was similar to the desktop. It
Speaker 2: even used the same widget or control names, like you
Speaker 2: could say, tag names that were used for building the
Speaker 2: Eclipse SWT library, so I was trying to match the
Speaker 2: syntax of glimmer dslfware SWT. But that enabled this. Basically
Speaker 2: I could take any desktop library, game or app that
Speaker 2: was built glimmer dsftware SWT and run its code in
Speaker 2: glimmer Ds Software Web without writing HTMLOCSS like I would
Speaker 2: just keep the same exact desktop codes in Ruby and
Speaker 2: it would run the app in the browser. So I
Speaker 2: was able to run Tetris, for example. That way, I
Speaker 2: built it for the desktop and it ran on the
Speaker 2: web with the same exact code, which was pretty impressive,
Speaker 2: but in Mike However, practically, speaking from a like a
Speaker 2: business web development point of view, I don't think it's
Speaker 2: a very practical idea. I think most developers want to
Speaker 2: know about HTML and CSS and they want to do
Speaker 2: things following more the webway, and if I hide HTML
Speaker 2: and CSS from them, I don't think they'd be pleased.
Speaker 2: But also if I were to take the other approach,
Speaker 2: which has used HTMLCSS on the desktop, that causes the
Speaker 2: other like issue, which is like desktop developers writes a
Speaker 2: lot less code because they don't have to mark with HTMLCSS.
Speaker 2: The stop guy libraries are usually simpler than web stuff.
Speaker 2: So so I think it's better to.
Speaker 1: Just keep the two.
Speaker 2: Technologies in a way separate with their dsls because I
Speaker 2: believe web requirements are different from desktop requirements.
Speaker 1: Yeah, that makes sense. I know, having worked with like
Speaker 1: React Native, it is painful even just between like you know,
Speaker 1: separate provider platforms of iOS and Android and having to
Speaker 1: do Windows and Linux and managing that. You know, I
Speaker 1: can't imagine that's helpful to have to do for everything.
Speaker 2: Yeah, this is one of those ideas that sound good
Speaker 2: on paper, but when you start actually following them in practice,
Speaker 2: they're not very practical, Like I know people, Yeah, I
Speaker 2: mean so, yeah, I guess that's my answer.
Speaker 1: Well, this is awesome. I love seeing this work happening,
Speaker 1: and you have so many great examples here that that
Speaker 1: brings me to kind of like, you know, before the
Speaker 1: show we were talking about you know, you're gearing up
Speaker 1: for your Ruby COMF talk and workshop. You know, do
Speaker 1: you want to shed some light on on the workshop
Speaker 1: that you're doing and maybe how people can start to
Speaker 1: get involved in a lot of this Glimmer stuff you're building.
Speaker 2: Yeah. Sure. This year, so I'll be presenting a newer
Speaker 2: version of the same workshop I conducted last year. It
Speaker 2: was a two hour workshop called how to Build Desktop
Speaker 2: Applications in Ruby. In twenty twenty three and twenty twenty four,
Speaker 2: it is going to be how to Build Basic Desktop
Speaker 2: Applications in Ruby. This one is going to be limiting
Speaker 2: the workshop content to the basics of desktop development so
Speaker 2: that it gives people more time to breathe and also
Speaker 2: digest the ideas related to MVC pattern MVP and bidirection
Speaker 2: and UNI directional data binding. So it will give people
Speaker 2: a lot more time to be able to play around
Speaker 2: and learn a desktop version of Glimmer. So the version
Speaker 2: used is going to be the Fukka Ruby Award, the
Speaker 2: one sorry, the one that won that Ruby Award. It
Speaker 2: will be glimmerdself for Libui. This library. Actually, the nice
Speaker 2: thing about it is that you just installed the Ruby
Speaker 2: gem and you're good to go. So I actually you
Speaker 2: include in the workshop description the instructions like I tell
Speaker 2: people just install the Ruby gem and then want a
Speaker 2: sample to make sure it works and you're good to go.
Speaker 2: So I'll be basically using that library as an educational
Speaker 2: library for building very small desktop app so limit of
Speaker 2: the stuff with LIBYUI. What's good about it is that
Speaker 2: it's very good for very simple apps. You can build
Speaker 2: them very quickly, and also it's good for apps that
Speaker 2: are mostly tools or productivity tools or development related tools
Speaker 2: that can help with your day to day work because
Speaker 2: it's a very good library for packaging apps as gems,
Speaker 2: so you can package anything like you can scaffold an
Speaker 2: app with It supports scaffolding features similar to rails, but
Speaker 2: for desktop apps, and then you can package your scaffolded
Speaker 2: app as a gem very quickly, and then you can
Speaker 2: give it to others and people just install the gem
Speaker 2: and use it. So I would recommend this library the
Speaker 2: most for people that want to build productivity tools for
Speaker 2: up day to date work. If you want to pack
Speaker 2: is your app as a Mac app or a Windows app,
Speaker 2: this library does have two options for doing it, and
Speaker 2: it's Windows option works very well. It's Mac option is
Speaker 2: very new. There's a guy that packaged it on the
Speaker 2: Mac just a few months ago and I documented what
Speaker 2: he did. He actually documented what he did in the
Speaker 2: blog post that I linked to. So it does offer
Speaker 2: some packaging options, but they're not the most complete or comprehensive. Today,
Speaker 2: I have other libraries like glimmer dsl FORSWT lets you
Speaker 2: package your apps as real native apps with like an
Speaker 2: ex or MSI on installer on Windows, or DMG file
Speaker 2: or PKG file on Mac, or even wn files on
Speaker 2: Linux or RPM. So that one if people want to
Speaker 2: build a more serious app, I would recommend glimmer dysself
Speaker 2: fors WT. But if they're building a very quick productivity
Speaker 2: app or small app that will show a table that
Speaker 2: is summarizing data from a database, I would recommend glimomer
Speaker 2: dssel for LIBI. Yeah.
Speaker 1: I was looking at they're reading it with all the example.
Speaker 1: It's pretty slick. It has like all of the major
Speaker 1: components that you know you'd want to use build a
Speaker 1: simple desktop m from the first glance. So very cool.
Speaker 2: Yeah. One cool thing that I've been doing is actually
Speaker 2: whenever I add features to say glimmer DSLF FORLIBUI that
Speaker 2: I think are useful, I end up also adding them
Speaker 2: to glimmer DSL for Web like one such a feature
Speaker 2: as component slots. So now if I build, for example,
Speaker 2: and name an address form like I mentioned earlier as
Speaker 2: an example, I can provide ad slots in it, and
Speaker 2: people can contribute tags or like markup inside those slots,
Speaker 2: and it does stop app It would be there would
Speaker 2: be contributing controls. So that way, people can for example,
Speaker 2: add a message at the top of the name and
Speaker 2: address form between the name and the address that can
Speaker 2: inform people of something, or they can add another form
Speaker 2: like a nested form within it or do stuff like that.
Speaker 2: So I mean this this feature is called component slots.
Speaker 2: It's borrowed from the Web Component slots standard. Like on
Speaker 2: the Web and the HTML Web Component Standard, they do
Speaker 2: have the idea of slots, so it's kind of borrowed
Speaker 2: from that. It's also borrowed from that, I think view
Speaker 2: component the library. The rails library has slots as well.
Speaker 2: So anyways, that's something that I ended up adding to
Speaker 2: glimmer yr self for Libui first, and then I added
Speaker 2: it to glimmer dr self for Web and it works
Speaker 2: very well because then it enables any like if you
Speaker 2: take any component, you're not limited by what the people
Speaker 2: who build the component did in it. You can actually
Speaker 2: open it up like it's on. It follows the opened sorry,
Speaker 2: the open closed principle. You can open any like component
Speaker 2: up without touching its code, so it's closed for modification,
Speaker 2: but it's open for extension, and you can add anything
Speaker 2: to that component in the in the slots that are
Speaker 2: designated for the changes for anything to add.
Speaker 1: Yeah, very cool. I'd love to see all the examples here.
Speaker 1: How do you find time for all this?
Speaker 2: Nights and weekends, especially long weekends like Labor day weekend
Speaker 2: or whatever, any long weekends. Yeah, I end up using
Speaker 2: them for this, but it's it's my passion project. And
Speaker 2: also in my opinion, I really really think that current
Speaker 2: front end development and development experience and RAILS is very
Speaker 2: very bad. Like when I every time I receive a
Speaker 2: PR on a React component at work, I'm like, Wow,
Speaker 2: this code is absolutely awful and it's the best code
Speaker 2: they could write. By the way, I'm not felting any
Speaker 2: who ever wrote the code. It's it's the React way,
Speaker 2: but like it reacts code is so absolutely awful. And
Speaker 2: I mean so I dabbled with other approaches, like I
Speaker 2: was going to consider recommending SVELT or view JS network.
Speaker 2: But then that's when I like, that's when I thought
Speaker 2: about Glimmer and Ruby, and I'm like, wow, I could
Speaker 2: even do better than spelt in view, and in my opinion,
Speaker 2: I succeeded at that. So I think part part of
Speaker 2: it is passion, like I'm very passionate about Ruby open
Speaker 2: source projects. The other part of it is also thinking
Speaker 2: seriously about how to improve our development productivity for customers,
Speaker 2: because this is a game changer. If you can save
Speaker 2: six months a year of development work because you're using
Speaker 2: front end Ruby instead of JavaScript, that's an absolute game changer.
Speaker 2: And that code is also going to be more maintainable
Speaker 2: for years to come, so it'll be cheaper to maintain
Speaker 2: for years to come as well. And on top of it,
Speaker 2: like basically it pays for itself. So like like if
Speaker 2: people try to say, give you an excuse of oh,
Speaker 2: I don't have time to check out this library or
Speaker 2: try it out, I'll be like, no, you don't have
Speaker 2: time not to check it out, because right now you're
Speaker 2: spending six months more every year using another library. If
Speaker 2: you spend only two or three weeks learning this library,
Speaker 2: you're going to save like five weeks and a half
Speaker 2: or so, so it's actually paying for its own investment automatically,
Speaker 2: like just by exploring this library. So in my opinion,
Speaker 2: uh so that's another reason why I'm into it, Like
Speaker 2: I believe it's gonna enhance my work experience significantly if
Speaker 2: we adopted in my company right now.
Speaker 1: Yeah, totally, I could see that for sure, And I
Speaker 1: would love to see somebody uh maybe ingesting some of
Speaker 1: these examples to AI to help with you know, get
Speaker 1: adjusting to the DSL, because that's probably one of the
Speaker 1: biggest aspects of learning uh new new frameworks to me personally,
Speaker 1: at least not.
Speaker 2: In Glimmer DSL for Web as much because it intentionally
Speaker 2: honors the HTML, the markup language almost exactly as is.
Speaker 2: So for example, if you want to use an on
Speaker 2: click listener, any any any on click attributes or on
Speaker 2: change or on anything, they're all supported automatically Glimmer, So
Speaker 2: like all your knowledge will be you'll be able to
Speaker 2: transfer it to Glimmer, but following a different way. You
Speaker 2: just have to write the code with less code. Like
Speaker 2: instead of opening and closing every tag, you don't have
Speaker 2: to open and close the tax anymore. Can just put
Speaker 2: the tag name and then open up block with curly
Speaker 2: braces and then close up curly braces and you're done.
Speaker 2: So's it's more dry. Like people who write HTML don't
Speaker 2: write don't write dry code because HTML itself is not dry.
Speaker 2: I mean, that's part of the reason why XML became
Speaker 2: obsolete and people started using JSON because Jason is a
Speaker 2: lot drier than XML. But unfortunately in web view development,
Speaker 2: like people haven't made that transition yet, So this approach
Speaker 2: is like one one key reason for the design of
Speaker 2: glimmer day self for Web being different from glimmer das
Speaker 2: self for Opal was to enable enable people to not
Speaker 2: have much of a learning curve. They can just transfer
Speaker 2: their HTML skills as is. So like any attributes you
Speaker 2: know on any elements are supported by glimmer da self
Speaker 2: for Web, and any listeners are supported and any and
Speaker 2: then all the same tags are supported by their same name.
Speaker 2: It's just with a slightly different syntax that's actually less
Speaker 2: code than HTML.
Speaker 1: That's awesome. Yeah, I'm gonna have to play with this
Speaker 1: around myself because it looks like a lot of fun.
Speaker 1: We're kind of getting to the time here. Is there
Speaker 1: anything else you wanted to share talk about before we
Speaker 1: wind down to PIX.
Speaker 2: I don't think so. I think we covered.
Speaker 1: Yeah, I mean you're you're you're doing it all. It
Speaker 1: seems I'd love to see all of the uh, you know,
Speaker 1: the options that people have even within the glimmer ecosystem.
Speaker 1: It's really uh, you know, please keep keep it up
Speaker 1: because I think you're heading in the right way. So
Speaker 1: let's uh, let's move the pics. Uh do you do
Speaker 1: you have anything or you want me to go first?
Speaker 1: I can give you some time.
Speaker 2: I don't think I have anything, to be honest, I
Speaker 2: think like the topic of this podcast will give people
Speaker 2: a lot of stuff to check out already, So like
Speaker 2: I would recommend checking out, you know, the glimmer of
Speaker 2: DASL for Web GitHub project, run like the online hosted
Speaker 2: sample and play around with it. It has a bunch
Speaker 2: of samples written in Ruby. And then lastly, I would
Speaker 2: recommend obviously for everyone to take out like build a
Speaker 2: Rails like a new Rails app from scratch, and then
Speaker 2: integrate Glimmer DSL for Web into it and then play
Speaker 2: around with it.
Speaker 1: Yeah, totally, that's that's the path I'm gonna take. So well,
Speaker 1: I uh, I don't really have too much to share
Speaker 1: here other than I'm building a robot arm cool it
Speaker 1: by hugging face. It's called little robot, and you can
Speaker 1: train it to do things. It has like it's two arms,
Speaker 1: but it has like a follower arm and uh, you know,
Speaker 1: a leader arm, and so you can lead the other
Speaker 1: one and tell it, show it how to pick up
Speaker 1: things and push buttons. And I hope that one day
Speaker 1: I get it to like type on the keyboard and
Speaker 1: like look at my screen and then just like work
Speaker 1: for me. But it's a lot of fun. I'm just
Speaker 1: to the assembly phase. I completed that and it's been
Speaker 1: it's been a lot of fun. So I'm looking forward to.
Speaker 2: Do you control the leader arm directly or do you
Speaker 2: give it voice commands or or does it follow your
Speaker 2: arm using a camera with AI like AI vision.
Speaker 1: So this this particular one, they have like a couple
Speaker 1: of different versions of the arms, but this one is
Speaker 1: they have like you basically have like two of the
Speaker 1: same kind of arm, and you can move one of
Speaker 1: them that moves the other in the same ways, so
Speaker 1: mirrors it. They call it tele operation. But they have
Speaker 1: like you know, you can have multiple robot arms, so
Speaker 1: like you can have multiple leaders, multiple followers, and so, uh,
Speaker 1: there is a camera aspect that lets you train and
Speaker 1: learn kind of what is happening that way, and so
Speaker 1: I think maybe in the future it will get to
Speaker 1: the point where you could just use your own arms
Speaker 1: and hands. But I think right now it's just like
Speaker 1: because the dexterity is not there yet, it's just two
Speaker 1: arms and you train one with the other kind of thing.
Speaker 2: So, what are some applications of this robots arm? Like
Speaker 2: what did you use it for that you think could.
Speaker 1: Be so right away, I had a bunch of screws
Speaker 1: that were all different sizes that came in the same package,
Speaker 1: and I want to just sort it rather than me
Speaker 1: sort that the screws, So like that will probably be
Speaker 1: my first one because it's like they're tiny screws and
Speaker 1: they're hard to sort, and like that should be something
Speaker 1: easy or not easy, but like straightforward to train the
Speaker 1: arm to do. But their examples that they have are
Speaker 1: like legos sorting right, finding the right colors, Like I
Speaker 1: think they had one example where they're you know, pushing
Speaker 1: buttons on something else. So I don't really know what
Speaker 1: I'm gonna do with it yet. It's mostly just fun
Speaker 1: to explore all of this real world AI aspect stuff,
Speaker 1: so definitely. Yeah, so check that out if you're interested.
Speaker 1: La Rollebot. Well, it's been awesome talking to Andy. I
Speaker 1: appreciate you coming on again and all the work you're
Speaker 1: doing in the space because you know, we need it
Speaker 1: and I love to do more ruby than anything else,
Speaker 1: so I appreciate it. And yeah, if people want to
Speaker 1: reach out to you or find you on the internet,
Speaker 1: how do they do that.
Speaker 2: They can find me on LinkedIn. I'm just Andy Malley
Speaker 2: on LinkedIn, or I mean I have a Twitter It's
Speaker 2: called Andy Optava at Andy O B T, I V
Speaker 2: A and what else. And then if they need to
Speaker 2: reach out to me about Glimmer directly, if they visit
Speaker 2: the giitub project, there's a getter chatlink, so they can
Speaker 2: click on the getter chatlink and that would take them
Speaker 2: to a chat room that is all about Blimmer.
Speaker 1: Awesome. Well, thanks again for coming on and thank you
Speaker 1: for listening everybody. Yeah, and you know, until next time,
Speaker 1: more Ruby on the way.