In this episode of JavaScript Jabber, our host Charles Max Wood, panelist Dan Shappir, and special guest Yoav Abrahami, CTO of Wix Enterprise, engage in a fascinating discussion on the evolving landscape of web frameworks. They dive into the functional and nonfunctional requirements of frameworks, the emerging innovations in meta frameworks, and the significant market shifts driven by increasing regulations and AI advancements. Yoav shares insights into his work on creating a collaborative web framework aimed at bridging the gap between designers and developers, while also addressing crucial future trends in security and design-to-code capabilities. Tune in to explore the dynamic future of web development with insights from industry leaders.

Charles Max Wood [00:00:05]:
Hey. Welcome back to another episode of JavaScript Jabber. This week on our panel, we have Dan Shapiro.

Dan Shappir [00:00:11]:
Hello from Tel Aviv.

Charles Max Wood [00:00:13]:
I'm Charles Max Wood from Top End Devs. Hello from Lehi, Utah. We also have a special guest, and that is Yoav Abrahami. I hope I got I hope I got close, Max.

Yoav Abrahami [00:00:24]:
You got it right.

Dan Shappir [00:00:27]:
It's

Charles Max Wood [00:00:27]:
Yeah. I got on when you guys were chatting when I hopped on, and I was like, yeah. My Hebrew is atrocious because I don't speak it. So yeah. Anyway yeah. So you're, VP. Did I get that right? No. CTO of enterprise at Wix.

Charles Max Wood [00:00:44]:
Right?

Yoav Abrahami [00:00:45]:
I'm CTO of Wix Enterprise, which is like a it's funny to say it's like a small startup of trying to take Wix, which is mostly a consumer product and designer product, and adapt it to enterprise sales. And Okay. So it's exciting.

Charles Max Wood [00:01:05]:
Very cool.

Dan Shappir [00:01:06]:
So, we actually had you out before, just so you know. Yeah. I

Charles Max Wood [00:01:11]:
was gonna say I think we got you before.

Dan Shappir [00:01:13]:
Yeah. We had you out before about almost two year about two years ago, I think.

Yoav Abrahami [00:01:18]:
Two years ago, I think. Yeah. That that was that was exciting. It was a very different topic, I think. And, we had a very heated debate there about Yeah. The clouds and code ownership.

Dan Shappir [00:01:32]:
Yeah. With AJ, who unfortunately cannot join today.

Charles Max Wood [00:01:37]:
Yeah. I'll put a link into the, into the chats. So if you're watching on YouTube, you can pick it up there and and go listen to that one too. So so besides your, I guess, your title at Wix, what else has changed last few years?

Yoav Abrahami [00:01:53]:
So, you know, the first thing that to change was that, I used to be the head of a Wix developer platform, a coed of that, moved to another position. I'm also working on another initiative, which part of it is creating a new, web framework, which is kind of why I'm very interested in that topic of web frameworks. Uh-huh. And I think those are two major things. You know, when you talk about Israel, there is another big thing that happened in the last year and a half. Uh-huh. I think they will probably leave that out of the podcast.

Charles Max Wood [00:02:33]:
Yeah. Yeah. The the the political situation there is a little bit

Dan Shappir [00:02:38]:
brought War.

Charles Max Wood [00:02:39]:
Everything, but, yeah, the war. Yeah. I keep hearing about, hostages coming home, which is a good thing. So

Dan Shappir [00:02:47]:
Yeah. The last, the last few weeks have been, you know, kind of a bright spot in, this, pretty Yeah. Dark tunnel that, hostages that have been held for coming on five hundred days are finally being released. Basically, a year and a half. Yeah. Yeah. K. Yeah.

Dan Shappir [00:03:09]:
Yeah. Hopefully, it will continue. They are being released, you know, in small batches every a a few every week, and, hopefully, this will continue. Anyway Yep. Yeah. Let let's talk tech, though.

Charles Max Wood [00:03:22]:
Yeah. Let's talk tech. So so framework. So you said you're building your own framework, which, you know, I guess it's been a week, so we can use another one. Do you wanna just, talk briefly about that and what you're pulling together? I I I don't know. Maybe Dan had a different direction he wanted to take this.

Dan Shappir [00:03:39]:
No. It's fine.

Yoav Abrahami [00:03:40]:
I I think you know, what I'm trying to solve is the problem of designer and developer collaboration. Oh, okay. So it's trying to do a form a framework that allows a designer to base basically publish or deploy the application.

Charles Max Wood [00:04:05]:
Okay.

Yoav Abrahami [00:04:06]:
You know, think about the designer changing the application and deploying the application. That's kind of what I'm trying to solve. It's a it is a very, very big requirement.

Charles Max Wood [00:04:20]:
Uh-huh.

Yoav Abrahami [00:04:20]:
And the funny thing is that it actually turns it actually becomes evident at some point that it is actually the same requirement as allowing you to consume third party components in a safe way. You know? So think about using some other component of the of another company and not being exposed to the to the code in a way that can risk greater risk to your application. And Mhmm. It it somehow or in order to support designer developer collaboration, when when you break that requirement down into what it means, you get that other possibility as well. Again, it's still work in progress. It's very, very experimental. And so I'm not going to go and, you know, steal the podcast, make an announcements, go and look and use my framework. That's not the point.

Yoav Abrahami [00:05:16]:
But this is something of why I'm very opinionated and why I'm looked very deeply into different frameworks.

Dan Shappir [00:05:23]:
It's an interesting thing that when JavaScript and the DOM along with it were created, they were created specifically for designers or, tinkerers. The actual developers were supposed to be using Java or something like that. And it's interesting to see how, you know, the developers have kind of co opted JavaScript and TypeScript. And with the frameworks, the heavy duty frameworks that we have today, they're definitely geared towards developers and much less towards designers or people like that. You know, I'm thinking like, if I'm, you know, somebody learning to code and being thrown into React, that's it's easy to drown, I think.

Yoav Abrahami [00:06:13]:
I think it's even more than that. Think I'll take you in two different directions. One, think about the and system fifteen years ago. Fifteen years ago, a developer would never deploy an application. That would never happen. They would build something up, then give it hand it over to system. They would do acceptant tests. And then after testing, checking, they would deploy the application at some point.

Yoav Abrahami [00:06:43]:
And then we had DevOps, which changed the way we work. It moved the responsibility to deploy an application from system to the developer, and it gave developers the tools to make the application work and different tools than the ones that system have. And what I'm looking to do now is to shift it again from the developer to the designer. Now just think about it. A designer that has no idea how to code, has no understanding of creating and running an application or a stable application would deploy your application. That sounds scary, but that's actually what happened with system and developers fifteen years ago. Now it also means that the tools today that the designers are using are very different. They're not going to write HTML or CSS.

