Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653

I'm going to present it for the fourth time this year.

like build gooy's with it on the desktop. So I checked out what are my options at the time that were built by other people, And I saw Shoes and I saw TK and Ruby. TK did not have a DSL. It was like writing code for it was very ugly. It felt like I'm writing Java code, so I didn't like working with it. Shoes was very nice, but unfortunately it was a bit not very well maintained and it

had bugs and it would crash randomly. So I built Glimmer originally as a Ruby layer on top of the Eclipse SWT library, which is used in the Eclipse ID because that's what I used at work at the time. So I built it using j Ruby because I had to run on top of the JVM. Eventually, the idea proved itself to be interesting and useful enough to a point where I ended up then covering all the available

gooey toolkits and Ruby with Glimmer. So I have a Glimmer DSL for TK now Glimmer DSL for GTK for FX Ruby meaning Fox Toolkit for Libyu I started about is a library that's a bit recent that was one of the more recent Glimmers that were built, and the most recent one is w wx wx Widgets has been covered by Glimmer recently because somebody built a new binding called w x ruby that replaced the old wx Ruby just a couple of years ago, so I ended up

also covering it with the Glimmer DSL. So but to get back to that question, what happened is eventually I ended up last year coming up with the idea of building Glimmer DSL for web which is a web version of Glimmer that uses all the innovations for data binding that were used in desktop development, but building web user interfaces.

standards like on macOS or Windows. So it's a lot faster to build a desktop app with a desktop guy toolkit than to build it with HTML and CSS. I think. So Electron runs on top of a browser, and so the good news is that browsers are a desktop app. Everybody who is doing web development uses desktop apps because the browser is a desktop application, But Electron is not real desktop development like a cross platform. We toolkits are actually a lot simpler to use than Electron.

then you have to do a lot more work. So you can actually do things that are the same things that you could do with HTML and CSS, but in dusktop they could Like basically, you draw on a canvas, and you can do anything with a canvas. But in general, it's discouraged in desktop development unless you have an app that's actually drawing diagrams or doing things like visual games,

two D games or stuff like that. In general, if you don't have diagrams or games or anything that's very like custom it's better to stick to the you know, like using standard do we too get controls like text, field, list, combo box, et cetera.

It's only for the Mac. So that part overlaps a bit with glimmer, but I would not use it. I would rather use Glimmer because when you build a Glimmer app. Once it runs on all platforms, then if you're using one of the native guy toolkits like LIBYUI, wx widgets or SWT, your apps will look native on every platform as well. So uh, but the mobile aspect of Ruby Motion is very cool. Actually, I do want to explore the idea of building a Glimmer DSL for Ruby Motion Mobile.

That would be very cool because then I can write the app and Ruby with a nice DSL and it would run on mac os and Android or sorry not macro iOS and Android. So that's something up that that would be interesting to explore. But otherwise Dragon Ruby is more optimized for gaming. Uh And yeah Glimmer. Glimmer allows you to build games, but it's not optimized for games. It's not about like offering you the best performance for

games or anything like that. Although it's libraries are pretty optimized for performance, like they do run fast, but it's the library itself is not tailored toward towards gaming. I would still recommend if people want to build complex games, Dragon rubies definite take the Way to Go or something else like Ruby two D or there are a few other libraries for gaming as well.

in this direction? You want to describe maybe what the Glimmer DSL for web is, And it's because it's funny you mentioned that, you know, we as web developers are really desktop app developers, so you want to just like dive into you know how that correlates.

as a desktop app, and I built it. I bet, I built the first MVP version in ten minutes, and it was like so amazing because Ruby, Ruby is so awesome, and so I noticed that I don't have the same productivity in web front and interface developm using JavaScript, not even close. Like JavaScript is so cumbersome. Even the newest versions of JavaScript are so like over engineered, and they

focus on premature optimizations that are not important whatsoever. So because of all of that, like, for example, like JavaScript makes you worry nowadays about const versus let, which to me, like as a Rubist, that's the least of my concerns when I'm building a business app. I just want to focus on the business concerns and not on low level details like that. They also have an import export system, which on the surface sounds great, but in reality it's not.

Like practically in Ruby, we don't it's a lot simpler because we don't have that important export system and we don't care. Like it works fine enough for us without it. Ruby works pretty well for us. So there are a lot of differences between JavaScript and Ruby as far as productivity,

