Speaker 1: Hey, welcome back to another episode of JavaScript Chamber.
Speaker 2: This week, on our panel, we have Dan.
Speaker 3: Shapier, Hello from Tel Aviv.
Speaker 2: I'm Charles Maxwood from Top End Devs, Hello from.
Speaker 1: Lehigh, Utah. We also have a special guest, and that
Speaker 1: is you have Abraham.
Speaker 2: I hope I got I hope I got close.
Speaker 4: Man, got it right?
Speaker 1: Yeah, I got on when you guys were chatting when
Speaker 1: I hopped on and I was like, yeah, my.
Speaker 2: Hebrews atrocious because I don't speak it. So yeah, anyway, yeah,
Speaker 2: so you're VP. Did I get that right? No Cto
Speaker 2: of Enterprise at Wicks, Right.
Speaker 4: I'm CITYO of Wicks Enterprise, which is like a it's
Speaker 4: funny to say, it's like a small startup of trying
Speaker 4: to take Wicks which is mostly consumer product and designer
Speaker 4: product and adapted to enterprise. And okay, so it's exciting.
Speaker 2: Very cool.
Speaker 3: So we actually had before just you know, I was
Speaker 3: gonna say, yeah, we had you off before about almost
Speaker 3: two years about two years ago, I think.
Speaker 4: Two years ago. I think, Yeah, that that was that
Speaker 4: was exciting. Was a very different topic, I think, and
Speaker 4: we had a very heated debate there about clouds and code.
Speaker 3: Ownership yeah, with a j. Unfortunately you cannot join today.
Speaker 1: Yeah, I'll put a link into the into the chats,
Speaker 1: so you're watching on YouTube, you can pick it up
Speaker 1: there and and go listen to that one too. So
Speaker 1: so besides your I guess your title at Wicks, what
Speaker 1: else has changed last few years?
Speaker 4: So, you know, the first thing that to change was
Speaker 4: that I used to be the d of weeks development platform,
Speaker 4: a co ed of that, and moved to another position.
Speaker 4: I'm also working on another initiative, which part of it
Speaker 4: is creating a new web framework, which is kind of
Speaker 4: why I'm very interested in that topic of web frameworks.
Speaker 4: And I think those are two major things. So when
Speaker 4: you talk about Israel, there is another big thing that
Speaker 4: happened in the last year and a half. I think
Speaker 4: they will probably live that out of the podcast.
Speaker 1: Yeah, yeah, the political situation there is a little bit everything,
Speaker 1: but yeah, the war I keep hearing about hostage is
Speaker 1: coming home, which is a good thing.
Speaker 3: So yeah, the last few weeks have been, you know,
Speaker 3: kind of a bright spot in this pretty dark tunnel
Speaker 3: that hostages that have been held for or coming on
Speaker 3: five hundred days, yeah, or finally being.
Speaker 2: Released basically a year and a half.
Speaker 3: Yeah, yeah, yeah, hopefully it will continue. They are being released,
Speaker 3: you know, in small batches every a few every week,
Speaker 3: and hopefully this will continue anyway. Yeah yeah, let's talk
Speaker 3: tech though, Yeah, let's talk tech.
Speaker 1: So so framework, So you said you're building your own framework,
Speaker 1: which you know, I guess it's been a week, so
Speaker 1: we can use another one. Do you want to just
Speaker 1: talk briefly about that and what you're pulling together.
Speaker 2: I don't know. Maybe Dan had a different direction he
Speaker 2: wanted to take this.
Speaker 3: No, it's fine, I think.
Speaker 4: Yeah. What I'm trying to solve is the problem of
Speaker 4: designer and developer collaboration. Oh okay, so it's trying to
Speaker 4: do a framework that allows a designer to basically publish
Speaker 4: or deployed application. Okay, you know, think about the designer
Speaker 4: changing the application and deploying the application. That's kind of
Speaker 4: what I'm trying to solve. It's a it is a
Speaker 4: very very big requirement. And the funny thing is that
Speaker 4: it actually turns, it actually becomes eident at some point
Speaker 4: that it is actually the same requirement as allowing you
Speaker 4: to consume the party components in a safe way. So
Speaker 4: think about using someone component of another company and not
Speaker 4: being exposed to the to the code in a way
Speaker 4: that can risk creater risk to your application. And it's
Speaker 4: some out in order to support designer developer collaboration. When
Speaker 4: when you break that requirement down into what it means,
Speaker 4: you get that other possibility as well. Again, it's still
Speaker 4: working progress. It's very very experimental. So I'm not going
Speaker 4: to go and still the podcast making announcements, go and
Speaker 4: look and use my framework. That's not the point, but
Speaker 4: it is something of why I'm very opionated and why
Speaker 4: I'm looked very deeply into different frameworks.
Speaker 3: It's an interesting thing that when JavaScript and the dome
Speaker 3: along with it were created, they were created specifically for
Speaker 3: designers or tinkers. The actual developers were supposed to be
Speaker 3: using Java or something like that, and it's interesting to
Speaker 3: see how the developers have kind of co opted JavaScript
Speaker 3: and typeescript and with the frameworks, the heavy duty frameworks
Speaker 3: that we have today, they are definitely year towards developers
Speaker 3: and much less towards designers or people like that. You know,
Speaker 3: I'm thinking like, if I'm you know, somebody learning to
Speaker 3: code and being thrown into React, that's it's easy to
Speaker 3: drown I think.
Speaker 4: I think it's even more than that. I think I'll
Speaker 4: take you in two different directions. One, think about these
Speaker 4: and system fifteen years ago. Fifteen years ago, a developer
Speaker 4: would never deploy an application that would never happen. They
Speaker 4: would build something up, then give it to end it
Speaker 4: over the system. They would do acceptant tests, and then
Speaker 4: after testing, checking, they would deploy the application at some point.
Speaker 4: And then we had develops which change the way we work.
Speaker 4: It moved the responsibility to deploy and application from system
Speaker 4: to the developer, and it gave developers the tools to
Speaker 4: make the application work, and all different tools than the
Speaker 4: ones that system. And what I'm looking to do now
Speaker 4: is to shift it again from the developer to the designer.
Speaker 4: Just think about it. A designer that there has no
Speaker 4: idea how to code, is no understanding of creating the
Speaker 4: running application or stable application, would deploy your application. That
Speaker 4: sounds scary, but that's actually what happened with system and
Speaker 4: developers fifteen years ago. Now, it also means that the
Speaker 4: tools that the designers are using are very different. They're
Speaker 4: not going to write HTMIL or CSS. That's not how
Speaker 4: they work. If you go and look at what you're
Speaker 4: using Photoshop, Figma. You know, there's CONSI file tools. It's
Speaker 4: not HTML and CSS, so you need to bridge a
Speaker 4: much larger gap and then and over the responsibility to them,
Speaker 4: and then over the tools to them so that they
Speaker 4: can be effective and own the application.
Speaker 3: That's what we have AI for now. Well, you know,
Speaker 3: a I.
Speaker 4: Can do a lot, but unfortunately, up until today it
Speaker 4: didn't replace the developer all the designer. We still have
Speaker 4: a few years for us at least.
Speaker 3: You know, when people ask me if I'm worried about
Speaker 3: AI replacing development developers, I say, well, you know, eventually
Speaker 3: AI will replace everybody, so it's just a question of
Speaker 3: time when they'll get to you. Nobody is safe anyway.
Speaker 1: Yeah, yeah, when people ask me the question as well,
Speaker 1: not yet. I mean, some of the tools are really nice,
Speaker 1: but at the end of the day, making the decisions
Speaker 1: that I make, they just are not there at all.
Speaker 4: I think the easiest way to understand that is if
Speaker 4: you'll give an AI to fly jetliner. It would do
Speaker 4: that very well, probably better than any human pilot. It
Speaker 4: would flew. It would fly a plane in a very
Speaker 4: correct way mountain. It would be very correct and a
Speaker 4: very smooth flight. But it's okay for it to fly
Speaker 4: into a mountain. So I think this is kind of
Speaker 4: the god with a I.
Speaker 3: You remind me, I had a friend who was an
Speaker 3: airline pilot and he basically described his job to me
Speaker 3: once as like one hundred hours of boredom and five
Speaker 3: minutes of pure terror.
Speaker 1: Yeah, we've had autopilot for years and it's been a
Speaker 1: tool that the pilots have used for years, and.
Speaker 2: It's worked great.
Speaker 1: You know, we typically don't see too many airline catastrophes
Speaker 1: the last week notwithstanding. And you know, but it's a
Speaker 1: different problem, it's a different set of problems than what
Speaker 1: we're talking about with programming.
Speaker 3: Well, it's actually easier for an AI to fly plane
Speaker 3: than to drive a car. But you know, let's pull
Speaker 3: let's I would like to pull us back to talk
Speaker 3: about frameworks. And I would actually like to start with
Speaker 3: something that I've been thinking about a lot, and in
Speaker 3: fact even had kind of a change of a perspective about.
Speaker 3: And I can talk about that, but I first would
Speaker 3: like to hear you you have and that's talking about
Speaker 3: what are in fact framework, what constitutes a framework versus say,
Speaker 3: you know, a library or a set of tools or
Speaker 3: an application or whatever.
Speaker 4: So you know. For me, the definition is actually actually
Speaker 4: pretty simple. Every software, everything, any kind of software in
Speaker 4: the world can be split into two kinds of interactions.
Speaker 4: There is an interaction that is going into your code
Speaker 4: something calling your code, and there is an interaction where
Speaker 4: your code is called calling something else. Now, when your
Speaker 4: code is calling something else, you have a choice. You
Speaker 4: can choose which tool you are going to use to
Speaker 4: call something else. Now you have to use a tool.
Speaker 4: There is no way to call something else without using
Speaker 4: a tool. Might be a system library, might be a
Speaker 4: built in library, might be some ail level library like
Speaker 4: NTM or some other package. But there is always you
Speaker 4: have the choice almost everywhere of what you use. That
Speaker 4: is where it is a set of tools you can
Speaker 4: just choose from. But when you are being called, you
Speaker 4: don't have the choice of who is calling you. You
Speaker 4: are building an application within some kind of a container
Speaker 4: that runs your code, or some kind of box that
Speaker 4: calls your code. This is what is a framework. It
Speaker 4: is a frame that is activating your code on different
Speaker 4: entry points. And then your code can choose to different
Speaker 4: teams and give and call some exit points, some using
Speaker 4: some utilities and some tools.
Speaker 3: So I had the exact same outlook on frameworks versus liberries.
Speaker 3: But then my point of view shifted a little bit,
Speaker 3: and now I think about it more in the context
Speaker 3: of architecture. When I think about when you're dictating the
Speaker 3: architecture its libraries, When the architecture is kind of dictated
Speaker 3: to you, that's a framework.
Speaker 4: But it's kind of the same same.
Speaker 3: Yeah, you's a big overlap, but it does shift the
Speaker 3: perspective a bit. I think that the best frameworks are
Speaker 3: the frameworks that the architect that they make the architecture
Speaker 3: of the solution that you're going to build more clearer.
Speaker 3: Let's let's put it this way. You know where the
Speaker 3: pieces are supposed to slide in.
Speaker 4: I think what you're talking here is about something a
Speaker 4: little bit different when you talk about, you know, frameworks.
Speaker 4: There's a few concepts that have emerged over time to
Speaker 4: make software to be easier to code against. One is
Speaker 4: the ability to make it easy to be tested in
Speaker 4: a simple environment. Another one is the concept of locality
Speaker 4: of definition, so that all of the concerns are in
Speaker 4: one file and not spread across multiple files. And another
Speaker 4: thing that is a bit of a little bit subtle
Speaker 4: is that the syntax is that when you read it,
Speaker 4: you can understand what it does. You know, people tend
Speaker 4: to call it no magic, but I don't like that
Speaker 4: definition because we as developers consider everything smart that someone
Speaker 4: has written as magic. So it's not. I won't say that.
Speaker 4: I would say that if it makes you right in
Speaker 4: a syntax that is easy for the average developer that
Speaker 4: is working with you to understand what's going on, then
Speaker 4: it is probably doing something good.
Speaker 3: That fair the principle of least surprise basically, yeah.
Speaker 4: So it's look yeah.
Speaker 1: So my question with that is, so, I mean, folks
Speaker 1: that listen to the show know that I do most
Speaker 1: of my work in Ruby on rails. And some of
Speaker 1: that is true, right, some of it if you really
Speaker 1: read stuff, or you read the code and it's you know,
Speaker 1: you pretty intuitively know what it does.
Speaker 2: So some of the.
Speaker 1: Stuff you pretty intuitively know what it does because you've
Speaker 1: been doing rails for twenty years, right, and so you
Speaker 1: look at it and you know what the conventions are
Speaker 1: and you follow it.
Speaker 2: So how much of it's one and how much of
Speaker 2: it's the other? Right?
Speaker 1: With react or view or any of these other tools
Speaker 1: that might give you that sense of Okay, I can
Speaker 1: look at this code and know what it is.
Speaker 2: How much of that is?
Speaker 1: Wow, it clarifies that that's what's going on here, and
Speaker 1: how much of that is I've been doing react for
Speaker 1: long enough that I know what that's what this code is.
Speaker 4: You know, the measure of ooh against uh. Theory about
Speaker 4: that when you go into a new system and you're like, hey,
Speaker 4: doing something really exciting. Whoa, and then you when you
Speaker 4: go into another and then you try to make it
Speaker 4: do something it doesn't work, and then you figure, ah,
Speaker 4: it has to work that way. That's not intuitive. You know,
Speaker 4: that's the measure. It's the measure how much times it's
Speaker 4: doing things in the way you expect it to be
Speaker 4: doing versus how much times it surprises you're doing something
Speaker 4: in a very unintuitive way. This is kind of a
Speaker 4: measure for APIs and the local tools to know how
Speaker 4: good they are the moments against the ouh moments.
Speaker 3: Yeah, I would like to add to that. You know,
Speaker 3: at the end of the day, I'm always drawn back
Speaker 3: to the No Silver Bullet article that talks about essential
Speaker 3: versus what was the other one? Essential complexity versus non
Speaker 3: essential complexity and you know, we are solving complicated problems,
Speaker 3: at least we strive to. And when you solve complicated problems,
Speaker 3: even when there are strong guidelines for what the architecture
Speaker 3: should be like, don't expect the solution to be trivial.
Speaker 3: That's point number one and point number two. You know,
Speaker 3: you try to make your system idiot proof, but then
Speaker 3: somebody goes along and invents a better idiot. So people
Speaker 3: will always find way to surprise you and work against
Speaker 3: the grain of what the framework encouragees you know.
Speaker 4: But I think, I think then sorry, you need you
Speaker 4: need to look at frameworks in in three different aspects.
Speaker 4: There is one which is the functional aspect does it that?
Speaker 4: Does does it doing? Is it doing what you needed
Speaker 4: to be doing? And are different frameworks similar in terms
Speaker 4: of the functional aspects of the framework regardless of the syntax.
Speaker 4: And then there is a second question, which is when
Speaker 4: you look at the non functionals like like performance, for instance,
Speaker 4: are the record or do you do you even care?
Speaker 4: Is the difference significant? And for example, is the fact
Speaker 4: that svelt is much more efficient then react? Is it
Speaker 4: something you really care about in your specific case, your
Speaker 4: specific application. And only after you're done with those two
Speaker 4: with the functional and non functional only then you come
Speaker 4: to syntax and you all knows you are with the developer.
Speaker 3: Yeah, but look, when I think about React, for example,
Speaker 3: for me, the core of React are a few well
Speaker 3: defined concepts, and now it's pretty unfortunate that a lot
Speaker 3: of React developers may not actually be familiar with these
Speaker 3: core concepts. And the core concepts, by the way, are
Speaker 3: regenerate the UI as a function, regenerating the entire UI
Speaker 3: from the state whenever the state changes and you need
Speaker 3: directional data flow. Maybe I'm missing one or another one,
Speaker 3: but those are like the core concepts for me when
Speaker 3: I'm thinking about React, and then when I think about
Speaker 3: let's say Solid, it has different core concepts. Or if
Speaker 3: I'm thinking about Spelt, it also has different core concepts.
Speaker 3: So a big part of ideally of choosing a framework
Speaker 3: would have been choosing the framework whose architecture or the
Speaker 3: architecture that it advocates for for building applications best suits
Speaker 3: your personal tastes. Now, unfortunately most of us don't go
Speaker 3: through this process. That's a framework choice is tendable. Yeah,
Speaker 3: just to finish because in a lot of cases, the
Speaker 3: framework choice is kind of dictated to us.
Speaker 4: You're right, it's again it's assuming that functional is equal
Speaker 4: and assuming that the non functional is equal, then you
Speaker 4: come to aesthetics. And what you're talking about is still
Speaker 4: just aesthetics. And you know React, you brought the concept
Speaker 4: of React. React is neither reactive nor functional today. You know,
Speaker 4: it's it's it has done a lot, does it done
Speaker 4: a huge work moving us forward, as you know, fronted
Speaker 4: developers it there is a reason why it is the
Speaker 4: number one firm of today in the world, right, but
Speaker 4: it's kind of not what it aimed at doing. You know,
Speaker 4: context is you could argue that props, context, and state
Speaker 4: are all different ways to get data into the function,
Speaker 4: and two of them are not functional.
Speaker 3: Well, you know, the dom is not functional. JavaScript is
Speaker 3: not functional, and you're kind of living within the framework
Speaker 3: itself is living within the confines of the environment that
Speaker 3: it's built on. There, you know, you could go with
Speaker 3: ELM if you know, if you really want to go
Speaker 3: to the extreme, but that you know, there's a price
Speaker 3: to pay for that as well. You know, let's say
Speaker 3: ditching JavaScript in favor of ELM or reason or something
Speaker 3: like that.
Speaker 4: No one said that the esthetics is simple getting the
Speaker 4: hostel of a FERMUK in the right way is super hard,
Speaker 4: and there is reason why we have lots of frameworks
Speaker 4: trying different directions and different things. You know, you look
Speaker 4: at what's happening today. There is one major direction going
Speaker 4: on today, which is signals. Everyone except React as signals today.
Speaker 4: There might be some old firms that don't have them,
Speaker 4: that they didn't adopt signals, but almost everyone except React
Speaker 4: are using signals as the main obstruction for state management.
Speaker 4: And there is a reason behind that. It Trying signals
Speaker 4: on different places, different frameworks, different syntaxes seems to work.
Speaker 4: Trying signals in terms of the non functional performance, Okay, again,
Speaker 4: it seems to work. It seems to be something that
Speaker 4: people comprint. By the way, signals is not a trivial team.
Speaker 4: It takes time to understand that, but once you do,
Speaker 4: it becomes something that is very robust to use. So
Speaker 4: again it's just aesthetics.
Speaker 3: Well for me, it's more than aesthetic actually, because it
Speaker 3: informs the way that you deconstruct or the problem and
Speaker 3: then construct the solution. So for example, first of all,
Speaker 3: I'd like to mention, by the way that when we
Speaker 3: had Joe Savona and Satia FROMETA to talk about the
Speaker 3: React compiler. Joe said very clearly that signals are not
Speaker 3: in reacts future. He basically said, you know, if if
Speaker 3: signals become a part of the JavaScript language, there is
Speaker 3: actually a proposal for that, then then we will, and
Speaker 3: I'm speaking for Joe, then we will support it. But otherwise,
Speaker 3: no signals for React because that's not the that's not
Speaker 3: their vision for how front and applications should be built.
Speaker 3: Their whole thing is about, you know, reconciliation and stuff
Speaker 3: like that.
Speaker 4: I'll talk at what you're saying right now. You're talking
Speaker 4: about opinions of.
Speaker 3: Course, frameworks, our opinions that that's kind of my point.
Speaker 4: Well, I to be honest, I don't agree. I think
Speaker 4: that this is kind of this is kind of this
Speaker 4: is kind of a state we arrived by forgetting the
Speaker 4: functional and unfunctional requirements, and we kind of set it
Speaker 4: very you know, very basic frameworks that are in your
Speaker 4: not really that are just competing with one another on
Speaker 4: aesthetics and performance and that's it. But there's a lot
Speaker 4: more other stuff that you can compete on, such as
Speaker 4: let's talk about web essentials. You know, web essentials is
Speaker 4: a list of I think probably thirteen fourteen items that
Speaker 4: when you're doing, when you are working as a web developer,
Speaker 4: you need to take care of. And there are things
Speaker 4: like creating responsive design, being performan breakpoints, multilingual, a BIT testing,
Speaker 4: so ABY testing is actually not a web essential, but
Speaker 4: it's nice to have cookies regulation in the EU, accessibility
Speaker 4: the new accessibility regulation in the U now a g
Speaker 4: DPR p i R, and there's more.
Speaker 2: And all of those are lists somewhere that I could
Speaker 2: just publish.
Speaker 4: I have it in my I have it somewhere I can,
Speaker 4: I can send it to you. And basically all of
Speaker 4: that list is anything you're doing, anything that is customer
Speaker 4: facing on the Internet, you have to take care of
Speaker 4: all of that list. If you're doing an enterprise behind
Speaker 4: the behind the look in, you need to take care
Speaker 4: of most of it. And your se O is another one.
Speaker 4: And all of the cost lot of money. Why aren't
Speaker 4: frameworks helping us with all of that list of stuff?
Speaker 3: I think when you start talking about these things, you're again,
Speaker 3: and it's an interesting distinction to make from what I see,
Speaker 3: you're starting to move from talking about frameworks to talking
Speaker 3: about meta frameworks, from talking about react to talking about
Speaker 3: the next JS, from talking about view to talking about
Speaker 3: next and so on and so forth. At least that's
Speaker 3: been my experience with these sorts of things. Most frameworks
Speaker 3: these days have a much lower bar in the in
Speaker 3: the functionality that they're trying to provide. There are more
Speaker 3: about you know, use us instead of using just the DOM.
Speaker 4: But keep in mind when you talk when you asked
Speaker 4: about what is the definition of framework, I framok is
Speaker 4: not defined as only something on the client that interacts
Speaker 4: with the don It is defined, as you said, as
Speaker 4: something that imposes an architecture on your application that guides
Speaker 4: you into building better software. With that definition, I would
Speaker 4: expect the sub the framework to help me with all
Speaker 4: of the web essentials as well, because it's something I
Speaker 4: have to do. It's something those are more constraints my
Speaker 4: applications to work with. I would expect the architecture of
Speaker 4: the framework to be such that would take care of
Speaker 4: those concerns, or at least help me to take care
Speaker 4: of them.
Speaker 1: So I have to ask then, because it seems like,
Speaker 1: you know, if you take this narrow definition of a framework,
Speaker 1: you know whether it's you know, an aesthetic way of
Speaker 1: putting together an apple, or whether it gives you the architecture,
Speaker 1: whether or not it provides you with some of these
Speaker 1: essentials you know that you would expect it to.
Speaker 2: It seems like that it.
Speaker 1: Seems like there are various definitions and maybe various expectations
Speaker 1: that people have of a framework, right, because I could
Speaker 1: expect that, Okay, for me, the framework that I want
Speaker 1: will do all these things. For somebody else, it may
Speaker 1: just say, hey, here's how you're going to structure your application,
Speaker 1: here's the understanding of here's where the pieces go. Here
Speaker 1: are a series of tools, libraries, toolkits, et cetera that
Speaker 1: make the API that I'm building against that much more friendly. Right,
Speaker 1: And so there are all these different pieces that people
Speaker 1: consider when they have the framework, and it seems like
Speaker 1: a lot of people are picking it for different reasons.
Speaker 2: Right.
Speaker 1: So some people may be picking it because hey, I
Speaker 1: want a more esthetically pleasing thing, or I want to
Speaker 1: be more efficient in my time use by having the
Speaker 1: framework handles and things for me, or by fitting a
Speaker 1: mental model that I can synk my head into. And
Speaker 1: so you know, you're saying, well, it's aesthetics, or you
Speaker 1: know it's aesthetics, and maybe some of these other things.
Speaker 1: But how do you really make that decision on what
Speaker 1: people should consider a framework.
Speaker 4: I don't think there is one answer for what is
Speaker 4: a framework. I think the role of a framework is
Speaker 4: to help us to make us small efficient, right, And
Speaker 4: because you know I could just use Jake Uark and
Speaker 4: that would work, I would yeah, And then we decided
Speaker 4: to move to React because it is more efficient to
Speaker 4: write code and React compelled to j Query both in
Speaker 4: the first ramp up and then in maintainability. And then
Speaker 4: when you're taking just that those two concerns, the first
Speaker 4: ramp up and maintainability, and you're also starting to add
Speaker 4: things like accessibility into the mix, and you're asking a,
Speaker 4: I mean, how much work do I need to do
Speaker 4: in a React application to make it to make it accessible?
Speaker 4: Versus can I get the framework that would help me
Speaker 4: to have lift that that burden in making me more
Speaker 4: efficient there? And the same can go for any of
Speaker 4: the other Web concerns.
Speaker 3: M My experience though, has been that most people who
Speaker 3: use JavaScript frameworks for the front end, because it pulls
Speaker 3: them kind of away from the actual semantic HTML, end
Speaker 3: up with the mountains of dives, which is anything but
Speaker 3: semantic and anything but accessible and so forth, and that
Speaker 3: if you want to get these in the context of frameworks,
Speaker 3: you usually what you end up is reaching for library
Speaker 3: for component libraries that are compatible with the framework that
Speaker 3: you can use from within the framework, or maybe if
Speaker 3: the organization is large enough, then it creates its own
Speaker 3: design system or adopts some external design system in order
Speaker 3: to get everything you describe. So are design should design
Speaker 3: systems have been part of the frameworks the framework itself.
Speaker 3: Shouldn't they be bluggable to the framework?
Speaker 4: You know? I think saying that the thermok allows a
Speaker 4: design system that solves some of the concerns is a
Speaker 4: way to support concerns now with accessibility that might work
Speaker 4: with multilingual or with GDPR or cookies you might need
Speaker 4: something else. Design system will not solve cookies regulation for you.
Speaker 4: So I think even though you know real act and
Speaker 4: all of the frameworks allow design systems because a just
Speaker 4: makes us much more efficient to use the design system components,
Speaker 4: it's still not enough. So I really think that frameworks
Speaker 4: will need to take that into account. We are in
Speaker 4: a market that we're shifting in light speed from an
Speaker 4: unregulated market to a very very regulated market, And that
Speaker 4: means that the price of creating an application and a
Speaker 4: website goes up very fast because of those regulations. And
Speaker 4: we don't know where're going to end up with and
Speaker 4: don't even we didn't even start talking about AI. What
Speaker 4: does it mean for your framework to make your application
Speaker 4: AI ready by whatever going to be the nominate AI
Speaker 4: client application that could going to be the next in
Speaker 4: the Internet beside Google and Facebook and TikTok.
Speaker 3: By the way, when you're saying AI ready, are you
Speaker 3: talking about using AI to generate your code, or about
Speaker 3: integrating AI functionality into the actual end product or both
Speaker 3: or something else.
Speaker 4: I'm talking about something else. It's clear to for everyone
Speaker 4: that there is going to be a dominant AI application
Speaker 4: over the Internet. You know, right now the Internet is
Speaker 4: about one hundred billion dollars market around search and about
Speaker 4: another one hundred billion dollars market around social. You can
Speaker 4: assume that there's going to be another one ordred billion
Speaker 4: dollars market around advertising or discovery or something like that.
Speaker 4: With AI. We don't know the application, we don't know
Speaker 4: the provider, we don't know when it's going to happen,
Speaker 4: but it's probably going to app something like that, and
Speaker 4: then you want your business to be listed there as well.
Speaker 4: You know, today, when you build a business or any website,
Speaker 4: you have to be listed in Google and in social.
Speaker 4: You probably want a mobile application as well. You want
Speaker 4: to cover all the different fronts that you might get
Speaker 4: users from. So what would be that next front with AI?
Speaker 4: We don't know yet, but something will happen. And when
Speaker 4: that will happen, how will your framework help you to
Speaker 4: be there in the right way.
Speaker 3: So you're basically talking about having some sort of presence
Speaker 3: within an AI driven interface, whatever that might be. And
Speaker 3: that's kind of similar to how we currently have. Like
Speaker 3: you said, let's say a page on Facebook or something,
Speaker 3: or or on Instagram or something like that. Is that
Speaker 3: what you're talking about.
Speaker 4: Yeah, it's you know, think about think about two thousand
Speaker 4: and eleven, a year before Facebook really become dominant. If
Speaker 4: at twenty eleven I would say, hey, websites, you need
Speaker 4: to prepare yourself to social. We don't know what's going
Speaker 4: to be the dominant social application, but something is coming.
Speaker 4: This is kind of what I would sound like. So
Speaker 4: we know there's something coming, we just don't know what
Speaker 4: and who.
Speaker 3: And again maybe it's just me or the terminology that
Speaker 3: I'm familiar with because of React and things similar to it.
Speaker 3: But React or view or Swelt or solid they've set
Speaker 3: their sights much much lower than that. As I said,
Speaker 3: if the things that you're talking about, our starts are
Speaker 3: more in the realm of meta frameworks or even you know,
Speaker 3: meta meta frameworks. I've heard the term stacks sometimes used.
Speaker 3: So for example, Kensey Dodds has this epic stack which
Speaker 3: involves you know, obviously Remix, but also and React, but
Speaker 3: also a particular authentication provider and a payment provider and
Speaker 3: a database provider and so on so forth, and you
Speaker 3: integrate all of these things together, hopefully more or less seamlessly,
Speaker 3: in order to get a more holistic type solution that
Speaker 3: might address the requirements that you seem to be talking about.
Speaker 3: Or at least that's how it seems to me.
Speaker 4: But I have to ask you a question. When you
Speaker 4: look from jaquerd up to React and up to Angulau,
Speaker 4: doesn't it seem the same. jQuery is actually much liner.
Speaker 4: It tries to do much new. Compelled to react or
Speaker 4: act is trying to so much more compere to jQuery.
Speaker 4: Jaquerry is just trying to obstruct a little bit to
Speaker 4: dom APIs, that's all. And it is a framework, the
Speaker 4: most popular one in the world. And then React is
Speaker 4: also a framework, but it adds another obstruction layer on top,
Speaker 4: and angular is the same, and then we're going to
Speaker 4: be we might add another obstruction layer on top. You know,
Speaker 4: you're trying to put labels on it, but why are
Speaker 4: those labels important?
Speaker 3: Well, I actually think that labels are important. You know,
Speaker 3: there's that statement that there are two hard things in
Speaker 3: computer science, cash and validation, naming things and off by
Speaker 3: one errors, and so naming things is actually pretty pretty important.
Speaker 3: You know, uh, design patterns this are basically ways of
Speaker 3: naming things so that we have a common vocabulary. So
Speaker 3: I do think that having common terminology is actually important
Speaker 3: for us to be able to converse and exchange ideas
Speaker 3: and concepts.
Speaker 4: I can accept that, But I just I think that
Speaker 4: even Evin said that a meta framework is just another
Speaker 4: filmwork that does more.
Speaker 3: Yeah again for me, right now again, my opinion may
Speaker 3: certainly change, but right you know, you you seem to
Speaker 3: have a very different definition. A definition that I used
Speaker 3: to have for framework versus meta framework was basically that
Speaker 3: it straddles both sides of the network divide that meta
Speaker 3: framework has a service side aspect to it, whereas a
Speaker 3: framework doesn't. But but your definition seems again to be
Speaker 3: much more holistic than mine, you know.
Speaker 4: But let's work with all definitions. I'm fine with that.
Speaker 4: So when I'm saying that frameworks need to cope with
Speaker 4: all of the web essentials, it's fine saying meta frameworks
Speaker 4: we need to cope with all of the web essentials.
Speaker 4: Totally fine. It's a little bit limiting, but you know,
Speaker 4: I don't care. That's fine. Now we can go to
Speaker 4: more extreme things that are upening with frameworks. Again, meta
Speaker 4: frameworks might be And I'm seeing two trends or two
Speaker 4: lines that are kind of interwined together. One is the
Speaker 4: idea of the idea of gradual rendering. When we start
Speaker 4: seeing that a little bit in frameworks. The idea of
Speaker 4: gradual rendering is that let's start shifting rendering back as
Speaker 4: much as we can now to the server side and
Speaker 4: to earlier timeline. Now you already have frameworks that are
Speaker 4: doing the normally we would call that a build time
Speaker 4: rendering or static side generation. But actually don't like this definition.
Speaker 4: When you look at data, you have data that changes slowly,
Speaker 4: like blog posts and products, and I don't know, there's
Speaker 4: many things that change slowly, and then there's things that
Speaker 4: change fast, and then there are things that change interactively
Speaker 4: when user clicks on something and something changes on the client.
Speaker 4: So interactive things have state management and run on the client.
Speaker 4: Fast changing you need to do in assal slowly changing.
Speaker 4: You I can do an event of something changed, why
Speaker 4: can't I combine all three of them in one page
Speaker 4: in one component. Now you're starting to see things like
Speaker 4: that happening react several components. Let's a developer to choose
Speaker 4: to have one layer selver rendered, which is only selver rendered,
Speaker 4: and then have another layer or another subcomponent that is
Speaker 4: rendered on the selver but is also interactive on the
Speaker 4: client quickly starting to do stuff like that. Your other
Speaker 4: films are starting to do stuff like that. But I
Speaker 4: haven't really seen that as been a first class pattern
Speaker 4: in any of the frameworks.
Speaker 3: I would take it a step further. It seems to
Speaker 3: me that, and I'll be blunt, it seems that framework
Speaker 3: makers are solving problem that the market is not looking
Speaker 3: for them to solve. I'm you know, I've spoken to
Speaker 3: a lot of organizations in this context who basically say,
Speaker 3: you know, we want React on the front end and
Speaker 3: something else doing RESTful APIs on the back end, and
Speaker 3: I don't and I don't want React on my back end.
Speaker 3: Uh and and next and Versall's success not notwithstanding the
Speaker 3: majority of enterprise React applications that I'm saying are very
Speaker 3: much keeping the framework on the client side.
Speaker 4: Only you're right, And yet when you go and when
Speaker 4: and keep in mind that Versall is building websites. In
Speaker 4: website you must have selvis a rendering because of CEO, again,
Speaker 4: because because of web essentials. But then even for the enterprises,
Speaker 4: they get to the point where there's an a but
Speaker 4: we have a performance problem, or we have a flickering
Speaker 4: or a textload long to load the page, and we
Speaker 4: need to do something about that. Now when you run
Speaker 4: React on the selver, when you react was not designed
Speaker 4: to work on a selver environment. What versaill we're doing
Speaker 4: is actually very smart. But they're trying to take something
Speaker 4: that doesn't really fit in that environment and make it
Speaker 4: work in that environment. It wasn't designed for it. Think
Speaker 4: what would happen if you actually go and design a
Speaker 4: free work that would work in such a way and
Speaker 4: would support both the website and enterprise use cases.
Speaker 3: Well, I guess, Chuck, you're supposed to say at this point,
Speaker 3: that's why we have rails. And what's the name.
Speaker 2: You've been refraining from saying that this whole time.
Speaker 3: So rail rails, And what's the name of the thing
Speaker 3: that you use in stimulus or the other one, turbo
Speaker 3: turbo stimulus whatever. You've got a whole bunch of terms.
Speaker 2: Wire.
Speaker 3: I think that was the one.
Speaker 4: Yeah, Well, Rails did a lot of really good stuff,
Speaker 4: and it tink. Its kind of when you look at
Speaker 4: the what I would call the one point five age
Speaker 4: of the Internet, which is basically static, basically self aside
Speaker 4: rendering everything and a little bit of JavaScript, a little
Speaker 4: bit of jQuery on the client. Your WordPress is there,
Speaker 4: Shopify is there, Rails is there. Rails is kind of
Speaker 4: the best of the breed, but it does suffer. And
Speaker 4: there is a reason why we move to Web two
Speaker 4: point zero, which starts with React and Angula, which our
Speaker 4: client first libraries, simply because you want to be very
Speaker 4: productive on the client and very interactive on the client,
Speaker 4: and very fast on the climb. And then you know,
Speaker 4: when you start moving from front and libraries back to
Speaker 4: the back end. Why would they use a different language
Speaker 4: for the back end and the front end. Why would
Speaker 4: they use react on the front end and rails on
Speaker 4: the back end. It makes my life much harder. And
Speaker 4: only that would be two different people, you know, rails
Speaker 4: in a very good way for someone else that needs
Speaker 4: to learn both react and rails and how to connect
Speaker 4: them together. That's are there the news in next years?
Speaker 4: And again it's the lockdates the Yeah, so yeah.
Speaker 2: I thought you were going to go to express or something.
Speaker 1: I'm like, now express, if you're going if you're going
Speaker 1: to react to next?
Speaker 2: I can, I can? I can see that.
Speaker 4: Yeah, And I think what we're what I would, I
Speaker 4: think we're kind of they've kind of converging on is
Speaker 4: there's them that I just don't want to use. So
Speaker 4: instead I'm going to say firmworks that are designed to
Speaker 4: vote for the back end and the front end as
Speaker 4: first as citizens. And when you when.
Speaker 3: Okay, I'm going to make a conjecture, Well, I think
Speaker 3: that what you or or at least what I'm I'll
Speaker 3: restate what I seem to be hearing you say. You're
Speaker 3: basically saying most modern frameworks that we've seen started there,
Speaker 3: started out client side, and then evolved to work on
Speaker 3: the back end as well. So next GS grew out
Speaker 3: of React and it's effectively implementing a React specification. Knox
Speaker 3: grew out of view, so on and so forth. What
Speaker 3: you're saying is, you know, we've had no GS and
Speaker 3: whatnot on the back end long enough so that we
Speaker 3: can think about frameworks evolving the other way around, starting
Speaker 3: their life on the back end and then evolving to
Speaker 3: support the front end. Is am I getting the gist
Speaker 3: from what you're saying?
Speaker 4: Almost? What I'm saying is think about the framework that
Speaker 4: is designed to work on all three life cycles of
Speaker 4: the web. And you have three life cycles, not two
Speaker 4: of them. You have one for slowly changing data like
Speaker 4: a product was updated maybe once a day or once
Speaker 4: a week. You have a fast change in data that
Speaker 4: you have to render for a user directly on the server,
Speaker 4: like user name or cookies. And then you have interactive
Speaker 4: data or interactive interactions on the client and state management.
Speaker 4: And it doesn't make any sense that those are three
Speaker 4: different obstructions that are done in three different ways. Why
Speaker 4: can't I do them in one? Why can't I get
Speaker 4: the framework that speaks in that language and just does
Speaker 4: it all and not force me to start meshing up
Speaker 4: different things and different concepts to try and understand what
Speaker 4: goes work.
Speaker 2: I mean a lot of the things that you're talking
Speaker 2: about are things that.
Speaker 1: I mean, I kind of manage this stuff so that
Speaker 1: it changes when it needs to or gets you know,
Speaker 1: interaction happens when it needs to. I don't know that
Speaker 1: I think of them as all that different, right they
Speaker 1: all more or less use the same mechanisms.
Speaker 2: Or am I missing something?
Speaker 3: Well, let me put it this way. What I'm saying
Speaker 3: a lot basically people dealing with this problem by effectively
Speaker 3: ignoring it. So, for example, if they build a holy
Speaker 3: client side grander application and just make calls back to
Speaker 3: the two end point to RESTful endpoints whenever they need
Speaker 3: to get more data, so they don't need to think
Speaker 3: about how often the data changes, so they respond quickly
Speaker 3: to client side interactions, and then whenever they need to
Speaker 3: get you know, data from the back end, they just
Speaker 3: call a RESTful API and it comes whichever way it comes.
Speaker 3: So so effectively they respond to both types of interactions
Speaker 3: or all three types of interactions and essentially the same
Speaker 3: the exact same way by by writing event handlers in
Speaker 3: JavaScript that that tender events. These events might be a
Speaker 3: user a mouse click, or these events might be some
Speaker 3: data arriving over the network. It's it's all the same,
Speaker 3: and I I agree with you of that, and reacts
Speaker 3: O her components have been trying to propose a new
Speaker 3: approach to dealing with it, basically saying, you know, I'm
Speaker 3: rendering some stuff on the server, I'm rendering some stuff
Speaker 3: on the client. I'm rendering some stuff on both sides.
Speaker 3: By the way, I'm I totally don't know how many
Speaker 3: organizations are actually using reacts over components in production, certainly
Speaker 3: in anger. Let's say, it's it's an interesting question, you know,
Speaker 3: as I said, there's a growing you know, it seems
Speaker 3: that next gs is eating the React website market, that
Speaker 3: the majority of new React websites are being built using
Speaker 3: next gs. But I have no idea how many of
Speaker 3: them are actually using reacts over components. Certainly, how many
Speaker 3: of them are actually using reacts server components correctly, That's
Speaker 3: that's a totally different question, and it's an interesting one,
Speaker 3: And I don't know how to get this data. What
Speaker 3: how do you think a solution to that might come
Speaker 3: along or might look like that actually solves that problem
Speaker 3: with lower fraction and greater acceptance.
Speaker 4: You can see what both next and well forgot the name.
Speaker 4: There's another fermework and they're doing data loaders that by
Speaker 4: the name of the data loader of function you know
Speaker 4: on which environment run it. You can look at what
Speaker 4: the quicks is doing where you can there is a
Speaker 4: different specific API which is very similar but specific API.
Speaker 4: It says this is something that runs on the selver
Speaker 4: or in the case of quick, everything is by different
Speaker 4: running on the cellver and only being loaded to the
Speaker 4: client if needed, and the compiler is kind of understanding
Speaker 4: what needs to been downloaded to the client. I think
Speaker 4: we need to figure out the syntax. We don't have
Speaker 4: it today.
Speaker 3: By the way, syntax, as far as I can tell,
Speaker 3: seems to me. The solution that these meta frameworks I'll
Speaker 3: use that term are adopting seems to be RPC based,
Speaker 3: so that when when it's it's it's it's functions that
Speaker 3: when they are executed on the server, it's just it's
Speaker 3: just a function called, but when they're executed on the client,
Speaker 3: it's it becomes serialized automatically over the wire. So that's
Speaker 3: the abstraction that I'm seeing kind of being adopted for
Speaker 3: addressing that issue. Now, even that has different approaches associated
Speaker 3: with it. So both that's we had Tenner Lindsley talking
Speaker 3: about what he's doing with the ten with ten stacks start,
Speaker 3: and he's also using RPC, but he's doing it in
Speaker 3: a very different way than the way that next GS
Speaker 3: is even though you might say that in both cases
Speaker 3: it is kind of our PC.
Speaker 4: Yeah, anyway, I want to take you even one step more.
Speaker 4: You know, we talked about design systems. You're using components
Speaker 4: from design systems. Sometimes those components have a large number
Speaker 4: of configuration options. You know, for instance, you might have
Speaker 4: a gallery that I might have multiple layouts, and you
Speaker 4: might be choosing one layout or another, and if that
Speaker 4: choice is static, it's basically a constant or even if
Speaker 4: it is a choice made by slowly changing data, why
Speaker 4: would you download to the browser the full component with
Speaker 4: all of the different options. Why not start looking at
Speaker 4: the values of slowly changing data, which after defining what
Speaker 4: is that that value, it basically become constant data after
Speaker 4: that first phase of rendering, and then let's start deleting
Speaker 4: all the unnecessary code, So all of the other layouts
Speaker 4: of the gallery they don't need to be there. All
Speaker 4: of the other style options they don't need to be there.
Speaker 4: It might have you might have you know, different tabs
Speaker 4: or different you know, screens, or different options that you
Speaker 4: can just delete and just remove, and it might go
Speaker 4: all the way down to your to your design system
Speaker 4: that might have lots of very complicated components because they
Speaker 4: need to cope with lots of complicated situations. You know,
Speaker 4: a drop down with fifty different options of how to
Speaker 4: open a drop down, but I need one, So why
Speaker 4: would you download the browser all of the different options?
Speaker 4: So there is also another potential here for lots of
Speaker 4: very aggressive optimizations that to be honest, no one is
Speaker 4: doing today.
Speaker 3: Well I think quick guys that you mentioned is kind
Speaker 3: of trying to do so at least some of the stuff. Basically,
Speaker 3: it's using a compiler two bundler or smart bundler or transpiler,
Speaker 3: call it what you will, to decide for you which
Speaker 3: code needs to exist where effectively. And then you know, again,
Speaker 3: if if we're talking about stuff like like the hot
Speaker 3: wire that the Chuck mentioned before, you know, when we
Speaker 3: spoke about what's it called HTMX. It's basically saying, why
Speaker 3: why do why send Jason over the wire? That I
Speaker 3: need to have smart on the client side to be
Speaker 3: able to process it according to you know, sophisticated logic
Speaker 3: and transform it into HML when I can just send
Speaker 3: the HTML. And and to an extent, again reacts over
Speaker 3: components are kind of going in that direction. They're not
Speaker 3: actually sending HTML, they're sending virtual dom as it were,
Speaker 3: over the wire, but they are. But again, it's it's
Speaker 3: basically the idea of having generic mechanism that transforms it
Speaker 3: into UI rather than having to download all the custom logic.
Speaker 4: But think about what's happening here. You have a lot
Speaker 4: of innovation going on around all around from meta frameworks,
Speaker 4: around performance and around making your application more efficient. Quick
Speaker 4: is doing that, Civil component is doing that, HTMX is
Speaker 4: doing that, and we're kind of all searching for what
Speaker 4: would be the right obstruction when we want to build
Speaker 4: an application or a website. I would say that and
Speaker 4: add to that all of the web concerns and you
Speaker 4: get like a big area of activity just around the
Speaker 4: existing frameworks and the existing needs.
Speaker 3: So, given everything that we've said so far and giving
Speaker 3: everything that you know, You've explained what is the future
Speaker 3: of frameworks.
Speaker 4: So I think I think you know my bed which
Speaker 4: is and again I'm I'm far reaching. I think we
Speaker 4: need to add two more requirements into the mix. I
Speaker 4: think that if the only reason to move from React
Speaker 4: to another framework is aesthetics and performs, it's not good enough.
Speaker 4: That includes view and swelled and quick and everything else
Speaker 4: and HTMX and so on. And that's why I React.
Speaker 4: No one is living React, to be honest, because the
Speaker 4: need is not strong enough. But I think there are
Speaker 4: two other requirements that are very strong. One is to
Speaker 4: be able to consume teled party components in a way
Speaker 4: that you are both you and the component are safe
Speaker 4: from one another. And you know, just last summer, we
Speaker 4: had an issue where vs code plugins appeared to be
Speaker 4: very There was a published an article that says that
Speaker 4: the self could managed to put a malicious viscode plug
Speaker 4: in with hundreds of thousands of developers, and then they
Speaker 4: can't developed the plug in market for viscode, and thousands
Speaker 4: of plug ins on vis code are potentially malicious. And
Speaker 4: then you have a WordPress which is known to be
Speaker 4: you know, all of the plug ins to be not
Speaker 4: all of them, but a lot of them to be
Speaker 4: really problematic. And then you have lots of other cases
Speaker 4: like that, And then you're downloading a free NPM across
Speaker 4: your company. You're all around talking about enterprises and you
Speaker 4: have no idea what attack vectors are going on through NPM,
Speaker 4: and it is an attack vector to get a certain
Speaker 4: version of library to be legit, and then the next
Speaker 4: one a minor version to have some vulnerability or even
Speaker 4: some attack and you just download used in your code
Speaker 4: in your application and you're exposed to it. So what
Speaker 4: if I can give you a framework. I'm gonna say
Speaker 4: that I can give you that, But what if the
Speaker 4: future framework would protect you from that automatically one example?
Speaker 3: But can framework really do that? Doesn't that need to
Speaker 3: be solved at the platform level, or at least I
Speaker 3: or at least have you know, for the platform to
Speaker 3: provide building blocks that the frameworks can then use to
Speaker 3: provide a provider analistic solutions to stuff like that.
Speaker 4: I think you're asking the wrong question. The right question
Speaker 4: is if someone will make something like that, will be
Speaker 4: able to create a framework that is such a new
Speaker 4: requirement working within it in some way and people are innovative,
Speaker 4: they'll find a way, for instance, that that would be
Speaker 4: a reason to move frameworks. And I think two of
Speaker 4: the requirements that can put on the table for frameworks
Speaker 4: to challenge that would challenge our exiting frameworks is one
Speaker 4: the security and the second one is designed to code.
Speaker 4: Those are the two ones, because we both of either
Speaker 4: one of those will challenge everything we have today in
Speaker 4: a significant way.
Speaker 3: So yeah, I know it's interesting because look, so for example,
Speaker 3: the quick gang made the bat that that getting a
Speaker 3: more performance solution would get people to switch, and so
Speaker 3: far it hasn't really happened, certainly not on mass. Whether
Speaker 3: or not people will switch for that, it's you know,
Speaker 3: maybe I have no insight, but that's the point.
Speaker 4: You know, when the only thing you're comparing are non functional,
Speaker 4: it's very odd to get someone to switch. You have
Speaker 4: to be really, really better and in a really pain
Speaker 4: point when you're starting to move to easier you know, functionals,
Speaker 4: and for a framework allowing designer to work in a
Speaker 4: different way, that's a functional thing. It changes the all
Speaker 4: DNA of your framework. Or when solving a big problem
Speaker 4: like security and your security team is like hey, hey
Speaker 4: dev team, you know we can drop all of that
Speaker 4: million dollar deal of code scanning that we're doing all
Speaker 4: the time to make sure all of your MPM dependencies
Speaker 4: are working and just use a secure framework. Then again,
Speaker 4: no one knows what the future is going to be.
Speaker 4: But my bet is that future framework will not be
Speaker 4: just about aesthetics and better performance. There's going to be
Speaker 4: some other needs, some other requirement, or some other problem
Speaker 4: that it solves on top of all of the existing problems.
Speaker 4: It might be security, might be designed to code, might'd
Speaker 4: be something else. I don't know, so I'll kind of
Speaker 4: inverse your statement. What you're saying is that there are
Speaker 4: a couple of hard problems that we need to be
Speaker 4: solving that fall under the umbrella term web essentials. Current
Speaker 4: existing frameworks and even meta frameworks are not either or
Speaker 4: not solving these problems or not sufficiently solving these problems.
Speaker 4: Something will come along that will and you want to
Speaker 4: call that the future framework. I would say doubt with
Speaker 4: learning of the aesthetics of our current frameworks, that would
Speaker 4: probably be our next big framework.
Speaker 3: I would also, very much, by the way, like to
Speaker 3: have a link to that list of web essentials.
Speaker 4: By the way, I'll send it you I I think
Speaker 4: I edit in the React next the presentation did last year,
Speaker 4: but I'll send.
Speaker 2: It to you.
Speaker 3: Okay, that'll be great. I'll look at that presentation as well.
Speaker 3: I think I did, but I don't remember off the
Speaker 3: top of my head right now.
Speaker 2: Yeah, we're getting towards the end of our scheduled time
Speaker 2: and I have to go soon.
Speaker 1: So is there some kind of overriding point that you
Speaker 1: want to make or some conclusion you want to give
Speaker 1: us you all.
Speaker 4: I think I would say that there's we are at
Speaker 4: a point where something is going to happen with web frameworks.
Speaker 4: You know when you look at we look when you
Speaker 4: want to predict the future, you look at the history,
Speaker 4: and you know our web frameworks. You know, Age one
Speaker 4: was in nineteen ninety five, silver entering. Age one point
Speaker 4: five was in a round two thousand and one with
Speaker 4: j Querry. Age two was with Angular and React around
Speaker 4: twenty ten, and then the metal frameworks and addless CMS
Speaker 4: systems twenty sixteen. That's kind of the two point five age.
Speaker 4: And now there's all kinds of different innovations and ideas
Speaker 4: floating around trying to make something new, and at the
Speaker 4: same time, we're moving from a non regulated market to
Speaker 4: highly regulated market. And on the same time, we have
Speaker 4: AI coming into the mix, and there's going to be
Speaker 4: another something that is going to challenge the Internet with AI.
Speaker 4: By the way, it's not going to replace anything. It's
Speaker 4: just going to be another distribution channel based on AI
Speaker 4: that's going to be accompanying web and mobile and social.
Speaker 4: So with all of that together, something big is going
Speaker 4: to happen with web frameworks. What is it? I think
Speaker 4: that is the big question. But I can promise you
Speaker 4: is that it's not anything like the films we have today.
Speaker 4: It's not going to be just aesthetics and little bit
Speaker 4: better performance. It's going to be something bigger.
Speaker 2: All right, cool, let's go into our picks.
Speaker 1: So one game that my family's played a bit lately
Speaker 1: is called The Crew Mission Deep Sea. Now I've picked
Speaker 1: the Crew before that was the Quest for Planet Nine,
Speaker 1: and they're effectively the same. The difference is is that
Speaker 1: with the the Crew the Deep Sea version, what you
Speaker 1: wind up doing is.
Speaker 2: You still have the missions right, so it still gives
Speaker 2: you a handicap of some kind.
Speaker 1: You can't yeah, you have to do things in a
Speaker 1: sortain order or right. You do so many missions The
Speaker 1: difference is that with the deep Sea mission, the missions,
Speaker 1: you actually flip cards over, just like you did in
Speaker 1: the Quest for Planet Nine, but they can be anything
Speaker 1: from you have to take two cards of this color
Speaker 1: and two cards of that color, or you I mean,
Speaker 1: there are all kinds of things, whereas with the original version,
Speaker 1: you'd flip it over and you'd have to take that card,
Speaker 1: and then you have little tiles you'd put on them.
Speaker 1: You have to do this one first and this one last,
Speaker 1: or you have to do these three in order, or
Speaker 1: you have to do this one first and the next
Speaker 1: two in order after that, and then this one has
Speaker 1: to be last, or things like that. So and it's
Speaker 1: trick taking. So anyway, it's pretty simple and straightforward as
Speaker 1: far as all that goes.
Speaker 2: Game game Board Geek or Board game Geek it rates
Speaker 2: it at.
Speaker 1: A two point four, so it's it's right around casual gamer.
Speaker 2: Good pick it up and have fun with it.
Speaker 1: I like playing these games with four people. You can
Speaker 1: three to five and it's not bad at three or five.
Speaker 1: But anyway, it's it's a fun game. So I'm gonna
Speaker 1: pick that for my pick. My wife and I watched
Speaker 1: a movie this week called Homestead. Let me get a
Speaker 1: link for this and put it in the in the comments.
Speaker 1: But we watched a movie called Homestead, and it's so
Speaker 1: essentially the premise of the show. If you go watch
Speaker 1: the trailer, this is about what you'll get from it.
Speaker 1: Is there's a nuclear bomb that goes off in California,
Speaker 1: in southern California, and then there are other terrorist attacks.
Speaker 1: It's a little fuzzy on it, but they just I
Speaker 1: got was that there major power outages. The power grid
Speaker 1: goes out on the east coast of the United States,
Speaker 1: and so it there's this homestead. Essentially, it's it's some land.
Speaker 1: I kind of othered it was in Montana, but I'm
Speaker 1: not sure on that. But anyway, this guy hires an
Speaker 1: ex Green Beret to put together a security team just
Speaker 1: in case there's kind of a worldwide catastrophe and he
Speaker 1: needs to protect.
Speaker 2: His his area.
Speaker 1: And he's he's like this uber prepper, right, So they
Speaker 1: have medical supplies and you know, they grow stuff on
Speaker 1: their property and all kinds of stuff like that, and
Speaker 1: so you know, this catastrophe hits and so this guy,
Speaker 1: you know, basically grabs his family and heads up to
Speaker 1: where this this homestead is and they you know, they
Speaker 1: they set things up and are protecting the homestead kind
Speaker 1: of thing.
Speaker 2: It was really good. And then when we watched it afterwards,
Speaker 2: so we were part of the Angel Guild, which is
Speaker 2: Angel Studios is the one that put it out.
Speaker 1: Angel Studios also did The Chosen and a bunch of
Speaker 1: other movies that I've picked.
Speaker 2: They turned it into a series, and so we.
Speaker 1: Actually watched the first episode of the series too, and
Speaker 1: it's pretty good. So I'm gonna pick that if that's
Speaker 1: kind of your cup of tea kind of the it
Speaker 1: kind of walks you through the apocalypse and anyway, it's
Speaker 1: it's really awesome.
Speaker 2: So I've been enjoying that, and.
Speaker 4: So you know, talk about the apocalypse. I looked. I've
Speaker 4: seen the series A Van nelsin recently, which is a
Speaker 4: you know, another adaptation of vampires taking over America, and
Speaker 4: but it's you know, it's very very fun. But you know,
Speaker 4: my pig is actually going to be different a different movie.
Speaker 4: I would go with Themselves, which is a movie about
Speaker 4: a princess that is you know bestally it's a common
Speaker 4: girl that is a princess chosen heir to be his wife,
Speaker 4: and it's like a fairy tale story, and then after
Speaker 4: the marriage he kinds of trowser under into a pit
Speaker 4: to be sacrificed to a dragon, and then it kind
Speaker 4: of goes off rails and becomes a very different moviehm.
Speaker 4: Which you know. One thing that actually I liked about
Speaker 4: it is that first it's very very different, and second
Speaker 4: it doesn't go with the regular style of the Prince
Speaker 4: saves the Princess. It actually goes either way around, which
Speaker 4: is really encouraging and really fresh, I would say, m hm.
Speaker 4: As for a game, he's the kay to choose a
Speaker 4: cards game, mhm. You know, there is a game that
Speaker 4: really enjoyed, I really enjoy playing with my kids called
Speaker 4: The Wins, and it actually starts to become a recurring
Speaker 4: idea of queens and Princess, but e's actually it's a
Speaker 4: it's it's a game where there are there are a
Speaker 4: ten queens or so it's a sixteen queens on the board,
Speaker 4: which upside down. I don't know which card is.
Speaker 2: Which queens sleeping quinns. Yeah, yeah, I've played this with
Speaker 2: my kids. It's a fun one.
Speaker 4: It's a really fun one, and my kids are very
Speaker 4: enthusiatic about that, very passionate. So that's just great game.
Speaker 2: Yeah, it's it's very approachable.
Speaker 1: So my daughter is nine now, but I think we
Speaker 1: got it when she was like six or seven, and
Speaker 1: it's definitely approachable for younger kids. But yeah, there's enough
Speaker 1: meat to the game to where adultsod enjoy playing with it.
Speaker 1: It's not when I would pick to play with my friends,
Speaker 1: but with my kids definitely. And Board Game Geek waits
Speaker 1: it at one point oh five, so it's got fairly
Speaker 1: simple mechanics. I can't place two to five people too,
Speaker 1: that's what it says here. And yeah, terrific game.
Speaker 4: Yeah, it's a great game. And you know, my kids
Speaker 4: are nine and eleven, which is just the right age,
Speaker 4: and yeah, it's what's wondrous with them.
Speaker 2: Yeah.
Speaker 1: I had somebody ask me on I think it was
Speaker 1: Ruby Rogues last week. They asked me what games I
Speaker 1: recommend for kids, and I listed a whole bunch there.
Speaker 1: But there are a ton of just terrific games you
Speaker 1: can play with kids.
Speaker 3: That. Yeah.
Speaker 1: I wonder if Board game Geek actually has a list
Speaker 1: for kids.
Speaker 2: I know they have categories here, here we go categories.
Speaker 4: Yeah. I actually I actually never tried that Bold game
Speaker 4: bold game gigs.
Speaker 1: Yeah, board game Geek, So I'll just do that as
Speaker 1: a pick and I'll just throw it out as well.
Speaker 2: So Board Game Geek.
Speaker 1: The way that it works is it's essentially kind of
Speaker 1: this database of board games and they do board games
Speaker 1: and card games. And then what you can do is
Speaker 1: they have forums as well. So if you a lot
Speaker 1: of times, I'm on board game Geek because I'm going, what,
Speaker 1: you know, what what is the I have a question
Speaker 1: about a mechanic in a game? Right, So they didn't
Speaker 1: they didn't clarify, and so.
Speaker 2: You know, I need to know, hey, how does this
Speaker 2: work or that work?
Speaker 4: And I have to say. The director I'm looking at
Speaker 4: is Whiskey Base, and it's a little bit different. It's
Speaker 4: kind of give ratings for different whiskey drums, and so
Speaker 4: you know, you can know which spirit to get, especially
Speaker 4: when you go to the more unique ones and more
Speaker 4: little ones. Just as a Glen Garry twenty nine on
Speaker 4: its way to my house, which is supposed to be
Speaker 4: ninety five at in Corn Whiskey Base, which is kind
Speaker 4: of amazing. We see how it goes.
Speaker 2: Very cool. Yeah I don't drink alcohol at all, but yeah,
Speaker 2: I mean.
Speaker 1: We used to have somebody would pick beers every episode,
Speaker 1: so right, it's like, hey, you have to try this one.
Speaker 1: And sometimes they were local brews and sometimes yeah, I
Speaker 1: could definitely see myself getting into that if that was
Speaker 1: my my thing.
Speaker 2: But yeah, very cool. Well you ovious.
Speaker 1: If people want to check out with Enterprise or they
Speaker 1: want to see what you're working on or catch you
Speaker 1: at a conference or anything, how do they find you?
Speaker 4: Twitter? That is it one. Also there's week Engineering Blog.
Speaker 4: There's lots of stuff there, and you know, just give me,
Speaker 4: give me a call, you know, reach out to me
Speaker 4: on Twitter or then I am there. I'll be up
Speaker 4: to help anyone.
Speaker 2: Sounds good. All right, Well, I'm gonna go ahead and
Speaker 2: wrap this up. Thanks for coming.
Speaker 4: I don't think of having me here. Was a super
Speaker 4: fun
Speaker 2: Yeah, until next time, folks, max out