Hey, Welcome back to another Ruby Dev Summit interview. I'm here with Andy
Mala. I'm always worried that I'm saying your name wrong. I'll just admit
Mali Male Andrew or Andy is the He won the Fukuoka Ruby Award in twenty
twenty two for the Glimmer desktop UI. There was an official name, but
I can't keep it straight in my head, so I apologize for O libui.
Awesome. Yep. And then you have a master's degree from in software
engineering from De Paul University. And yeah, anything else that I missed that's
important. I've spoken at Ruby KMF three times so far, twenty eight,
twenty twenty two, and twenty twenty three. I've spoken at rails conv twice,
twenty twelve and twenty fourteen. Awesome. Well, I'm gonna dive us
right in, and anything that you've spoken about at those conferences it's into this
question. I'm happy to hear it or any other ideas you have. But
I've been asking everybody what is the future of Ruby? Yeah? Most certainly
my presentations at Ruby KOMF were about my open source project, Glimmer, and
in twenty twenty three I gave a workshop on how to build desktop applications with
Glimmer DSL FORLIBUI. So I certainly see Ruby moving more into the Dusktop in
the future and not just being a web only language. So we can,
you know, build a lot of tooling and Ruby. Like I've built my
own ID. I have an ID called Gladiator that I've built completely with Glimmer.
Oh wow. I've also I know a Japanese developer that built his own
internet radio app and I use it every day to listen to jazz music.
I really like it, and it was also built in Glimmer. It's kind
of like a Ruby version of iTunes in a way. And yeah, so
a lot of so we can build tooling and Ruby. We could build like
any you know, like media tools kind of like for playing music, play
simple play sorry, build simple games kind of like Tetris or simple board games.
So yeah, there's a lot of future for Ruby in the on the
Dusktop. I would say, I think it took a while for Ruby to
get back to the dusktop because Shoes stopped getting maintained about seven years ago,
maybe eight years ago. So fortunately I had time to maintain glimmer right after
that. And I've been maintaining it very actively for the last maybe six years
or five years, a little like about a year after Shoes dropped out.
So yes, so I do see a future for Ruby on the dustop.
Yeah, I remember Shoes did. Did the support for it drop out?
When? Why the lucky stuff kind of disappeared? That was the first dropout,
which happened in the mid two thousands, and that's what prompted me to
create Glimmer back in two thousand and seven, the very original version. So
originally it used to run in Ja Ruby and it was using the SWT toolkit.
Eventually I decided that the idea is good enough, like if using a
Ruby DSL that I can expand it to all other toolkits. So now it
supports tk GTK, Java FX, swing FX, Ruby wx widgets. So
yeah, it supports every single toolkit that is available in Ruby today, about
seven of them. So I guess in practical terms, does that mean that
I can write say, macapps and Windows apps and maybe Linux apps. Yes.
All the Glimmer dsls for desktop development are platform cross platform library okay,
supporting yes, Mac, Windows and Linux. The SWT Glimmer library which runs
in Ja. Ruby can also let you package your app as a native executable
on those platforms. So I can create a DMG aisle on Mac, or
an e x E or m s I on Windows, or a Debian file
or RPM on Linux. So that way, when I package the app and
I give it to somebody to install, they don't have to install Ruby,
they don't have to install j Ruby, they don't have to install Java.
Everything is included. That's awesome. That is so awesome. So so yeah,
So, I mean, I definitely see Ruby going more into the desktop.
And in my opinion, I think it's a shame that nowadays a lot
of Rubis or people that claim to be Rubis, are using id s and
code editors not built in Ruby. I mean, some of them work at
very big, prestigious companies, uh, and they claim to be you know,
Ruby experts, and yet they don't build their own ID or or editor
and Ruby. They use an inferior like they use vs code, which is
built in JavaScript, which is an inferior language, a very inferior language in
fact, And uh, it's a shame because they could have spent time contributing
to the Ruby ecosystem instead. And like the productivity of using a Ruby DSL
is way higher in my experience than using something like HTML CSS with JavaScript.
So I do, I mean, I do call like bullshit a bit on
some of the people that without using Ruby tools or tools built in Ruby,
like desktop tools built. But I think that that is at the same time,
that's a great opportunity to go into that in the future. I mean,
I did my best to put my money where my mouth is and build
my own board editor with Glimmer and Ruby. So I think that's why I
see a great future in it. I'm just a very I mean, I
would say I'm not an ide building experts. I just built my own as
a first experience and it kind of worked for me. But I would I
would hope that, like sorry, like I would look forward to what experts
could do then with Ruby start development to help build, to help build better
Ruby tooling. Yeah, I think. I think. As I've talked to
a whole bunch of different people within the Ruby community for this summit, we've
seen some expansion into other areas. One that comes to mind is Dragon Ruby
right where it's mostly focused on game development, but you can deploy your games
to pretty much any platform, Yes, are there right. That's another part
of my prediction for Ruby. Uh. In the future, it's going more
into gaming and definitely and Ruby seems like a great option right now because from
what I've seen in demos like at Ruby coff twenty twenty two, it has
great performance. Yeah, but there are other options as well like Ruby two
D and go through UH. It also can build very simple games in Glimmer,
So I definitely see Ruby getting more into gaming in the future as well.
Right on the flip side of that, you know, where we've talked
a little bit about Dragon, Ruby was mostly mobile focused initially and then kind
of spread to these other platforms for gaming. Do you see something like Glimmer
moving more toward mobile where you know, maybe I'm building my business app for
the desktop and then later I have the option to build it for the iPhone
or Android or something like that. It's not a game. Yeah, That's
certainly a third area that I think Ruby will have a future in as well
as mobile development. I definitely think Ruby Motion Story, which was built by
the creator of Dragon, Ruby, is a good option to get people started
and building cross platform apps on mobile, so meaning apps that run on iOS
and Android. I've experimented with it a little bit, and I do want
to eventually have a glimmer DSL to simplify development with it. So I did
look into the idea a little bit, but I got pulled into other projects,
but I want to get back into it eventually. I think even without
Glimmer like, ruby Motion does provide an interesting option for cross platform mobile development
in Ruby. Yeah, I need to talk to a mirror about that,
because he acquired ruby Motion and then put all the focus into Dragon Ruby and
I'm wondering. Yeah, now that you mention it, if yeah, ruby
motion is still an option for the Hey, I'm not building a video game
app. I'm building a whatever mobile app. Yeah, last that I checked,
Ruby Motion is still functional and it works, and there are people that
are quite pleased with it. However, one thing that it's lagging behind in
right now is support for the latest Ruby versions. So Dragon Ruby, for
example, by contracts like you said, like they're very active into supporting it.
So it actually already supports Ruby three point two, if I'm not mistaken,
whereas I believe Ruby Motion might be still stuck at Ruby two point zero
or something like that. So that is definitely something that I I'd like to
see them improve upon. But at the same time that like that, that
also makes it an opportunity for Ruby expanding into mobile development in the future.
Yep. Absolutely. Otherwise, the fourth area that I was thinking about is
basically web development in the front end. So Ruby in the front end was
something that Matt's mentioned in his keynote speech at Ruby Comp twenty twenty two,
and he said that given that we have options like Ruby wasn't we should be
able to now run a real Ruby in the browser and do real full like
full front end developments in Ruby. So that means we can have isomorphic,
isomorphic applications built with Ruby on the back end with rails and Ruby on the
front end with rubym or another option like opal ruby. So opal ruby usually
produces like Ruby wasim will compile the entirety of Ruby, whereas opah Ruby is
more like a transpiler to job us will produce much smaller downloadables. So in
my opinion, Opal ruby is the more convenient option for using Ruby in the
front end if a company does not want to have long like big downloadables like
it's only in kilobytes in open Ruby, whereas in was'm it's in megabytes,
so I think. But both of the good news is both of them are
options on the table nowadays, so I definitely see what'll be expanding more into
front end development and also becoming like enabling isomorphic application fragments, which means I
can reuse the same Ruby logic that's in the back end for some business rules
on the front end as well, so that way I don't have to re
implement the order tax calculation algorithm on the front end again in JavaScript, if
I want to calculate it in the clients, I can just reuse the exact
same code from the back end in the front end. I've actually experimented without
myself and got that working. In fact, recently I spent the holidays like
creating a new Glimmer library to support development on the web with open Ruby using
Glimmer DSL, and I was able to have it. Basically. The nice
thing about it is you can build HTML using a Ruby DSL, which means
I don't need ERB, I don't need GSX, I don't need to mix
multiple languages anymore. We can step a level higher and abstraction and just have
one language that handles both structure and logic, so that way I can add
if statements or each iterator into the exact same code that is building the HTML
GUI, so then the code becomes a lot lighter, and also it enables
me to then use like very advanced object oriented techniques for Ruby to do real
MBC and MVP development. And the new Glimmer DSL for Web project is basically
the newest one. It started in twenty twenty three and it got finished for
a first beta version just a few weeks ago, and it basically enables also
the usage of all the desktop data binding features of Glimmer on the web,
and I've played around with using it a bit for building samples, and I
was shocked by how productive it is compared to something that React. I felt
like I was at least double as productive as I am with React, which
I use in my current company. So we've been exploring switching React with Glimmer
DSL for Web recently and we're probably going to do a proof of concept of
that and implement it soon. So I definitely see a future for Ruby on
the web development front end as well. Right and just if people are more
interested in either Ruby WISM or OPAL, there are interviews done with Ellie Esquito
who does OPAL and with Yah with with Elias a lot about I hit him
up if you will ask him questions about YEP. I also talked to you
to Psycho, who's the Ruby cor committer for Ruby WASM. So yeah,
if you want to if you want to know more, there's more. Yeah,
And and I love the ideas of getting Ruby on all of these different
platforms. It I mean that I don't know it. I remember back in
the day when basically your good options for a lot of this development was you
would do Cotland development or Java development for Android, and then in anything that
ran the Android system in the back end, so things like firestick TVs and
stuff like that. Or you'd use Swift or Objective C to do your Apple
stuff and that's so that your mobile phones and your Apple TV and then you
know, on and on and on, and then JavaScript kind of broke into
those and it was nice because then it was like, Okay, well this
is a language, it's a little bit more familiar, and I can mostly
do the same thing and have it work in multiple places. But the thing
is is like, I don't know. I've written a couple of react native
apps. I've written a couple of other apps with different JavaScript options and they're
just not my favorite tools to use. And so yeah, as I imagine,
Okay, well, hey I can do this in Ruby, and I
can be hyper productive and I can get what I want and it's going to
be performed enough for people to use. That gets me really excited that that's
what fires me up. And so you know the things that you're talking about,
it's like, yeah, well, if those are all the case,
then the sky's kind of the limit. Yeah, definitely. The only area
that I left out other than desktop, mobile, web and gaming is AI.
So I actually I'm a co organizer of the trall or it's called the
Montreal RB Ruby meet up in Montreal, which is a meetup for like basically
giving software engineering talks using Ruby or Ruby on rails, but people will usually
cover different areas of development like desktop development, web development. And the last
two months we had two AI talks that were very interesting. Both of them
involved building large language models, and so one of them was given by let
me see the name of the guy. His name was let me see,
So I mean the library is called lang chain, and that was the library
he presented. His name is Andre Bondarev. He's based out of New or
So, Yeah, he gave it an interesting talk about how do you leverage
Ruby more for AI and machine learning development. And then the other guy was
called John Sebastian Boulanea, and he gave a talk called building an AI Medical
Scribe and Ruby, and that one was very interesting because basically it was like
an AI scribe that would accompany physicians by listening on the microphone while they're talking
to their patients, and it would basically listen to everything they discuss and then
it would summarize the conversations into the most useful pieces of summary information, which
then the physicians can later use to save time and avoid having to read the
entire transcript, so it saves them, it would save them hours of work
basically. That so basically both of those talks were about using Ruby for AI.
So that's definitely another area that Ruby could break more into in the future.
Yeah, we've had Andre on the podcasts. I don't know the the
other guy that you mentioned, but we did talk to Alex Rudahl who's been
working with the open ai and written the open Ai gem and yeah, it's
it's fascinating to see where some of this stuff goes. Now, lang Chain
itself is written in Python, but the Ruby libraries and the Ruby bindings,
from what I understand, are excellent. And I know that Valentino Stole,
who's my co host on Ruby Roakes, has also done a bunch of stuff
with that. And yeah, as the tools get better, I mean,
there's there's no reason why. Hey, you know what, there's this awesome
tool out there. It's kind of like using postgress, which is also not
written in Ruby, right, but we connect to it because it does the
work on the back end we need. Yeah, you know, there's no
reason why we can't write these apps in Ruby and you know, surface some
kind of useful AI to them in rails or something else and take that to
the next level. Super exciting. I'm also talking to Alex incidentally about doing
an AI challenge and it'll probably be the middle of March. Is what we're
looking at, and leverage some of the open AI stuff. But yeah,
it might be interesting to talk to somebody and see about doing something with a
lang chain or something like that where it then is not using open Aiyes,
models, you know, large language models, et cetera. And their imaging
models, but actually building your own would be really interesting, and maybe Andre's
the right person to go to for that mm hm. But so it's it's
cool stuff and it's it's so powerful as far as like the different options you
have then to give a better experience to your users, which I think is
what we all want. It's we want to solve a problem that people have
in a way that really fits with what they need. Yeah, exactly.
I mean there there is a place for other programming languages like C plus plus,
Swift, c Sharp, see and Java. Like sometimes there are needs
to optimize algorithms with types, and for those cases I might use a different
linuage from Ruby. But at the same time, if I'm building like highly
uh, I would say abstract things that can benefit from object oriented and DSL
sorry object oriented programming and dsl's then Ruby is definitely an excellent filelnce for it.
And I personally still think Ruby in my opinion, Ruby could do anything
that Python or JavaScript could do, but better or even Pearl. So in
my mind, anything that has been available in JavaScript, Python and Pearl should
be we could we could use Ruby for it instead. Going forward, Yep,
absolutely are there other things coming down the pipe with Ruby that you're excited
about or want to talk about. Well, I mean, yesterday somebody hit
me up about my new project, Glimmer DSL for a web and he said
that he likes the front end a development aspect of it a lot, that
he was curious about how to integrate it with back end developers from rails,
and he asked need to expand it so that it would offer an alternative to
RB on the back end as well, using Glimmers Gloomer DSL. So the
interesting thing that him and I discussed yesterday that I'm still exploring is basically you
could have the same exact components on the front end and back end, so
you would develop a component once and it could either be server side rendering for
it when the page first renders or it can later be rendered after the Patient's
interesting and the interesting part is if it included any JavaScript logic, and like
if we're using Opal, Ruby or WASM, it wouldn't be JavaScript. But
either way, if it has a listeners or data bindings, they would not
get hydrated and activated till after the page is rendered, So there would need
to be some logic that would you know, if I'm running on the front
end, it would attach the listeners right away. If I'm running on the
back end, the event listeners are attached after rendering the page. So that's
something I'm researching right now, is how to use like how to build isomorphic
applications or DSL for both the back end and the front end. Yeah,
and if you're looking for a model that does a lot less of the how
do I put it the big upfront heavy duty hydration like react or Angular does.
Quick has a really interesting model of doing that where they use web sockets
to effectively lazy load in and then eager load in stuff as it goes.
Yeah, that web sockets is definitely are definitely on the agenda of things to
explore as well to figure out how I can make the life of rail software
engineers easier or like sorry, more like more productive whenever they use web sockets
as well. Yeah, and there's so much exciting stuff coming in rails,
you know, not to kind of steal the conversation and what you're talking about
here with the future of Ruby, but yeah, I think there are going
to be a lot of good options for that. I think they also use
web workers which is something that EHH says he wants to make first class in
RAILS. Yes, that is another thing that I'd like to explore eventually in
the future. So rails offers the new you know, hot Wire and Turbo
technologies, which are very interesting because they decrease the need for writing JavaScript manually
for a lot of buses, especially cases that are just doing straight AJAX and
then you know, putting whatever HTML where received from the server into an element.
So there are other alternatives that are doing something similar, like htm X,
which lets you to any sort of like element replacement with AJAX calls by
using HTML attributes. So both options are interesting in my opinion. They're orthogonal
to a library like Glimmer. Glimmer is just providing a way of writing client
side code uh in instead of JavaScript, and it would be interesting to combine
solutions. So eventually I do want to spend a bit of time to looking
into how to better integrate with Turbo, So I definitely find that interesting as
well. For sure about the future. Yeah, we had Carson Gross on
JavaScript Jabber last year, so if you're looking for more info on HTMX,
yeah, we talked to them at length about how it works so awesome.
Yeah. Yeah, I've been looking at it a bit recently because it is
definitely orthogonal and it could be combined with Glimmer, except instead of adding the
HTML attributes in real HTML, we can just add them in Ruby instead using
the Glimmer DSL. So, because the Glimmer DSL is simply HTML CSS,
there's nothing, there's nothing more to it. It's just the standard HTML CSS,
but you're using it from a better language that allows you to be able
to write logic and structure in one language instead of having to, you know,
use ERB and Ruby or JSX and JavaScript. We don't have that separation
anymore. It's not needed, so we can be a lot more productive.
That's cool. I'll have to check that out. Yeah, so I mean
that that is one interesting thing on the web that I I'm looking into,
is, you know, more improvements to Glimmer DSL for Web, like being
able to write components that run on both back and the front end. As
far as desktop development, recently, I added a library for rendering charts and
graphs and currently supports a line graph and a bar chart. And it's been
asked of me by somebody who's building a real application that has bars, sorry,
that has graphs and charts using Glimmer DSL for Libyui. So I've actually
helped that person build that application. Once it's completely finished, it'll probably get
announced on my blog. But as part of that project, we extracted another
library called Glimmer Libui graphs and charts and nice supports two graphs right now,
and I'm working on adding a bubble chart soon. The good news about this
is it will open the floodgase for people doing more data science and Ruby,
including graphic and charting as opposed to having by fun. So that's stuff for
something exciting as well. And another thing I'm working on is improving the support
for a few components and Glimmer desktop libraries so that they support slots just like
they do on the web. So I'm for working on that as well.
That's awesome, and I, like I said before, I mean, I
love the fact that we're getting into a place where oh I need this other
kind of app, where I need to target this other kind of platform,
and hey, look we've got great options for you know, for doing this.
So yeah, yeah, that's super cool. You you mentioned Montreal RB.
Are you seeing what are you seeing in the meetup space. So we
got the last two talks where AI talks. Like I mentioned already before that,
we had to talk about how to do payments and Ruby on Ruby on
rails, any payment solutions like Stripe or other payment gageways like repay or Zoom
rails or there are many many payment gateways out there. So it's just a
general talk that gave also information about like the business of payment and not just
the development software development of payment. Before that, I had a talk on
Rail's few components, and before that I had a talk on Microsoft Coyota,
which allows you to be able to build, sorry not build, generate any
Ruby SDKs for rest APIs automatically. So that way, if somebody using the
open API spec, so you know, for example, I get the open
API spec for uh, let's just say integrating with Azure storage services, I
can Let's just suppose their their library is going out of dates or they haven't
updated in a while. What I could do is actually I could just use
Karyota and it would generate and SDK automatically from their open API spec. I
don't even have to use the library anymore. And the good thing about it
is. It can allow us to then add things like repeating like sorry,
like things related related to software reliability like repeating calls, recovering from exceptions,
reach wise, et cetera. So it's a it's a it's a very interesting
library that actually GitHub officially adopted recently in an announcement as the new way of
them building SDKs for their APIs. So they're not going to be maintaining their
own custom ap SDKs anymore. From what I read in the announcement, They're
going to be using Microsoft Coyota. So that's another interesting technology that got covered
at Montreal ARB recently. Very cool. That sounds really handy. So they
just generate the swagger dots and they're off to the races. Yep. Yeah.
Pretty much before that, we had a Montreal RB talk about how to
build command line tools in Ruby that was interesting, and somebody also gave a
talk on optimizing mathematical algorithms in Ruby that was interesting as well. Very cool.
Are there places where people can find these talks or are they? Yeah?
There? So, I mean, we we announce our talks on meetup
dot com. We just have a meetup group, So if you search for
Montreal dot RB on meetup dot com you'll find us. And actually there's also
a YouTube channel. It's called at Montreal dash RB. If you go to
that channel at Montreal dash ar, it'll give you the all the talks recorded.
So we try to record every single talk unless the speaker doesn't want want
to. So we have more than ten talks on that channel. Awesome.
We re rebooted the group after the COVID lockdowns about two years ago and that
that and then that was when we started posting talks in one channel on YouTube.
So yeah, we have about we have over ten videos on it.
Nice. Yeah, that's we've been trying to revive the one here in Salt
Lake and it just it's been kind of a thing. So yeah, So
we definitely had to start small and keep doing it for a while, even
if people were coming as much, Like at first, not many people are
coming obviously, some people were afraid of COVID still and didn't want to go
out as much. We didn't care. We just kept hosting it over and
over and over and then it kept growing and growing, and like it's so
right now it's a lot like we're filling the room every time. Almost in
the last three times, so it definitely helped you just be persistent. Yeah,
I think that's what it's going to take. There was some idea around
not holding it at a company's space, but that eliminates like ninety percent of
the spaces that are really available to us, And so I think some of
the co working spaces might be willing to let us use like their you know,
their presentation area or their conference room every once in a while. But
if we don't have any people who are trying to help organize it that are
members that the co working space, it gets a little complicated too. So
I'm really thinking I might just reach out to some of the companies here in
Utah and just say, hey, do you have a space where we can
hold the meet up and do you have an employee that will let us in,
and are you willing to buy pizza or whatever. I wonder if some
bars can also allow you to the talk, like the bars that have a
stage for a band. I wonder if, like if you could project a
screen there instead. But yeah, we definitely so for us, we have
we've been hosting the talks between two companies, one of them is my company,
Lexop and other companies called Potlock. Both of them are based in Montreal
and their technology companies that use to Ruby on mails development. So we've been
splitting the hosting locations between two companies and that definitely works for us. Yeah,
so the way that our geography is set up, they're kind of three
ish more or less business hubs. There's a lot of stuff that happens in
Utah County, which is where I live. I live just on the north
end almost in Salt Lake County, and most of the business hub around here
is right near me, right, So it's almost in salt Lake County,
and there are a couple of rather like arch companies that have offices there,
and so we could definitely get away with it. There are some that are
kind of in the South Valley in salt Lake County, and then they are
a bunch downtown Salt Lake, and then they're a handful in Davis County,
which is north of Salt Lake, you know, all along the I fifteen
corridor. And so that could be interesting, right, just finding those spaces
where hey, can we post a meet up at your office? And some
of them like plural sites office is up in Davis County and they might be
willing to host us even though they don't use Ruby on rails, they do
have some Ruby content in their subscription and might be willing to host us just
out of the kindness of Hey, if people like us, they might sign
up for a subscription. So I don't know, but yeah, I think
it'd be worth reaching out and trying to pull something like that together. And
like I said, also, there are a few of these companies that I
know people at that I could just say, hey, can you, you
know, ask around the office and see if they'll let you do it.
So anyway, we kind of got a little off topic there, but it's
all good. I think the meetup scene is kind of coming back. We're
definitely seeing more conferences. Are there other things that you're seeing up and coming
in the Ruby community that you wanted to go over? I'm not sure,
I mean, but I definitely feel like Ruby is still a highly effective language.
And yeah, I do notice something actually more recently, I noticed that
a lot of people that have left Ruby for other overhype technologies are returning to
it now. That's what's interesting. Like twenty twenty four or even the end
of twenty twenty three, a lot of people that have left Ruby for Ilixur
or Rost for whatever other languages are all of the sudden returning and being like
Ruby on rails is way simpler than anything else noticed that recently, and I
agree with it. So are there reasons that you're seeing for that or like
anything in particular? I mean, the only reason I can think of is
waking up of the hype the hype spell. I personally, I'm a very
very like I try to be very realistic and practical about how I think about
software. I think about software from a software engineering like pros and cons point
of view. I never think of it from the point of view of,
oh, this is cool, this is fun, this is something used at
a large company x y Z like Facebook. I never think that way.
I always think, you know, you know the pros, what are the
cons? Is it making out life better or worse? Development more cheaper or
more expensive, more productive, et cetera. So I tend to guard myself
against falling for hype spells to begin with, like I try to, you
know when Like so, I think some people might have made the mistake of
falling for hype a bit and then they woke up from it, and then
they realized, like, because I've heard of people that used Elixir for a
while or some other technology it might have been JavaScript, and then they came
back to Rails and then they're like, wow, Rails is amazing, like
it it feels so productive by comparison, it's so lightweight. So I think
it's just people rediscovering that. Yeah, I think there's something to that.
I think also down to some of the points you're making about some of the
stronger points of Ruby or Rails and then people, yeah, recognizing that the
other technology is not giving them what they want. So I know a lot
of people that yeah, they went over to Alixer or to React for different
reasons, right, and some of the promise was there, right, which
is why they moved over because they fiddled with it, and yeah, it
kind of delivered what it said it did. But as those technologies of mature,
Yeah, they come to realize that a Ruby's becoming more performant. It's
you know, Rails is delivering on more and more of the promise and you
know, coming back to I feel like Rails is coming back to its roots,
which is funny because DH has always been the guy driving it. But
coming back to its roots of hey, look, we're going to give you
something that just you can build something just awesome, which is kind of the
focus of Rails Composer, which is a project I'm working on. But yeah,
you boil it down to those things, and then yeah, people start
realizing, hey, this is what I want to make what technology, you
know, and yeah, Elixer adds this level of complexity or you know,
it's not as nice as Rails has been to do some of this stuff or
things like that. Yeah, I have been following that same exact vision with
Glimmer libraries, like I try to give people a way to build the Dusktop
up in ten minutes if they need to, right, like a very simple
MVP in ten minutes at least most sorry, and then maybe they can even
finish the full app in like an hour or a few hours. And I've
definitely been trying to emulate what the HH has done in Rails, Right.
I think that's a big selling point for sure for Ruby. I do agree
about that, yep. Yeah, I mean it's the same idea behind Rails
Composer, where it's there are a whole bunch of things you're going to need
for your app, user management, permissions management, payment management, you know,
stuff like that, and so hey, pull our pieces in and then
work on the thing that you actually care about, which is my customers need
something that helps them do whatever it is that your app does, right,
so you know, yeah, you get all the boilerplate, all the main
stuff out of the way. And for me, the SaaS has a certain
level of boilerplate to it, so you get that all out of the way,
so you can live in your zone of genius. And what I find
is that, yeah, a lot of these technologies, especially React, in
my opinion, they they've added so many things to it and pushed it in
a direction to where you have to be a master of many things in order
to get what you want out of it, Whereas in Rails, if you
want to boil it down to just the basic NBC framework, you can get
away with that and build a simple app really fast. Yeah, I mean
you can still as caffold the full app in one command, which is awesome.
Yep, more or less. So yeah, all right, Well we're
almost to our forty five minutes. If people want to connect with you or
find out more about Glimmer or any of the other things, we've talked about
where do they find you online? They probably find me on GitHub Andy Octiva
is my handle, or they could find me on my blog, which is
Andy Maale dot blogspot dot com. And I'll make sure to send you the
links so that you can include them somewhere that people can clear if they want.
Yeah, well, we'll have show notes for the interviews, so yeah,
definitely. And yeah, I mentioned a few of the other people that
we've interviewed. I think I'm gonna reach out to Andrea, even though I
already talked to Alex and see if we can get him on for an interview
as well. And then, yeah, thanks, thanks for joining us,
folks, and until next time, Max out