and there are huge differences. Like I mean, I know, like every once in a while dhh and says online on Twitter or something that he thinks that JavaScript after they updated it to act script has become a great language. But honestly, I don't find it a great language at all. I think he's wrong. I think he's kind of caved into what the popular demand or sorry, popular choice by people is instead of actually being a leader and being like, no,

we could do even better Ruby. So that's a lot of those aspects are what prompted me to explore building

a glimmer using a front end Ruby technology. And today in twenty twenty four, we do have front end Ruby technologies, like we have opal Ruby, which just won a fuko Ka Ruby Award in twenty twenty three, so it's a pretty impressive library that gives you a Ruby to JavaScript transpiler, sorry, JavaScript to Ruby transpiler, so that way you can write code that will run as JavaScript like in your website, and consumers of your website will not know that it's Ruby,

but you actually wrote the code in Ruby first and it got transpiled to JavaScript. So that's that's technology. That's one techno. And another one is Ruby WOSM, which compiles Ruby into like quasim low level code and it basically gives you like all the features of Ruby three point one or three point two nowadays in the browser. And then there's also Ruby two JS is the third option, but that one is not as comprehensive as the first two options.

I don't think you can build everything with it. But yeah, so I ended up choosing Opal as a start for building Glimmer DSL for Web because and I wanted to try the idea out. I tried it out in another project. I had a project called Glimmer DSL for Opal in the past, which which is retired now it's archived, and I was able to prove to myself that I can do everything that Glimmer does on the desktop in a

web user interface on the web. And after I proved that idea, I built Blimmer DSL for Web starting last year, and it was it took that approach of being more friendly towards people that know HTML very well or no JavaScript or CSS very well. So it has the dsls that are very close to them to those languages. So it basically does give you an HTML DSL a CSSDSL which is optional. If you want to manage CSS separately,

you can or you could use it. And then the JavaScript aspect got replaced by Ruby, so any or JavaScript logic code can always be written now with Ruby instead of JavaScript, and anything that you could do in JavaScript. You could do it with opal Ruby. So Glimmer DSL for web is not limited whatsoever given that, like, you

can integrate with any available JavaScript library out there. For example, I built a sample selector app that lets people visit a rails app that gives them a bunch of Glimmer samples and then they select one and then they see the code syntax highlighted, and then they can launch it in the web because it's a web apps, it's a web user like front end apps, and then they can launch it directly in the in the browser. So the syntax highlighting aspect, I didn't have to implement it myself

from scratch. I used the library called highlight JS, and I was able to like integrate it very very quickly, Like it took me just a few minutes, or maybe a bit more than ten minutes, but so yeah, So I mean I was able to after I experimented with the idea for quite a while, I took a page like one of the sophisticated pages in my work website. By the way, I work for lek Stop, which is a death collection agency based in Montreal that uses web technology to reach people that are late at paying their

bills either by email or SMS messages. So we have a rails app. Basically we're a rail shop and right now we're using like we've been using React for the last number of years. But I built a proof of concept where I rewrote a React page that had a table of data with passionation, sorting and filtering, and I was able to rewrite it and Glimmer DSTL for a

weapon in about one day. But also the performance was just fast enough, Like I didn't feel any like I didn't feel like performance was too slow or anything like that. It was fast enough, and the code was amazing, like I was able to cut the total code in about by about half. And also the main React component was about five hundred lines of code. And in Glimmer. Glimmer has a very like friendly like op approach of following

MVC and MVP patterns and with NBC and MVVP. The the React component mixes a lot of like data concerns, like it has tate hooks and effects, and it mixes like business concerns with the view present presentation of the view. Whereas when I rewrote it in Glimmer, it shrunk from five hundred lines to fifty lines or something like that.

So it was the one. Yeah, it became a tenth of the size, and all of the data management stuff that REACT let's you do with state hooks and effects got extracted into logic in a presenter or a model. So like I had an MVP pattern where there's a view, a model, and a presenter. The presenter is kind of like a controller, Like MVP is a variation on MVC. But yeah, the code became a lot better because then I can manage the code with standard op for anything

that is not view related that's just mostly logic or so. Yeah, so it was I did a demo of this to my coworkers at work and the CTO and they were pretty impressed. I'm going to be doing another demo soon to the engineering manager of the company and engineering department manager. Sorry, and we're gonna be looking into an idea for rolling it out if the demo goes well. I hope it would go well. And like one idea for rolling it out is it's not a big bang thing. You don't

