Valentino Stoll

speaker

350 appearances 6 recordings 1 series first heard Sep 2024 last heard Oct 2024

Valentino Stoll’s voice in public audio — every appearance, attributed to the second.

Trend

recordings per month · last 12 months

No recordings in the last 12 months.Older appearances are listed below; set an alert to hear about the next one.

Appearances

newest first · ▶ plays the moment

Ruby Rogues · Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653 · 25 Sep 2024 podcast

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, 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 Rails?

Yeah, I mean, so, like, what's been your overall experience, like, as far as, like, you know, why move to Glimmer as an example? Oh, good. You know, like, is it kind of straightforward if, like, a team that hasn't seen Glimmer before to, like, make the transition pretty easily? I guess you'll find out.

That's really cool.

No, I'm not familiar.

There's been so much work and to be honest, so many failed attempts as well along the way. But I think we're finally getting somewhere. Looking at your example Rails app here, you have a sample Glimmer DSL web app for Rails. People can 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 backend. And it makes a lot of sense. And it's definitely like, we are getting closer here.

Yeah, totally. And so like I wanted to dig in here a little bit because what we're talking about is kind of like componentizing like these front end pieces into a more modular way that can be reused and encapsulated in more of the Ruby way and trying to keep it to Ruby as much as we can, right? Without like degrading the front end performance too much.

And so I want to talk about that componentization, like creating these web things, right? Like if I have a form, can I make a form component? Is that like straightforward to do with the Glimmer DSL? What has been your experience with like encapsulation there?

Yeah, that's really cool. And I mean, I think that's been one thing that's caused the divide too, to be honest, in that, you know, people like to stylize and make their own web components with React or whatever framework that they've, you know, that they've chosen and handle all their, you know, front end interactions and stuff. But then

you know, have to request that the backend team like help supply that data or new, like as data changes, like how do you add and adjust to the component without, uh, you know, the data being there on the backend. And so you have this like dual edge coupling. Uh, 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.

Um, so how, I'm wondering like, uh, 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 gonna be focusing specifically on styling and adjusting the components. Like, is it still kind of a straightforward process of like HTML, CSS kind of manipulation for front end styling of the components? Or is it take more of like a, I need to learn Glimmer DSL, you know, aspect of things?

I see. Yeah, I mean, that makes a lot of sense. Looking at more of these examples in this Rails sample, you're using an external code highlighter, which is really cool. And it's just all in Ruby. Yeah, really, really cool. So I'm curious, what's the deploy process look like for this stuff? Is it the same as any Rails app, any Ruby app? What's that look like?

Yeah, totally. And thinking more about, like, the bundler aspect of it, it makes me think of, what was it, Rails Assets, if you were familiar with that, where Rails Assets was, like, basically just a gem format where you could pull in Node-related NPM packages into your Rails asset pipeline, which was, to me, like, super great. It didn't require any of the, you know,

javascript packaging systems or or extra dependencies like that uh and it worked great and just bundle install and it included all the assets that you needed and handled all that and i do miss that and so i'm hopeful with this uh kind of uh push here that we can kind of get back to something like that uh which makes brings me to my next topic uh of uh turbo

Yeah, I agree with you there. Definitely, and having the context switch constantly between the two definitely slows down the development. For me personally, I don't want to speak for everyone, but... Yeah, I mean, I feel like we've been driving like we keep talking about this.

We keep driving toward like a more like view component style, like in an application development process that is getting closer. And this seems to be like crossing that bridge of the missing pieces to 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 backends.

Yeah, very awesome. I'm looking forward to seeing that come together. I'm sure I'm not the only one. Yeah, me too. So like this brings me to my like last kind of question, I guess, is like the, you know, how does, are there any plans to bridge the gap of consolidating the application development to allow automatically creating both for web and desktop?

and mobile and XYZ, like, is that a desirable future? Or is that better to keep things separate still?

Yeah, that makes sense. I know having worked with like React Native, it is painful even just between like, you know, separate provider platforms of iOS and Android and having to do Windows and Linux and managing that, you know, I can't imagine that's helpful to have to do that. for everything.

Showing 201–220 of 350 · page 11 of 18