Andy Maleh

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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