Yoav Abrahami [00:07:31]:
That's not how how they work. If you go and look at what using, you know, Photoshop, Figma, you know, there's tools. It's not HTML and CSS. So you need to bridge a much larger gap and then end over the responsibility to them and end over the tools to them so that they can be, you know, effective and own the application.

Dan Shappir [00:07:54]:
That's what we have AI for. No?

Yoav Abrahami [00:08:00]:
Well, you know, AI can do a lot, but, unfortunately, up until today, it didn't replace the developer or the designer. We still have a few years for us at least.

Dan Shappir [00:08:18]:
You know, when people ask me if I'm worried about, AI replacing development developers, I say, well, you know, eventually, AI will replace everybody. So it's just a question of time when they'll get to you. Nobody's safe. Anyway

Yoav Abrahami [00:08:37]:
Yeah. Yeah.

Charles Max Wood [00:08:38]:
Yeah. When people ask me the question as well, not yet. I mean, some of the tools are really nice, but at the end of the day, making the decisions that I make, they just are not there at all.

Yoav Abrahami [00:08:52]:
I I think I think the easiest way to understand that is if we'll give an AI to fly a jetliner, it would do that very well, probably better than any human pilot. It would flew it would fly a plane in a very correct way mountain. It would be very correct and and a very smooth flight, but it's okay for it to fly into a mountain. So I think You this is kind of the gap that we have with AI.

Dan Shappir [00:09:24]:
You remind me. I I had a friend who was a an airline pilot, and he basically described his job to me once as, like, a hundred hours of boredom and five minutes of pure terror.

Charles Max Wood [00:09:42]:
Yeah. I mean, we we've had autopilot for years, and it's been a tool that the pilots have used for years. And it's worked great. You know, we typically don't see too many, airline catastrophes, the last week notwithstanding. And, you know, but but it's a different problem. It's a different set of problems than what we're talking about with programming.

Dan Shappir [00:10:05]:
Well, it's actually easier for an AI to fly a plane than to drive a car. But, you know, let's put let I I would like to pull us back to, to talk about frameworks. And I would actually like to start with something that I've been thinking about a lot and, in fact, even had the kind of a change of of perspective about, and I can talk about that. But I first would like to hear you, Yov. And that's talking about what are, in fact, framework. What of, what constitutes a framework versus, say, you know, a library or a set of tools or an application or whatever?

Yoav Abrahami [00:10:42]:
So, you know, for me, the definition is actually actually pretty simple. Every software, everything, any kind of software in the world can be split into two kinds of interactions. There is an interaction that is going into your code, something calling your code, and there is an interaction where your code is called calling something else.

Charles Max Wood [00:11:09]:
Mhmm.

Yoav Abrahami [00:11:09]:
Now when your code is calling something else, you have a choice. You can choose which tool you are going to use to call something else. Now you have to use a tool. There is no way to call something else without using a tool. Might be a system library, might be a built in library, might be some higher level library like NPM or some other package. But there is always you are you have the choice almost everywhere of what to use. That is where it is a set of tools that you can just choose from. But when you are being called, you don't have the choice of who is calling you.

Yoav Abrahami [00:11:50]:
You are building an application within some kind of a container that runs your code or some kind of box that calls your code. This is what is a framework. It is a frame that is activating your code on different entry points. And then your code can choose different things and give and call some exit points, some using some utilities and some tools.

Dan Shappir [00:12:18]:
So I I I had the exact same outlook on frameworks versus libraries, but then my point of view shifted a little bit. And now I think about it more in the context of architecture. When I think about when you're dictating the architecture, it's libraries. When the architecture is kind of dictated to you, that's a framework.

Yoav Abrahami [00:12:49]:
Mhmm. But it's kind of same same.

Dan Shappir [00:12:52]:
Yeah. There's a big overlap, but but it does shift the the perspective a bit. I think that the best frameworks are the frameworks that the architect that they make the architecture of the solution that you're going to build more clearer. Let's let's call put it this way. You know where the pieces are supposed to slide in.

Yoav Abrahami [00:13:19]:
I think what you're talking here is about something a little bit different. The when you talk about, you know, frameworks, there's a few concepts that have emerged over time to make software to be easier to code against. You know? One is the ability to make it easy to be tested in in a simple environment. Another one is the concept of locality of definition so that all of the concerns are in one file and not spread across multiple files. And another thing that is a bit of little bit subtle is that the syntax is such that when you read it, you can understand what it does. You know, people tend to call it no magic, but I don't like that definition because we as developers consider everything smart that someone has written as magic. So it's not I won't say that. I would say that if it makes you write in a syntax that is easy for the average developer that is working with you to understand what's going on, then it is probably doing something good that far.

Dan Shappir [00:14:33]:
The principle of least surprise, basically.

Yoav Abrahami [00:14:37]:
Yep. So it still look yeah.

Charles Max Wood [00:14:40]:
So my question with that is, so, I mean, folks that listen to the show know that I do most of my work in Ruby on Rails, and some of that is true. Right? Some of it, you you read stuff or you read the code and it's you know, you pretty intuitively know what it does. Some of the stuff, you pretty intuitively know what it does because you've been doing Rails for twenty years. Right? And so you look at it and you know what the conventions are and you follow it. So how much of it's one and how much of it's the other, right, with React or Vue or any of these other tools that might give you that sense of, okay. I can look at this code and know what it is. How much of that is wow. It clarifies that that's what's going on here and how much of that is.

Charles Max Wood [00:15:20]:
I've been doing React for long enough that I know what that's what this code is.

Yoav Abrahami [00:15:24]:
You you know the measure of against a? You hear about that? When you go into a new system and you're like, hey. It's doing something really exciting. Woo. And then when you go into another and and then you try to make it do something and it doesn't work, and then you figure, it has to work that way. That's not intuitive. You know, that's the measure. It's the measure of Okay. How much times it's doing things in the way you expect it to be doing versus how much times it surprises you doing something in a very unintuitive way.

Yoav Abrahami [00:15:56]:
This is kind of a measure for APIs and developer tools to know how good they are. The the moments against the moments.

Dan Shappir [00:16:05]:
Yeah. I would like to add to that. You know, at the end of the day, I'm always drawn back to the no silver bullet article that talks about, essential versus, what was the other one? Essential complexity versus nonessential complexity. Mhmm. And, you know, we are solving complicated problems, at least we strive to to. And when you solve complicated problems, even when there are strong guidelines for what the architecture should be like, don't expect the solution to be trivial. That's point number one. And point number two, you know, you try to make your system idiot proof, but then somebody goes along and invents a better idiot.

