March 6, 2025 • 75 mins
In this episode of JavaScript Jabber, our host Charles Max Wood, panelist Dan Shappir, and special guest Yoav Abrahami, CTO of Wix Enterprise, engage in a fascinating discussion on the evolving landscape of web frameworks. They dive into the functional and nonfunctional requirements of frameworks, the emerging innovations in meta frameworks, and the significant market shifts driven by increasing regulations and AI advancements. Yoav shares insights into his work on creating a collaborative web framework aimed at bridging the gap between designers and developers, while also addressing crucial future trends in security and design-to-code capabilities. Tune in to explore the dynamic future of web development with insights from industry leaders.
Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.
Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:05):
Hey, welcome back to another episode of JavaScript Chamber.
Speaker 2 (00:09):
This week, on our panel, we have Dan.
Speaker 3 (00:10):
Shapier, Hello from Tel Aviv.
Speaker 2 (00:13):
I'm Charles Maxwood from Top End Devs, Hello from.
Speaker 1 (00:16):
Lehigh, Utah. We also have a special guest, and that
is you have Abraham.
Speaker 2 (00:22):
I hope I got I hope I got close.
Speaker 4 (00:24):
Man, got it right?
Speaker 1 (00:27):
Yeah, I got on when you guys were chatting when
I hopped on and I was like, yeah, my.
Speaker 2 (00:32):
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.
Speaker 4 (00:45):
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.
Speaker 2 (01:05):
Very cool.
Speaker 3 (01:06):
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.
Speaker 4 (01:18):
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.
Speaker 3 (01:31):
Ownership yeah, with a j. Unfortunately you cannot join today.
Speaker 1 (01:37):
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?
Speaker 4 (01:53):
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
(02:14):
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.
Speaker 1 (02:33):
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.
Speaker 3 (02:46):
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.
Speaker 2 (03:04):
Released basically a year and a half.
Speaker 3 (03:05):
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.
Speaker 1 (03:24):
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.
Speaker 2 (03:36):
I don't know. Maybe Dan had a different direction he
wanted to take this.
Speaker 3 (03:39):
No, it's fine, I think.
Speaker 4 (03:42):
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
(04:03):
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
(04:27):
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
(04:49):
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
(05:13):
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.
Speaker 3 (05:23):
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
(05:49):
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
(06:10):
drown I think.
Speaker 4 (06:14):
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
(06:34):
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
(06:57):
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
(07:20):
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
(07:43):
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.
Speaker 3 (07:55):
That's what we have AI for now. Well, you know,
a I.
Speaker 4 (08:04):
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.
Speaker 3 (08:18):
You know, when people ask me if I'm worried about
AI replacing development developers, I say, well, you know, eventually
AI will replace everybody, so it's just a question of
time when they'll get to you. Nobody is safe anyway.
Speaker 1 (08:37):
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.
Speaker 4 (08:52):
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
(09:14):
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.
Speaker 3 (09:24):
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.
Speaker 1 (09:42):
Yeah, we've had autopilot for years and it's been a
tool that the pilots have used for years, and.
Speaker 2 (09:50):
It's worked great.
Speaker 1 (09:51):
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.
Speaker 3 (10:05):
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
(10:26):
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.
Speaker 4 (10:42):
So you know. For me, the definition is actually actually
pretty simple. Every software, everything, any kind of software in
the world can be split into two kinds of interactions.
There is an interaction that is going into your code
something calling your code, and there is an interaction where
(11:05):
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
(11:28):
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
(11:50):
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
(12:11):
teams and give and call some exit points, some using
some utilities and some tools.
Speaker 3 (12:18):
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
(12:39):
architecture its libraries, When the architecture is kind of dictated
to you, that's a framework.
Speaker 4 (12:49):
But it's kind of the same same.
Speaker 3 (12:53):
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
(13:16):
pieces are supposed to slide in.
Speaker 4 (13:20):
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
(13:42):
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,
(14:02):
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
(14:27):
is working with you to understand what's going on, then
it is probably doing something good.
Speaker 3 (14:32):
That fair the principle of least surprise basically, yeah.
Speaker 4 (14:37):
So it's look yeah.
Speaker 1 (14:40):
So my question with that is, so, I mean, folks
that listen to the show know that I do most
of my work in Ruby on rails. And some of
that is true, right, some of it if you really
read stuff, or you read the code and it's you know,
you pretty intuitively know what it does.
Speaker 2 (14:55):
So some of the.
Speaker 1 (14:56):
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.
Speaker 2 (15:04):
So how much of it's one and how much of
it's the other? Right?
Speaker 1 (15:06):
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.
Speaker 2 (15:14):
How much of that is?
Speaker 1 (15:16):
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.
Speaker 4 (15:24):
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,
(15:46):
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.
Speaker 3 (16:06):
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,
(16:28):
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
(16:49):
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.
Speaker 4 (17:04):
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
(17:29):
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
(17:50):
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.
Speaker 3 (18:12):
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
(18:38):
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.
(18:58):
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,
(19:23):
just to finish because in a lot of cases, the
framework choice is kind of dictated to us.
Speaker 4 (19:28):
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,
(19:49):
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,
(20:10):
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.
Speaker 3 (20:24):
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
(20:47):
to pay for that as well. You know, let's say
ditching JavaScript in favor of ELM or reason or something
like that.
Speaker 4 (20:56):
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
(21:16):
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
(21:40):
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
(22:03):
again it's just aesthetics.
Speaker 3 (22:06):
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
(22:29):
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,
(22:51):
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.
Speaker 4 (23:08):
I'll talk at what you're saying right now. You're talking
about opinions of.
Speaker 3 (23:12):
Course, frameworks, our opinions that that's kind of my point.
Speaker 4 (23:19):
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
(23:42):
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
(24:04):
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
(24:28):
the new accessibility regulation in the U now a g
DPR p i R, and there's more.
Speaker 2 (24:36):
And all of those are lists somewhere that I could
just publish.
Speaker 4 (24:41):
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.
(25:03):
And all of the cost lot of money. Why aren't
frameworks helping us with all of that list of stuff?
Speaker 3 (25:14):
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
(25:35):
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.
Speaker 4 (26:00):
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
(26:21):
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
(26:43):
those concerns, or at least help me to take care
of them.
Speaker 1 (26:47):
So I have to ask then, because it seems like,
you know, if you take this narrow definition of a framework,
you know whether it's you know, an aesthetic way of
putting together an 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.
Speaker 2 (27:09):
It seems like that it.
Speaker 1 (27:12):
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
(27:33):
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.
Speaker 2 (27:48):
Right.
Speaker 1 (27:49):
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.
(28:11):
But how do you really make that decision on what
people should consider a framework.
Speaker 4 (28:16):
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
(28:38):
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
(28:59):
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
(29:20):
the other Web concerns.
Speaker 3 (29:23):
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
(29:47):
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
(30:08):
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.
(30:29):
Shouldn't they be bluggable to the framework?
Speaker 4 (30:33):
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.
(30:55):
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
(31:17):
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
(31:38):
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
(32:00):
the Internet beside Google and Facebook and TikTok.
Speaker 3 (32:05):
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.
Speaker 4 (32:21):
I'm talking about something else. It's clear to for everyone
that there is going to be a dominant AI application
over the Internet. You know, right now the Internet is
about one hundred billion dollars market around search and about
another one hundred billion dollars market around social. You can
(32:45):
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,
(33:07):
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.
Speaker 3 (33:29):
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,
(33:53):
or or on Instagram or something like that. Is that
what you're talking about.
Speaker 4 (33:59):
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
(34:20):
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.
Speaker 3 (34:34):
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,
(34:57):
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
(35:17):
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,
(35:38):
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.
Speaker 4 (35:50):
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.
(36:12):
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
(36:34):
those labels important?
Speaker 3 (36:37):
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
(37:03):
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.
Speaker 4 (37:20):
I can accept that, But I just I think that
even Evin said that a meta framework is just another
filmwork that does more.
Speaker 3 (37:30):
Yeah again for me, right now again, my opinion may
certainly change, but right you know, you you seem to
have a very different definition. 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
(37:52):
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.
Speaker 4 (38:06):
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
(38:31):
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
(38:57):
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
(39:17):
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
(39:39):
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.
(39:59):
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,
(40:24):
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.
Speaker 3 (40:45):
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
(41:09):
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
(41:33):
majority of enterprise React applications that I'm saying are very
much keeping the framework on the client side.
Speaker 4 (41:40):
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
(42:01):
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
(42:22):
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.
Speaker 3 (42:41):
Well, I guess, Chuck, you're supposed to say at this point,
that's why we have rails. And what's the name.
Speaker 2 (42:49):
You've been refraining from saying that this whole time.
Speaker 3 (42:52):
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.
Speaker 2 (43:06):
Wire.
Speaker 3 (43:07):
I think that was the one.
Speaker 4 (43:10):
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
(43:32):
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
(43:56):
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
(44:17):
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.
Speaker 2 (44:37):
I thought you were going to go to express or something.
Speaker 1 (44:39):
I'm like, now express, if you're going if you're going
to react to next?
Speaker 2 (44:45):
I can, I can? I can see that.
Speaker 4 (44:48):
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
(45:08):
first as citizens. And when you when.
Speaker 3 (45:12):
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,
(45:35):
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
(45:58):
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?
Speaker 4 (46:14):
Almost? What I'm saying is think about the framework that
is designed to work on all three life cycles of
the web. And you have three life cycles, not two
of them. You have one for slowly changing data like
a product was updated maybe once a day or once
a week. You have a fast change in data that
(46:37):
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
(46:57):
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.
Speaker 2 (47:20):
I mean a lot of the things that you're talking
about are things that.
Speaker 1 (47:24):
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.
Speaker 2 (47:40):
Or am I missing something?
Speaker 3 (47:42):
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
(48:03):
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.
(48:25):
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,
(48:49):
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.
(49:13):
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
(49:35):
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
(49:58):
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.
Speaker 4 (50:18):
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
(50:40):
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
(51:04):
we need to figure out the syntax. We don't have
it today.
Speaker 3 (51:08):
By the way, syntax, as far as I can tell,
seems to me. The solution that these meta frameworks I'll
use that term are adopting seems to be RPC based,
so that when when it's it's it's it's functions that
(51:29):
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
(51:53):
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
(52:14):
is even though you might say that in both cases
it is kind of our PC.
Speaker 4 (52:21):
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
(52:41):
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
(53:04):
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
(53:27):
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
(53:48):
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?
(54:08):
So there is also another potential here for lots of
very aggressive optimizations that to be honest, no one is
doing today.
Speaker 3 (54:17):
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,
(54:42):
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
(55:03):
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
(55:25):
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.
Speaker 4 (55:45):
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
(56:05):
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
(56:25):
existing frameworks and the existing needs.
Speaker 3 (56:31):
So, given everything that we've said so far and giving
everything that you know, You've explained what is the future
of frameworks.
Speaker 4 (56:41):
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.
(57:02):
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
(57:25):
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
(57:47):
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
(58:09):
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
(58:29):
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
(58:51):
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?
Speaker 3 (59:01):
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.
Speaker 4 (59:22):
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
(59:43):
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
(01:00:04):
a significant way.
Speaker 3 (01:00:07):
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
(01:00:35):
or not people will switch for that, it's you know,
maybe I have no insight, but that's the point.
Speaker 4 (01:00:46):
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
(01:01:09):
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
(01:01:31):
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
(01:01:53):
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
(01:02:18):
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
(01:02:42):
probably be our next big framework.
Speaker 3 (01:02:49):
I would also, very much, by the way, like to
have a link to that list of web essentials.
Speaker 4 (01:02:57):
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.
Speaker 2 (01:03:09):
It to you.
Speaker 3 (01:03:10):
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.
Speaker 2 (01:03:18):
Yeah, we're getting towards the end of our scheduled time
and I have to go soon.
Speaker 1 (01:03:23):
So is there some kind of overriding point that you
want to make or some conclusion you want to give
us you all.
Speaker 4 (01:03:31):
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
(01:03:52):
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
(01:04:12):
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
(01:04:35):
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
(01:04:58):
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.
Speaker 2 (01:05:12):
All right, cool, let's go into our picks.
Speaker 1 (01:05:15):
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
(01:05:40):
wind up doing is.
Speaker 2 (01:05:43):
You still have the missions right, so it still gives
you a handicap of some kind.
Speaker 1 (01:05:46):
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
(01:06:07):
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
(01:06:28):
trick taking. So anyway, it's pretty simple and straightforward as
far as all that goes.
Speaker 2 (01:06:41):
Game game Board Geek or Board game Geek it rates
it at.
Speaker 1 (01:06:47):
A two point four, so it's it's right around casual gamer.
Speaker 2 (01:06:54):
Good pick it up and have fun with it.
Speaker 1 (01:06:57):
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.
(01:07:19):
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.
(01:07:42):
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
(01:08:07):
ex Green Beret to put together a security team just
in case there's kind of a worldwide catastrophe and he
needs to protect.
Speaker 2 (01:08:17):
His his area.
Speaker 1 (01:08:19):
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
(01:08:40):
they set things up and are protecting the homestead kind
of thing.
Speaker 2 (01:08:44):
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.
Speaker 1 (01:08:53):
Angel Studios also did The Chosen and a bunch of
other movies that I've picked.
Speaker 2 (01:08:58):
They turned it into a series, and so we.
Speaker 1 (01:08:59):
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.
Speaker 2 (01:09:14):
So I've been enjoying that, and.
Speaker 4 (01:09:20):
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,
(01:09:43):
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
(01:10:05):
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
(01:10:28):
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
(01:10:51):
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
(01:11:15):
ten queens or so it's a sixteen queens on the board,
which upside down. I don't know which card is.
Speaker 2 (01:11:23):
Which queens sleeping quinns. Yeah, yeah, I've played this with
my kids. It's a fun one.
Speaker 4 (01:11:30):
It's a really fun one, and my kids are very
enthusiatic about that, very passionate. So that's just great game.
Speaker 2 (01:11:41):
Yeah, it's it's very approachable.
Speaker 1 (01:11:44):
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
(01:12:05):
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.
Speaker 4 (01:12:14):
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.
Speaker 2 (01:12:23):
Yeah.
Speaker 1 (01:12:24):
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.
Speaker 3 (01:12:38):
That. Yeah.
Speaker 1 (01:12:40):
I wonder if Board game Geek actually has a list
for kids.
Speaker 2 (01:12:48):
I know they have categories here, here we go categories.
Speaker 4 (01:12:51):
Yeah. I actually I actually never tried that Bold game
bold game gigs.
Speaker 1 (01:12:56):
Yeah, board game Geek, So I'll just do that as
a pick and I'll just throw it out as well.
Speaker 2 (01:13:00):
So Board Game Geek.
Speaker 1 (01:13:02):
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,
(01:13:22):
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.
Speaker 2 (01:13:33):
You know, I need to know, hey, how does this
work or that work?
Speaker 4 (01:13:35):
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
(01:13:56):
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.
Speaker 2 (01:14:13):
Very cool. Yeah I don't drink alcohol at all, but yeah,
I mean.
Speaker 1 (01:14:21):
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.
Speaker 2 (01:14:33):
But yeah, very cool. Well you ovious.
Speaker 1 (01:14:37):
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?
Speaker 4 (01:14:46):
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.
Speaker 2 (01:15:04):
Sounds good. All right, Well, I'm gonna go ahead and
wrap this up. Thanks for coming.
Speaker 4 (01:15:09):
I don't think of having me here. Was a super
fun
Speaker 2 (01:15:12):
Yeah, until next time, folks, max out
Hey, welcome back to another episode of JavaScript Chamber.
Speaker 2 (00:09):
This week, on our panel, we have Dan.
Speaker 3 (00:10):
Shapier, Hello from Tel Aviv.
Speaker 2 (00:13):
I'm Charles Maxwood from Top End Devs, Hello from.
Speaker 1 (00:16):
Lehigh, Utah. We also have a special guest, and that
is you have Abraham.
Speaker 2 (00:22):
I hope I got I hope I got close.
Speaker 4 (00:24):
Man, got it right?
Speaker 1 (00:27):
Yeah, I got on when you guys were chatting when
I hopped on and I was like, yeah, my.
Speaker 2 (00:32):
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.
Speaker 4 (00:45):
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.
Speaker 2 (01:05):
Very cool.
Speaker 3 (01:06):
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.
Speaker 4 (01:18):
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.
Speaker 3 (01:31):
Ownership yeah, with a j. Unfortunately you cannot join today.
Speaker 1 (01:37):
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?
Speaker 4 (01:53):
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
(02:14):
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.
Speaker 1 (02:33):
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.
Speaker 3 (02:46):
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.
Speaker 2 (03:04):
Released basically a year and a half.
Speaker 3 (03:05):
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.
Speaker 1 (03:24):
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.
Speaker 2 (03:36):
I don't know. Maybe Dan had a different direction he
wanted to take this.
Speaker 3 (03:39):
No, it's fine, I think.
Speaker 4 (03:42):
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
(04:03):
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
(04:27):
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
(04:49):
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
(05:13):
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.
Speaker 3 (05:23):
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
(05:49):
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
(06:10):
drown I think.
Speaker 4 (06:14):
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
(06:34):
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
(06:57):
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
(07:20):
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
(07:43):
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.
Speaker 3 (07:55):
That's what we have AI for now. Well, you know,
a I.
Speaker 4 (08:04):
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.
Speaker 3 (08:18):
You know, when people ask me if I'm worried about
AI replacing development developers, I say, well, you know, eventually
AI will replace everybody, so it's just a question of
time when they'll get to you. Nobody is safe anyway.
Speaker 1 (08:37):
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.
Speaker 4 (08:52):
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
(09:14):
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.
Speaker 3 (09:24):
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.
Speaker 1 (09:42):
Yeah, we've had autopilot for years and it's been a
tool that the pilots have used for years, and.
Speaker 2 (09:50):
It's worked great.
Speaker 1 (09:51):
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.
Speaker 3 (10:05):
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
(10:26):
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.
Speaker 4 (10:42):
So you know. For me, the definition is actually actually
pretty simple. Every software, everything, any kind of software in
the world can be split into two kinds of interactions.
There is an interaction that is going into your code
something calling your code, and there is an interaction where
(11:05):
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
(11:28):
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
(11:50):
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
(12:11):
teams and give and call some exit points, some using
some utilities and some tools.
Speaker 3 (12:18):
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
(12:39):
architecture its libraries, When the architecture is kind of dictated
to you, that's a framework.
Speaker 4 (12:49):
But it's kind of the same same.
Speaker 3 (12:53):
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
(13:16):
pieces are supposed to slide in.
Speaker 4 (13:20):
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
(13:42):
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,
(14:02):
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
(14:27):
is working with you to understand what's going on, then
it is probably doing something good.
Speaker 3 (14:32):
That fair the principle of least surprise basically, yeah.
Speaker 4 (14:37):
So it's look yeah.
Speaker 1 (14:40):
So my question with that is, so, I mean, folks
that listen to the show know that I do most
of my work in Ruby on rails. And some of
that is true, right, some of it if you really
read stuff, or you read the code and it's you know,
you pretty intuitively know what it does.
Speaker 2 (14:55):
So some of the.
Speaker 1 (14:56):
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.
Speaker 2 (15:04):
So how much of it's one and how much of
it's the other? Right?
Speaker 1 (15:06):
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.
Speaker 2 (15:14):
How much of that is?
Speaker 1 (15:16):
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.
Speaker 4 (15:24):
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,
(15:46):
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.
Speaker 3 (16:06):
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,
(16:28):
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
(16:49):
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.
Speaker 4 (17:04):
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
(17:29):
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
(17:50):
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.
Speaker 3 (18:12):
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
(18:38):
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.
(18:58):
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,
(19:23):
just to finish because in a lot of cases, the
framework choice is kind of dictated to us.
Speaker 4 (19:28):
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,
(19:49):
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,
(20:10):
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.
Speaker 3 (20:24):
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
(20:47):
to pay for that as well. You know, let's say
ditching JavaScript in favor of ELM or reason or something
like that.
Speaker 4 (20:56):
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
(21:16):
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
(21:40):
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
(22:03):
again it's just aesthetics.
Speaker 3 (22:06):
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
(22:29):
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,
(22:51):
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.
Speaker 4 (23:08):
I'll talk at what you're saying right now. You're talking
about opinions of.
Speaker 3 (23:12):
Course, frameworks, our opinions that that's kind of my point.
Speaker 4 (23:19):
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
(23:42):
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
(24:04):
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
(24:28):
the new accessibility regulation in the U now a g
DPR p i R, and there's more.
Speaker 2 (24:36):
And all of those are lists somewhere that I could
just publish.
Speaker 4 (24:41):
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.
(25:03):
And all of the cost lot of money. Why aren't
frameworks helping us with all of that list of stuff?
Speaker 3 (25:14):
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
(25:35):
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.
Speaker 4 (26:00):
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
(26:21):
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
(26:43):
those concerns, or at least help me to take care
of them.
Speaker 1 (26:47):
So I have to ask then, because it seems like,
you know, if you take this narrow definition of a framework,
you know whether it's you know, an aesthetic way of
putting together an 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.
Speaker 2 (27:09):
It seems like that it.
Speaker 1 (27:12):
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
(27:33):
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.
Speaker 2 (27:48):
Right.
Speaker 1 (27:49):
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.
(28:11):
But how do you really make that decision on what
people should consider a framework.
Speaker 4 (28:16):
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
(28:38):
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
(28:59):
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
(29:20):
the other Web concerns.
Speaker 3 (29:23):
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
(29:47):
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
(30:08):
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.
(30:29):
Shouldn't they be bluggable to the framework?
Speaker 4 (30:33):
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.
(30:55):
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
(31:17):
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
(31:38):
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
(32:00):
the Internet beside Google and Facebook and TikTok.
Speaker 3 (32:05):
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.
Speaker 4 (32:21):
I'm talking about something else. It's clear to for everyone
that there is going to be a dominant AI application
over the Internet. You know, right now the Internet is
about one hundred billion dollars market around search and about
another one hundred billion dollars market around social. You can
(32:45):
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,
(33:07):
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.
Speaker 3 (33:29):
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,
(33:53):
or or on Instagram or something like that. Is that
what you're talking about.
Speaker 4 (33:59):
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
(34:20):
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.
Speaker 3 (34:34):
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,
(34:57):
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
(35:17):
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,
(35:38):
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.
Speaker 4 (35:50):
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.
(36:12):
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
(36:34):
those labels important?
Speaker 3 (36:37):
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
(37:03):
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.
Speaker 4 (37:20):
I can accept that, But I just I think that
even Evin said that a meta framework is just another
filmwork that does more.
Speaker 3 (37:30):
Yeah again for me, right now again, my opinion may
certainly change, but right you know, you you seem to
have a very different definition. 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
(37:52):
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.
Speaker 4 (38:06):
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
(38:31):
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
(38:57):
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
(39:17):
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
(39:39):
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.
(39:59):
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,
(40:24):
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.
Speaker 3 (40:45):
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
(41:09):
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
(41:33):
majority of enterprise React applications that I'm saying are very
much keeping the framework on the client side.
Speaker 4 (41:40):
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
(42:01):
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
(42:22):
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.
Speaker 3 (42:41):
Well, I guess, Chuck, you're supposed to say at this point,
that's why we have rails. And what's the name.
Speaker 2 (42:49):
You've been refraining from saying that this whole time.
Speaker 3 (42:52):
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.
Speaker 2 (43:06):
Wire.
Speaker 3 (43:07):
I think that was the one.
Speaker 4 (43:10):
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
(43:32):
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
(43:56):
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
(44:17):
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.
Speaker 2 (44:37):
I thought you were going to go to express or something.
Speaker 1 (44:39):
I'm like, now express, if you're going if you're going
to react to next?
Speaker 2 (44:45):
I can, I can? I can see that.
Speaker 4 (44:48):
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
(45:08):
first as citizens. And when you when.
Speaker 3 (45:12):
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,
(45:35):
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
(45:58):
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?
Speaker 4 (46:14):
Almost? What I'm saying is think about the framework that
is designed to work on all three life cycles of
the web. And you have three life cycles, not two
of them. You have one for slowly changing data like
a product was updated maybe once a day or once
a week. You have a fast change in data that
(46:37):
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
(46:57):
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.
Speaker 2 (47:20):
I mean a lot of the things that you're talking
about are things that.
Speaker 1 (47:24):
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.
Speaker 2 (47:40):
Or am I missing something?
Speaker 3 (47:42):
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
(48:03):
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.
(48:25):
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,
(48:49):
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.
(49:13):
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
(49:35):
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
(49:58):
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.
Speaker 4 (50:18):
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
(50:40):
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
(51:04):
we need to figure out the syntax. We don't have
it today.
Speaker 3 (51:08):
By the way, syntax, as far as I can tell,
seems to me. The solution that these meta frameworks I'll
use that term are adopting seems to be RPC based,
so that when when it's it's it's it's functions that
(51:29):
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
(51:53):
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
(52:14):
is even though you might say that in both cases
it is kind of our PC.
Speaker 4 (52:21):
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
(52:41):
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
(53:04):
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
(53:27):
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
(53:48):
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?
(54:08):
So there is also another potential here for lots of
very aggressive optimizations that to be honest, no one is
doing today.
Speaker 3 (54:17):
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,
(54:42):
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
(55:03):
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
(55:25):
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.
Speaker 4 (55:45):
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
(56:05):
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
(56:25):
existing frameworks and the existing needs.
Speaker 3 (56:31):
So, given everything that we've said so far and giving
everything that you know, You've explained what is the future
of frameworks.
Speaker 4 (56:41):
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.
(57:02):
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
(57:25):
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
(57:47):
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
(58:09):
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
(58:29):
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
(58:51):
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?
Speaker 3 (59:01):
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.
Speaker 4 (59:22):
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
(59:43):
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
(01:00:04):
a significant way.
Speaker 3 (01:00:07):
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
(01:00:35):
or not people will switch for that, it's you know,
maybe I have no insight, but that's the point.
Speaker 4 (01:00:46):
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
(01:01:09):
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
(01:01:31):
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
(01:01:53):
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
(01:02:18):
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
(01:02:42):
probably be our next big framework.
Speaker 3 (01:02:49):
I would also, very much, by the way, like to
have a link to that list of web essentials.
Speaker 4 (01:02:57):
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.
Speaker 2 (01:03:09):
It to you.
Speaker 3 (01:03:10):
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.
Speaker 2 (01:03:18):
Yeah, we're getting towards the end of our scheduled time
and I have to go soon.
Speaker 1 (01:03:23):
So is there some kind of overriding point that you
want to make or some conclusion you want to give
us you all.
Speaker 4 (01:03:31):
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
(01:03:52):
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
(01:04:12):
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
(01:04:35):
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
(01:04:58):
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.
Speaker 2 (01:05:12):
All right, cool, let's go into our picks.
Speaker 1 (01:05:15):
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
(01:05:40):
wind up doing is.
Speaker 2 (01:05:43):
You still have the missions right, so it still gives
you a handicap of some kind.
Speaker 1 (01:05:46):
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
(01:06:07):
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
(01:06:28):
trick taking. So anyway, it's pretty simple and straightforward as
far as all that goes.
Speaker 2 (01:06:41):
Game game Board Geek or Board game Geek it rates
it at.
Speaker 1 (01:06:47):
A two point four, so it's it's right around casual gamer.
Speaker 2 (01:06:54):
Good pick it up and have fun with it.
Speaker 1 (01:06:57):
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.
(01:07:19):
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.
(01:07:42):
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
(01:08:07):
ex Green Beret to put together a security team just
in case there's kind of a worldwide catastrophe and he
needs to protect.
Speaker 2 (01:08:17):
His his area.
Speaker 1 (01:08:19):
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
(01:08:40):
they set things up and are protecting the homestead kind
of thing.
Speaker 2 (01:08:44):
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.
Speaker 1 (01:08:53):
Angel Studios also did The Chosen and a bunch of
other movies that I've picked.
Speaker 2 (01:08:58):
They turned it into a series, and so we.
Speaker 1 (01:08:59):
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.
Speaker 2 (01:09:14):
So I've been enjoying that, and.
Speaker 4 (01:09:20):
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,
(01:09:43):
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
(01:10:05):
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
(01:10:28):
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
(01:10:51):
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
(01:11:15):
ten queens or so it's a sixteen queens on the board,
which upside down. I don't know which card is.
Speaker 2 (01:11:23):
Which queens sleeping quinns. Yeah, yeah, I've played this with
my kids. It's a fun one.
Speaker 4 (01:11:30):
It's a really fun one, and my kids are very
enthusiatic about that, very passionate. So that's just great game.
Speaker 2 (01:11:41):
Yeah, it's it's very approachable.
Speaker 1 (01:11:44):
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
(01:12:05):
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.
Speaker 4 (01:12:14):
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.
Speaker 2 (01:12:23):
Yeah.
Speaker 1 (01:12:24):
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.
Speaker 3 (01:12:38):
That. Yeah.
Speaker 1 (01:12:40):
I wonder if Board game Geek actually has a list
for kids.
Speaker 2 (01:12:48):
I know they have categories here, here we go categories.
Speaker 4 (01:12:51):
Yeah. I actually I actually never tried that Bold game
bold game gigs.
Speaker 1 (01:12:56):
Yeah, board game Geek, So I'll just do that as
a pick and I'll just throw it out as well.
Speaker 2 (01:13:00):
So Board Game Geek.
Speaker 1 (01:13:02):
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,
(01:13:22):
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.
Speaker 2 (01:13:33):
You know, I need to know, hey, how does this
work or that work?
Speaker 4 (01:13:35):
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
(01:13:56):
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.
Speaker 2 (01:14:13):
Very cool. Yeah I don't drink alcohol at all, but yeah,
I mean.
Speaker 1 (01:14:21):
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.
Speaker 2 (01:14:33):
But yeah, very cool. Well you ovious.
Speaker 1 (01:14:37):
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?
Speaker 4 (01:14:46):
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.
Speaker 2 (01:15:04):
Sounds good. All right, Well, I'm gonna go ahead and
wrap this up. Thanks for coming.
Speaker 4 (01:15:09):
I don't think of having me here. Was a super
fun
Speaker 2 (01:15:12):
Yeah, until next time, folks, max out
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Law & Order: Criminal Justice System - Season 1 & Season 2
Season Two Out Now! Law & Order: Criminal Justice System tells the real stories behind the landmark cases that have shaped how the most dangerous and influential criminals in America are prosecuted. In its second season, the series tackles the threat of terrorism in the United States. From the rise of extremist political groups in the 60s to domestic lone wolves in the modern day, we explore how organizations like the FBI and Joint Terrorism Take Force have evolved to fight back against a multitude of terrorist threats.