Andy Maleh

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,

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,

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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

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.

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.

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.

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.