Dan Shappir [00:16:52]:
So people will always find way to surprise you and works works against the grain of what the framework, encourages. You know But I think

Yoav Abrahami [00:17:06]:
I think, Dan, sorry to cut cut me, but there

Dan Shappir [00:17:08]:
is Go for it.

Yoav Abrahami [00:17:09]:
You need you need to look at frameworks in in three different aspects. There is one which is the functional aspect. Does it that does does it doing is it doing what you need it to be doing? And are different frameworks similar in terms of the functional aspects of the framework regardless of the syntax? And then there is a second question, which is when you look at the nonfunctionals, like, say, like performance, for instance, are they equal, or do you do you even care? Is the difference significant? You know, for example, is the fact that Svelte is much more efficient than React, is it something you really care about in your specific case, your specific application? And only after you're done with those two, with the functional and nonfunctional, only then you come to syntax and, you know, how now you are you are with the developer.

Dan Shappir [00:18:12]:
Yeah. But look. When I think about React, for example, for me, the core of React are few well defined concepts. You know, it's pretty unfortunate that a lot of React developers may not actually be familiar with these core concepts. And the core concepts, by the way, are, re the UI as a function, regenerating the entire UI from the state whenever the state changes, and you need directional data flow. Maybe I'm missing one or another one. But those are, like, the core concepts for me when I'm thinking about React. And then when I think about, let's say, Solid, it has different core concepts.

Dan Shappir [00:18:54]:
Or if I'm thinking about Svelte, it also has different core concepts. So a big part of, ideally, of choosing a framework would have been choosing the framework whose architecture or the architecture that it advocates for for building application best suits your personal taste. Now, unfortunately, most of us don't go through this process.

Yoav Abrahami [00:19:19]:
That's the

Dan Shappir [00:19:20]:
the framework choice is kind of yeah. Just to finish, because in a lot of cases, the framework choice is kind of dictated to us. You're right. But, anyway

Yoav Abrahami [00:19:30]:
It's it's, again, it's assuming that the functional is equal and assuming that the nonfunctional is equal, then you come to aesthetics. And what you're talking about is still just aesthetics. And, you know, React, you brought the concept of React. React is neither reactive nor functional today. You know, it's it's it has done a a lot. It does it done a huge work moving us forward as, you know, front end developers. It there is a reason why it is the number one framework today in the world. Right.

Yoav Abrahami [00:20:05]:
But it's kind of not what it aimed at doing. You know, context is you could argue that props, context, and state are all different ways to get data into the function, and two of them are not functional.

Dan Shappir [00:20:24]:
Well, you know, the DOM is not functional. JavaScript is not functional, and you're kind of living within the the framework itself is is living within the confines of the environment that it's built on. There you know, you could go with Elm if, you know, if you really want to go to the extreme, but that you know, there there's a price to pay for that as well. You know, let's say, ditching JavaScript in in favor of Elm or Reason or something like that.

Yoav Abrahami [00:20:56]:
No one said that the aesthetics is simple. Getting the aesthetics of a framework in the right way is super hard. And there is reason why we have lots of frameworks trying different directions and different things. You know? There you look at what's happening today. There is one major direction going on today, which is signals. Everyone except React has signals today. There might be some old frameworks that don't have them, that didn't adopt signals, but almost everyone except React are using signals as the main abstraction for state management. And there is a reason behind that.

Yoav Abrahami [00:21:39]:
It's trying signals on different places, different frameworks, different syntaxes seems to work. Trying signals in terms of the nonfunctionals performance, okay, again, seems to work. It seems to be something that people comprehend. By the way, signals is not a trivial thing. It takes time to understand that, but once you do, it becomes something that is very robust to use. So, again, it's just aesthetics.

Dan Shappir [00:22:06]:
Well, for me, it's more than aesthetic, actually, because it it it informs the way that you deconstruct or con the the problem and then construct the solution. So for example, first of all, I'd like to mention, by the way, that when we had, Joe Savona and Satya from Meta to talk about the React, compiler, Joe said very clearly that, signals are not in React's future. He basically said, you know, if if signals become a part of the JavaScript language, there's actually a proposal for that, then then we will and I'm speaking for Joe, then we will support it. But, otherwise, no signals for React because that's not the that's not their vision for for how, front end applications should be built. Their whole thing is about, you know, reconciliation and stuff like that.

Yoav Abrahami [00:23:08]:
But talk to what you're saying right now. You're talking about opinions.

Dan Shappir [00:23:12]:
Oh, of course. Mhmm. Frameworks are opinions. That that's kind of my point.

Yoav Abrahami [00:23:19]:
Well, I'd to be honest, I don't agree. I think that this is kind of this is kind of this is kind of a state we arrived by forgetting the functional and nonfunctional requirements. And we kind of set it very, you know, very basic frameworks that are, you know, not really that are just competing with one another on aesthetics and performance, and that's it. But there's a lot more other stuff that you can compete on.

Dan Shappir [00:23:52]:
Such as?

Yoav Abrahami [00:23:55]:
Let's talk about web essentials. You know, web essentials is a list of, I think, probably thirteen, fourteen items that when you're doing when you are working as a web developer, you need to take care of. And there are things like creating responsive design, being performant, breakpoints, multilingual, AB testing. So AB testing is actually not web essential, but it's nice to have.

Dan Shappir [00:24:23]:
Accessibility. Regulation

Yoav Abrahami [00:24:26]:
cookies regulation in the EU, accessibility, the new accessibility regulation in the EU now, GDPR, PIR, and there's more. And all of those Is there

Charles Max Wood [00:24:37]:
a list somewhere that that I could just publish?

Yoav Abrahami [00:24:40]:
I have it in my I have it somewhere. I can I can send it to you? And, basically, all of that list is anything you're doing, anything that is customer facing on the Internet, you have to take care of all of that list. If you're doing an enterprise behind the behind the login, you need to take care of most of it. And your SEO is another one. And all of that cost lot of money. Why aren't frameworks helping us with all of that list of stuff?

Dan Shappir [00:25:14]:
I think when you start talking about these things, you're again, and it's an an an interesting decision to make from from what I see. You're starting to move from talking about frameworks to talking about meta frameworks, from talking about React to talking about Next. Js, from talking about Vue to talking about Nuxt, and so on and so forth. At least that's been my experience with these sort of things. Most frameworks these days have a much lower bar in in the in the functionality that they are trying to provide. They are more about, you know, use us instead of using just the DOM.