have to do it everywhere at once. Like the nice thing about front ends on the web is that every web page is a self contained fun end app in a way. So that means for any new web page that we build, we could use Glimmer and keep all the older web pages and whatever old technology we had. But that's not even how we're going to start with it. What we're gonna do is basically only internal facing web pages that are in the admin UI are going to start using Glimmer. Glimmer dssel for web is like the

idea I'm going to be proposing at the next meeting. Uh. And that way, we can gradually play around with it in a few admin pages first, and I just want to make sure there aren't any gotchas that I haven't discovered on my own from building my own sample apps. Uh. And after we do that for about you know, four months or six months, then we can start, uh maybe rewriting some admin pages that we're in React in Glimmer

instead of just adding new pages in Glimmer. And then after that the phase after that, Phase three would be start start writing new pages on the public facing website with Glimmer. And then finally the last phase would be to rewrite React components with Glimmer. If we feel like it is needed, it's completely optional, but it's it could be useful because Glimmer Ruby code is a lot a lot more maintainable than we are JS codes, way more like, in my experience at least double as maintainable.

so simple and easy to read. We'll share it here in our show notes. So I'm like really curious. A lot of this looks similar to kind of like the Flex markup for those familiar with uh uh, you know Joel Draper's Flex project where they have like a DSL for kind of building up the dom elements and mutating them. I'm curious, like, uh, you know now that you've been like kind of reworking even like react stuff, Like what is as a Ruby developer, Like I am assuming that you've developed in reels.

just write Ruby code in the fun end. That's it, but you don't have any support for building frameworks or components or data binding or any of that. Glimmer adds the extra layer that is missing that enables you to do anything you could do data binding, for example using like same. It has the same data binding features as Glimmer desktop libraries. But all of those data binding features

we are actually pre date Glimmer. They come from Microsoft technologies that were used in Visual Basic, I Believe and other Microsoft products. They were also used by some mac Gooey building products as well, so those same ideas got adopted by view js and Veldt. So the same old sort of data binding features that people know I from

Veldt and viewjs are available in Glimmer. Accepting Glimmer it's a lot nicer because you write Ruby code instead of JS code, and it also doesn't have the separation between markup is in HTML and logic is in JavaScript and Ruby. Everything is Ruby. The nice thing is for HTML we have an HTML DSL, the CSS there's the CSSDSL, and for logic that's just Ruby. So everything is in one language so it fits in a lot, so that eliminates the friction between multiple languages. Which actually creates a rag

on productivity. A lot of people are kind of like the Pragmatic book metaphor of the boiled frogs. Have you heard of the boiled frogs story from the Pragmatic Programmer book?

as a reactive basically reactive behavior. It will jump right away just to protect its life. But if you put a frog in a pot with water that is cold, and then you raise the heat very gradually like you turn on you turn on the heat, and then you is it very very gradually, you can boil the frog without it knowing, because it will boil very very gradually, so it will not know that it is boiling, but

eventually it will boil. So they mentioned that a lot of developers end up in that situation where they use technologies at work that put a drag on their productivity and they get used to them, and getting used to things is like one of the biggest risks in adopting

bad practices and software engineering. So people might like use JavaScript, which has very contradictory paradigms to Ruby with a rail's application for years and think they're doing the best they could, but in fact they're actually not doing the best they could. They're creating it like a drag on productivity because they have multiple languages that have different paradigms, and they're also in their head their context switching between the two languages

all the time. So I personally noticed, like I pay a lot of attention because of reading that story and the Pragmatic Programmer book, And at first I felt for that trap too. I used JavaScript for many years thinking it was the best thing, but eventually I realized, like I, like I mentioned, I used glimmer for building desktop apps a lot, and like that's not even like JavaScript development's n even close to that. And so basically a lot of people are bold boiled frogs in a way, they're

not realizing how much productivity they're losing. In my experience, I would like I think Glimmer DSL for a web would cut down the work in half in half in general, so like if you have twelve months at front end development work and JavaScript and React, you could do it in six months in Ruby and Glimmer DSL for web.

So that's part of the reason why I'm actually using it with rails, not against It's not like I still use rails for the back end, but Glimmer is kind of like providing a drop in replacement for your JavaScript libraries that you're adding to Rails. So if you're using VIEWJS or Amber or SVELT or Angular or react any, Glimmer can do a lot better than any of those in my experience as far as productivity, assuming you know,

