Hey, welcome back to another episode of JavaScript Jabber. I'm your host this
week, Charles max Wood. Looks like Dan Shapiro just joined us. Dan,
you wanna stay high and we just barely started. So Hi, I'm
glad that I was able to make it on time. Can you hear me?
Okay? Yeah, I'm Charles max Wood from top End Devs and we
have a special guest this week. It is Goe Buckley. Ohen, do
you want to introduce yourself? Tell us how awesome you are, Thanks,
Chuck, appreciate the invite and happy to be here. Yeah. My name
is Owen Buckley. I've been been an enthusiast web developer for a very long
time, since the days that broadband carried much excitement through the world, and
have been professionally developing for about twenty years, primarily in web. Actually got
my first job working on set talk boxes for like TVs and stuff, which
was really an interesting application of JavaScript. But yeah, throughout my career worked
at agencies, consultancies, enterprises, so have been very fortunate to see a
lot of innovation in web development. And yeah, really excited to talk about
kind of where I kind of see web development today. So this is this
episode is going to be about us old timers with a twist. With the
twist, there's the webs for everyone. I have to say that the set
top box thing, I've always wanted to build apps for the TV type things,
so Apple TV or fire Stick or something like that. I've always thought
that would be cool. So yeah, maybe someday. But yeah, I
think we ran across your project Evergreen, and yeah talking about full stack and
web components and stuff like that. Which web components It seems like it gets
popular for a while and then people stop talking about I think it's popular again
for a while. So yeah, do you want to kind of give us
a little bit of an introduction as to where you are and what you're working
on here, and then we can dive into the specifics. Sure? Sure,
So yeah, by project, the project Greenwood that I've been working on
for a little while now, is I guess maybe a homage distillation of all
the good things I've seen in web development and maybe pushing back on I guess
maybe the idea that well, there's a lot of tools and options out there,
not every project necessarily needs a high level of tooling and complexity to achieve
you know, like say a landing page or a blog or something like that.
And yeah, I think mostly just coming to realize that the web has
gotten really, really, really good. I gave a local meetup talk a
couple a few weeks ago called from Webpack to web APIs, and I was
trying to use that as a mechanism to showcase that while webpack did a lot
of very cool things back in the day, it also kind of inverted some
expectations around like how you could actually consume various file formats like CSS and jason
and basically things that weren't JavaScript. But today the web actually has a lot
of capabilities to consume those file formats natively. And that's kind of really the
theme behind Greenwood Project Evergreen is the web has come a long way. You
might be able to just use the web for a lot of the tooling and
development that you might have had to rely on a tool in the past,
because it's kind of the way the web works the ecosystem. The community kind
of pushes it forward and then hopefully the great, best and greatest makes it
back in the platform. I think jQuery probably being the most classic example of
taking all those good lessons and being like, oh, yeah, we could
just put this into the web and to be Web components play a really useful
role in that because although they might be a little more low level in terms
of, like say, some of the authoring capabilities other libraries and frameworks give
you, they're also really good for templating because ultimately, at the end of
the day, they're just HTML tags. They operate again, it's just regular
HTML. And so a lot of what Greenwood's also been pushing is how to
get that on the client and server. If I have one component that I
want to just render out as HTML and the server, can I do that?
Yes? If I need a little inneractivity, could I still use that
same definition on the client the answer is also yes. And so kind of
just built kind of around that concept and applied it to many web standards and
techniques. But can you be a bit more specific? I mean, so,
project evergreen, what is it? Is it something like front and framework?
Is it something like a full stack framework? Is it something like a
web server? What is it? At the end of the day. Primarily
so, project Evergreen is the basic kind of like the GitHub organization around a
collective of projects. The main one that you would use in a day to
day capacity is Greenwood, And that's kind of a hybrid between something like a
VAT, which is primarily focused on like the local development experience, but also
pairs that with some with like developments or like application scaffolding and conventions that you
might get from like a NEXT or NEXT or spell kit, like API routes
and file based routing and stuff like that. The web is it going to
account for everything, and so you know you're still going to want some sort
of local development environment and some conventions to build your application. So yeah,
Greenwood is basically trying to leverage web standards front to back, so you as
an author could hopefully just rely on like MDN more and I don't have to
write as many docs to explain how these things work here. You just say
we use say import attributes. That's how you reference JavaScript, CSS, JSON.
So hopefully trying to reduce the surface area of the framework itself, which
is great from a maintenance perspective, by leaning on web standards that exist today
or coming very soon, and in that regard, hopefully trying to help educate
and make it more easy for new developers to onboard because those skills are going
to be very transferable. I'm learning web development. Oh great, here's you
know. It's basically the hopefully to kind of be the framework, or I
call it the workbench, because we don't have like a lot of like framework
code that you use from us. We just, like I said, it's
kind of like VAT for development, but with a blend of kind of some
of the next isms that you might get to build the application, but it
ultimately boils down to Web standards as much as possible, for like the APIs
or how you would right say, an API end point like just request and
response like native response objects. So if I'm understanding correctly, in a sort
of a funny way, it's kind of like a meta framework but without the
framework. So yeah, you get the things that you commonly get from meta
frameworks on top of frameworks, like file based routing, like API end points,
like deployments and provisioning and bundling and stuff like that, only instead of
like next gs being on top of React and knuts being on top of view
in your case, you're on top of nothing. I guess the closest analogy
would be web components in terms of you know, next on top of React.
So where you know, at least for a component model would be on
top of webpodes, but you don't have to. You could just build a
regular HTML file if you want. That was actually kind of one of the
biggest motivations a couple of years ago we started, was just if I want
to, can I literally just start with an index dot HTML and go from
there. If I don't need server side render, if I don't need API
endpoints, could I still just prototype with HTML? Could I just practice web
standards? So, and that's kind of what we call I'd like to refer
to it more as like a workbench because there is an AD. I've tried
to avoid having as much ceremony as you might have with some of the other
meta frameworks, mostly by trying to eliminate the spoke APIs because hopefully nine out
of ten times I could just link to an MDN DOT to kind of supplement
that development workflow. But yeah, you're you're pretty much spout on now.
In terms of the web components, I know that often web components are used
in the context of something like like lit or something like that. Is that
also in your case or you just do the web components, you know,
straight on Vanilla JavaScript and the web APIs both by defaults. Greenwood supports all
in the browser, you know, it doesn't really have to do anything,
but if you want to server render those web components, we do have a
library called WCC that's baked into Greenwood. So Vanilla web composed like your standard
you know, extends HTML element will work without any sort of additional setup.
But it is very It is easy to add LIT and use that instead.
And one of the things I try to use, one of the approaches I
took to try and emphasize that workbench is if you want to use LIT,
MPM install LIT. It's in your package, Jason, You're good to go.
We have a plug in if you want to server render LIT, and
now you can use lint like it looks like in the docs in Greenwood.
So and this could extend to other tools like HTMX and tailwind and all that
stuff. So we hope that we provide a means for you to layer on
what you want without getting in the way. Like a lot of other frameworks,
meta frameworks you might have install their plugins their rap around something like LIT.
We just want you to be able to install LIT and use it like
you would read from the LIT docs and if you're using their server rendering technology,
we're going to honor that too. So we don't want to invent more
things than we have to or get in the way of you being able to
Like we could just link to TAIL one and say here, just follow the
steps for you know, installing it as a post CSS plug in. So
now, one of the things that I think you also mentioned it, but
I also saw that in the documentation and examples on your website, is that
the routing is file based routing. So and kind of the similar model to
what most people or most depths now expect and from, you know, against
solutions like next gs and whatnot. This routing the router that you create,
Uh, it's a server side router, right, it's right, like or
put another way, it's the framework is what you know we refer today as
multipage applications or other web originally worked. You know, these days we call
it multipage applications. The while back we just called them web applications. Right,
But so, or put another way, it's not about client side routing.
It's it's it's whenever I go from page A to page B, I
go back to the server to get a new page. Yes, so we'll
yeah, file based routing expresses itself in Greenwood predominantly for like that MPa style
mapping a ur L to you know, a particular file, be it HTML
or JavaScript. If you're using server side rendering as an option, and Greenwood
does allow you to just build entirely a static site, so you can just
build and just get a bunch of HTML files and deploy them to a CDN.
You could actually run Greenwood as a server like you normally could just a
no JS server. You could deploy to any sort of like EC two or
fly or render. And additionally, we have at least right now for Netlify
in Versell, you can also build your application to run in a serverless environment,
and through that adapter plug in, we'll make sure that like that,
file based routing is configured the way that Netlify or verseell expect mostly around the
like the serverless endpoints, they have their own unique like URL pattern that would
break if we just expose you know, s API slash books right in a
Netlify example might be like function slash this, slash that slash that, and
so we can honor that file based routing through that configuration, so it's mostly
about predictability. We do have it's kind of experimental, but we do have
a client side router that you can opt into that kind of does a like
a live wire HTMX type thing where it'll load partials of your pages so you
can kind of sustain like the app shell and it'll just kind of swap out
the body tag as you navigate from page to page, so you can kind
of have that spa like experience even though you built an entirely static site.
And also you could just do a single page application to I have an example
of that that a music with lt might be better as a static app,
but I did just want to have examples of, you know, the various
ways you could do that, and that's all just similar routing. Like if
the single page application you just do source index dot html instead of source pages
and all that stuff. So it's really easy to move between those different conventions
even at the page level. So you could have a in your pages director,
you could have an about dot html that would be static, and you
could have say a products dot JS and that would be server rendered, and
so you just have them side by side and Greenwood will figure it out depending
on how you want to deploy it. Obviously, yeah, server rendered route.
You can't deploy on a CDN. But that's where the service adapters come
in. And since you mentioned HTMX, do you can I use Greenwood together
with HTMX. It works, It works great. I'm glad. I'm glad
you asked. Well, it kind of makes sense because you know your meta
framework without the framework. They are a framework without the framework. So it
seems that's it's it seems like a good match. It's it's perfect. And
this goes back to what we had wanted to really provide for a while,
which is that kind of seamless interrupt from front end to back. And so
I did just drop a link of a HTMX demo repo that I made and
it's kind of like an e mini e commercey type application, so you could
search for products, browse for products and and things like that. And what's
interesting is I hope it helps demonstrate that Greenwood can do. Is you just
install h mpm I HTMX, or you could just load it as a script
tag like we let you write script tags. You know, we let you
write style tags. Right, it's very HTML first from that perspective, we
don't really want to get in the way between you and your code. And
also make sure that the code you write is almost one to one with the
code you ship, maybe except for like modification or something like that. But
in this demo, what I thought was really nice is so each product renders
inside like a card component, title, image, button to click, and
that's a web component. It's just a vanilla custom element. And I can
in an API route, say for the search route, I can in that
API endpoint call out, get a bunch of products, load a web component
on the server, get all the HTML for the ten, fifteen, twenty
cards that gets returned as an HTML response. HTMX drops that in the page.
Great, now you've got your search results. But that card component is
also a script tag in the head of the page right below HTMX, And
as soon as that HTML loads onto the page, the browser immediately upgrades that
app card component. And now you can click the button and it will say
like you selected product XYZ. So you wrote one card component entirely like you
could have copy pasted it out of MDN. And it works both client and
server. So it's great for rendering HTML. You can also render JSON if
you want. But I think the real value is that one card component can
just be entirely HTML. But if you do need some interactivity through declarative shadow
dom detection, you can make that card component interactive on the client. You'd
have to do any sort of like none of the code that you wrote,
you know, like I said, you could have literally copy pasted it from
MDN. You know. That's that's all you have to know is you know
how to write a web component. It works now. So the one thing
that I can think of where a framework might need to have slightly more extensive
support for HDMX beyond being just well a web server is for the partial support.
So sometimes you you know, based on the request headers, you might
respond slightly differently to an HDMX a request or to a page request that has
HGMX in it. Is that something that Evergreen can handle? Mh. Yeah.
So the API endpoints are kind of you've worked with serverlist functions, the
classic kind of boiler plate. As you export like a handler function, it
takes in a request object as a parameter and you return a response object.
So within that request object you can totally use like URL search prems if you
want to do stuff with query parameters. You can use headers like the actual
headers native headers objects, so you can introspect on those and then do any
sort of logic you want. The API end points can return one line of
HTML, many lines of HTML. You can totally pack in as much as
you want so within HTMX. Depending on how granularly you want to define,
like your actions, your hypermedia actions, you can do it all at one
or have very many like mini API end points. So yeah, with Greenwood's
API end points, you control the entire response, so you don't have to
worry about like stripping away like head tags or anything like that. You know,
you just whatever you want to return, So just like a you know,
classic API end point. Now again listening to all the explanations and also
looking at the Evergreen documentation and examples, there's obviously a project that's kind of
similar, which is Astro. If I were to consider the differences between Evergreen
or an Astro, like what scenarios, you know, are you more appropriate
for what scenarios? Maybe an Astro is more appropriate for what would be the
bigger What would be the differences between these two projects? Yeah, so I
think one of the philosophies of that I tried to approach Greenwood with was that
it felt like it could be something that, like anybody with enough time could
eventually realize. I think the probably the starkest difference between something like Greenwood and
Astro is that we're not necessarily trying to support all libraries and frameworks. So,
you know, one of the selling points of astro is typically that you
can bring your own library or framework. You know, that's that's a lot
of work to make that all possible. And on top of that, you
know you have to kind of keep up with the roadmaps of each of those
projects. Okay, React introduced rscs, are you going to support that?
Views can introduce vapor, are you going to support that? And I think
maybe another question is, you know, in exploring Astro, how does it
compare to something like next, which is tailor designed for for React? And
so I think one reason to consider Greenwood is if you know, just web
standards and web components are the thing that you know aligns with you or makes
sense to you, and you know you want to be able to write just
HTML and there isn't a lot of you know, a lot of work happening
underneath the hood. Hopefully it just surfaces the developer experience, you know,
in a lot more familiar way. I think Astro is really cool, but
thinking of it from the perspective of a solo maintainer, it does seem like
it would be a lot of work to keep that project going. So,
you know, we just kind of want to be We kind of want to
find our niche, which is just web standards, web components, to kind
of be the next of that, so to speak. Now, so in
a sense you're closer to the metal and more directly built on the underlying web
standards, if That's what I'm hearing. So it's less about how do I
integrate this framework and that framework. I mean, sure, if you want
to use a framework, you can always put in a script tag. But
at the end of the day, if I'm thinking about the silly scenarios where
I'd be using Evergreen, where Evergreen mostly shines is if I want to be
closer to the metal, you know, use it either just straight on vanilla
JavaScript, maybe with LIT, maybe with HGMX, but not a lot more
than that in most cases. Yeah, And I think the other thing is
that you know, as I've noticed, it's some of like the Astro demos.
You know, if you want to use LIT or you want to use
some of the libraries, there is often like another package to install first.
And you know, I again, I think the webs come far enough,
the toolings come far enough that, you know, philosophically, yeah, like
you said, if you want to use LIT, you can just install LIT.
I don't want to kind of put any like wrappers or packages or abstractions
in front of that. So yeah, it might be kind of interesting to
think, like, well, if it's just the web, what do I
need this for? But you know, one really great example that our focus
allows us to go really deep on is web compatibility across the server, right,
so investing in just making sure that you can template out some web components
on the server, or be able to import CSS or yeah CSS or Jason
or even HTML in a way that we anticipate the standards will go in Like
CSS and JSON modules are already standardized. HTML's up and coming specification. So
I'd say part of it is really just a way for us to figure out
like what's worth focusing on. Going back to my intro, where I say,
how fortunate I am to see all the innovation in the web space.
I take that as influence. It doesn't mean I want to write them all.
And you know, I think there's a lot of value in that sort
of innovation. But I guess the philosophy behind Greenwood is, Okay, what
if we take all that inspiration, look at what the web offers and provide
and bring that into the experience or more specifically, bring that to like the
W three C participate in the web component's community group. So there's a whole
other topic where we can maybe dive into where the web post community group iterates
on these community protocols. So for things like say like a context like API
that you might see and react, could there be a community protocol that all
web components libraries could rally around. So yeah, basically just trying to specialize
on kind of one area of web development instead of trying to tackle all the
possibilities. Oh, don't get me wrong, I really like the concept.
I mean I really like the concept that if I want to just do more
or less vanilla JavaScript with web components that I have, but I'm wary about
all the effort of having to deal with routing and stuff like that and bundling
and configuring the deployment, like what's the solution? And it's really great that
Evergreen provides this this route that I can use that you know, I don't
I can do vanilla JavaScript and I can get all the benefits and I don't
know amenities of that I would usually get me to get from a meta framework,
but without having to bring along all the baggage specifically the framework. Yeah,
exactly. I was actually going to ask something along these lines, because
Yeah, it seems like to a certain extent, it's either embracing the standards
or maybe avoiding, as Dan put it, some of the baggage from some
of the frameworks that are out there. But when it comes right down to
it, I mean, what is the real benefit of that, other than
that you embraced the standards or you know, you didn't have to go and
embrace some of the baggage on something like react or view or Angular. Is
it performance? Is it simplicity? Understand? Is it? Askkelex Russell.
He will tell you. I would say, there's a there's a couple,
uh, a couple of ways I think uh that I you know, view
that. So I think one aspect is like from a developer or users hopefully
like predictability. Uh in terms of again the hopefully keeping the learning curve low,
but when you do want to accelerate your learning curve, it's just an
on ramp to more web standards. And uh, you know, I'm a
big advocate for teaching and learning. You know, I've mentored a lot in
my career, so the fundamentals have always been, you know, something I've
advocated for like sure, you know I'm not saying don't use React, don't
use Next and stuff like just like with anything in our industry, you know,
there's the right tool for the job. And in some cases, you
know, uh, something like a Next or like a React could make a
lot more sense. Or also if you're just your business has been heavily invested
in it, you know it's not saygo rewrite all that stuff. So hopefully
from at least the just like the again, the like the predictability of kind
of knowing what's at your fingertips and trying to create a an on ramp that
says close to web stands as possible. Has the flip side of from like
a maintenance perspective that's specification helps us answer a lot of decisions around Okay,
we want to make an API endpoint, what's the design should be, Well,
we've got requests and response like it should obviously be that. What's the
way to link and embed Jason and CSS and HTML. Well, there's specs
and standards for that. So hopefully from the other side of it, like
the maintainer side of it, it helps us and not have to come up
with new APIs that you have to learn. Just make the ones that exist
fit into what you might come to expect from a standard development workflow. Okay,
yeah, I in all projects I've been able to import CSS. Okay,
you can do that, just add with type equals CSS and bang,
now you've got a JS file that is not owned entirely by one better framework.
Right. So, so yeah, the predictability, the learning aspect,
and you know, I'll just say for myself, like the maintenance aspect of
it. As amazing as things like next an Astro and whatnot are, they
also come with a lot of work on the development and maintenance side, And
so hopefully something like Greenwood can be very sustainable even with a small maintainer team,
but still benefit a lot of people to the degree that it can before
maybe it hits the tipping point of your particular application that says okay, yeah,
maybe I need a reactor or something like that. So I think it's
mostly Ultimately, I think it just comes down to providing that option, right,
you know, I think there's plenty of room for everybody, and so
at the very least, if we can just help highlight how far the web
has come and then present it in a way that looks very familiar to how
the tools have helped us get this far, I'd be very happy with that.
But also I love getting close to the standards, and I think one
of my favorite things having started working on this project is heavy participation with the
Web Opponent's Community Group, but also the Winter CG bringing web standards and web
components to serverless and edge runtime. So we benefit a lot from the collaboration
that happens in something like Winter CG, where they're as committed to bring web
standards to JavaScript runtimes, which is you know, makes me very happy to
hear, because when something like that happens, not only can your JavaScript file
move from framework to framework, but also from runtime to runtime and you only
just had to write the one kind of the one way. Yeah, I
definitely agree that this interoperability between jobscript run times like would be it bun or
Dino or node obviously, but also cloud flare workers and versell workers and whatnot.
You know, that's a really big plus. And and if because you're
so simple and basically just use the underlying APIs, have a much easier time
of it. I know, for example, we we we had Kevin from
from Dino on as a guest and he talked about the challenges of getting next
JS to properly work on top of Dino. So having Evergreen is something really
simple and straightforward that just runs is obviously a big, a big benefit in
a in an upside Also, I really like the approach of being really close
to the web standards. And I think, you know, the fact that
it's called Evergreen kind of reflects this because it's evergreen knowledge. I mean,
you know, frameworks like we have we we look at react as something that's
been around forever and will be around forever. I don't know if that's the
case. What I do know is that the web will be around forever.
Uh And and what whenever you're building on top of the underlying web APIs you
know, they'll they will be they will be supported now, they will be
supported on forever and on every device, and and and you know, it
just works, so obviously that's that's a big benefit. And and I jokingly
mentioned Alex Russell before, but he constantly talks about how we are over engineering
the solutions that we're coming up with for the existing problems. And you know,
if you can basically just get a working solution from the underlying web platform
itself, then you know, it's a big win also for the user because
it's usually a much more streamlined and lighter weight type of a solution exactly.
Yeah, And as I mentioned, you know, learning and mentoring have been
a big part of my career in the various positions I've held, and I've
really fallen in love with the web all over again because having been in consultancies
and enterprise the web, you don't find the web the web There a lot,
not to disparage anything that I have used, but it gave me.
It did give me opportunities to work with Angler for a year a few years,
then work with React for a few years. And you know, I
think I'm not tribalistic in the sense of only use X, Y or Z.
I think the various options are great, and so I just wanted to
provide you know, a happy path for like web components and web standards as
you know, you know, you if going through Greenwood's docks and whatnot like
that, you'll probably see a lot of inspiration from things like spell Kate,
from things like next and so it's just like, well, yeah, the
web can have those two, but we'll just substitute a React component model with
a Web component model instead of webpath to bundle all your assets. Will just
use the Web standard API and just make that work under the hood and let
you run it on the server as well as the browser. Right, So
yeah, hopefully it Yeah, it could just be part of the choice that's
out there. And yeah, I mean there wasn't a lot of this back
when I started, and I think it's just nice to see that all the
innovation in developer experience and like application like design and development that you know,
really this something, this project is really made possible by the fact that people
keep going back to web standards and asking for things like, hey, okay,
we can import JavaScript, why not CSS? Why not? Jason A
couple of years later, you can now have a standard based way to import
CSS and Jason right, And there's kind of a lot of what Webpack gave
us that we didn't realize it was and we kind of took it for granted
and now it's just there for the taking. And that's the dex big feature
of trying to get in, which I think is going to be really really
great. And yeah, and it'll work no JS browser for sell all that,
all those places that you'd want it to so and I didn't have to
come up with anything. Yeah, it sounds great. Sounds a little bit
like there's a little bit of a story here to how you came to this,
and I like a story, So why don't you tell us the story?
Like where where were you and how did you get to the point where
you were? Not just hey, this is a good idea to go to
web standards. But I'm doing this right, this is a thing that can
happen. Yeah, there's a there is a story about I guess at this
point maybe three years or so ago now, there was a conversation and conversation
happening over on the MDN docs where they wanted to I forget the specific nature,
but they wanted to change like the framework or the server rendering of the
MDN docs itself. So they had a discussion and people were participating and a
lot of people suggested use web components. And one of the first things I
said is we can't serve a render web components. It was like, there
it is, there it is. And it just started with that. It
actually started with just running it through like the very first iterations of Greenwood,
we were just running it through Puppeteer and you know, getting the HTML out
that way. Then as our sites grew to server rendering and server lists,
like, well, puppeteer is really not gonna scale that well, I realized
there wasn't like a li HTML SSR version of just regular HTML element And so
about two years about it. Yeah, two years ago I created WCC,
which is just the lower level tool of like the very familiar like render two
string kind of API that you get from a React SSR. At the homages
are sprinkled everywhere, but in that sense you can say, here's a path
to a web component, give me the HTML. And then that became the
default foundation for Greenwood. And did a talk about running web server rendering web
components in I did a netlefy and AWS and that just kind of really really
made it click for me, like what the projects like potential could be.
And that's what I really started getting heavy into the Web Composed Community Group and
started contributing to our annual report to the W three C about kind of what
are the latest and greatest needs from the community with web components, like what
are some of the gaps that we could fill up? And then led to
Winter CG because of the SSR and Serverleist story and trying to be very active
in all three and just try to absorb and learn as much as I can
to make sure that you know, Greenwood is able to provide that kind of
web continuity no matter what platform you're writing for, and be in tune to
what could be better in that experience and bring that back to those channels.
Talk to implementers, you know, I can use this for prototypes, like
hey, here's a potential way to do HTML modules A or B or C.
Because that's how a lot of the web standards advancements work. They really
rely on the community to help identify and prototype and kind of demonstrate the value
of if we had this thing, this is what we could get out of
it. Like the next big one that I'm exploring is actual like templating in
the browser. So if you've ever used like mustache or handlebars with the little
double curlies, like there proposals for that, so you might be able to
get like that card component. You might just be able to do double curlyes
like image url and then you could stamp out as many of those templates with
like the you know, the attributes that you're passing into your component just there
for free in the browser. And again a lot of that is based on
what other projects have done, So it's like, that's a good idea,
could that be in the webspec you want me to prototype it. Here's a
couple examples someone else has that, And then now you've got a conversation going
and you got a couple browser vendors in the in the room and just kind
of goes from there. Nice. One other question I have is are there
other people who are using this like to build I want to professional production application
somewhere not At the moment, I've just pretty much been working on it on
the side and actually just trying to build up the kind of like a better
vision for the project. One thing that I'm working on right now is the
a new website with a new homepage and some just because it's been a couple
of years since we wrote that and we've grown so much that I want to
make sure that it accurately reflects what the project's about, what the team is
about. And I guess partially just maybe being a little bit shy because there
is so much great work from so many influential engineers that you know, maybe
there's a little sprinkle of imposter syndrome. But over the past year or so,
being able to whip up an HTMX demo just like that, and being
able to get like lit an SSR working has kind of shown that, Okay,
the base foundation is sound, I can at least start delivering on this
promise of bringing your own if you want, and it'll still work. And
so that's kind of really the plan for the rest of this year is to
kind of finalize those kind of standards and conventions about the project and at least
kind of nailed down with that first one dot ZHO kind of specification would look
like, and kind of start rolling it out and seeing what people people think.
So hoping to get there, but it was just kind of cautious because
things move so fast and I didn't kind of want to overextend myself just being
in my own bubble. So and also just I've got a couple more projects
I want to build, so each one I use as a way to test
out something like say, dynamic routing. You know, it's like there's there's
some table steaks that are fairly common. I just want to make sure we've
got at least a good answer, if not an implementation. So just yeah,
just kind of touch and go, but definitely open for anybody to try
it. We've got Slack and discords and get ub discussion, so it's definitely
there to use. There's definitely examples, but it is pre wide at the
moment. One more thing or two more things that I noticed is the significant
emphasis at least in the documents on markdown. And the other thing is the
use of Yamel as a kind of a server side scripting language in a sense.
The fact that you can put yamal blocks that if I understood correctly,
at the top of files to set all sorts of values for inside the files.
Or am I or did I misunderstand? H No, we do at
the moment, we do have first party support for markdown, so you could
do like an index dot HTML. You could do an index dot MD or
it reminds me of yeah and yeah. The little YAML blocks that you see
at the top of markdown files are what they're referred to as front matter.
So there are ways to like in one of the examples, if I want
to load a script only on this very specific blog post, I have a
way to say, hey, just for this blog post out of the hundreds
that this page template might be generating, I do want to throw in this
like counter demo or a specific title, So just add as a little more
customizability to the markdown. But yeah, we yeah, you can do a
markdown file as well. So the core I guess formats out of the box
for pages are HTML, markdown in JavaScript working on a PR now, because
we do have a plug in for type scripts, but it doesn't at support
like pages as typescript, so that'll be coming. So if you use the
typescript plug in, you'll be able to do pages slash index dotts as well,
or anything you can write a plugin for. That's one of our philosophies
too, is we do have plugins, and those are basically ways to help
differentiate kind of what is standard or this is what isn't standard. Right,
So one maybe questionable decision we made as we made typescript a plug in instead
of being in the core, just like we made importing CSS and JSON a
plug in instead the core. But now that import attributes exist, this is
one of the visions's plugins hand become the core because they become web standards.
And in the next release I'll be able to deprecate two plugins entirely because the
thing now is just a web standard. So maybe when types of comments become
a standard, you will need a Typescript plug in anymore. So we're still
around. Then I'll keep that one. It seems like you shouldn't hold your
breath for that one. Yeah, probably not. But in the meantime you've
got TSEC as a plug in, so you can still take advantage of that.
Cool. Now, in terms of data access, any particular story there
or is it basically just NPMI. Yeah, for all your dependencies, you
should be able to use whatever package manager you prefer. For local development,
we use import maps, so we don't do any bundling development. We basically
just look at the dependencies in your package, Jason and basically just walk all
their like Maine and entry point files and use that to build up an important
map that is then insert into the HTML of whatever page you're developing on.
And it's nice for like debugging because if you get an error, it's like
literally right to the file that you want to go to and for And yeah,
we don't have to like do any processing of your node modules other than
just read the package Jasons, and we cash that result in memory while you're
developing, so we don't have to keep hitting node modules every time you reload
the page. For production, we will do run it through roll up just
to do a little bundling. But I would like to get a feature in
where you could basically deploy unbundled if you want to, So depending on because
the ability to do that, you know, is something that you probably want
to benchmarket profile. If you've just got a few script tags, yeah,
just throw it out as is as you have in your like source directory.
You know you've got maybe lots of pages, lots of components. Bundling might
be a useful optimization. So, like I said, we bundle for production
by default, and unbundled local development, but we would like to give you
the option to go unbundled for production at some point. That's really interesting,
but it's not what I asked. No, but it's good that you explained
that, because that's really useful information. But I was specifically asking about if
you have any preferences or guidelines or what not about accessing the data layer,
like the database or something like that. Oh sure, yeah, yeah,
sorry. So with our server rendered pages or the API routes, you're basically
in a server environment. So like one of my projects for a little YouTube
music streaming show I do myself, we use a We use content full for
like all the event posts, and in that project, I statically build the
homepage that has like the upcoming events in it, and so in that's like
index dot JS file. I could just call content Ful using their s DK
and grab those events and you know, build that all out as HTML.
So yeah, you're entirely capable of hitting a database, hitting a CMS,
hitting the file system. So if you want to build up a bunch of
static content that way, or you know, or if you want to do
it at request time, that's totally possible. And we do want to add
the feature like you get next JS where you have like the like say the
bracket id dot JS that does like the dynamic path routing. So that's a
feature we'll be adding to our SSR pages as well. So uh kind of
yeah, So in tools like next JS, it'll say you have a template
for your blog posts. Right, so you've got and you've got like one
hundred blog posts, but you only want one JS file and you basically just
pass in like the title, the headache, hero image and stuff like that.
The way that next supports that is in your pages directory instead of say
like blog dot j s, you would put uh, square brackets j So,
because we have a plug in that allows you to fetch external content and
kind of feed that into Greenwood, but that next paradigms a lot more I
believe ergonomic because instead of having a plug in with all your content fetching over
here, you can just literally have it in the page where you know you're
also defining the template. So we want to kind of refine refine that.
But yeah, I've got some projects that use content fual. I've got another
project that just calling regular sequel to a planet scale database, and I mean
you could conceivably use Greenwood as just a back end of APIs if you wanted
to cool. All right, I'm gonna push just toward picks. We've been
talking for almost an hour, which is always fun, and this has been
really interesting. I guess to just wrap it up. Two questions. One
is if somebody wants to start using Evergreen or Greenwood, is there kind of
a getting started guide somewhere that people can pick up. Yeah. Sure,
if you go to Greenwood js dot io, we've got a getting started a
button right there on the homepage. We have compatibility with stacklets, so from
that page you can just jump right into it on stackplets and run it.
You can clone the companion repo that we have, or you know if you
want to jump right in the code or follow along with the guide. So
we've got a few different options to get you up and running just to play
with it. Cool. And then the other question is if people want to
connect with you on the internet, where do they find you? Yeah?
Sure, so I am on Twitter, slash x at the greenhouse io all
one word, and my website is also the greenhouse dot io. So mostly
you'll see more activity on the Greenwood JS website, but I do occasionally post
and on Twitter. I'm usually just shouting out about things I'm working on for
Greenwood, little demos. So if you want to see what the next release
of Greenwood's gonna have, yeah, my Twitter will probably be showing all those
little code snippets sporadically. Awesome. All right, well, let's go ahead
and do our picks, Dan, you want to start us out. Sure,
I don't have that much in way of picks today. I would want
to shout out one thing, so, as I guess people obviously know,
there's a war going on here. It's not as high intensity as it was
before, but it's still ongoing. That's the war in Gaza between Israel and
Amas, the Hamas government of Gaza. Was it the government of Gaza?
But anyway, my pick is a debate that was organized and moderated by Lex
Friedman on his YouTube channel. On the one side, he had Benny Morris,
who's a well known Israeli historian who's done a ton of research on the
whole founding of Israel and the Zionist movement and UH and the Palestinians and whatnot
with him on his side of the debate. You might say call it the
Israeli side perspective, even though he's not Israeli. Was the YouTuber or streamer
Destiny. I don't know how familiar you are with him, Chuck. He
does a political commentary, so but again he's not Israeli. He's American and
he doesn't really have you know, he's not Jewish or anything. But I
yeah, I still did. I guess they kind of presented Israeli narrative,
although both of them are very much opposed as I am, to the current
Israeli government. On the other side of the discussion were Finkelstein and Rabani,
who presented the Palestinian narrative, and they talked about anything and everything from a
ninety forty eight Zionism, the founding of Israel all the way to the current
conflict. And there are different positions and take on the situation. It got
pretty heated it sometimes. One big caveat is that it's a really long thing.
They said, from looking I haven't watched all of it. It's almost
five hours long. It is divided into chapters, so you know, if
you're only interested in certain parts, or want to watch it in parts,
or you know, watch it until you've had enough of it, then you
definitely can. So I will share the link to that. I haven't watched
all the comments found. Yeah, I haven't watched all of it, but
you know, it's it's interesting. It didn't really you know, nothing that
I personally didn't know before, but still still very interesting for those of you
who want to really understand the opposing views that are underlining this conflict that's been
ongoing for well century more or less in a lot of ways. So that
would be my pick for today. Awesome. I'm gonna jump in with my
picks a couple of things. First of all, I always do a board
game pick, so a little light, lighter, fair, I guess than
the Israel Palestine debate, though, I think it's important for people to understand
the perspectives that are involved. So definitely go check that out, even if
you have to kind of consume it in pieces, because I've yeah, I've
heard, like like I told Dan, I've heard some of the names involved,
and you know, they seem to know in depth certain aspects of this,
and so you'll definitely come out of an understanding better what the debates are,
what the arguments are. So I'm going to pick a game called The
White Castle, and it is a game. So the games always have like
a theme, right, or a setting. Some of them it's pretty thin,
right, It's just you know, we gave you just enough to move
the pieces around and make it interesting for you to try and win. And
some of these are a little more involved. This one's a little bit more
involved. I am not in love with some of the design on it.
It was a little bit hard to follow some of the time, and it
was mostly because the artwork and things just so like they had icons. You
have three different kinds of what workers I guess I mean your dice are your
workers in this game. It's a fairly complicated game board game. Giatewaights it
at three point oh one, which is probably one of the more complicated games
I've ever picked. I've picked a couple that are in the forest, but
anyway, so just be aware this one's a little bit more involved. And
what you do is you roll the dice, you place the dice as workers.
You get the benefits, and some of the benefits are that you get
to place your farmer, your cortizan or your samurai. And you know,
as you place them again based on dice rolls. You get more points,
you get certain benefits things like that. So you can place the courtizan and
then you move the courtizan up through the house up to the top level,
and when you get to the top level, you get more points, you
get a benefit. And I'm really slimming this down because it would take me
forever to explain to you all how to play it. But it was really
kind of fun and I kind of wish I could play it again a couple
more times. I played it at salt Con a couple of weeks ago,
which is the bordering conference that I went to, And anyway, I really
liked it. But yeah, the icons, like the icon for the farmer
it looks kind of like a bridge, which doesn't make any sense. And
then the icon for the courtizan was I don't even remember what it was.
But the icons did not match up with what you would want them to tell
you right, so you always had to be looking it up and oh,
oh yeah, this means I get to place this right. And so as
you're getting ready to play your die, because you pull the dice off the
bridge and then place them when you're getting ready to do that kind of placement,
then you're constantly trying to figure out, Okay, what is that and
what is that? Oh yeah, that's this and anyway. So that's my
main complaint with it. But overall, like the gameplay and the flow was
pretty good and definitely some interesting and different mechanics to it. I mean,
I've played enough board games to where I don't see new mechanics all that often,
but this was an interesting blend of mechanics that you commonly see in some
of these work replacement and dice games, so I'm gonna pick that. I'm
also working on getting JavaScript Geniuses launched, so if you want a weekly call
where we get on and we talk about different things related to JavaScript, maybe
have an expert like Owen or like Kevin, who we have last week,
or you know, people like that come on. I'm kind of aiming for
every other week having an expert, and then the other every other week it'll
be a discussion of either questions that people pose beforehand, right so that I
can prep but other people can prep and say, Okay, here's the answer
to your question, or where we just sit down and talk right and we're
just like, hey, you know we're going to do a breakout room for
five minutes, and then we're all going to come back together and we're going
to talk about, you know, some stuff related to JavaScript and web development
and then go back out into breakout rooms or however we decide that it's going
to work in the best way. I kind of want to experiment with that
piece because I want people to get to know each other and kind of build
your network. I hate the terminology of building your network, but get to
know other people who you can collaborate with and have a relationship within the community.
So anyway, if you're looking for that, I should have the page
up here within the next few days as we record this, which is on
March eighteenth, so yeah, March twentieth. First, you know, keep
an eye out. Go to JavaScript Geniuses dot com and you can sign up,
and uh, I'm definitely interested in doing that. If you want to
talk to me about it first, you can do that too. Just email
me Chuck at Topendevs dot com and I'll get back to you on that.
The other one is is I keep having people ask me how to start a
podcast, So I'm gonna put a course up for that that'll be up at
podcast playbook dot com again, similar timeframe. I have to get some stuff
together, you know, before you can sign up, but we're we're definitely
gonna be doing that. It's gonna be a six week program since it's the
pilot. I've seen programs like this priced in the like two thousands. Since
it's my pilot program, and I'm gonna be you know, ironing out,
ironing out some of the wrinkles. I'm charging five hundred dollars ahead. So
if you want to join in to start your own podcast, then go to
podcast playbook dot com and you can sign up for five hundred bucks. And
that's that's what I got. Owen, what are your parts? Yeah,
I got two. One coming out of somewhat related to our conversation today is
I actually just finished Hypermedia Systems, the book that was co authored by Carson
Gross, the creator of HTMX, And yeah, it was a nice kind
of refresher on some of those early I guess motivations of things like rest at
least how it was initially conceived by Roy Fielding and kind of maybe how it's
morphed to be more synonymous with JSON APIs over time. So yeah, it
was really good. Lots of good practical examples of HTMX as well, but
I was a little more invested in the history lesson aspects of it. And
the cover is really really cool, so you can actually just get the cover
as a poster. It's that cool. And so yeah, give that a
shot if you're interested in HTMX or the history of HTML a little bit.
And yeah, my second pick is a music pick. So I've been really
loving the new album by The Smile, which is part of from the couple
members from Radio Ahead. The new album is called Wall of Eyes. Really
nice album, some really great production on that. So if you like Radio
Ahead or Tom York and you haven't heard of that album, by all means,
give it a try. Different producer than they normally work with, just
because of time and conflicts, but have no fear. It sounds great as
you would expect. And this is a follow up to their first album from
a couple of years ago, and it's really great to see their their progress
working as a as a trio. So yeah, those that's what I got
for the show. Awesome. I just posted our interview with Carson Gross from
Yeah of last year, So yeah, if you're if you're into HTMX,
you want to know a little bit more about it, Definitely check that one
out. I think we got him all twice. We did. The other
one was quite a long time ago. Mm hmm. We got two point
zero coming out soon, so maybe back. Yeah, that was that was
the main topic of our last conversation with the upcoming two point zero version of
HTMX. Yeah, we also had him in December of twenty twenty one,
and it was when he was switching HTMX over from inter Cooler. M I'll
post that all real quick too. Yeah. All right, well, I
think I think that's everything. This was a lot of fun, very interesting
stuff. We'll wrap up until next time, folks. Max out