Yoav Abrahami [00:26:00]:
But keep in mind, when you talk when you ask about what is the definition of framework, a framework is not defined as only something on the client that interacts with the DOM. It is defined, as you said, as something that imposes an architecture on your application that guides you into building better software. With that definition, I would expect the sub the, the framework to help me with all of the web essentials as well because it's something I have to do. It's something those are more constraints my application has to work with. I would I would expect the architecture of the framework to be such that would take care of those concerns or at least help me to take care of them.

Charles Max Wood [00:26:47]:
So I have to ask then because it seems like, you know, if you take this narrow definition of a framework, you know, whether it's, you know, an aesthetic way of putting together an application or whether it gives you the architecture, whether or not it provides you with some of these, essentials, you know, that you you would expect it to, It it seems like that it it seems like there are various definitions and maybe various expectations that people have of a framework. Right? Because I could expect that, okay. For me, the framework that I want will do all these things. For somebody else, it may just say, hey. Here's how you're gonna structure your application. Here's the understanding of here's where the pieces go. Here are series of tools, libraries, tool kits, etcetera, that make the API that I'm building against, that much more friendly. Right? And so there are all these different pieces that people consider when they have the framework, and it seems like a lot of people are picking it for different reasons.

Charles Max Wood [00:27:48]:
Right? So some people may be picking it because, hey. I want a more aesthetically pleasing thing, or I want to be more efficient in my time use by having the framework handle certain things for me or by fitting a mental model that I can sink my head into. And so, you know, you're you're saying, well, it's aesthetics or, you know, it's aesthetics and maybe some of these other things. But how do you really make that decision on what people should consider a framework?

Yoav Abrahami [00:28:16]:
I don't think there is one answer for what is a framework. I think the the role of the framework is to help us, to make us more efficient.

Charles Max Wood [00:28:28]:
Right.

Yoav Abrahami [00:28:29]:
And because, you know, I could just use jQuery, and that would work. Yeah. I would integrate with more applications. Yeah. And then we decided to move to React because it is more efficient to write code in React compared to jQuery, both in the first ramp up and then in maintainability. And then when you're taking just that those two concerns, the first ramp up in maintainability, and you're also starting to add things like accessibility into the mix, And you're asking, a, I mean, how much work do I need to do in a React application to make the to make it accessible versus can I get a framework that would help me to have lift that, you know, that burden in making me more efficient there? And the same can go for any of the other, you know, web concerns.

Dan Shappir [00:29:23]:
Mhmm. My experience, though, has been that most people who use JavaScript frameworks for the front end, because it pulls them kind of away from the ace the actual semantic HTML, end up with mountains of divs, which is anything but semantic and it anything but accessible, and so forth. And that if you want to get these in the context of frameworks, usually, what you end up is reaching for, library, for component libraries that are compatible with the framework that you can use from within the framework. Or maybe if the organization is large enough, then it creates, its own design system or adopts some external design system in order to get everything you described. So are design should design systems have been part of the frameworks? The framework itself, shouldn't they be pluggable to the framework?

Yoav Abrahami [00:30:33]:
I you know, I think saying that the framework allows a design system that solves some of the concerns is a way to support concerns. Now with accessibility, that might work. With multilingual or with GDPR or cookies, it you might need something else. Design system will not solve cookies regulation for you. So I think even though, you know, React and all of the frameworks allow design systems because, a, just makes it us much more efficient to use design system components, it's still not enough. So I really think that, you know, frameworks, we'll need to take that into account. We are in a in a market that, you know, we are shifting in light speed from an unregulated market to a very, very regulated market. And that means that the price of creating an application and a website goes up very fast because of those regulations.

Yoav Abrahami [00:31:37]:
And we don't know where we're going to end up with. And don't even we didn't even start talking about AI. What does it mean for your framework to make your application AI ready by whatever going to be the nominate AI client application that could going to be, you know, the next, you know, big deal in the Internet beside Google and Facebook and TikTok.

Dan Shappir [00:32:05]:
By by the way, when you're saying AI ready, are you talking about using AI to generate your code or about integrating AI functionality into the actual end product or both or something else?

Yoav Abrahami [00:32:21]:
I'm talking about something else. It's clear to for everyone that there is going to be a dominant AI application over the Internet. You know, right now, the Internet is about $100,000,000,000 market around search and about another $100,000,000,000 market around social. You can assume that there's going to be another $100,000,000,000 market around advertising or discovery or something like that with AI. We don't know the application. We don't know the provider. We don't know when it's going to happen, But it's probably going to happen something like that. And then you want your business to be listed there as well.

Yoav Abrahami [00:33:04]:
You know, today, when you build a business or any website, you have to be listed in Google and in social. You probably want a mobile application as well. You want to cover all the different fronts that you might get users from. So what would be that next front with AI? We don't know yet. But something will happen. And will when that will happen, how will your framework help you to be there in the right way?

Dan Shappir [00:33:28]:
So you're basically talking about having some sort of presence within an AI driven interface, whatever that might be. And that's kind of similar to how we currently have, like you said, let's say, a page on on Facebook or something or or or an or any or on Instagram or something like that. Is is that what you're talking about?

Yoav Abrahami [00:33:59]:
Yeah. You know, it's you know, think about think about 02/2011, a year before Facebook really become dominant. If at 02/2011, I would say, hey. Websites, you need to prepare yourself to social. We don't know what's going to be the dominant social application, but something is coming. This is kind of what I would sound like. So we know there's something coming. We just don't know what and who.

Dan Shappir [00:34:34]:
And and, again, maybe it's just me or the terminology that I'm familiar with because of React and and things similar to it. But React or Vue or Svelte or Solid have set their sights much much lower than that. As I said, if the the things that you're talking about are start are more in the realm of meta frameworks or even, you know, meta meta frameworks. I've heard the term stacks sometimes used. So for example, Ken c Dodds has his epic epic stack

Charles Max Wood [00:35:17]:
Mhmm.

Dan Shappir [00:35:17]:
Which involves, cert you know, obviously, Remix, but also and React, but also a particular, authentication provider and a payment provider and a database provider and so on and so forth. And you integrate all of these things together, hopefully, more or less seamlessly in order to get a more holistic type solution that might address the the the requirements that you seem to be talking about, or at least that's how it seems to me.

Yoav Abrahami [00:35:50]:
I I but I have to ask you a question. When you look from jQuery up to React and up to Angular, doesn't it seem the same? You know, jQuery is actually much leaner. It tries to do much, you know, compared to React. React is trying to so much more compared to jQuery. Mhmm. JQuery is just trying to abstract a little bit the DOM APIs. That's all. And it is a framework, the most popular one in the world.