like it has fast enough performance. Like for my work app the largest sorry the web page with the most elements has only twelve hundred elements, and like I discovered they were render fast enough with Glimmer, I don't even need any of the like performance like advertisements of like React or Velt for that like uppa, Ruby's fast enough in my experience, So in general, I think we can follow the eighty twenty rule where we can avoid premature

optimization because people tell you know, it's the root of all evil and software engineering, because it makes people complicate their code unnecessarily, like React code is unreadable compared to Ruby code, or like especially like Rails back end code for example, so like why are we using it in

a Rails app? Like that's contradictory. So I'm trying to provide a way for people to use Ruby on the front end just like the back end, and that way that opens the door to things like being able to reuse back end Ruby logic in the front end directly.

So for example, if I have a few pieces of logic that are validating taxes for payments or calculating story taxes for like an order, I can actually ship that code to the front end, assuming it has no security requirement restriction requirements on it, and reuse it in the fund directly. So that way I don't have to write in rest EPI to reuse it. A lot of developers waste time writing rest APIs to connect JS code to the back end, or they waste time rewriting the back

end code and JS. That's another like performance waste or drain, sorry not productivity drain. So open Ruby also saves us from having to do that. Then I can like reuse back end Ruby code directly in the fun end where needed, So any secure code remains back and only not everything will be opened up to the fun end. But things that are reusable on the front end and don't have any security restriction requirements, you can actually reuse them directly

in the fun end. So I mean to answer your question like, I'm using Glimmer to actually improve my productivity and rails app development, and I would say double it as far as front end development and rails apps. One other thing you mentioned was that Flex. One thing to clarify about Flex is Flex is only about two years old and the approach they use is actually not different from what Glimmer had for years. On the dusktop they let you build components with markup with sorry, with a

Ruby DSL that lets you build the HTML. But Glimmer Desktop Libraries lets you do the same thing with components, but instead of using HTML markup and the DSL used the Desktop Control DSL, which like you know, will give you dustop widgits like list or Combo box or text field, et cetera. So I would say that like whatever they came up with, they came after Glimmer, They're not. The Flex approach is not with Glimmer copied. Glimmer just copied

its own. It's older the stop self. But Flex, thankfully is another library that is exploring the same ideas for Glimmer, but only on the back end, like they're doing it at least for now, they're mainly exploring things on the back end, whereas Glimmer, the estolf for webs is doing it on the front end. Both of them, to be more a fair both Glimmer and Flex borrowed the idea of writing a DSL for the guy or the user interface,

whether it's using HTML, markup or desktop controls. They borrowed that from much older technologies like Shoes or mark Cobby Markabby was one of the first dsls and Ruby. I believe that allowed people to write HTML and Ruby. So so yeah, I just wanted to clarify the history of it.

check out as well. It definitely makes a lot more sense now as you've been explaining it, seeing it as like you said, the data binding aspect of connecting the front end components to the back end, and it makes a lot of sense, and it's definitely like we are getting closer here.

front end has a similar story. Opal Ruby started in the mid twenty tens, like it might have been twenty twelve, was the first first alpha version of it, and it took about ten years as well to figure out what to do with opal Ruby on the front end before we arrive at what we think is like the most practical solution. So I agree with you and I think that's okay. Like it takes time sometimes to figure out how to do things. The best way possible.

I make a form component? Is that like straightforward to do with the Glimmer DSL. What is your been your experience with like encapsulation there?

right now. So for example, I found and they build a name and address form because that's a very common form that could be used on multiple pages on the website, like for payment, like for shipping, like for many different things.

You could definitely do that today. In fact, one of the samples or multiple of the samples to include a name and address form or an address form at least, so it basically abstracts or like you mentioned, encapsulates all the things related to displaying an address form into a component, and it basically will expect you then to provide it an address model, so that way, when you work with it, you don't even have to worry about working with the

guy directly. You just work with the address model, and when you update the address model, because of bidirectional data binding, it will automatically show updates on the form on the screen. So it'll save developers a lot of work. Like this approach saves developers a lot of work because they don't have to If you have components that are very well encapsulated, you can just work with their data and their data will automatically reflect on the GUI because of data binding.

their you know, front end interactions and stuff. But then you know, I have to request that the back end team like help supply that data or new like as data changes, Like how do you add and adjust to the component without you know, the data being there on the back end. And so you have this like dual edge coupling. And if we have that coupling anyway, why not have it all in the same place. I think

