Andy Maleh
Appearances
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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 front end app in a way. So that means for any new web page that we build, we could use Glimmer and keep all the older web pages and whatever old technology we had. Uh, but, but that's not even how we're going to start with it.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Uh, what we're going to do is basically, uh, only internal facing web pages that are in the admin UI, uh, are going to start using Glimmer, uh, Glimmer DSL 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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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. And after we do that for about four months or six months, then we can start maybe rewriting some admin pages that were in React in Glimmer instead of just adding new pages in Glimmer.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And then after that, the phase after that, phase three would be 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 could be useful because Glimmer Ruby code is a lot more maintainable than React.js code, way more.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Like in my experience, at least double as maintainable.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Like the whole thing. Like all the cool things that Ruby offers as far as metaprogramming, as far as building DSLs and all of that. We can like build GUIs 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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
That I've developed in Rails? What do you mean? Sorry. Like, you've used Rails before? 2008 or 2007. Yeah. Okay.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
There might be a slight misunderstanding. Glimmer is only the front-end part. Glimmer integrates with Rails. Glimmer is a Rails library, by the way. It's not just an open Ruby library. It's also a Rails gem. It integrates with Rails apps and enables you to suddenly, in any Rails app, be able to write the front end in Ruby. That's it.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Except it lets you write the front end in Ruby using a nice Glimmer DSL. Without Glimmer, if I use Opal Ruby alone, you can just write Ruby code in the front end. That's it. But you don't have any support for building frameworks or components or data binding or any of that. Glimmer adds the extra layer that is missing that enables you to do anything you can do with data binding, for example.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
It has the same data binding features as Glimmer desktop libraries, but all of those data binding features are actually predate Glimmer. They come from Microsoft technologies that were used in Visual Basic, I believe. and other Microsoft products. They were also used by some Mac GUI building products as well. So those same ideas got adopted by Vue.js and Svelte.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So the same old sort of data binding features that people know from Svelte and Vue.js are available in Plumber. Except in 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 as in HTML and logic as in JavaScript. In Ruby, everything is Ruby. The nice thing is for HTML, you have an HTML DSL. For CSS, there's a CSS DSL.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And for logic, there's just Ruby DSL. So everything is in one language. So it fits in a lot. So that eliminates the friction between multiple languages, which actually creates a drag on productivity. A lot of people are kind of like the pragmatic book metaphor of the boiled frogs. Have you heard of the boiled frog story from the pragmatic programmer book?
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
It felt like I'm writing Java code. So I didn't like working with it. Her 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 IDE because that's what I used at work at the time.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I can repeat it. It's basically like... It's a very interesting book that I highly recommend reading to anyone working in the software development industry. But they're basically saying that one risk that... people get into is becoming both frogs.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
What they mean is like they say, if you take a frog and put it in a pot with boiling water, the frog will jump out right away of the pot as a reaction, as a like a way of like, yeah, as a reactive, basically reactive behavior. It'll jump right away just to protect its life.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Uh, but if you put a frog in a pot with water that is cold, and then you raise the heat, uh, very gradually, like you turn on, uh, you turn on the heat and then you raise it very, very gradually. You can boil the frog without it knowing, uh, uh, because it'll boil very, very gradually. So it will not know that it is boiling, but eventually it will boil.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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 in software engineering. So people might like use JavaScript, which has very contradictory paradigms to Ruby, with a Rails application,
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
for years and think they're doing the best they could but in fact they're actually not doing the best they could uh 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 in the pragmatic programmer book and at first i fell for that trap too i used javascript for many years thinking it was the best thing
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
But eventually I realized, like I mentioned, I use Glimmer for building desktop apps a lot. I'm like, that's not even like JavaScript development is not even close to that. And so basically a lot of people are boiled frogs in a way. They're not realizing how much productivity they're losing. In my experience, I would like, I think Glimmer DSL for web would cut down the work in half
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
in half in general. So like if you have 12 months of front end development work in JavaScript and React, you could do it in 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 backend,
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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 Vue.js or Ember or Svelte or Angular or React, Glimmer can do a lot better than any of those, in my experience, as far as productivity. Assuming it has fast enough performance. For my work app, the web page with the most elements has only 1,200 elements.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And I discovered they render fast enough with Glimmer. I don't even need any of the performance advertisements of React or Svelte for that. Apple Ruby is fast enough in my experience.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
In general, I think we can follow the 80-20 rule where we can avoid premature optimization because people tell you it's the root of all evil in software engineering because it makes people complicate their code unnecessarily. React code is unreadable compared to Ruby code or especially Rails backend code, for example. Why are we using it in a Rails app? That's contradictory. It
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I'm trying to provide a way for people to use Ruby on the front end, just like the backend. And that way that opens the door to things like being able to reuse backend Ruby logic in the front end directly. So,
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So I built it using JRuby because it had to run on top of the JVM. Eventually the idea proved itself to be interesting and useful enough to a point where I ended up then covering all the available GUI toolkits in Ruby with Glimmer. So I have a Glimmer DSL for TK now, a Glimmer DSL for GTK, for FX Ruby, meaning Fox Toolkit, libui started as a library that's a bit recent.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
For example, if I have a few pieces of logic that are validating taxes for payments or calculating, sorry, taxes for like an order, I can actually ship that code to the front end, assuming it has no security requirement, restriction requirements on it and reuse it in the front end directly. So that way I don't have to write in REST API to reuse it.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
A lot of developers waste time writing REST API's. to connect JS code to the backend, or they waste time rewriting the backend code in JS. That's another performance waste or drain. I'm sorry, productivity drain. So Opal Ruby also saves us from having to do that. Then I can like reuse backend Ruby code directly in the front end where needed.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So any secure code remains backend only and not everything will be opened up to the front end, but things that are reusable on the front end and don't have any security restriction requirements, you can actually reuse them directly in the front end. So, I mean, to answer your question, like I'm using Glimmer to actually improve my productivity in Rails app development.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And I would say double it as far as front end development in Rails apps. One other thing you mentioned was 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 desktop. They let you build components with markup, sorry, with a Ruby DSL that lets you build the HTML.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
But Glimmer desktop libraries lets you do the same thing with components. But instead of using HTML markup, In the DSL, you use the desktop control DSL, which like, you know, it'll give you desktop widgets 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. The Flex approach is not what Glimmer copied.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Glimmer just copied its older desktop self. But Flex, thankfully, is another library that is exploring the same ideas for Glimmer, but only on the back end. They're doing it, at least for now, they're mainly exploring things on the back end, whereas Glimmer DSL for Web is doing it on the front end. Both of them, to be more fair, both Glimmer and Flex are
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
borrowed the idea of writing a dsl for the gui or the user interface whether it's using html markup or desktop controls they borrowed that from much older technologies like shoes or markabi markabi was one of the first dsls in ruby i believe that allowed people to write html in ruby so so yeah i just wanted to clarify the history of it so yeah super interesting uh
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So I think that's OK, because that's exactly how Ruby started. So Ruby started in the 90s, mid 90s, and it took it 10 years before Rails came to fruition. So it wasn't until the mid 2000s that Ruby became very viable on the back end. And now the front end has a similar story. Opal Ruby started in the mid 2010s, like might have been 2012 was the first first alpha version of it.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And it took about 10 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 OK. Like, it takes time sometimes to figure out how to do things the best way possible.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
That was one of the more recent glimmers that were built. And the most recent one is wxwidgets has been covered by glimmer recently because somebody built a new binding called wxruby that replaced the old wxruby just a couple of years ago. So I ended up also covering it with a glimmer DSL. But to get back to that question, what happened is eventually I ended up...
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Yeah. So to start, the Glimmer HTML DSL gives you access to using any HTML tag, including SVG tags as well. So if you want to use a form tag, you can use it it's already supported. Every tag that is in HTML is supported by Glimmer right now, Glimmer DSL for web. So you could just use any basic HTML tags out of the box.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Now, if you want to build your own components, it also supports that completely right now. So for example, if I want to 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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
In fact, one of the samples or multiple of the samples 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 an address model.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So that way, when you work with it, you don't even have to worry about working with the GUI directly. You just work with the address model. And when you update the address model, because of bidirectional data binding, it'll automatically show updates on the form on the screen. So it'll save developers a lot of work.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Like this approach saves developers a lot of work because they don't have to, if you have components that are very well encapsulated, you can just work with their data and their data will automatically reflect in the GUI because of data binding.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Yeah, so one thing to clarify is that Glimmer DSL for web in the end generates real JavaScript, real HTML, and real CSS. So when you use it, you will generate standard HTML, CSS, JavaScript. So people have concerns about testing the front-end user interfaces. They can just test them as basic HTML. They don't have to even be involved in the Ruby part.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
If people are backend developers that know backend Ruby and they use it with Rails, now this opens the door completely for them to use Glimmer on the front end. So that actually... in my experience, improves productivity in a number of ways. Usually it's recommended to do full-stack development, not back-end, front-end.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
last year coming up with the idea of building glimmer dsl for web which is a web version of glimmer that uses all the innovations for data binding that were used in desktop development but with building web user interfaces so i mean the first thing i think of uh when i think of what you know cross-platform desktop apps is like electron and and maybe like
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
At least in my company, we definitely, and a few other companies I worked at in the past, that's definitely the approach we adopted because then the developer is aware of the full value being offered to the customer end-to-end from the user interface all the way down to the database and then back.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So then they can optimize the code or simplify the code with a better understanding of the holistic view of everything and be able to provide a better product to customers in general. And also, in my experience, results in less work and less communication overhead. When there are front-end and back-end developers, there's communication overhead. There's more work about translating content
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
things from the backend to the front end and vice versa. And if there are multiple languages, that's even worse than like there's even more translation going on. So this enables now backend developers to just do fun work and not worry anymore about that. So in a way it saves companies from actually it cuts down the hiring costs
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Because companies that have backend developers, they don't even need, like if there's a startup that wants to be as efficient as possible, as productive as possible, they don't even have to hire front-end developers anymore if they have solid backend Ruby developers. So that's a very big win. But on the other hand, if there are companies that have backend front-end developers,
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
front-end developers would learn this just like learning any other front-end library. Because for example, React definitely had a very large, like a big learning curve in a sense, because they had JSX, which was not a normal, it's not a standard technology. JSX is actually not standard HTML, not standard CSS, not even standard JavaScript. So it's very weird.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And like React has a lot of weird things that in my opinion, like waste a lot of productivity to learn. Like, Why are we working with low-level states when we actually have object-oriented programming languages that are way more advanced? They have the same idea. So in my mind, React reinvents OOP in a different way and gives it a different name.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Basically, object attributes are called states, hooks in React. And object observers, they call them effects in React. And that's it. 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 React's ideas have been around since the 90s at least.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
The idea of components has been around since the 90s from Visual Basic, for example. So anyways... So in the end, I found it more productive to like, and we actually have to open weird curly braces to mix logic with view concerns. So if I want to say this, do this, if that, do that, it's a bit weird opening the curly braces thing. it's very hard to integrate the logic with the view.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Whereas in Ruby and Glimmer DSL for web, you are in Ruby already. You're just using a Ruby DSL. You can actually write if and that immediately in the same language. Also, it's even better than ERB as well because ERB requires that developers open scriptlets to mix logic with view concerns. Sorry, not the concerns, but it's actually presentation logic. It is view logic.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
But to mix it with view structure, you have to open scriptlets, which can get really annoying after a while. And over a year adds up so much that it would actually... present a drag on productivity, which goes back to that boiled frog metaphor that I spoke of earlier.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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 DSL for web in no time and then be more productive in it than using JavaScript.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So I'm using the Opal Rails gem, which is 100% compliant with the Rails classic asset pipeline. So it runs on top of Sprockets. So it's actually very simple. It brings us back to the old simple days of CoffeeScript and older JavaScript before we had to start using crazy bundlers like Webpack. I mean, in my opinion, that's a benefit because
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
At my job, maintaining Webpack is such a monstrosity with all its options and configuration settings that upgrading it is a very difficult process. I recently upgraded it from an old version to a newer one, and it was absolute hell. It took more than a month. to finish the work. So this just, whereas this just runs on top of sprockets.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So meaning you just do a Rails asset precompile when you deploy production and it generates JavaScript files and that's it. Then you put the JavaScript files in a CDN. So then people will download them with instant like download speeds and the website will be very like high performance as a result of that. And locally on my machine, there's no bundler again. There's just Opal Rails, the gem.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So the irony is that Electron is not real desktop. So Electron runs on top of browser, embedded browsers. So it's actually, you write the app in actually HTML and CSS. So unfortunately, as a result of that, you forego all the simplicity of desktop GUI toolkit development because desktop GUIs are usually a lot simpler than web GUIs because they have limitations
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So what that means is every time I hit a webpage, the Opal code gets compiled on the spot in development. So that way, as I update the code and I refresh the webpage, it picks up the newer changes. That said, I heard from the Opal people that they are working on... like a way to integrate Opal with bundlers like Webpack.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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 Webpack is like my way of doing things, I would say with this is to not use a bundler. In any third-party libraries, I would link to their CDNs. That's fast enough and good enough.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I realize 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, which is what Rails is used for the most, I'd rather not use a bundler.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I'd rather just have things bundled with Rails asset pre-compile on deploy and locally would just compile live when I'm doing development.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
what are your feelings on turbo and like the html over the wire aspects of rails um so uh turbo is nice if i have a very simple business app and i need very very few like front end uh front end e interactions uh without writing front end code uh I can use Turbo for that, like where it would update certain parts of the screen automatically based on backend directives from a controller action.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So I think for simpler apps, it works fine. For more sophisticated apps, it doesn't do everything. And that's the reason why a lot of Rubyists nowadays reach for React and other JavaScript libraries like Svelte and Vue.js is because they at one point hit a wall or feel like it's too complicated to manage turbo from controllers on the back end than to actually just write front-end code.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I think turbo in a way is a bit like written in with the approach of being a bit aversive to writing front-end JavaScript code because JavaScript code is not nice. But if we had the front-end language that was nice, and we do now in 2024, which is Ruby using Opal or Wasm, then there's no reason for me to consider Turbo in that case.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I would rather just write front-end Ruby code the normal way and following an MVC pattern, and that should be good enough. I can just make REST API calls. I mean, at my job, People do that anyways with React right now. They connect React to the backend with REST API calls. So, I mean, I feel like that's simple enough and a lot of people are comfortable with that model.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
One thing about Turbo is it has a bit of a learning curve because its model is a bit like, out of the normal, out of the ordinary, the mental model. So people have to think a lot about IDs on elements in HTML. So in my experience, I feel like writing features in Glimmer DSL for web is simpler because I'm just writing basic Ruby code. I don't have to worry about IDs.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
that are enforced to comply with operating system standards like on Mac OS or Windows. So it's a lot faster to build a desktop app with a desktop GUI toolkit than to build it with HTML and CSS. So Electron runs on top of a browser. 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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
You can just use variables the normal Ruby way and variables will identify elements. You can grab elements by variable instead of by ID. uh, in general, like in general, you don't have to refer to IDs and elements. Uh, so it's even, it's simpler than jQuery. It's simpler than my mind a bit than the mental model of turbo. Um,
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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 as code a bit boilerplate-ish 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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
But also it's written in JavaScript, which is very ugly compared to back-end Ruby code. Like, even if I'm writing a tiny bit of sprinkles in JavaScript, if I can write them in Ruby, it would be even better.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Yeah, one of the issues with previous attempts of providing a front-end development library that would use Ruby, like Opal Ruby, for example. For example, there was a much older framework called Vault that was a bit popular around 2015 or 2016. Vault was basically providing people with a full isomorphic approach to development on the web so that you write the front end with Vault using the Ruby.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
They might have had a DSL. And then on the back end, they basically have models that can establish connections to the back end directly without you writing controllers or writing REST APIs on the back end, if I remember right. It was a very innovative approach. It had very good ideas. The issue with it was that it forced people to change their mental model for Rails too much. That's a problem.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
If somebody wrote 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 augment your Rails app with something better on the front end and no more than that.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So I intentionally just provide a drop-in replacement for your JavaScript library on the front end And the nice thing about it is JavaScript frontend apps are every page is its own app. So if you have older things built with jQuery or React in the past, it doesn't matter. You can start any new pages using Glimmer and it's very easy to add it and you can get started very quickly.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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 backend, we have things like flex or view component. And on the front end, there's, you know, Glimmer DSL for web.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
But Electron is not real desktop development. Like, cross-platform GUI toolkits are actually a lot simpler to use than Electron.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
My idea is to actually extend Glimmer support to the backend as well. So eventually you write your Glimmer web components on the front end. And then 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 ERP anymore. You drop ERP and replace it with a much simpler Glimmer DSL.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
But basically, it would work kind of like Vue 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... first render the HTML and then they will hydrate and add the JavaScript layer on top of that. There will be a bit of work to explore that idea, but that idea is on the horizon.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Another idea I had in mind was to actually replace ERP files with a simpler solution called GRB. So GRB would be Glimmer RB, which is basically files that look like ERB, except instead of using templates style like scriptlet syntax, you would use the Glimmer DSL directly in them. So that's another idea I have.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So 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 it 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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
If you do that, then Rails developers don't even have to write controllers anymore. You don't have to worry about... I can remove all of the boilerplate code of writing controllers out, and then I can remove all the boilerplate code of writing JavaScript services out, like REST services.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And that way I can connect JavaScript front-end models directly to ActiveRecord or back-end models in Rails, which is kind of like what Vault and also HyperStack, which is another Opal Ruby library, does. Unfortunately, both of them are no longer maintained, or at least HyperStack hasn't had a release in three years.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I don't know if it is maintained still, but either way, I think that's a very important thing in software engineering, is incremental development, like iterative incremental development.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And in a way, Glimmer is adopting that approach for rolling out its features where people can start with a drop-in replacement for their JavaScript front-end library, then move on to a backend technology like either GRB or rendering front-end components on the backend directly.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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. It would basically automate it so that I don't have to write REST code myself directly. So yeah, these are some of the ideas in the pipeline for Glimmer DSL for web.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So I explored that idea with my older Glimmer web library. It was called Glimmer DSL for Opal. It was just a library that was exploring using Opal to render user interfaces. And the approach of that library actually was very different from Glimmer DSL for web. Its approach was actually to hide HTML and CSS files.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
completely from developers so that they actually work with a GUI mental model that was similar to the desktop. It even used the same widget or control names, like you could say tag names, that were used for building the Eclipse SWT library. So I was trying to match the syntax of Glimmer DSL for SWT.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Yeah, so the good news is that it's like the 80-20 rule. In general, you... You write very simple GUIs that comply to the style guidelines. And you can write those GUIs very quickly, very little code using Glimmer. But 20% of the time when you need to have your own customizations, you can actually build... completely custom user interfaces from scratch if you prefer.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Yeah, sure. My name is Andy Mallet. I have about 20 years of software engineering experience. And I've been programming since I was a kid, really. And yeah, I have a bachelor's degree in computer science from McGill University in Montreal and a master's degree in software engineering from DePaul University, Chicago.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
What that enabled is basically I could take any desktop game or app that was built with Glimmer DSL for SWT and run its code in Glimmer DSL for web without writing HTML or CSS. I would just keep the same exact desktop code in Ruby and it would run the app in the browser.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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 my however, practically speaking, from like a business web development point of view, I don't think it's a very practical idea. I think most developers want to know about HTML and CSS and they want to do things following more the web way.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And if I hide HTML, CSS from them, I don't think they'd be pleased. But also, if I were to take the other approach, which is use HTML, CSS on the desktop, that causes the other issue, which is desktop developers write a lot less code because they don't have to muck with HTML, CSS. Desktop GUI libraries are usually simpler than web stuff.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So I think it's better to just keep the two technologies in a way separate with their DSLs. because I believe web requirements are different from desktop requirements.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Um, yeah, this is one of those ideas that sound good on paper, but when you start actually following them in practice, they're not very practical. Like I know people. Yeah. I mean, so yeah, I guess that's my answer.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Yeah, sure. This year, so I'll be presenting a newer version of the same workshop I conducted last year. It was a two-hour workshop called How to Build Desktop Applications in Ruby in 2023. In 2024, it's going to be How to Build Basic Desktop Applications in Ruby. This one is going to be limiting the workshop content
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
to the basics of desktop development so that it gives people more time to breathe and also digest the ideas related to MVC pattern, MVP, and bidirectional and unidirectional data binding. So it will give people a lot more time to be able to play around and learn a desktop version of Glimmer. So the version used is going to be the Fukuoka Ruby Award.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
The one, sorry, the one that won the Fukuoka Ruby Award. It'll be Glimmer DSL 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 do include in the workshop description the instructions. Like I tell people just install the Ruby gem and then run a sample to make sure it works and you're good to go.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So I'll be basically using that library as an educational library for building very small desktop app. So Glimmer DSL for LibUI, what's good about it is it'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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So you can package anything, like you can scaffold an app with it, support 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 will just install the gem and use it. So I would recommend this library the most for people that want to build productivity tools for day-to-day work.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
But then you have to do a lot more work. So you can actually do things that are the same things that you could do with HTML and CSS, but in desktop, 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, 2D games or stuff like that.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
If you want to package your app as a Mac app or a Windows app, this library does have two options for doing it. Its Windows option works very well. Its 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 a blog post that I linked to.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So it does offer some packaging options, but they're not the most complete or comprehensive today. I have other libraries like Glimmer DSL for SWT lets you package your apps as real native apps with like an EXE or MSI installer on Windows or DMG file or PKG file on Mac. or even Debian files on Linux or RPM.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So that one, if people want to build a more serious app, I would recommend Glimmer DSL for SWT. But if they're building a very quick productivity app or small app that will show a table that is summarizing data from a database, I would recommend Glimmer DSL for LibUI.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Yeah, one cool thing that I've been doing is actually whenever I add features to say Glimmer DSL for Live UI that I think are useful, I end up also adding them to Glimmer DSL for web. Like one such a feature is component slots. So now if I build, for example, a name and address form, like I mentioned earlier, as an example, I can provide add slots in it and people can contribute components
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
or like markup inside those slots. In a desktop app, there would be contributing controls. So that way people can, for example, add a message at the top of the name and address form between the name and the address that can inform people of something or they can add another form like a nested form within it or do stuff like that. So, I mean, this feature is called component slots.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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, I think, Vue component, the Rails library has slots as well. So anyways, that's something that I ended up adding to Glimmer DSL for lib UI first, and then I added it to Glimmer DSL for web.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And it works very well because then it enables any, like if you take any component, you're not limited by what the people who built the component did in it. You can actually open it up. It follows the open-close principle. You can open any component up without touching its code. So it's closed for modification, but it's open for extension.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And you can add anything to that component in the slots that are designated for the changes for anything to add.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Nights and weekends. Especially long weekends like Labor Day weekend or whatever, any long weekends. I end up using them for this, but it's my passion project. And also, in my opinion, I really, really think the current front-end development experience in Rails is very, very bad. Every time I receive a PR on a React component at work, I'm like, wow, this code is absolutely awful.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And it's the best code they could write, by the way. I'm not faulting any whoever wrote the code. It's the React way. But React's code is so absolutely awful. And I mean, so I dabbled with other approaches. Like I was going to consider recommending Svelte or Vue.js at work. But then that's when I thought about Glimmer and Ruby. And I'm like, wow, I could even do better than Svelte and Vue.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
In general, if you don't have diagrams or games or anything that's very custom, it's better to stick to using standard GUI toolkit controls like text field, list, combo box, etc.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And in my opinion, I succeeded at that. So yeah. I think part of it is passion. 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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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. on top of it, like basically it pays for itself. So like,
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
like if people try to say, give you an excuse of, oh, I don't have time to check out this library or try it out. I'd be like, no, you don't have time not to check it out because right now you're spending 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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So it's actually paying for its own investment automatically, like just by exploring this library. So in my opinion, so that's another reason why I'm into it. Like, I believe it's going to,
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Not in Glimmer DSL for web as much because it intentionally honors the HTML markup language almost exactly as is. So for example, if you want to use an on-click listener, any on-click attributes or on change or on anything, They're all supported automatically in Glimmer. So all your knowledge, you'll be able to transfer it to Glimmer.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
But following a different way, you just have to write the code with less code. Instead of opening and closing every tag, you don't have to open and close the tags anymore. You can just put the tag name and then open a block with curly braces and then close up curly braces and you're done. So it's more dry. People who write HTML don't write dry code. because HTML itself is not dry.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I mean, that's part of the reason why XML became obsolete and people started using JSON, because JSON is a lot drier than XML. But unfortunately in web view development, like people haven't made that transition yet. So this approach is like one key reason for the design of Glimmer DSL for web being different from Glimmer DSL for Opal was to enable people to not have much of a learning curve.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
They can just transfer their HTML skills uh, as is. So like any attributes, you know, on any, uh, elements are supported by Glimmer DSL for web and any listeners are supported in any, um, and, 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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I don't think so. I think we covered everything.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I don't think I have anything, to be honest. I think the topic of this podcast will give people a lot of stuff to check out already. So I would recommend checking out the Glimmer DSL for web GitHub project. run like the online hosted sample and play around with it. It has a bunch of samples written in Ruby.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Um, and then lastly, I would recommend obviously for everyone to, uh, take a, 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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Do you control the leader arm directly? Or do you give it voice commands? Or does it follow your arm using a camera with AI vision?
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So what are some applications of this robot's arm? Like what did you use it for that you think could be?
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Yeah, sure. So Ruby Motion has two parts. There's the Ruby Motion mobile development aspect of it. That one supports iOS and Android development using Ruby code. I've actually tested it to build like a demo, like a proof of concept iOS app, and it works. It's very nice. It might have been last year or the year before was when I tested it. It still works.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
They can find me on LinkedIn. I'm just Andy Malley on LinkedIn. Or I mean, I have a Twitter called Andy Optiva at Andy O-B-T-I-V-A. And what else? And then if they need to reach out to me about Glimmer directly, if they visit the GitHub project, there's a Gitter chat link. So they can click on the Gitter chat link and that would take them to a chat room that is all about Glimmer.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And then they have a desktop component, but it's not cross-platform. It's only for the Mac. So that part overlaps a bit with Glimmer, but I would not use it. I would rather use Glimmer because when you build a Glimmer app once, it runs on all platforms. And if you're using one of the native GUI toolkits like LibUI, WX Widgets, or SWT, your apps will look native on every platform as well.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
But the mobile aspect of RubyMotion is very cool. Actually, I do want to explore the idea of building a Glimmer DSL for RubyMotion mobile. That would be very cool because then I can write the app in Ruby with a nice DSL and it would run on iOS and Android. So that's something that would be interesting to explore. But otherwise, DragonRuby is more optimized for gaming
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And yeah, Glimmer allows you to build games, but it's not optimized for games. It's not about like offering you the best performance for games or anything like that. Although its libraries are pretty optimized for performance, like they do run fast, but the library itself is not tailored towards gaming.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I would still recommend if people want to build complex games, Dragon Ruby is definitely the way to go. Or something else like Ruby 2D, or there are a few other libraries for gaming as well.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And I guess I became famous when I won the Fukuoka Ruby Award in 2022 for my project Glimmer DSL for LibUI. which I presented at RubyConf three times already. I'm going to present it for the fourth time this year. And I've also spoken at RailsConf twice before.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Yeah, sure. I mean, I mean, I personally experienced building desktop apps with Glimmer for quite a while now. And it's very quick to build any idea I have. Like one day I needed the metronome. I actually play drums as a hobby. And my phone metronome app got a bug in it after the latest update. So I ended up building my own metronome with glimmer as a desktop app. And I built it.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I bet I built the first MVP version in 10 minutes. And it was like, so amazing because of Ruby. Ruby is so awesome. And so, so, I noticed that I don't have the same productivity in web front-end interface development using JavaScript, not even close. Like JavaScript is so cumbersome.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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, For example, JavaScript makes you worry nowadays about const versus let, which to me, as a Rubyist, that's the least of my concerns when I'm building a business app.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I just want to focus on the business concerns, not on low-level details like that. They also have an import-export system, which... on the surface sounds great, but in reality, it's not like practically in Ruby, we don't, it's a lot simpler because we don't have that import export system and we don't care. Like it works fine enough for us without it. Ruby works pretty well for us.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So there are a lot of differences between JavaScript and Ruby as far as productivity. And, uh, There are huge differences. I mean, I know every once in a while DHH says online on Twitter or something that he thinks that JavaScript, after they updated it to ECMAScript, has become a great language. But honestly, I don't find it a great language at all. I think he's wrong.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I think he's kind of caved in to what the popular choice by people is instead of actually... being a leader and being like, no, we could do even better with Ruby. So a lot of those aspects are what prompted me to explore building a Glimmer using a front-end Ruby technology. And today in 2024, we do have front-end Ruby technologies.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Like we have Opal Ruby, which just won a Fukuoka Ruby Award in 2023. So it's a pretty impressive library that gives you a JavaScript to Ruby transpiler. So that way you can write code that will run as JavaScript 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 one technology.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Another one is Ruby Wasm. which compiles Ruby into like Wasm low-level code. And it basically gives you like all the features of Ruby 3.1 or 3.2 nowadays in the browser. And then there's also Ruby to JS is a third option, but that one is not as comprehensive as the first two options. I don't think you can build everything with it.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
But yeah, so I ended up choosing Opal as a start for building Glimmer DSL for web. 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 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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
I won one of the awards. Yeah, a special Fukuoka Ruby Award. That's what it was called.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
And after I proved that idea, I built Dlimmer DSL for web starting last year. And it took that approach of being more friendly towards people that know HTML very well or know JavaScript or CSS very well. So it has DSLs that are very close to them, to those languages. So it basically does give you an HTML DSL, a CSS DSL, which is optional.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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 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.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So Glimmer DSL for web is not limited whatsoever, given that you can integrate with any available JavaScript library out there. Uh, for example, I built a sample selector app that lets people visit a rails app that gives them a bunch of glimmer samples. Um, 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 app.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
Uh, it's, it's a web user, like front end apps, and then they can launch it directly in the, in the browser. So the syntax highlighting aspect, I didn't have to implement it myself from scratch. I used a library called highlight JS. And I was able to like integrate it very, very quickly. Like it took me just a few minutes or maybe a bit more than 10 minutes.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So Glimmer started originally as a desktop development GUI library. It was like I started it in the mid 2000s as a way of making myself learn Ruby. At the time, I was a Java developer and I did a lot of Java desktop development work at like a couple of companies. And I needed I heard about Ruby and I saw Rails and I thought it was awesome. And I'm like, why don't we do this on the desktop?
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
But so, yeah, so I mean, I was able to, after I experimented with the idea for quite a while, I took a page, like one of the sophisticated pages in my work website, By the way, I work for Lexop, which is a debt collection agency based in Montreal that uses web technology to reach people that are late at paying their bills, either by email or SMS messages. So we have a Rails app, basically.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
We're a Rails shop. And right now, 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 table of data with pagination, sorting, and filtering. I was able to rewrite it in Glimmer DSL for Web in about one day. But also the performance was just fast enough. I didn't feel like performance was too slow or anything like that.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
It was fast enough. The code was amazing. I was able to cut the total code by about half. And also the main React component was about 500 lines of code. And in Glimmer, Glimmer has a very friendly OOP approach of following MVC and MVP patterns. And with MVC and MVP, the React component mixes a lot of data concerns.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
It has state hooks and effects, and it mixes business concerns with the presentation of the view. Whereas when I rewrote it in Glimmer, it shrunk from 500 lines to 50 lines or something like that. So it was the one, yeah, it became a 10th of the size and all of the data management stuff that React lets you do with state hooks and effects got extracted into logic and a presenter or a model.
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
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 OOP for anything that is not view related. That's just mostly logic or
Ruby Rogues
Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653
So yeah, 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 that engineering manager of the company and engineering department manager, sorry. And we're going to be looking into an idea for rolling it out if the demo goes well. I hope it would go well. And one idea for rolling it out is... It's not a big bang thing.