Yoav Abrahami [00:36:19]:
And then React is also a framework, but it adds another abstraction layer on top, and Angular is the same. And then we're going we might add another abstraction layer on top. You know, you're trying to put labels on it, but why are those labels important?

Dan Shappir [00:36:37]:
Well, I actually think that labels are important. You know, they there's that statement that they are two hard things in computer science, cache invalidation, naming things, and off by one errors. And so naming things are act is actually pretty pretty important. You know, design patterns exist, are are basically ways of naming things so that we have a con a a common vocabulary. Mhmm. So so I do think that having common terminology is is actually important for us to be able to converse and exchange ideas and concepts.

Yoav Abrahami [00:37:19]:
I can accept that. But I just but I think that even having said that, a meta framework is just another framework that does more.

Dan Shappir [00:37:30]:
Yeah. Again, for me right now, again, my opinion may certainly change, but right you know, you you seem to have a very different definition. The definition that I used to have for framework versus meta framework was basically that it straddles both sides of the network divide. That, meta framework has a server side aspect to it, whereas the framework doesn't. Mhmm. But but your definition seems, again, to be much more holistic than mine.

Yoav Abrahami [00:38:05]:
Yeah. But, you know, but let's work with your definition. You know, I'm fine with that. So when I'm saying that frameworks will need to cope with all of the web essentials, it's fine saying meta frameworks will need to cope with all of the web essentials. Totally fine. It's a little bit limiting, but, you know, I don't care. That's fine. Now we can go to more extreme things that are happening with frameworks.

Yoav Abrahami [00:38:35]:
Again, meta frameworks might be. And I'm seeing two trends or two lines that are kind of intertwined together. One is the idea of the idea of gradual rendering. Yeah. When you you so when we start seeing that a little bit in frameworks, the idea of gradual rendering is that let's start shifting rendering back as much as we can. Now we have

Dan Shappir [00:39:09]:
service side you mean?

Yoav Abrahami [00:39:11]:
To the server side and to, earlier timeline. Now you already have frameworks that are doing the normally, we would call that a build time rendering or static site generation, but actually don't like this definition. When when you look at data, you have data that changes slowly, like blog post and products and I don't know. There's many things that change slowly. And then there's things that change fast, and then there there are things that change interactively when user clicks on something and something changes on the client. So interactive things have state management and run on the client. Fast changing, you need to do an SSR. Slowly changing, you could do an event of something changed.

Yoav Abrahami [00:40:02]:
Why can't I combine all three of them in one page in one component? Now you're starting to see things like that happening. React server components lets a developer to choose to have one layer server rendered, which is only server rendered, and then have another layer or another subcomponent that is rendered on the server but is also interactive on the client. Quick is starting to do stuff like that. Your other folks are starting to do stuff like that, but I haven't really seen that as being a first class pattern in any of the frameworks.

Dan Shappir [00:40:45]:
I would take it a step further. It seems to me that and and I'll be blunt. It seems that framework makers are solving a problem that the market is not looking for them to solve. I'm you know, I I've spoken to a lot of organizations in this context who basically say, you know, we want React on the front end and something else doing restful APIs on the back end, and I don't and I don't want React on my back end. And and Next and Vercel's success not notwithstanding, the majority of enterprise React applications that I'm seeing are very much keeping the framework on the client side only.

Yoav Abrahami [00:41:43]:
You're right. And yet when you go and when and keep in mind that Vercel is building websites. In website, you must have server side rendering because of SEO, again, because because of web essentials. But then even for the enterprises, they get to a point where they say, hey. But we have a performance problem or we have a flickering or a text load long to load the page, and we need to do something about that. Now when you run React on the server, when React was not designed to work on a server environment, what Vercelia were doing is actually very smart, but they're trying to take something that doesn't really fit in that environment and make it work in that environment. It wasn't designed for it. Think what would happen if you actually go and design a framework that would work in such a way and would support both the website and enterprise use cases.

Dan Shappir [00:42:41]:
Well, I guess, Chuck, you're supposed to say at this point that's why we have Rails and, what what's the name

Charles Max Wood [00:42:49]:
of been refraining from saying that this whole time. So Rail

Dan Shappir [00:42:53]:
rails. And what's the name of that the the thing that you use in Rails? Stimulus or or the other one.

Charles Max Wood [00:43:01]:
A turbo?

Dan Shappir [00:43:02]:
Turbo, stimulus, whatever. You've got a whole bunch of terms

Charles Max Wood [00:43:05]:
for it. Wire?

Dan Shappir [00:43:07]:
Wire. I think that was the one. Yeah.

Yoav Abrahami [00:43:10]:
Well, Rails did a lot of really good stuff. And it tickets kind of when you look at the what I would call the 1.5 age of the Internet, which is basically static basically server side rendering everything and a little bit of JavaScript, little bit of jQuery on the client. Your WordPress is there. Shopify is there. Rails is there. Rails is kind of the best of the breed. Mhmm. But it does suffer, and there is a reason why we move to web two point o, which starts with React and Angular, which are client first libraries, simply because you want to be very productive on the client and very interactive on the client and very fast on the client.

Yoav Abrahami [00:44:01]:
And then, you know, when you start moving from front end libraries back to the back end, why would they use a different language for the back end and the front end? Why would they use React on the front end and Rails on the back end? It makes my life much harder, and only that would be two different people. You know Rails in a very good way. For someone else that needs to learn both React and Rails and how to connect them together, that's harder than using Next. Js. And, again, it's the lock it's the the

Charles Max Wood [00:44:33]:
it's the transpore of vitality. So Yeah. Yeah. I thought you were gonna go to express or something. I'm like

Yoav Abrahami [00:44:41]:
No. Express Yeah.

Charles Max Wood [00:44:43]:
Express If you're going if you're going react to next, I I can I can I can see that?

Yoav Abrahami [00:44:48]:
Yeah. And I think what we're what I would I think we're kind of, Dave, kind of converging on is there's them that I just don't want to use. So instead, I'm going to say frameworks that are designed both for the back end and the front end is first as citizens. And when you when Okay.

Dan Shappir [00:45:15]:
I I'm going to make a, a conjecture. Well, I mean, I think, that what you or or at least what I'm I I I'll restate what I seem to be, hearing you say. You're basically saying most modern frameworks that we've seen started their started out client side and then evolved to work on on the back end as well. So Next. Js grew out of React, and it's effectively implementing a React specification. Nux grew out of you, so on and so forth. What you're saying is, you know, we've had Node JS and whatnot on the back end long enough so that we can think about frameworks evolving the other way around, starting their life on the back end and then evolving to support the front end? Is is am I am I getting the gist of what you're saying?

