Elm Town 91 – Culture, codegen and (web) components with Joe Thel

Interesting.

Yeah.

So let's get into that a little bit.

So what are the specific cases where you use web components?

Sure.

I think of them as two different classes of web components that we need to use at Dgram.

One of them is a super general case that I think applies to everybody, which is that you just have leaf elements that you want to zhuzh up a little bit.

And to like move into the sort of pseudo component territory that Elm offers is kind of a pain or maybe just like more pattern than you want.

So like a really easy example is we have like an expando, right? You know, a little button, you click it, it expands, collapses.

We want to animate that.

Animating that smoothly when the content of it is dynamic means that you have to measure it in JavaScript.

You can measure it in Elm too, but you are moving out into either subscription territory or even port territory.

And then to do that in a sort of modularized, componentized way, you are putting in a lot of where if you just used a custom element, you're writing like eight lines of novel code, maybe.

So that's class one, which is zhuzhed up leaf elements.

And then class two, and this is a DeepGram-specific problem, although not unique

to DeepGram, is

we have a lot of stateful JavaScript-y things to deal with, mostly web sockets, microphones, audio contexts maybe more generally than microphones.

But obviously, as an audio-focused company, DeepGram has a lot of these features that it needs to build.

And if you're going to use a WebSocket, well, you're bouncing out to JavaScript no

matter what.

And we found that web components are really probably the, OK, personal opinion, but I think the best way to manage that rather than ports and then having a socket manager that kind of live as like freestanding code.

Yeah.

Yeah.

I mean, that makes sense.

So you have these two different cases where you really get a lot of benefit from using them.

Interesting.

Yeah.

So let's get into that a little bit.

So what are the specific cases where you use web components?

Sure.

I think of them as two different classes of web components that we need to use at Dgram.

One of them is a super general case that I think applies to everybody, which is that you just have leaf elements that you want to zhuzh up a little bit.

And to like move into the sort of pseudo component territory that Elm offers is kind of a pain or maybe just like more pattern than you want.

So like a really easy example is we have like an expando, right? You know, a little button, you click it, it expands, collapses.

We want to animate that.

Animating that smoothly when the content of it is dynamic means that you have to measure it in JavaScript.

You can measure it in Elm too, but you are moving out into either subscription territory or even port territory.

And then to do that in a sort of modularized, componentized way, you are putting in a lot of where if you just used a custom element, you're writing like eight lines of novel code, maybe.

So that's class one, which is zhuzhed up leaf elements.

And then class two, and this is a DeepGram-specific problem, although not unique

to DeepGram, is

we have a lot of stateful JavaScript-y things to deal with, mostly web sockets, microphones, audio contexts maybe more generally than microphones.

But obviously, as an audio-focused company, DeepGram has a lot of these features that it needs to build.

And if you're going to use a WebSocket, well, you're bouncing out to JavaScript no

matter what.

And we found that web components are really probably the, OK, personal opinion, but I think the best way to manage that rather than ports and then having a socket manager that kind of live as like freestanding code.

Yeah.

Yeah.

I mean, that makes sense.

So you have these two different cases where you really get a lot of benefit from using them.