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