Yoav Abrahami [00:46:14]:
Almost. What I'm saying is think about the framework that is designed to work on all three life cycles of the web. And you have three life cycles, not two of them. You have one for slowly changing data, like product was updated maybe once a day or once a week. You have a fast change in data that you have to render for a user directly on the server, like username or cookies. And then you have interactive data or interactive interactions on the client and state management. And there it doesn't make any sense that those are three different obstructions that are done in three different ways. Why can't I do them in one why can't why can't I get the framework that speaks in that language and just does it all and not force me to start meshing up different things and different concepts to try and understand what goes where.

Charles Max Wood [00:47:20]:
I mean, a lot of these things that you're talking about are things that, I mean, I I kinda manage this stuff so that it changes when it needs to or gets you know, interaction happens when it needs to. I I don't know that I think of them as all that different. Right? They they all more or less use the same mechanisms, or am I missing something?

Dan Shappir [00:47:42]:
Well, let me put it this way. What I'm seeing a lot, basically, people dealing with this problem by effectively ignoring it. So for example, if they they built a wholly client side render application and just make calls back to the to end point to restful endpoints whenever they need to get more data. So they they don't need to think about how often the data changes. So they respond quickly Mhmm. To client side interactions.

Yoav Abrahami [00:48:12]:
Mhmm.

Dan Shappir [00:48:14]:
And then whenever they need to get, you know, data from the back end, they just call a restful API and, you know, it comes whichever way it comes. So so, effectively, they respond to both types of interactions or through all three types of interactions in essentially the say the exact same way, by by writing event handlers in JavaScript, that that handle events. These events might be a user, a mouse click, or these events might be some data arriving over the network. But it's it's all the same. And I I agree with you, Av, that, React server components have been trying to propose a new approach to dealing with it, basically saying, you know, I'm rendering some stuff on the server. I'm rendering some stuff on the client. I'm rendering some stuff on both sides. By the way, I'm I totally don't know how many organizations are actually using React server components in production, certainly in anger, let's say.

Dan Shappir [00:49:27]:
It's it's an interesting question. You know, as I said, there there's a growing you know, it seems that Next. Js is eating the React website market that the majority of new React websites are being built using Next. Js, but I have no idea how many of them are actually using React server components. Certainly, how many of them are actually using React server components correctly? That's that's a totally different question. It's an interesting one, and I don't know how to get this data. What are how do you think a solution to that might come along or might look like that actually solves that problem with lower friction and greater acceptance?

Yoav Abrahami [00:50:18]:
You you can see what both next and well, I forgot the name. There's another framework. And they're doing data loaders that by the name of the data loader function, you know on which environment to run it. You can look at what Quix is doing where you can there is a different a specific API, which is very similar, but specific API that says, hey. This is something that runs on the server. Or I think in the case of QUIC, everything is by default running on the server and only being loaded to the client if needed. And the compiler is kind of understanding what needs to be downloaded to to the client. I think we need to figure out the syntax.

Yoav Abrahami [00:51:05]:
We don't have it today.

Dan Shappir [00:51:08]:
By the way, syntax, as far as I can tell, seems to me the solution that these, meta frameworks, I'll use that term, are adopting seems to be RPC based. So that when it's it's call it's it's functions that when they are executed on the server, it's just it's just a a function call. But when they're executed on the client, it's it becomes, serialized automatically over the wire. Yeah. So that's the abstraction that I'm seeing kind of being adopted for addressing that issue. Now even that has different approaches associated with it. So both let's say, we had Tanner Lindsley talking about what he's doing with, 10 with 10 stack start. And he's also using, RPC, but he's doing it in a very different way than the way that Next JS is using.

Dan Shappir [00:52:15]:
Even though you might say that in both cases, it is kinda RPC.

Yoav Abrahami [00:52:21]:
Yeah. Anyway, I wanna take you even one step more. You know, you we talked about design systems. You're using the you're using components from design systems. Sometimes those components have a large number of configuration options. You know, for instance, you might have a gallery that have might have multiple layouts, and you might be choosing one layout or another. And if that choice is static, it's basically a constant, or even if it is a a choice made by slowly changing data, why would you download to the browser the full component with all of the different options? Why not start looking at the values of slowly changing data, which after defining what is that that value, it basically become constant data after the that first phase of rendering. And then let's start deleting all the unnecessary code.

Yoav Abrahami [00:53:30]:
So all of the other layouts of the gallery, they don't need to be there. All of the other style options don't need to be there. It might have you might have, you know, different tabs or different, you know, screens or different options that you can just delete and just remove. And it might go all the way down to your to your design system that might have lots of very complicated components because they need to cope with lots and complicated situations. You know, a drop down with 50 different options of how to open a drop down, but they only need one. So why would you download the browser all of the different options? So there's also another potential here for lots of very aggressive optimizations that, to be honest, no one is doing today.

Dan Shappir [00:54:17]:
Well, I think WIC, you guys, that you mentioned is kind of trying to do so at least some of this stuff. Basically, it's, using a compiler to or bundle or or smart bundler or or transpiler, call it what you will, to to decide for you which codes needs to exist where effectively. And then, you know, again, if if we're talking about stuff like, like, the the hot wire that, that Chuck mentioned before, you know, when we spoke, with about, what's it called, HDMX. It's basically saying why why do why send JSON over the wire that I need to have smart on the client side to be able to process it according to, you know, sophisticated logic and transform it into HTML when I can just send HTML. And and and to an extent, again, React server components are kinda going in that direction. They're not actually sending HTML. They're sending virtual DOM as it were over the wire. But but they are but, again, it's it's basically the idea of having gen a generic mechanism that transforms it into UI rather than having to download all the custom logic.

Yoav Abrahami [00:55:45]:
But think about what's happening here. You have lots of innovation going on around all around from meta frameworks, around performance, and around making your application more efficient. You know, QUIC is doing that. Server components is doing that. HTMX is doing that. And we're kind of all searching for what would be the right obstruction when we want to build an application or website. I would say that. And add to that all of the web concerns, and you get, like, a a big area of activity just around the existing frameworks and the existing needs.

Dan Shappir [00:56:30]:
So given everything that we've said so far and given everything that, you know, you you've explained, what is the future of frameworks?