it makes a lot of sense to me personally. So how I'm wondering, like, you know, does this also like appease like teams that grow in skies and like have devoted front end teams, Like is there still kind of that is this like trying to like consolidate the team structure, or is it also like supporting the idea of Okay, we're gonna have front end people that are going to be focusing specifically on styling and adjusting the components, Like is it still kind of a straightforward process of like

HTML CSS kind of ulation for front end styling of the components, or is it take more of like I need to learn Glimmer DSL, you know, aspect of things.

have to even be involved in the Ruby part. If people are back end developers that know back end Ruby and they use it with rails, now this opens the door completely for them to use glimmer on the front end. So that actually, in my experience, improves productivity in number

of ways. Usually it's recommended to do full stack development, not back in front end, at least in my company we definitely and a few other companies I worked out in the past, that's definitely the approach we adopted, because then the developer is aware of the full value being offered to the customer end to end from the user interface all the way down to the database and then back, so then they can optimize the code or simplify the code as with a better understanding of like the holistic

view of everything and be able to provide a better product customers in general, and also in my experience, results in less work and less communication overhead. When there are fun end and back end developers, there's communication overhead, there's more work about translating things from the back endto the front end and vice versa. And if there are multiple languages that's even worse then, like there's even more translation

going on. So this enables now back in developers to just do fund work and not worry anymore about that a way, it saves companies from actually it cuts down the hiring costs because companies that have back end developers they don't even need, Like if there's a startup that wants to be as efficient as possible, as productive as possible, they don't even have to hire fun and developers anymore if they have solid back end Ruby developers. So that's

a very big win. But on the other hand, if there are companies that have back in front end developers, front end developers would learn this just like learning any other fund in library. Because for example, React definitely had a very large, like a big learning curve in a sense because they had JSX, which was not a normal base. It's not a standard technology. JSX is actually not standard HDML,

not standard CSS, not even standard JavaScript. So it's very weird, and like React has a lot of weird things that, in my opinion, like waste a lot of productivities to learn, Like why are we working low level state when we actually have objects oriented programming languages that are way more advanced.

They have the same idea. So in my mind, React reinvents op in a different way and give it a different gives it a different name, Like basically object attributes are cold states, hoax and react and object observers they call them effects and react and that's it. Like React is not really it's just reinventing things. It's not really

as modern and new as people think it is. For people that have been software engineering for a long time, they could tell that it like React reacts ideas have been around since the nineties at least, like the idea of components has been around since the nineties, from visual Basic for example. So anyways, so in the end, I found it more productive to like and reactually have to open weird curly braces to mix logic with view concerns. So if I want to say if this, do this,

if that, do that. It's a bit weird opening the curly braces. It's very hard to integrate the logic with a view. Whereas in Ruby and glimmer Da steltw for Web, you are in Ruby already, you're just using a redsl You can actually write if in that immediately in the same language. And also it's even better than ERB as well, because ERB lets you requires that developers open scriptlets to mix logic with a view like concerns. Sorry, not the concerns,

but more it's actually presentation logic. It's not really it is view logic. But yeah, to mix it with view structure you have to open u scriptlets, which can get really annoying after a while, and over a year adds up so much that it would actually present a dragon productivity, which goes back to that world frog metaphor that I

spoke of earlier. So in a way, I would say JavaScript developers that are worth their salt, that are actually smart, solid software engineers should be able to pick up glimmer Da stelf for Web in no time and then be more productive in it than using JavaScript.

using crazy bundlers like Webpack. I mean, in my opinion that's a benefit because Webpack, like at my job, maintaining Webpack is like wetpack is such a monstrosity with it with all its options and configuration settings that like upgrading it is a very difficult process. Like we I recently upgraded it from an old version to anywhere one and it was absolute hell and it took more than a month to finish the work. So uh, this just where's

this just runs on top of sprockets. So meaning you just do a rail's asset precompile when you deployed production and it generates JavaScript files and that's it. And then you put the JavaScript files in a cd N so then people download them with instant like download speeds. Uh and uh the website will be very like high performance as a result of that. And locally on my machine, there's no bundler again, there's just ople rails uh the gem.

So what that means is every time I had a web hit a web page, uh, the OPAL code gets compiled on the spot and development. So that way as I update the code and I refresh the web page, it picks up. Then you or changes that said, I heard from the Opole people that they are working on like a way to integrate Opole with bundlers like wetpack, and they might already have I believe they already have like proofs of concepts of it or maybe even working versions,

