Hey, welcome back to another episode of JavaScript Chamber.
This week, on our panel, we have Dan.
Shapier, Hello from Tel Aviv.
I'm Charles Maxwood from Top End Devs, Hello from.
Lehigh, Utah. We also have a special guest, and that is you have Abraham.
I hope I got I hope I got close.
Man, got it right?
Yeah, I got on when you guys were chatting when I hopped on and I was like, yeah, my.
Hebrews 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 Wicks, Right.
I'm CITYO of Wicks Enterprise, which is like a it's funny to say, it's like a small startup of trying to take Wicks which is mostly consumer product and designer product and adapted to enterprise. And okay, so it's exciting.
Very cool.
So we actually had before just you know, I was gonna say, yeah, we had you off before about almost two years about two years ago, I think.
Two years ago. I think, Yeah, that that was that was exciting. Was a very different topic, I think, and we had a very heated debate there about clouds and code.
Ownership yeah, with a j. Unfortunately you cannot join today.
Yeah, I'll put a link into the into the chats, so 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 Wicks, what else has changed last few years?
So, you know, the first thing that to change was that I used to be the d of weeks development platform, a co ed of that, and 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. And I think those are two major things. So when you talk about Israel, there is another big thing that
happened in the last year and a half. I think they will probably live that out of the podcast.
Yeah, yeah, the political situation there is a little bit everything, but yeah, the war I keep hearing about hostage is coming home, which is a good thing.
So yeah, the last few weeks have been, you know, kind of a bright spot in this pretty dark tunnel that hostages that have been held for or coming on five hundred days, yeah, or finally being.
Released basically a year and a half.
Yeah, yeah, yeah, hopefully it will continue. They are being released, you know, in small batches every a few every week, and hopefully this will continue anyway. Yeah yeah, let's talk tech though, 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 want to just talk briefly about that and what you're pulling together.
I don't know. Maybe Dan had a different direction he wanted to take this.
No, it's fine, I think.
Yeah. What I'm trying to solve is the problem of designer and developer collaboration. Oh okay, so it's trying to do a framework that allows a designer to basically publish or deployed application. Okay, 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. And the funny thing is that it actually turns, it actually becomes eident at some point that it is actually the same requirement as allowing you to consume the party components in a safe way. So think about using someone component of another company and not being exposed to the to the code in a way that can risk creater risk to your application. And it's
some out 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 working progress. It's very very experimental. So I'm not going to go and still the podcast making announcements, go and look and use my framework. That's not the point, but it is something of why I'm very opionated and why I'm looked very deeply into different frameworks.
It's an interesting thing that when JavaScript and the dome along with it were created, they were created specifically for designers or tinkers. The actual developers were supposed to be using Java or something like that, and it's interesting to see how the developers have kind of co opted JavaScript and typeescript and with the frameworks, the heavy duty frameworks that we have today, they are definitely year 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.
I think it's even more than that. I think I'll take you in two different directions. One, think about these 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 to end it over the system. They would do acceptant tests, and then after testing, checking, they would deploy the application at some point. And then we had develops which change the way we work.
It moved the responsibility to deploy and application from system to the developer, and it gave developers the tools to make the application work, and all different tools than the ones that system. And what I'm looking to do now is to shift it again from the developer to the designer. Just think about it. A designer that there has no idea how to code, is no understanding of creating the
running application or 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 that the designers are using are very different. They're not going to write HTMIL or CSS. That's not how they work. If you go and look at what you're
using Photoshop, Figma. You know, there's CONSI file tools. It's not HTML and CSS, so you need to bridge a much larger gap and then and over the responsibility to them, and then over the tools to them so that they can be effective and own the application.
That's what we have AI for now. Well, you know, a I.
Can do a lot, but unfortunately, up until today it didn't replace the developer all the designer. We still have a few years for us at least.
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 is safe anyway.
Yeah, 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.
I think the easiest way to understand that is if you'll give an AI to fly 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 a very smooth flight. But it's okay for it to fly into a mountain. So I think this is kind of the god with a I.
You remind me, I had a friend who was an airline pilot and he basically described his job to me once as like one hundred hours of boredom and five minutes of pure terror.
Yeah, 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 it's a different problem, it's a different set of problems than what we're talking about with programming.
Well, it's actually easier for an AI to fly plane than to drive a car. But you know, let's pull let's I would like to pull us back 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 kind of a change of a perspective about.
And I can talk about that, but I first would like to hear you you have and that's talking about what are in fact framework, what constitutes a framework versus say, you know, a library or a set of tools or an application or whatever.
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. 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 ail level library like NTM or some other package. But there is always you have the choice almost everywhere of what you use. That is where it is a set of tools you can just choose from. But when you are being called, you
don't have the choice of who is calling you. 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 to different teams and give and call some exit points, some using some utilities and some tools.
So I had the exact same outlook on frameworks versus liberries. 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 its libraries, When the architecture is kind of dictated to you, that's a framework.
But it's kind of the same same.
Yeah, you's a big overlap, but it does shift 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 put it this way. You know where the pieces are supposed to slide in.
I think what you're talking here is about something a little bit different 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. One is the ability to make it easy to be tested 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 a little bit subtle is that the syntax is 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 right 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 fair the principle of least surprise basically, yeah.
So it's look yeah.
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 if you really read stuff, or you read the code and it's you know, you pretty intuitively know what it does.
So 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 view 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 I've been doing react for long enough that I know what that's what this code is.
You know, the measure of ooh against uh. Theory about that when you go into a new system and you're like, hey, doing something really exciting. Whoa, and then you when you go into another and then you try to make it do something it doesn't work, and then you figure, ah, it has to work that way. That's not intuitive. You know, that's the measure. It's the measure how much times it's doing things in the way you expect it to be doing versus how much times it surprises you're doing something
in a very unintuitive way. This is kind of a measure for APIs and the local tools to know how good they are the moments against the ouh moments.
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 non essential complexity and you know, we are solving complicated problems, at least we strive 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. So people will always find way to surprise you and work against the grain of what the framework encouragees you know.
But I think, I think then sorry, 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 needed 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 non functionals like like performance, for instance, are the record or do you do you even care?
Is the difference significant? And for example, is the fact that svelt is much more efficient then 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 non functional only then you come to syntax and you all knows you are with the developer.
Yeah, but look, when I think about React, for example, for me, the core of React are a few well defined concepts, and now 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 regenerate 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. Or if I'm thinking about Spelt, 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 applications best suits
your personal tastes. Now, unfortunately most of us don't go through this process. That's a framework choice is tendable. Yeah, just to finish because in a lot of cases, the framework choice is kind of dictated to us.
You're right, it's again it's assuming that functional is equal and assuming that the non functional 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 lot, does it done a huge work moving us forward, as you know, fronted developers it there is a reason why it is the number one firm of today in the world, right, 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.
Well, you know, the dom is not functional. JavaScript is not functional, and you're kind of living within the framework itself 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's a price to pay for that as well. You know, let's say ditching JavaScript in favor of ELM or reason or something like that.
No one said that the esthetics is simple getting the hostel of a FERMUK 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, you look at what's happening today. There is one major direction going on today, which is signals. Everyone except React as signals today.
There might be some old firms that don't have them, that they didn't adopt signals, but almost everyone except React are using signals as the main obstruction for state management. And there is a reason behind that. It Trying signals on different places, different frameworks, different syntaxes seems to work. Trying signals in terms of the non functional performance, Okay, again, it seems to work. It seems to be something that people comprint. By the way, signals is not a trivial team.
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.
Well for me, it's more than aesthetic actually, because it informs the way that you deconstruct or 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 Satia FROMETA to talk about the React compiler. Joe said very clearly that signals are not in reacts future. He basically said, you know, if if signals become a part of the JavaScript language, there is 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 how front and applications should be built. Their whole thing is about, you know, reconciliation and stuff like that.
I'll talk at what you're saying right now. You're talking about opinions of.
Course, frameworks, our opinions that that's kind of my point.
Well, I 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 unfunctional requirements, and we kind of set it very you know, very basic frameworks that are in your 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, such as
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 performan breakpoints, multilingual, a BIT testing, so ABY testing is actually not a web essential, but it's nice to have cookies regulation in the EU, accessibility the new accessibility regulation in the U now a g DPR p i R, and there's more.
And all of those are lists somewhere that I could just publish.
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 look in, you need to take care of most of it. And your se O is another one. And all of the cost lot of money. Why aren't frameworks helping us with all of that list of stuff?
I think when you start talking about these things, you're again, and it's an interesting distinction to make 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 the next JS, from talking about view to talking about next and so on and so forth. At least that's been my experience with these sorts of things. Most frameworks these days have a much lower bar in the in
the functionality that they're trying to provide. There are more about you know, use us instead of using just the DOM.
But keep in mind when you talk when you asked about what is the definition of framework, I framok is not defined as only something on the client that interacts with the don 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 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 applications to work with. 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.
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 apple, or whether it gives you the architecture, whether or not it provides you with some of these essentials you know that you would expect it to.
It seems like that 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 going to structure your application, here's the understanding of here's where the pieces go. Here are a series of tools, libraries, toolkits, et cetera 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.
Right.
So some people may be picking it because hey, I want a more esthetically pleasing thing, or I want to be more efficient in my time use by having the framework handles and things for me, or by fitting a mental model that I can synk my head into. And so you know, 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.
I don't think there is one answer for what is a framework. I think the role of a framework is to help us to make us small efficient, right, And because you know I could just use Jake Uark and that would work, I would yeah, And then we decided to move to React because it is more efficient to write code and React compelled to j Query 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 and 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 it to make it accessible? Versus can I get the framework that would help me to have lift that that burden in making me more
efficient there? And the same can go for any of the other Web concerns.
M 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 actual semantic HTML, end up with the mountains of dives, which is anything but semantic and anything but accessible and so forth, and that if you want to get these in the context of frameworks, you 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 describe. So are design should design systems have been part of the frameworks the framework itself. Shouldn't they be bluggable to the framework?
You know? I think saying that the thermok 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 you might need something else. Design system will not solve cookies regulation for you. So I think even though you know real act and all of the frameworks allow design systems because a just makes us much more efficient to use the design system components,
it's still not enough. So I really think that frameworks will need to take that into account. We are in a market that we're 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. And we don't know where'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 the next in the Internet beside Google and Facebook and TikTok.
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.
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 one hundred billion dollars market around search and about another one hundred billion dollars market around social. You can assume that there's going to be another one ordred billion dollars 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 app something like that, and then you want your business to be listed there as well. 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 when that will happen, how will your framework help you to be there in the right way.
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 Facebook or something, or or on Instagram or something like that. Is that what you're talking about.
Yeah, it's you know, think about think about two thousand and eleven, a year before Facebook really become dominant. If at twenty eleven 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.
And again maybe it's just me or the terminology that I'm familiar with because of React and things similar to it. But React or view or Swelt or solid they've set their sights much much lower than that. As I said, if the things that you're talking about, our starts 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, Kensey Dodds has this epic stack which involves 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 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 requirements that you seem to be talking about. Or at least that's how it seems to me.
But I have to ask you a question. When you look from jaquerd up to React and up to Angulau, doesn't it seem the same. jQuery is actually much liner. It tries to do much new. Compelled to react or act is trying to so much more compere to jQuery. Jaquerry is just trying to obstruct a little bit to dom APIs, that's all. And it is a framework, the
most popular one in the world. And then React is also a framework, but it adds another obstruction layer on top, and angular is the same, and then we're going to be we might add another obstruction layer on top. You know, you're trying to put labels on it, but why are those labels important?
Well, I actually think that labels are important. You know, there's that statement that there are two hard things in computer science, cash and validation, naming things and off by one errors, and so naming things is actually pretty pretty important. You know, uh, design patterns this are basically ways of naming things so that we have a common vocabulary. So I do think that having common terminology is actually important for us to be able to converse and exchange ideas and concepts.
I can accept that, But I just I think that even Evin said that a meta framework is just another filmwork that does more.
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. A 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 service side aspect to it, whereas a framework doesn't. But but your definition seems again to be much more holistic than mine, you know.
But let's work with all definitions. I'm fine with that. So when I'm saying that frameworks need to cope with all of the web essentials, it's fine saying meta frameworks we 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 upening with frameworks. Again, meta frameworks might be And I'm seeing two trends or two lines that are kind of interwined together. One is the
idea of the idea of gradual rendering. 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 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 side generation. But actually don't like this definition.
When you look at data, you have data that changes slowly, like blog posts 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 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 in assal slowly changing.
You I can do an event of something changed, 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 several components. Let's a developer to choose to have one layer selver rendered, which is only selver rendered, and then have another layer or another subcomponent that is rendered on the selver but is also interactive on the client quickly starting to do stuff like that. Your other
films are starting to do stuff like that. But I haven't really seen that as been a first class pattern in any of the frameworks.
I would take it a step further. It seems to me that, and I'll be blunt, it seems that framework makers are solving problem that the market is not looking for them to solve. I'm you know, 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.
Uh and and next and Versall's success not notwithstanding the majority of enterprise React applications that I'm saying are very much keeping the framework on the client side.
Only you're right, And yet when you go and when and keep in mind that Versall is building websites. In website you must have selvis a rendering because of CEO, again, because because of web essentials. But then even for the enterprises, they get to the point where there's an a but we have a performance problem, or we have a flickering or a textload long to load the page, and we need to do something about that. Now when you run React on the selver, when you react was not designed
to work on a selver environment. What versaill we're 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 free work that would work in such a way and would support both the website and enterprise use cases.
Well, I guess, Chuck, you're supposed to say at this point, that's why we have rails. And what's the name.
You've been refraining from saying that this whole time.
So rail rails, And what's the name of the thing that you use in stimulus or the other one, turbo turbo stimulus whatever. You've got a whole bunch of terms.
Wire.
I think that was the one.
Yeah, Well, Rails did a lot of really good stuff, and it tink. Its kind of when you look at the what I would call the one point five age of the Internet, which is basically static, basically self aside rendering everything and a little bit of JavaScript, a 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, but it does suffer. And there is a reason why we move to Web two point zero, which starts with React and Angula, which our 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 climb. And then you know, when you start moving from front and 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 are there the news in next years? And again it's the lockdates the Yeah, so yeah.
I thought you were going to go to express or something.
I'm like, now express, if you're going if you're going to react to next?
I can, I can? I can see that.
Yeah, And I think what we're what I would, I think we're kind of they've kind of converging on is there's them that I just don't want to use. So instead I'm going to say firmworks that are designed to vote for the back end and the front end as first as citizens. And when you when.
Okay, I'm going to make a conjecture, Well, I think that what you or or at least what I'm I'll restate what I seem to be hearing you say. You're basically saying most modern frameworks that we've seen started there, started out client side, and then evolved to work on the back end as well. So next GS grew out of React and it's effectively implementing a React specification. Knox
grew out of view, so on and so forth. What you're saying is, you know, we've had no GS 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 am I getting the gist from what you're saying?
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 a 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 user name or cookies. And then you have interactive data or interactive interactions on the client and state management.
And 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 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 work.
I mean a lot of the things that you're talking about are things that.
I mean, I kind of manage this stuff so that it changes when it needs to or gets you know, interaction happens when it needs to. I don't know that I think of them as all that different, right they all more or less use the same mechanisms.
Or am I missing something?
Well, let me put it this way. What I'm saying a lot basically people dealing with this problem by effectively
ignoring it. So, for example, if they build a holy client side grander application and just make calls back to the two end point to RESTful endpoints whenever they need to get more data, so they don't need to think about how often the data changes, so they respond quickly to client side interactions, and then whenever they need to get you know, data from the back end, they just call a RESTful API and it comes whichever way it comes.
So so effectively they respond to both types of interactions or all three types of interactions and essentially the same the exact same way by by writing event handlers in JavaScript that that tender events. These events might be a user a mouse click, or these events might be some
data arriving over the network. It's it's all the same, and I I agree with you of that, and reacts O her 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 reacts over components in production, certainly
in anger. Let's say, it's it's an interesting question, you know, as I said, there's a growing you know, it seems that next gs is eating the React website market, that the majority of new React websites are being built using next gs. But I have no idea how many of them are actually using reacts over components. Certainly, how many of them are actually using reacts server components correctly, That's that's a totally different question, and it's an interesting one,
And I don't know how to get this data. What how do you think a solution to that might come along or might look like that actually solves that problem with lower fraction and greater acceptance.
You can see what both next and well forgot the name. There's another fermework and they're doing data loaders that by the name of the data loader of function you know on which environment run it. You can look at what the quicks is doing where you can there is a different specific API which is very similar but specific API.
It says this is something that runs on the selver or in the case of quick, everything is by different running on the cellver and only being loaded to the client if needed, and the compiler is kind of understanding what needs to been downloaded to the client. I think we need to figure out the syntax. We don't have it today.
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 when it's it's it's it's functions that when they are executed on the server, it's just it's just a function called, but when they're executed on the client, it's it becomes serialized automatically over the wire. 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 that's we had Tenner Lindsley talking about what he's doing with the ten with ten stacks start, and he's also using RPC, but he's doing it in a very different way than the way that next GS is even though you might say that in both cases it is kind of our PC.
Yeah, anyway, I want to take you even one step more. You know, we talked about design systems. 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 I 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 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 that first phase of rendering, and then let's start deleting all the unnecessary code, So all of the other layouts of the gallery they don't need to be there. All of the other style options they 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 of complicated situations. You know, a drop down with fifty different options of how to open a drop down, but I need one, So why would you download the browser all of the different options?
So there is also another potential here for lots of very aggressive optimizations that to be honest, no one is doing today.
Well I think quick guys that you mentioned is kind of trying to do so at least some of the stuff. Basically, it's using a compiler two bundler or smart bundler or transpiler, call it what you will, to decide for you which code needs to exist where effectively. And then you know, again, if if we're talking about stuff like like the hot wire that the Chuck mentioned before, you know, when we spoke about what's it called HTMX. It's basically saying, why
why do why send Jason 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 HML when I can just send the HTML. And and to an extent, again reacts over components are kind of going in that direction. They're not actually sending HTML, they're sending virtual dom as it were,
over the wire, but they are. But again, it's it's basically the idea of having generic mechanism that transforms it into UI rather than having to download all the custom logic.
But think about what's happening here. You have a lot of innovation going on around all around from meta frameworks, around performance and around making your application more efficient. Quick is doing that, Civil component 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 a website. I would say that and add to that all of the web concerns and you get like a big area of activity just around the existing frameworks and the existing needs.
So, given everything that we've said so far and giving everything that you know, You've explained what is the future of frameworks.
So I think I think you know my bed 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 performs, it's not good enough. That includes view and swelled and quick and everything else and HTMX and so on. And that's why I React. No one is living React, to be honest, because 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 teled 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 issue where vs code plugins appeared to be very There was a published an article that says that the self could managed to put a malicious viscode plug in with hundreds of thousands of developers, and then they can't developed the plug in market for viscode, and thousands
of plug ins on vis code are potentially malicious. And then you have a WordPress which is known to be you know, all of the plug ins to be 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're 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 some vulnerability or even some attack and you just download used in your code in your application and you're exposed to it. So what
if I can give you a framework. I'm gonna say that I can give you that, But what if the future framework would protect you from that automatically one example?
But can framework really do that? Doesn't that need to be solved at the platform level, or at least I or at least have you know, for the platform to provide building blocks that the frameworks can then use to provide a provider analistic solutions to stuff like that.
I think you're asking the wrong question. The right question is if someone will make something like that, will be able to create a framework that is such a new requirement working within it in some way and people are innovative, they'll find a way, for instance, that that would be
a reason to move frameworks. And I think two of the requirements that can put on the table for frameworks to challenge that would challenge our exiting frameworks is one the security and the second one is designed to code. Those are the two ones, because we both of either one of those will challenge everything we have today in a significant way.
So yeah, I know it's interesting because look, so for example, the quick gang made the bat that that getting a more performance solution would get people to switch, and so far it hasn't really happened, certainly not on mass. Whether or not people will switch for that, it's you know, maybe I have no insight, but that's the point.
You know, when the only thing you're comparing are non functional, it's very odd 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 easier you know, functionals, and for a framework allowing designer to work in a different way, that's a functional thing. It changes the all
DNA of your framework. Or when solving a big problem like security and your security team is like hey, 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 MPM dependencies are working and just use a secure framework. Then again, no one knows what the future is going to be. 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'd be something else. I don't know, 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 or 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. I would say doubt with learning of the aesthetics of our current frameworks, that would probably be our next big framework.
I would also, very much, by the way, like to have a link to that list of web essentials.
By the way, I'll send it you I I think I edit in the React next the presentation did last year, but I'll send.
It to you.
Okay, that'll be great. 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.
Yeah, we're getting towards the end of our scheduled time and I have to go soon.
So is there some kind of overriding point that you want to make or some conclusion you want to give us you all.
I think I would say that there's we are at a point where something is going to happen with web frameworks. You know when you look at we 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 nineteen ninety five, silver entering. Age one point five was in a round two thousand and one with j Querry. Age two was with Angular and React around twenty ten, and then the metal frameworks and addless CMS
systems twenty sixteen. That's kind of the two point five 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 non regulated market to highly regulated market. And on the same time, we have AI coming into the mix, and there's going to be another something that is going to challenge the Internet with AI.
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? I think that is the big question. But I can promise you is that it's not anything like the films we have today. It's not going to be just aesthetics and little bit better performance. It's going to be something bigger.
All right, cool, let's go into our picks.
So one game that my family's played a bit lately is called The Crew 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 right, so it still gives you a handicap of some kind.
You can't yeah, you have to do things in a
sortain order or right. You do so many missions The difference is that with the deep Sea mission, the missions, you actually flip cards over, just like you did in 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 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 have 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. So anyway, 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 four, so it's it's right around casual gamer.
Good pick it up and have fun with it.
I like playing these games with four people. You can 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. 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 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 they just I got was that there 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 kind of othered it was in Montana, but I'm
not sure on that. 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 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 protecting the homestead kind of thing.
It was really good. And then when we watched it afterwards, so we were 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've picked.
They turned it into a series, and so we.
Actually watched the first episode of the series too, and it's pretty good. So I'm gonna pick that if that's kind of your cup of tea kind of the it kind of walks you through the apocalypse and anyway, it's it's really awesome.
So I've been enjoying that, and.
So you know, talk about the apocalypse. I looked. I've seen the series A Van nelsin recently, which is a you know, another adaptation of vampires taking over America, and but it's you know, it's very very fun. But you know, my pig is actually going to be different a different movie.
I would go with Themselves, which is a movie about a princess that is you know bestally it's a common girl that is a princess chosen heir to be his wife, and it's like a fairy tale story, and then after the marriage he kinds of trowser under into a pit to be sacrificed to a dragon, and then it kind of goes off rails and becomes a very different moviehm.
Which you know. One thing that actually 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. It actually goes either way around, which is really encouraging and really fresh, I would say, m hm. As for a game, he's the kay to choose a
cards game, mhm. You know, there is a game that really enjoyed, I really enjoy playing with my kids called The Wins, and it actually starts to become a recurring idea of queens and Princess, but e's actually it's a it's it's a game where there are there are a ten queens or so it's a sixteen queens on the board, which upside down. I don't know which card is.
Which queens sleeping quinns. Yeah, yeah, I've played this with my kids. It's a fun one.
It's a really fun one, and my kids are very enthusiatic about that, very passionate. So that's just great game.
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 adultsod enjoy playing with it. It's not when I would pick to play with my friends, but with my kids definitely. And Board Game Geek waits it at one point oh five, so it's got fairly simple mechanics. I can't place two to five people too, that's what it says here. And yeah, terrific game.
Yeah, it's a great game. And you know, my kids are nine and eleven, which is just the right age, and yeah, it's what's wondrous with them.
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 wonder if Board game Geek actually has a list for kids.
I know they have categories here, here we go categories.
Yeah. I actually I actually never tried that Bold game bold game gigs.
Yeah, board game Geek, 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 and 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, and so.
You know, I need to know, hey, how does this work or that work?
And I have to say. The director I'm looking at is Whiskey Base, and it's a little bit different. It's kind of give ratings for different whiskey drums, and so you know, you can know which spirit to get, especially when you go to the more unique ones and more little ones. Just as a Glen Garry twenty nine on its way to my house, which is supposed to be ninety five at in Corn Whiskey Base, which is kind of amazing. We see how it goes.
Very cool. Yeah I don't drink alcohol at all, but yeah, I mean.
We used to have somebody 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 could definitely see myself getting into that if that was my my thing.
But yeah, very cool. Well you ovious.
If people want to check out with Enterprise or they want to see what you're working on or catch you at a conference or anything, how do they find you?
Twitter? That is it one. Also there's week Engineering Blog. There's lots of stuff there, and you know, just give me, give me a call, you know, reach out to me on Twitter or then I am there. I'll be up to help anyone.
Sounds good. All right, Well, I'm gonna go ahead and wrap this up. Thanks for coming.
I don't think of having me here. Was a super fun
Yeah, until next time, folks, max out