Yoav Abrahami [00:56:41]:
So I think I think, you know, my bet, which is and, again, I'm I'm far reaching. I think we need to add two more requirements into the mix. I think that if the only reason to move from React to another framework is aesthetics and performance, it's not good enough. And that includes Vue and Svelte and quick and oh, everything else, an HDMX and so on. You know? And that's why React no one is willing to live in React, to be honest, because the the need is not strong enough. But I think there are two other requirements that are very strong. One is to be able to consume third party components in a way that you are both you and the component are safe from one another. And, you know, just last summer, we had an an issue where the Versus code plugins appeared to be very there was a published an article that says that a a research group managed to put a malicious Versus Code plugin with hundreds of thousands of, developers.

Yoav Abrahami [00:57:58]:
And then they scanned the the plug in market for Versus code and thousands of plugins on Versus code are potentially malicious. And then you have WordPress, which is known to be, you know, all of the plugins to be or not all of them, but a lot of them to be really problematic. And then you have lots of other cases like that. And then you're downloading a free NPM across your company, you know, all around, talking about enterprises, and you have no idea what attack vectors are going on through NPM. And it is an attack vector to get a certain version of library to be legit and then the next one, a minor version, to have a some vulnerability or even some attack, and you just download it using your code in your application, and you're exposed to it. So what if I can give you a framework? I'm not saying that I can give you that. But what if the future framework would protect you from that automatically? You know, just one example.

Dan Shappir [00:59:01]:
But can a framework really do that? Doesn't that need to be solved at the platform level?

Yoav Abrahami [00:59:07]:
Mhmm.

Dan Shappir [00:59:08]:
Or at least or at least have, you know, for the platform to provide building blocks that the frameworks can then use to provide the provide an holistic solution to stuff like that?

Yoav Abrahami [00:59:22]:
I think you're you're asking the wrong question. The right question is if someone will make something like that, we'll be able to create a framework that is such a new requirement working within it in some way. And people are innovative. They they'll find a way, for instance. That that would be a reason to move frameworks. And I think two of the requirements that I can put on the table for frameworks to challenge that would challenge our existing frameworks is one, the security, and the second one is design to code. Those are the two ones. Because with both of either one of those will challenge everything we have today in a significant way.

Yoav Abrahami [01:00:07]:
So really much from

Dan Shappir [01:00:11]:
Yeah. I know. It's interesting because look. So for example, the quick gang made a bet that, that getting a more performance solution would get people to switch. And so far, it hasn't really happened, certainly not on at, you know, on mass. Whether or not people will switch for that, it's, you know, maybe. I I have no insight.

Yoav Abrahami [01:00:44]:
But that's the point. You know, when the only thing you're comparing are nonfunctionals, it's very hard to get someone to switch. You have to be really, really better and in a really pain point. When you're starting to move to either, you know, functionals and for for a framework, allowing designer to work in a different way, that's a functional thing. It changes the old DNA of your framework. Or when solving a big problem like security and your security team is like, hey. You know? Hey, dev team. You know, we can drop all of that million dollar deal of code scanning that we're doing all the time to make sure all of your NPM dependencies are working and just use a secure framework, then, again, no one knows what the future is going to be.

Yoav Abrahami [01:01:39]:
But my bet is that future framework will not be just about aesthetics and better performance. There's going to be some other needs, some other requirement, or some other problem that it solves on top of all of the existing problems. It might be security, might be designed to code, might be something else. I don't know.

Dan Shappir [01:02:02]:
So so I'll kind of inverse your statement. What you're saying is that there are a couple of hard problems that we need to be solving that fall under the umbrella term web essentials. Current existing frameworks and even meta frameworks are not either are not solving these problems or not sufficiently solving these problems. Something will come along that will, and you want to call that the future framework.

Yoav Abrahami [01:02:34]:
I would say that with learning of the aesthetics of our current frameworks, that would probably be our next big framework.

Dan Shappir [01:02:48]:
I would also very much, by the way, like to have a link to that list of of web essentials, by the way.

Yoav Abrahami [01:02:59]:
I'll send it for you. I I think I had it in the React next the presentation I did last year, but I'll send it to you.

Dan Shappir [01:03:10]:
Okay. That that'll be great. I'll I'll look at that presentation as well. I think I did, but I don't remember off the top of my head right now.

Charles Max Wood [01:03:18]:
Yeah. We're getting toward the end of our scheduled time, and I have to go soon. So, is there some kind of overriding point that you wanna make or some conclusion you wanna give us, you all?

Yoav Abrahami [01:03:31]:
I think I would say that there is we are at the point where something is going to happen with web frameworks. You know, when you look at the when you look when you want to predict the future, you look at the history. And, you know, our web frameworks, you know, age one was in 1995, server rendering. Age 1.5 was in around 02/2001 with jQuery. Age two was with Angular and React around, 02/2010, and then the meta frameworks and a a endless CMS systems 02/2016, that kind of the 2.5 age. And now there's all kinds of different innovations and ideas floating around trying to make something new. And at the same time, we're moving from a nonregulated market to a highly regulated market. And on the same time, we have AI coming into the mix, and if there's going to be another some something that's going to challenge the Internet with AI.

Yoav Abrahami [01:04:38]:
By the way, it's not going to replace anything. It's just going to be another distribution channel based on AI that's going to be accompanying web and mobile and social. So with all of that together, something big is going to happen with web frameworks. What is it? Then I think that is the big question. But I can promise you is that it's not anything like the frameworks we have today. It's not going to be just aesthetics and little bit better performance. It's gonna be something bigger.

Charles Max Wood [01:05:12]:
Alright. Cool. Let's go and do our picks. So one game that, my family's played a bit lately is called the crew deep mission deep sea. Now I've picked the crew before. That was the quest for planet nine. And they're effectively the same. The difference is is that, with the the crew, the deep sea version, what you wind up doing is, you still have the missions.

Charles Max Wood [01:05:44]:
Right? So it still gives you a handicap of some kind. You can't, yeah, you have to do things in a certain order or right. You you do so many, missions. The the difference is that with the deep sea mission, the missions, you actually flip cards over just like you did in, the quest the quest for planet nine, but they can be anything from you have to take two cards of this color and two cards of that color. Or you I mean, there there are all kinds of things. Whereas with the original version, you'd flip it over and you'd have to take that card, and then you add little tiles you'd put on them. You have to do this one first and this one last, or you have to do these three in order, or you have to do this one first and the next two in order after that, and then this one has to be last or things like that. So, and it's trick taking.

Charles Max Wood [01:06:29]:
So, anyway, it's it's pretty simple and straightforward as far as all that goes. Game, game board geek or board game geek, it rates it at a, two point o four. So it's it's right around casual gamer. You'd pick it up and have fun with it. I like playing these games with four people. You can play three to five, and it's not bad at three or five. But, anyway, it's it's a fun game. So I'm gonna pick that for my pick.