but I'm personally not interested in using them. In my mind, like a big benefit is avoiding wetpack. Is like my way of doing things I would say with this is to not use a bundler. I would in any third party libraries, I would link to their CDNs. That's fast enough and good enough. I realized that bundlers give you chunking and other features that people will say will give

you even better performance. But like for most apps that are smaller startup rails apps or mid sized apps, just what Rails is used for the most I'd rather not use a bundler. I'd rather just have things bundled with rails assets pre compile on deploy and locally would just compile live when I'm doing development.

super great. It didn't require any of the you know, JavaScript packaging systems or extra dependencies like that, and it worked great and just bundle install and it included all of the assets that you needed and handled all that. And I do miss that, And so I'm hopeful with this kind of push here that we can kind of get back to something like that, which makes brings me to my next topic, Uh Turbo. What what are your feelings on Turbo? And like the HTML over the wire aspects of rails.

sophisticated apps, it doesn't do everything. And that's the reason why a lot of Rubists nowadays reach for React and other JavaScript libraries like svelt and viejss is because they they at one point hit a wall or feel like it's too complicated to manage Turbo from controllers in the back end then to actually just write front end code. And I think a big like I think Turbo in a way is a bit like written and with the approach of being a bit aversive to writing front end

JavaScript code because JavaScript code is not nice. But if we have the front end language that was nice, and we do now in twenty twenty four, which is Ruby, using Opal or Rosen, then there's no reason for me to consider Turbo. In that case, I would rather just write front end Ruby code the normal way and like following an NBC pattern, and that should be good enough. Like I don't feel and I can just make the

rest API calls. I mean, on my job, people do that anyways with React right now they connect React to the back end with the rest API calls. So I mean, I feel like that's simple enough, and a lot of people are comfortable with that model. One thing about Turbo is that has a bit of a learning curve and because its model is a bit like out of the normal, out of the ordinary, the mental model, so people have to think a lot about IDs on elements in HTML.

So in my experience, I feel like writing features in Glimmer the Alpha Web is simpler because I'm just writing basic Ruby code. I don't have to worry about IDs. You can just use variables the normal Ruby way, and

variables will I defy elements. You can grab elements by variable instead of by ID in general, like generally you don't have to refer to IDs and elements, so it's even it's simpler than JQuery's simpler than my mind, a bit than the mental model of Turbo, and it can do things that are fully like just front end only interactions that don't even talk to the back end. So, as far as I know, Turbo is usually augmented by stimulus.

I find stimulus is code a bit boilerplate ish, and because it requires people to write controllers, I find that a bit too verbose. Personally, I feel like it's not dry enough. It could be drier, but also it's written in JavaScript, which is very ugly compared to back end Ruby code. Like even even if I'm writing a tiny bit of sprinkles in JavaScript, if I can write them in Ruby would be even better.

the missing pieces too. Of well, we still need JavaScript. JavaScript libraries are still helpful, like how do we use them in the context of our application, but not have to just use JavaScript to couple our our back ends.

popular around twenty fifteen or twenty sixteen. Vault was basically providing people with a full isomorphic approach to development on the web, so that you write the front end with Vault using the Ruby and they might have had a DSL, and then on the back end they basically have models that can establish connections to the back end directly without you writing controllers or writing recpis on the back end if I remember right. So it was a very innovative approach.

It had very good ideas. The issue with it was that it required it forced people to change their mental model for males too much. And that's a problem. If somebody wrote to a rails app that is doing very good for their business and it's been around for five years, it might be too much to ask for them to change their entire apps approach right away to something like Vault.

So Glimmer is aiming to intentionally provide the simplest possible thing that you could use to augmentary your rails app with something better on the front end, and no more than that. So I intentionally just provide a drop in replacement for your JavaScript library on the front end, and thee nice thing about it is JavaScript funends. Like sorry, front end apps are. Every page is its own app, So if you have older things built with j Query

or React in the past, it doesn't matter. You can start any new pages with using Glimmer and it's very easy to add it and you can get started very quickly. My plan behind that is it would expand gradually in the future so that more and more pieces can be added if people want to optionally. So the second so you mentioned that now things are coming together in a way because finally, like on the back end we have things like flex or view component and on the front

end there's you know, Glimmer dslf web. My idea is to actually extend Glimmer support to the back end as well. So eventually you write your glimmer web components on the front end and then you I want to support server side rendering of them on the back end, so that way, on the back end you don't have to use R anymore. You drop the RB and replace it with a much simpler glimmer DSL, but you would basically it would work