Charles Max Wood [01:07:09]:
My wife and I watched a movie this week called, Homestead. Let me get a link for, this and put it in the, in the comments. But, we watched a movie called Homestead, and it's so, essentially, the premise of the show if you go watch the the trailer, this is about what you'll get from it, is there's a nuclear bomb that goes off in California in Southern California, and then there are other terrorist attacks. It's a little fuzzy on it, but the the gist I got was that there are major power outages. The power grid goes out on the East Coast Of The United States. And so it there's this, homestead, essentially. It's it's some land. I kinda gathered it was in Montana, but I'm not sure on that.

Charles Max Wood [01:08:03]:
But, anyway, this guy, hires an ex Green Beret, to put together a security team just in case there's kind of a worldwide catastrophe, and he needs to protect his, his area. And he's he's like this Uber prepper. Right? So they have medical supplies, and, you know, they they grow stuff on their property and all kinds of stuff like that. And so, you know, this catastrophe hits, and so this guy, you know, basically grabs his family and heads up to where this, this homestead is, and they, you know, they they set things up and are are protecting the homestead kind of thing. It it was really good. And then when we watched it afterwards so we we're part of the Angel Guild, which is, Angel Studios is the one that put it out. Angel Studios also did the chosen and a bunch of other movies that I picked. They turned it into a series, and so we actually watched the first episode of the series too.

Charles Max Wood [01:09:01]:
And it's pretty good. So, I'm gonna pick that, if that's kinda your cup of tea, kind of the it it kind of walks you through the apocalypse. And, anyway, it's it's really awesome. So, I've been enjoying that. Yeah. And,

Yoav Abrahami [01:09:19]:
I So, you know, talking about the copa apocalypse, I looked I've seen the serious Van Helsing recently Uh-huh. Which is, you know, another adaptation of vampires taking over America. And but it's, you know, it's very, very fun. But, you know, my pick are actually going to be different a different movie. I would go with Damsail, which is a movie about a a princess that is you know, basically, it's a a common girl that is a princess chosen heir to be his wife, and it's like a fairy tale story.

Charles Max Wood [01:10:03]:
Uh-huh.

Yoav Abrahami [01:10:04]:
And then after the marriage, he kinds of throws her under into a pit to be sacrificed to a dragon. And then it kinds of goes off rails and becomes a very different movie, which, you know, one thing that I actually I I liked about it is that, first, it's very, very different. And second, it doesn't go with the regular style of the prince saves the princess. Mhmm. It actually goes either way around, which is really encouraging and really fresh, I would say. As for a game, it's okay to choose a a cards game. Mhmm. You know, there is a game that really I really enjoy, playing with my kids called the queens.

Yoav Abrahami [01:11:02]:
And it actually starts to become a a recurring idea of queens and princess.

Dan Shappir [01:11:08]:
Uh-huh.

Yoav Abrahami [01:11:08]:
But it's actually it's a it's it's a game where there are there are a 10 queens or so it's a 16 queens on the board, which are upside down. Don't know which card is which queen.

Charles Max Wood [01:11:24]:
Oh, sleepy queens.

Yoav Abrahami [01:11:26]:
Sleepy queens. Yeah.

Charles Max Wood [01:11:27]:
Yeah. I've played this with my kids. It's a fun one.

Yoav Abrahami [01:11:30]:
It's a really fun one, and my kids are very enthusiastic about that. They're very passionate. So that's, you know, just great game.

Charles Max Wood [01:11:41]:
Yeah. It's it's very approachable. So my daughter is nine now, but I think we got it when she was, like, six or seven. And it's definitely approachable for younger kids. But, yeah, there's enough meat to the game to where adults would enjoy playing with it. It's not one I would pick to play with my friends, but with my kids, definitely. And BoardGameGeek weights it at one point o five, so it's got fairly simple mechanics. I I think it plays two to five people too.

Charles Max Wood [01:12:11]:
That's what it says here. And, yeah, terrific game.

Yoav Abrahami [01:12:14]:
Yep. It's a great game. And, you know, my kids are nine and 11, which is just the right age, and Yep. It works wonders with them.

Charles Max Wood [01:12:23]:
Yeah. I had somebody ask me on I think it was Ruby Rogues last week. They asked me what games I recommend for kids, and I listed a whole bunch there. But, there are a ton of just terrific games you can play with kids that yeah. I I wonder if BoardGameGeek actually has a list for kids. I know they have categories here. Here we go. Categories.

Yoav Abrahami [01:12:51]:
Yeah. I actually I actually never tried that that board game board game geeks.

Charles Max Wood [01:12:56]:
Yeah. Board game geeks. So I'll just do that as a pick, and I'll just throw it out as well. So board game geek, the way that it works is it's essentially kind of this database of board games. They do board games and card games. And then, what you can do is, they have forums as well. So if you a lot of times, I'm on board game geek because I'm going, what, you know, what what is the I have a question about a mechanic in a game. Right? So they didn't, they didn't clarify.

Charles Max Wood [01:13:30]:
And so Yeah.

Yoav Abrahami [01:13:33]:
You know, I need to know, hey.

Charles Max Wood [01:13:34]:
How does this work or that work? And

Yoav Abrahami [01:13:36]:
I I have to say the director I'm looking at is whiskey bass, and it's little bit different. It's a kind of give ratings for different, whiskey drums. And so you know you can know which spirit to get, especially when you go to more unique ones and more little ones. Yeah. Just have a Glengarry 29 on its way to my house, which is supposedly 95, I think, on whiskey based, which is kind of amazing. Mhmm. We'll see how it goes.

Charles Max Wood [01:14:13]:
Very cool. Yeah. I don't drink alcohol at all, but, Yeah. I mean, it we we used to have somebody who would pick beers every episode. So right? It's like, hey. You have to try this one. And sometimes they were local brews and sometimes yeah. I I could definitely see myself getting into that if that was my my thing.

Charles Max Wood [01:14:33]:
But yeah. Very cool. Well, you all if if people wanna check out, Wix Enterprise or they wanna see what you're working on or catch you at a conference or anything, how do they find you?

Yoav Abrahami [01:14:46]:
Twitter, that is one. Also, there is week engineering blog. There is lots of stuff there. And, you know, just give me give me a call. You know, reach out to me on a on Twitter or LinkedIn. I'm there. I'll get to help anyone.

Charles Max Wood [01:15:03]:
Sounds good. Alright. Well, I'm gonna go ahead and wrap this up. Thanks for coming.

Yoav Abrahami [01:15:09]:
Oh, thank you for having me here. It was super fun.

Charles Max Wood [01:15:12]:
Yeah. Until next time, folks, max out.