kind of like view component or flex. Like the back end controller actions will just render glimmer components and if you render them from the back end on first hit of the website, they will, you know, first render the HTML and then they will hydrate and add the JavaScript clayer on top of that. So there will be a bit of work to explore that idea, but that idea is on the horizon. Another idea I had in mind was to actually replace E R E files with a

simpler solution called GRB. So GRB would be glimmer RB, which is basically files that look like RB, except instead of using template style like scriptlet syntax, you would use the glimmer DSL directly in them. So that's another idea I have. So I have I have a few ideas on the horizon to enable people to more and more like improve their rails, wave rendering views and componentizing their views.

And hopefully eventually once I add more and more of those ideas, I guess The fourth idea would be to do what Vault was doing, which is to have front end models act as proxies for back end models. If you do that, then rails developers don't even have to

write controllers anymore. You don't have to worry about so you're gonna like I can remove all of the boilerplate code of writing controllers out, and then I can remove all the boiler plate code of writing JavaScript services out like rest services, and that way I can connect JavaScript fund and models directly to active record or or back end models in Rails, which is kind of like what

Vault and also Hyperstack, which is another open Rugby library does. Unfortunately, both both of them are no longer maintained, or at

least Hyperstack hasn't had their released in three years. Maybe I don't know if it is maintained still, but either way, that's so that's I think that's a very important thing in software engineering is incremental development, like iterative incremental development, and in a way, Glimmer is adopting that approach for rolling out its features, where people can start with a you know, droping replacement for their job ASCRIPT fundend library and then move on to a back end technology like

either GRB or rendering front end components on the back end directly. And finally, it would be like replacing their controller layer completely with like a model proxy layer that would bypass the whole rest API thing, or it would basically automate it so that I don't have to write to rest code myself directly. So yeah, these are some of the ideas and the pipeline for Glimmer DASELF for Web.

GUI mental model that was similar to the desktop. It even used the same widget or control names, like you could say, tag names that were used for building the Eclipse SWT library, so I was trying to match the syntax of glimmer dslfware SWT. But that enabled this. Basically I could take any desktop library, game or app that was built glimmer dsftware SWT and run its code in glimmer Ds Software Web without writing HTMLOCSS like I would just keep the same exact desktop codes in Ruby and

it would run the app in the browser. So I was able to run Tetris, for example. That way, I built it for the desktop and it ran on the web with the same exact code, which was pretty impressive, but in Mike However, practically, speaking from a like a business web development point of view, I don't think it's

a very practical idea. I think most developers want to know about HTML and CSS and they want to do things following more the webway, and if I hide HTML and CSS from them, I don't think they'd be pleased. But also if I were to take the other approach, which has used HTMLCSS on the desktop, that causes the other like issue, which is like desktop developers writes a lot less code because they don't have to mark with HTMLCSS. The stop guy libraries are usually simpler than web stuff.

So so I think it's better to.

and UNI directional data binding. So it will give people a lot more time to be able to play around and learn a desktop version of Glimmer. So the version used is going to be the Fukka Ruby Award, the one sorry, the one that won that Ruby Award. It will be glimmerdself for Libui. This library. Actually, the nice thing about it is that you just installed the Ruby

gem and you're good to go. So I actually you include in the workshop description the instructions like I tell people just install the Ruby gem and then want a sample to make sure it works and you're good to go. So I'll be basically using that library as an educational library for building very small desktop app so limit of the stuff with LIBYUI. What's good about it is that

it's very good for very simple apps. You can build them very quickly, and also it's good for apps that are mostly tools or productivity tools or development related tools that can help with your day to day work because it's a very good library for packaging apps as gems, so you can package anything like you can scaffold an app with It supports scaffolding features similar to rails, but for desktop apps, and then you can package your scaffolded app as a gem very quickly, and then you can

give it to others and people just install the gem and use it. So I would recommend this library the most for people that want to build productivity tools for up day to date work. If you want to pack is your app as a Mac app or a Windows app, this library does have two options for doing it, and it's Windows option works very well. It's Mac option is very new. There's a guy that packaged it on the Mac just a few months ago and I documented what he did. He actually documented what he did in the

blog post that I linked to. So it does offer some packaging options, but they're not the most complete or comprehensive. Today, I have other libraries like glimmer dsl FORSWT lets you package your apps as real native apps with like an ex or MSI on installer on Windows, or DMG file or PKG file on Mac, or even wn files on Linux or RPM. So that one if people want to build a more serious app, I would recommend glimmer dysself

fors WT. But if they're building a very quick productivity app or small app that will show a table that is summarizing data from a database, I would recommend glimomer dssel for LIBI. Yeah.

be contributing controls. So that way, people can for example, add a message at the top of the name and address form between the name and the address that can inform people of something, or they can add another form like a nested form within it or do stuff like that. So I mean this this feature is called component slots. It's borrowed from the Web Component slots standard. Like on the Web and the HTML Web Component Standard, they do have the idea of slots, so it's kind of borrowed

from that. It's also borrowed from that, I think view component the library. The rails library has slots as well. So anyways, that's something that I ended up adding to glimmer yr self for Libui first, and then I added it to glimmer dr self for Web and it works very well because then it enables any like if you take any component, you're not limited by what the people who build the component did in it. You can actually open it up like it's on. It follows the opened sorry,

the open closed principle. You can open any like component up without touching its code, so it's closed for modification, but it's open for extension, and you can add anything to that component in the in the slots that are designated for the changes for anything to add.

who ever wrote the code. It's it's the React way, but like it reacts code is so absolutely awful. And I mean so I dabbled with other approaches, like I was going to consider recommending SVELT or view JS network. But then that's when I like, that's when I thought about Glimmer and Ruby, and I'm like, wow, I could even do better than spelt in view, and in my opinion, I succeeded at that. So I think part part of it is passion, like I'm very passionate about Ruby open

source projects. The other part of it is also thinking seriously about how to improve our development productivity for customers, because this is a game changer. If you can save six months a year of development work because you're using front end Ruby instead of JavaScript, that's an absolute game changer. And that code is also going to be more maintainable for years to come, so it'll be cheaper to maintain for years to come as well. And on top of it,

like basically it pays for itself. So like like if people try to say, give you an excuse of oh, I don't have time to check out this library or try it out, I'll be like, no, you don't have time not to check it out, because right now you're spending six months more every year using another library. If you spend only two or three weeks learning this library, you're going to save like five weeks and a half or so, so it's actually paying for its own investment automatically,

like just by exploring this library. So in my opinion, uh so that's another reason why I'm into it, Like I believe it's gonna enhance my work experience significantly if we adopted in my company right now.

to open and close the tax anymore. Can just put the tag name and then open up block with curly braces and then close up curly braces and you're done. So's it's more dry. Like people who write HTML don't write don't write dry code because HTML itself is not dry. I mean, that's part of the reason why XML became obsolete and people started using JSON because Jason is a

lot drier than XML. But unfortunately in web view development, like people haven't made that transition yet, So this approach is like one one key reason for the design of glimmer day self for Web being different from glimmer das self for Opal was to enable enable people to not have much of a learning curve. They can just transfer

their HTML skills as is. So like any attributes you know on any elements are supported by glimmer da self for Web, and any listeners are supported and any and then all the same tags are supported by their same name. It's just with a slightly different syntax that's actually less code than HTML.

of samples written in Ruby. And then lastly, I would recommend obviously for everyone to take out like build a Rails like a new Rails app from scratch, and then integrate Glimmer DSL for Web into it and then play around with it.

things and push buttons. And I hope that one day I get it to like type on the keyboard and like look at my screen and then just like work for me. But it's a lot of fun. I'm just to the assembly phase. I completed that and it's been it's been a lot of fun. So I'm looking forward to.

mirrors it. They call it tele operation. But they have like you know, you can have multiple robot arms, so like you can have multiple leaders, multiple followers, and so, uh, there is a camera aspect that lets you train and learn kind of what is happening that way, and so I think maybe in the future it will get to the point where you could just use your own arms

and hands. But I think right now it's just like because the dexterity is not there yet, it's just two arms and you train one with the other kind of thing.

arm to do. But their examples that they have are like legos sorting right, finding the right colors, Like I think they had one example where they're you know, pushing buttons on something else. So I don't really know what I'm gonna do with it yet. It's mostly just fun to explore all of this real world AI aspect stuff, so definitely. Yeah, so check that out if you're interested.

La Rollebot. Well, it's been awesome talking to Andy. I appreciate you coming on again and all the work you're doing in the space because you know, we need it and I love to do more ruby than anything else, so I appreciate it. And yeah, if people want to reach out to you or find you on the internet, how do they do that.