Embracing Web Standards with Owen Buckley - JSJ 626
Delve into a thought-provoking discussion with Owen Buckley, a seasoned web developer with 20 years of experience. Owen introduces Greenwood, a project focused on leveraging web standards and simplifying web development. Throughout the episode, They explore Greenwood's evolution, capabilities, and unique approach to application scaffolding and local development. From the emphasis on HTML and web components to Greenwood's seamless integration with HTMX, they uncover the project's vision to provide an onramp close to web standards. Join them as they navigate through the world of web development and gain valuable insights from Owen's expertise and passion for web standards and components.
Special Guests:
Owen Buckley
Show Notes
Delve into a thought-provoking discussion with Owen Buckley, a seasoned web developer with 20 years of experience. Owen introduces Greenwood, a project focused on leveraging web standards and simplifying web development. Throughout the episode, They explore Greenwood's evolution, capabilities, and unique approach to application scaffolding and local development. From the emphasis on HTML and web components to Greenwood's seamless integration with HTMX, they uncover the project's vision to provide an onramp close to web standards. Join them as they navigate through the world of web development and gain valuable insights from Owen's expertise and passion for web standards and components.
Sponsors
Sponsors
Socials
Picks
- Charles - The White Castle
- Owen - Hypermedia Systems
Transcript
Charles Max Wood [00:00:06]:
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 say hi? And, we just barely started. So,
Dan Shappir [00:00:22]:
Hi. Glad that I was able to make it on time. Can you hear me okay?
Charles Max Wood [00:00:27]:
Yep. I'm Charles Max Wood from Top 10 Devs, and we have a special guest this week. It is Owen Buckley. Owen, do you wanna introduce yourself? Tell us how awesome you are.
Owen Buckley [00:00:36]:
Thanks, Chuck. Appreciate the, the invite, and, happy to be here. Yeah. My name is Owen Buckley. I've been a been a enthusiast web developer for a very long time since the days that broadband carried much excitement, through the world, and I've been professionally developing for about 20 years, primarily in web. Actually got my first job working on set top 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.
Owen Buckley [00:01:24]:
And, yeah, really excited to to talk about kinda where I kinda see web development, today.
Dan Shappir [00:01:33]:
So this is this episode is going to be about us old timers
Owen Buckley [00:01:38]:
with with a twist with a twist. There's, the webs for everyone.
Charles Max Wood [00:01:44]:
I I have to say the the set top box thing. I've always wanted to build apps for the the the TV type thing. 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, 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 it.
Charles Max Wood [00:02:13]:
I think it's popular again for a while. So, yeah. Do you wanna kinda 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?
Owen Buckley [00:02:26]:
Sure. Sure. So, yeah, my 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 all the good things I've seen in web developments and maybe pushing back on, I guess, maybe the idea that while there's a lot of tools and options out there, not every project necessarily needs a 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 few weeks ago called from webpack to web APIs and 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 JSON and basic things that weren't JavaScript. But today, the web actually has a lot of capabilities to consume those file formats natively.
Owen Buckley [00:03:56]:
And that's kinda really the theme behind Greenwood and 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 that's kind of the way the web works. The ecosystem, the community kinda pushes it forward, and then hopefully the the great best and greatest makes it back to 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 the web. And to me, 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 against just regular HTML. And so a lot of what Greenwood's also been pushing is how to get that on the client and server.
Owen Buckley [00:05:07]:
If I have one component that I wanna just render out as HTML on the server, can I do that? Yes. If I need a little interactivity, could I still use that same definition on the client? The answer is also yes. And so kinda just built, kind of around that concept and applied it to many web standards and, techniques.
Dan Shappir [00:05:32]:
But can you be a bit more specific? I mean, so Project Evergreen, what is it? Is it something like a front end 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?
Owen Buckley [00:05:51]:
Sure. So project evergreen is the is kinda 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 VITs, 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 Nuxt or, SvelteKit, like, API routes and file based routing and stuff like that? You have the web. Is it going to account for everything? And so, you know, you're still gonna 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, you know, how these things were. How you just say, we use, say, import attributes. That's how you reference JavaScript, CSS, JSON.
Owen Buckley [00:07:13]:
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 their those skills are gonna be very transferable. I mean, learning web development? Oh, great. Here's you know, it's basically the hopefully, to kinda be the 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 kinda like Vite for development, but with a blend of kinda 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 write, say, an API endpoint, like just request and response, like, native request response objects.
Dan Shappir [00:08:22]:
So if I'm understanding correctly, in in a sort of a funny way, it's kind of like a meta framework, but without the framework. So Yeah. You you get the the things that you commonly get from meta frameworks on top of frameworks, like file based routing, like API endpoints, like, deployments and provisioning and bundling and stuff like that. Mhmm. Only instead of, like, Next JS being on top of React and Knox being on top of, Vue. In your case, you're on top of nothing.
Owen Buckley [00:09:00]:
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 web components, but you don't have to. You could just build a regular HTML file if you want. That was actually kinda one of the biggest motivations a couple 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, can I still just prototype with HTML? Can I just practice web standards? So and that's kinda why we call I like to refer to it more as, like, a a workbench, because there isn't as I've 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, like, bespoke APIs because, hopefully, 9 out of 10 times, I could just link to an MDN doc to kinda supplement that, development workflow. But, yeah, you're you're pretty much spot on.
Dan Shappir [00:10:12]:
Now in terms of, the web components, I know that, often web components are are used in the context of something like, like lit
Charles Max Wood [00:10:25]:
Mhmm.
Dan Shappir [00:10:25]:
Something like that. In is that also in your case, or you just do the web components, you know, straight on vanilla JavaScript and the web APIs?
Owen Buckley [00:10:37]:
Both. By default, Greenwood supports well, in the browser, you know, it doesn't really have to do anything. But if you want a server render those web components, we do have a library called WCC that's baked into Greenwood. So vanilla web components, 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 tried to you one of the approaches I took to try and emphasize that Workbench is if you wanna use lit, npm install lit, It's in your package JSON. You're good to go. We have a plug in if you wanna server render lit, and now you can use lit 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.
Owen Buckley [00:11:44]:
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 better frameworks might have installed their plugins, their wrappers 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 gonna honor that too. So we don't wanna invent more things than we have to or get in the way of you being able like, we could just link to Tailwind and say, here, just follow the steps for, you know, installing it as a post CSS plugin. So
Dan Shappir [00:12:28]:
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. Mhmm. So, and kind of the similar model to what most people or most devs now expect and and from, you know, again, solutions like Next. Js and whatnot. This routing, the router that you create, it's a server side router. Right? It run it'd be like or or put another way, it's the framework is what, you know, we refer today as multi page applications or
Charles Max Wood [00:13:10]:
Mhmm.
Dan Shappir [00:13:10]:
Other web originally worked.
Charles Max Wood [00:13:14]:
You
Dan Shappir [00:13:14]:
know, these days, we call it multipage applications. A while back, we just called them web applications. Right. But, so or 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 the new page.
Owen Buckley [00:13:37]:
Yes. So we'll, yeah, file based routing expresses itself in Greenwood predominantly for, like, that MPA style mapping a URL to, you know, a particular file via 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 could 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. That's just a Node JS server you can deploy to any sort of, like, e c 2 or fly or render. And, additionally, we have, at least right now, for Netlify and Vercel, 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 Vercel 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, /API/books.
Owen Buckley [00:15:04]:
Right? In a Netlify example, it might be like functions 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 a client side router that you can opt into, that kind of does a, like, a LiveWire HTMX type thing where, it'll load partials of your pages so you can kinda sustain, like, the app shell, and it'll just kinda swap out the body tag as you navigate from page to page. So you can kinda have that spa like experience even though you built entirely static site. And, also, you could just do a single page application too. I have an example of that that I'm using with Lit. Might be better as a static app, but I did just wanna have examples of, you know, the various, ways you could do that. And that's all just similar routing.
Owen Buckley [00:16:11]:
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 directory, 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 wanna deploy it. And, obviously, a server rendered route, you can't deploy on a CDN, but that's where the serverless adapters come in.
Dan Shappir [00:16:53]:
And since you mentioned the HTMX, do can I use, Greenwood together with HDMX?
Owen Buckley [00:17:00]:
It works. It works great. I'm glad, I'm glad you asked.
Dan Shappir [00:17:05]:
Well, it kinda makes sense because, you know, your, meta framework without the framework, there are framework without the framework. So it seems that, it's, it's, it seems like a good match.
Owen Buckley [00:17:16]:
It's it's perfect. And this goes back to what we have wanted to really provide for a while, which is that, kinda seamless interop from front end to back end. So I did just drop, a link of a HTMX demo repo that I made, and it's got a, like, a e mini ecommercey type application. So you could search for products, browse for products, and and things like that. And what's interesting is
Dan Shappir [00:17:48]:
or what
Owen Buckley [00:17:48]:
I hope it helps demonstrate that Greenwood can do is you just install h MPMI, HTML, 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 wanna get in the way between you and your code and also make sure that the code you write is almost one to 1 with the code you ship, maybe except for, like, minification 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 the search route, I can, in that API endpoints, call out, get a bunch of products, load a a web component on the server, get all the HTML for the 10, 15, 20 cards that gets returned as an HTML response.
Owen Buckley [00:19:04]:
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 h t m x. 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'll say, like, you selected, you know, product x, y, z. So you wrote 1 card component entirely. Like, you could have copy paste 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 the real value is that one card component can just be entirely HTML.
Owen Buckley [00:19:52]:
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've literally copy pasted it from MDN. You know? That's that's all you have to know is if you know how to write a web component, it works.
Dan Shappir [00:20:23]:
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 to an h t m x to an HDMX request or to a page request that has HDMX in it. Is that something that, Evergreen can handle?
Owen Buckley [00:20:53]:
Mhmm. Yeah. So the API endpoints, are kinda we've worked with serverless functions, the the classic kinda boilerplate as you export, you know, 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 params. If you wanna do stuff with query parameters, you can use, headers, like the actual headers, native headers object so you can introspect on those, and then do any sort of logic you want. The API endpoints can return one line of HTML, many lines of HTML. You can totally pack in as much as you want.
Owen Buckley [00:21:43]:
So within HTMLX, depending on how granularly you wanna define, like, your actions, your, hypermedia actions, you can do it all at 1 or have very mini, like, mini API endpoints. So, yeah, with, Greenwood's API endpoints, 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 wanna return. So, just like a, you know, classic, API endpoint.
Dan Shappir [00:22:24]:
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 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 Astro is more appropriate for? What would be the bigger what would be the differences between these two projects?
Owen Buckley [00:22:57]:
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 kinda keep up with the road maps of each of those projects. Okay. React introduced RSCs.
Owen Buckley [00:23:51]:
Are you gonna support that? Vue's gonna introduce vapor. Are you gonna 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 kinda wanna be we kinda wanna find our niche, which is just web standards, web components to kinda be the next of that, so to speak. Not So
Dan Shappir [00:25:10]:
in a 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 similar 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 HDMX, but not a lot more than that in most cases.
Owen Buckley [00:25:48]:
Yeah. And I think the other thing is that, you know, like, as I I've noticed in some of, like, the the Astro demos. You know, if you wanna use lit or you wanna use some of the libraries, there's often, like, another package to install first. And, you know, I again, I think the the web's come far enough. The the tooling's come far enough that, you know, philosophically yeah. Like you said, if if you want to, use lit, you can just install lit. I don't wanna kinda put any, like, wrappers or packages or abstractions in front of that. So, yeah, it might be kinda interesting to think, like, well, if it's just the web, what do I need this for? But, you know, one really great example with, that our focus allows us to go really deep on is web compatibility across the server.
Owen Buckley [00:26:46]:
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 c, yeah, CSS or JSON or even HTML in a way that we anticipate the standards will, go in. Like, CSS and JSON modules are already standardized. HTML's a 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. You know, 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 wanna write them all. And, you know, I think there's a lot of value in that sort of innovation.
Owen Buckley [00:27:44]:
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. I participate in the web components community group. So there's a whole another 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 in React, could there be a community protocol that all web components libraries could rally around? So, yeah, basically, just trying to specialize on kinda one area of web development instead of trying to tackle all the possibilities.
Dan Shappir [00:28:38]:
No. Don't get me wrong. I really like the concept. I mean, I 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 I it's really great that Evergreen provides this 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 of, of that I would usually get me get from a meta framework, but without having to bring along all the baggage, specifically the framework.
Owen Buckley [00:29:34]:
Mhmm. Yeah, exactly.
Charles Max Wood [00:29:38]:
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 what is the real benefit of that other than that you embrace the standards or, you know, you didn't have to go and and embrace some of the baggage on something like React or Vue or Angular? Is it performance? Is it simplicity? Ask Alex Russell. Understand? Is it
Dan Shappir [00:30:11]:
Ask Alex Russell. He will tell you. That's true.
Owen Buckley [00:30:16]:
I would say there's a there's a couple, couple ways, I think, that I, you know, view that. So I think one aspect is, like, from a developer or user is, hopefully, like, predictability, 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, 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.
Owen Buckley [00:31:11]:
Like, just like with anything in our industry, you know, there's the right tool for the job. And in some cases, you know, 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 to say go rewrite all that stuff. So, hopefully, from at least the just like the, again, the, like, the predictability of kinda knowing what's at your fingertips and trying to create a, an onramp that's as, close to web standards as possible has the flip side of from, like, a maintenance perspective, that specification helps us answer a lot of decisions around, okay. We wanna make an API endpoints. What's the design should be? Well, we've got request and response. Like, it should obviously be that. What's the way to link and embed JSON and CSS and HTML? Well, there's specs and standards for that.
Owen Buckley [00:32:23]:
So, hopefully, from the other side of it, like the maintainer side of it, it helps us 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.
Owen Buckley [00:32:51]:
Now you've got a j JS file that is not owned entirely by one better framework. Right? So, so, yeah, the the predictability, the the learning aspect, and, you know, I'll just say it for myself, like, the the maintenance aspect of it as amazing as things like Next and 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 Mhmm. To the degree that it can before maybe it hits the tipping point of your particular application that says, like, okay. Yeah. Maybe I need a a reactor or something like that. So I think it's mostly ultimately, I think it just comes down to providing that option.
Owen Buckley [00:33:48]:
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 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 components 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.
Dan Shappir [00:35:01]:
Yeah. I I definitely agree that, this, interoperability between, JavaScript run times, like, would be it BUN or Deno or Node, obviously, but also Cloudflare workers and Vercel workers and whatnot. You know, that that's a really big plus. And and if you because you are so simple and 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 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 of being really close to the web standards.
Dan Shappir [00:36:11]:
And I think, you know, the fact that it's called, evergreen kind of reflects this because it's evergreen knowledge.
Charles Max Wood [00:36:19]:
Mhmm.
Dan Shappir [00:36:20]:
I mean, you know, frameworks. Like, we have we 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. 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'll be supported on 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 he constantly talks about how we are overengineering, the, the solutions that we're coming up with for the existing problems.
Dan Shappir [00:37:13]:
And 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.
Owen Buckley [00:37:31]:
Exactly. Yeah. And but as I've 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. It's not to disparage anything that I have used, but it gave me it did give me opportunities to work with Angular for a year few years, then work with React for a few years. And, you know, I I think, I'm not tribalistic in 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, the you if, going through Greenwood's docs and whatnot like that, you'll probably see a lot of inspiration from things like SvelteKit from things like Next.
Owen Buckley [00:38:47]:
And so it's just like, well, you know, the web can have those too, but we'll just substitute a React component model with a web component model. Instead of Webpack to bundle all your assets, we'll 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 the browser. Right? So, yeah, hopefully, it, yeah, could just be part of the 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's 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 JSON? Couple years later, you can now have a standards based way to import CSS and JSON. Right? And there's kind of a lot of what Webpack gave us that we didn't realize it was, and we kinda took it for granted.
Owen Buckley [00:40:10]:
And now it's just there for the the taking, and, that's the next big feature I'm trying to get in, which I think is gonna be really, really great. And, yeah, and it'll work, Node. Js browser, Vercel, all that all those places that you'd want it to. So And I didn't have to come up with anything. Yeah.
Charles Max Wood [00:40:34]:
Yeah. It sounds it 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're 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.
Owen Buckley [00:40:54]:
Yeah. There is a there is a story, about, maybe, I guess at this point, maybe 3 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 the, like, the framework or the server rendering of the MDN docs itself. So they had a discussion, and people are participating. And a lot of people suggested use web components. And one of the first things they said is we can't serve or render web components. I was like, there it is. There it is. And it just started with that.
Owen Buckley [00:41:43]:
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 serverless, we're like, well, puppeteer is really not gonna scale that well. I realized there wasn't like, a a lit HTML SSR version of just regular HTML element. And so about 2 years about, yeah, 2 years ago, I created WCC, which is just the lower level tool of the like, the very familiar, like, render to string kind of API that you'd get from a React SSR if the the homages are sprinkled everywhere. But in that sense, you could say, here's a path to a web component. Give me the HTML. And then that became the the default foundation for Greenwood and did a talk about running web server rendering web components in, I did, Netlify and AWS, and that just kinda really, really made it click for me, like, what the project's, like, potential could be.
Owen Buckley [00:43:03]:
And that's when I really started getting heavy into the web post community group and started contributing to our annual report to the w three c about kinda what are the the the latest and greatest needs from the community with web components. Like, what are some of the the gaps that we could fill up and then led to winter CG because of the SSR and serverless 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 kinda 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 the web standards advancements work. They really rely on the community to help identify and prototype and kinda 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, little double curlies.
Charles Max Wood [00:44:36]:
Yep.
Owen Buckley [00:44:36]:
Like, there are proposals for that. So, you might be able to get, like, that card component. You might just be able to do double curlies, 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. Mhmm. 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 web spec? You want me to prototype it? Here's a couple examples.
Owen Buckley [00:45:13]:
Someone else has that. And then now you got a conversation going and you got a couple browser vendors in the, in the room and just kinda goes from there.
Charles Max Wood [00:45:25]:
Nice. One other question I have is, are there other people who are using this, like, to build for for I want a not professional production application somewhere?
Owen Buckley [00:45:37]:
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, the a a better vision for the project. One thing that I'm working on right now is the, a new website with a new home page and some, just because it's been a couple of years since we wrote that, and we've grown so much that, I wanna make sure that it accurately, you know, 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 HTML demo just like that and being able to get, like, lit and SSR working has kind of shown that, okay, the the base foundation is sound. I can at least start delivering on this promise of bring your own if you want and it'll still work. And so that's kinda really the the plan for the rest of this year is to kinda finalize those kinda standards and conventions about the project and at least kinda nail down what that first one dot o kind of specification would look like and kinda start rolling it out and seeing what, people people think. So, hoping to get there, but was just kinda cautious because things move so fast, and I didn't kinda wanna, overextend myself just being in my own bubble.
Owen Buckley [00:47:27]:
So, and also just I've got a couple more projects I wanna 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 stakes that are fairly common. I just wanna make sure we've got at least a good answer if not an implementation. So just, yeah, just kinda touch and go, but, definitely open for anybody to try it. We've got Slack and Discords and GitHub discussions. So it's it's definitely there to use. There's definitely examples, but it is pre one dot o at the moment.
Dan Shappir [00:48:07]:
One more thing or two more things that I noticed, is the the significant emphasis, at least in the documents, on markdown. And the other thing is the use of YAML as a kind of a server side scripting language in a sense. The fact that you can put YAML blocks at, if I understood correctly, at the top of files to to set all sorts of, values for inside the files, or am I or am I or did I misunderstand?
Owen Buckley [00:48:41]:
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 Jack Wolf. Yeah. And, and, yeah, the the little YAML blocks that you see at the top of markdown files are, what, what they refer to as front matter. So
Charles Max Wood [00:49:08]:
Uh-huh.
Owen Buckley [00:49:09]:
There are ways to like, in one of the examples, if I wanna 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 100 that this page template might be generating, I do want to throw in this, like, counter demo or a specific title. So it just adds adds a little more customizability to the markdown, but, yeah, we, Yeah. You can do a markdown file as well. So the the the core, I guess, formats out of the box for pages are HTML markdown in JavaScript. I'm working on a PR now, because we do have a plug in for TypeScript, but it, doesn't yet 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 dot ts as well or anything you can write a plug in for. That's one of our philosophies too is we do have plug ins, and those are basically ways to help differentiate kinda what is standard versus what isn't standard.
Owen Buckley [00:50:29]:
Right? So one maybe, questionable decision we made is we made TypeScript a plug in instead of being in the core, just like we made importing CSS and JSON a plug in instead of the core. But now that import attributes exist, this is one of the Visions' plugins could become the core because they become web standards. And in the next release, I'll be able to deprecate 2 plugins entirely because the thing now is just a web standard. So, maybe when, types' comments become a standard, we won't need a type script plugin anymore. So if we're still around then, I'll keep that one in backlog.
Dan Shappir [00:51:14]:
It seems like you shouldn't hold your breath for that one.
Owen Buckley [00:51:18]:
Yeah. Probably not.
Charles Max Wood [00:51:19]:
Yeah.
Owen Buckley [00:51:19]:
But in the meantime, you've got TSC as a plug in, so you can still, take advantage of that.
Dan Shappir [00:51:26]:
Cool. Now in terms of, of data access, any particular story there, or is it basically just NPMI?
Owen Buckley [00:51:36]:
Yeah. And 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 or development. We basically just look at the dependencies in your package JSON and basically just walk all their, like, main and entry point files and use that to build up a, an import map that is then inserted 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 wanna 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 JSON. So we cache that result in memory while you're developing so we don't have to keep hitting node modules every time you reload the page.
Owen Buckley [00:52:39]:
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 wanna benchmark a 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, if 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 unbundle local development, but we would like to give you the option to go unbundled for production, at some point.
Dan Shappir [00:53:28]:
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, about if you have any preferences or or guidelines or whatnot about accessing the data layer, like the database or something like that.
Owen Buckley [00:53:47]:
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 little YouTube, music streaming show I do myself, we use a, we use Contentful for, like, all the event posts. And, in that project, I statically build the home page that has, like, the upcoming events in it. And so in that, like, index dot JS file, I could just call using their SDK and grab those events and, you know, build that all out as HTML.
Owen Buckley [00:54:35]:
So, yeah, you're, entirely capable of hitting a database, hitting a CMS, hitting the file system. So if you wanna, like, build up a bunch of static content that way or, you know, or if you wanna do it at request time, that's, totally possible. And, we do wanna 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, to kinda flesh out. Yeah. So in tools like, Next. Js, it'll say you have a template for your blog post.
Owen Buckley [00:55:21]:
Right? So you've got, and you've got, like, 100 blog posts, but you only want 1 JS file, and you basically just pass in, like, the title, the head hero image, and stuff like that. The way that next supports that is, in your pages directory, instead of, say, like, blog dot JS, you would put, square brackets.
Dan Shappir [00:55:46]:
Oh, yeah. Yeah. Yeah.
Owen Buckley [00:55:47]:
Yeah. Yeah. Yeah. Yeah. Of course. Because we have a plug in that allows you to fetch external content and kinda feed that into Greenwood, but that next paradigm's a lot more, I believe, ergonomic because instead of having a plug in via your content fetching over here, You could just literally have it in the page, where, you know, you're also defining the the template. So, we wanna kinda refine refine that. But, yeah, I've I've got some projects that use Contentful.
Owen Buckley [00:56:19]:
I've got another project that just calling regular, SQL 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.
Charles Max Wood [00:56:39]:
Alright. I'm gonna push this 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, 2 questions. 1 is if somebody wants to start using, Evergreen or Greenwood, is there kind of a getting started guide somewhere that people can pick up?
Owen Buckley [00:57:00]:
Yeah, sure. If you go to greenwoodjsdot io, we've got a getting started, button right there on the home page. We have compatibility with stack. So from that page,
Charles Max Wood [00:57:14]:
you
Owen Buckley [00:57:14]:
can just jump right into it on stack and run it. You can clone, the companion repo that we have, or, you know, if you wanna jump right in the code or follow along with the the guide. So we got a few different options to get you up and running just to play with it. Cool.
Charles Max Wood [00:57:34]:
And then the other question is if people wanna connect with you on the Internet, where where do they find
Owen Buckley [00:57:39]:
you? Yeah. Sure. So I am on twitter/xat the greenhouse I o, 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 wanna see what the next release of Greenwood's gonna have, yeah, my Twitter will probably be showing all those little code snippets sporadically.
Charles Max Wood [00:58:16]:
Awesome. Alright. Well, let's go ahead and do our picks. Dan, you wanna start us out?
Dan Shappir [00:58:22]:
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 a war going on here. It's not as high intensity as it was before, but it's still ongoing. That's the the war in Gaza, between Israel and Hamas, 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, and the Palestinians and whatnot.
Dan Shappir [00:59:21]:
With him on on his side of the debate, you might say call it the, Israeli side perspective, even though he's not Israeli, was the the YouTuber or streamer Destiny. I don't know how familiar you are with him, Chuck. He does, 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 I yeah. He it's I'd still did. I guess they kind of presented the Israeli narrative, although both of them are very much opposed as I am to the current Israeli government.
Dan Shappir [01:00:03]:
On the other side of the of the discussion were, Finkelstein and, Rabani who presented the Palestinian narrative, and they talked about anything and everything from, 1948, Zionism, the founding of Israel, all the way to the current conflict and their different positions and take on the situation. It got pretty heated at 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 5 hours long. It is divided into chapters. So, you know, if you're only interested in certain parts or wanna watch it in parts or, you know, watch it until you have you've had enough of it, then you you definitely can.
Dan Shappir [01:00:51]:
So I will share the link to that. I haven't watched
Charles Max Wood [01:00:55]:
all the comments. I found Yeah.
Dan Shappir [01:00:57]:
I I 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.
Charles Max Wood [01:01:25]:
Awesome. I'm gonna jump in with my picks. A couple of things. First of all, I always do a board game pick. So little light lighter fare, 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 kinda consume it in pieces. Because I I've yeah.
Charles Max Wood [01:01:50]:
I've heard like like I told Dan, I've heard some of the names involved and, you know, they they seem to know in-depth certain aspects of this. And so you'll you'll definitely come out of it understanding better what the debates are, what the arguments are. So I'm gonna 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 to free you to try and win. And some of these are a little more involved. This one's a little bit more involved.
Charles Max Wood [01:02:27]:
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 3, different kinds of, what, workers, I guess. I mean, your dice are your workers in this game. It's a fairly complicated game. BoardGameGeek weights it at 3.01, which is probably one of the more complicated games I've ever picked. I've picked a couple that are in the fours, but, anyway, so just be aware that 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.
Charles Max Wood [01:03:05]:
And some of the benefits are that you get to place your farmer, your courtesan, 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 courtesan and then you move the courtesan up through the house up to the, the, the top level. And when you get to the top level, you get more points, you get a benefit. And then I'm really slimming this down because it would take me forever to explain to you all how to play it. But it was, it was really kind of fun and I kind of wish I could could play it again. A couple more times. I played it at salt con a couple of weeks ago, which is the board game conference that I went to.
Charles Max Wood [01:03:44]:
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 courtesan was, I don't even remember what it was, but the, 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 you pull the dice off the bridge and then place them, when you're getting ready to do that kind of placement, then, 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 was pretty good and, definitely some interesting and different mechanics to it.
Charles Max Wood [01:04:33]:
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 worker placement 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 had 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 and other people can prep and say, okay, here's the answer to your question or where we just sit down and talk.
Charles Max Wood [01:05:18]:
Right? And we're just like, Hey, you know, we're going to do a breakout room for 5 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'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 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 18th. So, yeah, March 20th, 21st,
Dan Shappir [01:06:01]:
you
Charles Max Wood [01:06:01]:
know, keep an eye out. Go to, javascriptgeniuses.com and you can sign up. And, I'm definitely interested in doing that. If you wanna talk to me about it first, you can do that too. Just email me chuck@topendevs.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 podcastplaybook.com.
Charles Max Wood [01:06:22]:
Again, similar time frame. I have to get some stuff together, you know, before you could sign up, but we're we're definitely gonna be doing that. It's gonna be a 6 week program since it's the pilot. I've seen programs like this priced in the, like, 2 1,000. But since it's my pilot program and I'm gonna be, you know, ironing out ironing out some of the wrinkles, I'm charging $500 ahead. So if you want to join in to start your own podcast, then go to podcastplaybook.com and you could sign up for $500. And that's that's what I got. Owen, what are
Owen Buckley [01:06:53]:
your thoughts? Yeah. I got 2. One coming out of, somewhat related to our conversation today is I actually just finished Hypermedia Systems, the book that, was coauthored 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 the history lesson aspects of it. And the cover is really, really cool. So, you can actually just get the cover as a poster.
Owen Buckley [01:07:51]:
Is that cool? And so, yeah, give that a a shot if you're interested in HTML or the history of HTML a little bit. And, yeah, the 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 Radiohead. The new album is called Wall of Eyes. Really nice album. Some really great production on that. So if you like Radiohead or Thom Yorke, and you haven't heard of that album, by all means, give it a a try. Different producer than they normally work with just because of timing conflicts, but, have no fear.
Owen Buckley [01:08:37]:
It sounds great as you would expect. And, this is a follow-up to their first album from a couple 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 for the show.
Charles Max Wood [01:08:56]:
Awesome. I just posted our interview with Carson Gross from
Owen Buckley [01:08:59]:
October
Charles Max Wood [01:09:00]:
of last year. So yeah, if you're, if you're into, HTMLX, you want to know a little bit more about it, definitely check that one out.
Dan Shappir [01:09:07]:
I think we got them all twice.
Charles Max Wood [01:09:10]:
We did. The other one was quite a long time ago. Mhmm.
Owen Buckley [01:09:14]:
We got 2.0 coming out soon, so maybe
Dan Shappir [01:09:17]:
come back. Yeah. That was that was the main topic of our last conversation with the the upcoming 2.0 version of HTML.
Charles Max Wood [01:09:26]:
Yep. We also had him in December of 2021, and it it was when he was switching HTMX over from intercooler. Mhmm. I'll I'll post that link here real quick too.
Owen Buckley [01:09:38]:
Yeah.
Charles Max Wood [01:09:38]:
Alright. 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.
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 say hi? And, we just barely started. So,
Dan Shappir [00:00:22]:
Hi. Glad that I was able to make it on time. Can you hear me okay?
Charles Max Wood [00:00:27]:
Yep. I'm Charles Max Wood from Top 10 Devs, and we have a special guest this week. It is Owen Buckley. Owen, do you wanna introduce yourself? Tell us how awesome you are.
Owen Buckley [00:00:36]:
Thanks, Chuck. Appreciate the, the invite, and, happy to be here. Yeah. My name is Owen Buckley. I've been a been a enthusiast web developer for a very long time since the days that broadband carried much excitement, through the world, and I've been professionally developing for about 20 years, primarily in web. Actually got my first job working on set top 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.
Owen Buckley [00:01:24]:
And, yeah, really excited to to talk about kinda where I kinda see web development, today.
Dan Shappir [00:01:33]:
So this is this episode is going to be about us old timers
Owen Buckley [00:01:38]:
with with a twist with a twist. There's, the webs for everyone.
Charles Max Wood [00:01:44]:
I I have to say the the set top box thing. I've always wanted to build apps for the the the TV type thing. 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, 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 it.
Charles Max Wood [00:02:13]:
I think it's popular again for a while. So, yeah. Do you wanna kinda 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?
Owen Buckley [00:02:26]:
Sure. Sure. So, yeah, my 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 all the good things I've seen in web developments and maybe pushing back on, I guess, maybe the idea that while there's a lot of tools and options out there, not every project necessarily needs a 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 few weeks ago called from webpack to web APIs and 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 JSON and basic things that weren't JavaScript. But today, the web actually has a lot of capabilities to consume those file formats natively.
Owen Buckley [00:03:56]:
And that's kinda really the theme behind Greenwood and 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 that's kind of the way the web works. The ecosystem, the community kinda pushes it forward, and then hopefully the the great best and greatest makes it back to 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 the web. And to me, 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 against just regular HTML. And so a lot of what Greenwood's also been pushing is how to get that on the client and server.
Owen Buckley [00:05:07]:
If I have one component that I wanna just render out as HTML on the server, can I do that? Yes. If I need a little interactivity, could I still use that same definition on the client? The answer is also yes. And so kinda just built, kind of around that concept and applied it to many web standards and, techniques.
Dan Shappir [00:05:32]:
But can you be a bit more specific? I mean, so Project Evergreen, what is it? Is it something like a front end 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?
Owen Buckley [00:05:51]:
Sure. So project evergreen is the is kinda 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 VITs, 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 Nuxt or, SvelteKit, like, API routes and file based routing and stuff like that? You have the web. Is it going to account for everything? And so, you know, you're still gonna 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, you know, how these things were. How you just say, we use, say, import attributes. That's how you reference JavaScript, CSS, JSON.
Owen Buckley [00:07:13]:
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 their those skills are gonna be very transferable. I mean, learning web development? Oh, great. Here's you know, it's basically the hopefully, to kinda be the 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 kinda like Vite for development, but with a blend of kinda 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 write, say, an API endpoint, like just request and response, like, native request response objects.
Dan Shappir [00:08:22]:
So if I'm understanding correctly, in in a sort of a funny way, it's kind of like a meta framework, but without the framework. So Yeah. You you get the the things that you commonly get from meta frameworks on top of frameworks, like file based routing, like API endpoints, like, deployments and provisioning and bundling and stuff like that. Mhmm. Only instead of, like, Next JS being on top of React and Knox being on top of, Vue. In your case, you're on top of nothing.
Owen Buckley [00:09:00]:
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 web components, but you don't have to. You could just build a regular HTML file if you want. That was actually kinda one of the biggest motivations a couple 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, can I still just prototype with HTML? Can I just practice web standards? So and that's kinda why we call I like to refer to it more as, like, a a workbench, because there isn't as I've 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, like, bespoke APIs because, hopefully, 9 out of 10 times, I could just link to an MDN doc to kinda supplement that, development workflow. But, yeah, you're you're pretty much spot on.
Dan Shappir [00:10:12]:
Now in terms of, the web components, I know that, often web components are are used in the context of something like, like lit
Charles Max Wood [00:10:25]:
Mhmm.
Dan Shappir [00:10:25]:
Something like that. In is that also in your case, or you just do the web components, you know, straight on vanilla JavaScript and the web APIs?
Owen Buckley [00:10:37]:
Both. By default, Greenwood supports well, in the browser, you know, it doesn't really have to do anything. But if you want a server render those web components, we do have a library called WCC that's baked into Greenwood. So vanilla web components, 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 tried to you one of the approaches I took to try and emphasize that Workbench is if you wanna use lit, npm install lit, It's in your package JSON. You're good to go. We have a plug in if you wanna server render lit, and now you can use lit 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.
Owen Buckley [00:11:44]:
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 better frameworks might have installed their plugins, their wrappers 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 gonna honor that too. So we don't wanna invent more things than we have to or get in the way of you being able like, we could just link to Tailwind and say, here, just follow the steps for, you know, installing it as a post CSS plugin. So
Dan Shappir [00:12:28]:
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. Mhmm. So, and kind of the similar model to what most people or most devs now expect and and from, you know, again, solutions like Next. Js and whatnot. This routing, the router that you create, it's a server side router. Right? It run it'd be like or or put another way, it's the framework is what, you know, we refer today as multi page applications or
Charles Max Wood [00:13:10]:
Mhmm.
Dan Shappir [00:13:10]:
Other web originally worked.
Charles Max Wood [00:13:14]:
You
Dan Shappir [00:13:14]:
know, these days, we call it multipage applications. A while back, we just called them web applications. Right. But, so or 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 the new page.
Owen Buckley [00:13:37]:
Yes. So we'll, yeah, file based routing expresses itself in Greenwood predominantly for, like, that MPA style mapping a URL to, you know, a particular file via 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 could 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. That's just a Node JS server you can deploy to any sort of, like, e c 2 or fly or render. And, additionally, we have, at least right now, for Netlify and Vercel, 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 Vercel 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, /API/books.
Owen Buckley [00:15:04]:
Right? In a Netlify example, it might be like functions 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 a client side router that you can opt into, that kind of does a, like, a LiveWire HTMX type thing where, it'll load partials of your pages so you can kinda sustain, like, the app shell, and it'll just kinda swap out the body tag as you navigate from page to page. So you can kinda have that spa like experience even though you built entirely static site. And, also, you could just do a single page application too. I have an example of that that I'm using with Lit. Might be better as a static app, but I did just wanna have examples of, you know, the various, ways you could do that. And that's all just similar routing.
Owen Buckley [00:16:11]:
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 directory, 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 wanna deploy it. And, obviously, a server rendered route, you can't deploy on a CDN, but that's where the serverless adapters come in.
Dan Shappir [00:16:53]:
And since you mentioned the HTMX, do can I use, Greenwood together with HDMX?
Owen Buckley [00:17:00]:
It works. It works great. I'm glad, I'm glad you asked.
Dan Shappir [00:17:05]:
Well, it kinda makes sense because, you know, your, meta framework without the framework, there are framework without the framework. So it seems that, it's, it's, it seems like a good match.
Owen Buckley [00:17:16]:
It's it's perfect. And this goes back to what we have wanted to really provide for a while, which is that, kinda seamless interop from front end to back end. So I did just drop, a link of a HTMX demo repo that I made, and it's got a, like, a e mini ecommercey type application. So you could search for products, browse for products, and and things like that. And what's interesting is
Dan Shappir [00:17:48]:
or what
Owen Buckley [00:17:48]:
I hope it helps demonstrate that Greenwood can do is you just install h MPMI, HTML, 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 wanna get in the way between you and your code and also make sure that the code you write is almost one to 1 with the code you ship, maybe except for, like, minification 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 the search route, I can, in that API endpoints, call out, get a bunch of products, load a a web component on the server, get all the HTML for the 10, 15, 20 cards that gets returned as an HTML response.
Owen Buckley [00:19:04]:
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 h t m x. 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'll say, like, you selected, you know, product x, y, z. So you wrote 1 card component entirely. Like, you could have copy paste 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 the real value is that one card component can just be entirely HTML.
Owen Buckley [00:19:52]:
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've literally copy pasted it from MDN. You know? That's that's all you have to know is if you know how to write a web component, it works.
Dan Shappir [00:20:23]:
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 to an h t m x to an HDMX request or to a page request that has HDMX in it. Is that something that, Evergreen can handle?
Owen Buckley [00:20:53]:
Mhmm. Yeah. So the API endpoints, are kinda we've worked with serverless functions, the the classic kinda boilerplate as you export, you know, 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 params. If you wanna do stuff with query parameters, you can use, headers, like the actual headers, native headers object so you can introspect on those, and then do any sort of logic you want. The API endpoints can return one line of HTML, many lines of HTML. You can totally pack in as much as you want.
Owen Buckley [00:21:43]:
So within HTMLX, depending on how granularly you wanna define, like, your actions, your, hypermedia actions, you can do it all at 1 or have very mini, like, mini API endpoints. So, yeah, with, Greenwood's API endpoints, 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 wanna return. So, just like a, you know, classic, API endpoint.
Dan Shappir [00:22:24]:
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 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 Astro is more appropriate for? What would be the bigger what would be the differences between these two projects?
Owen Buckley [00:22:57]:
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 kinda keep up with the road maps of each of those projects. Okay. React introduced RSCs.
Owen Buckley [00:23:51]:
Are you gonna support that? Vue's gonna introduce vapor. Are you gonna 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 kinda wanna be we kinda wanna find our niche, which is just web standards, web components to kinda be the next of that, so to speak. Not So
Dan Shappir [00:25:10]:
in a 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 similar 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 HDMX, but not a lot more than that in most cases.
Owen Buckley [00:25:48]:
Yeah. And I think the other thing is that, you know, like, as I I've noticed in some of, like, the the Astro demos. You know, if you wanna use lit or you wanna use some of the libraries, there's often, like, another package to install first. And, you know, I again, I think the the web's come far enough. The the tooling's come far enough that, you know, philosophically yeah. Like you said, if if you want to, use lit, you can just install lit. I don't wanna kinda put any, like, wrappers or packages or abstractions in front of that. So, yeah, it might be kinda interesting to think, like, well, if it's just the web, what do I need this for? But, you know, one really great example with, that our focus allows us to go really deep on is web compatibility across the server.
Owen Buckley [00:26:46]:
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 c, yeah, CSS or JSON or even HTML in a way that we anticipate the standards will, go in. Like, CSS and JSON modules are already standardized. HTML's a 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. You know, 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 wanna write them all. And, you know, I think there's a lot of value in that sort of innovation.
Owen Buckley [00:27:44]:
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. I participate in the web components community group. So there's a whole another 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 in React, could there be a community protocol that all web components libraries could rally around? So, yeah, basically, just trying to specialize on kinda one area of web development instead of trying to tackle all the possibilities.
Dan Shappir [00:28:38]:
No. Don't get me wrong. I really like the concept. I mean, I 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 I it's really great that Evergreen provides this 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 of, of that I would usually get me get from a meta framework, but without having to bring along all the baggage, specifically the framework.
Owen Buckley [00:29:34]:
Mhmm. Yeah, exactly.
Charles Max Wood [00:29:38]:
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 what is the real benefit of that other than that you embrace the standards or, you know, you didn't have to go and and embrace some of the baggage on something like React or Vue or Angular? Is it performance? Is it simplicity? Ask Alex Russell. Understand? Is it
Dan Shappir [00:30:11]:
Ask Alex Russell. He will tell you. That's true.
Owen Buckley [00:30:16]:
I would say there's a there's a couple, couple ways, I think, that I, you know, view that. So I think one aspect is, like, from a developer or user is, hopefully, like, predictability, 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, 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.
Owen Buckley [00:31:11]:
Like, just like with anything in our industry, you know, there's the right tool for the job. And in some cases, you know, 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 to say go rewrite all that stuff. So, hopefully, from at least the just like the, again, the, like, the predictability of kinda knowing what's at your fingertips and trying to create a, an onramp that's as, close to web standards as possible has the flip side of from, like, a maintenance perspective, that specification helps us answer a lot of decisions around, okay. We wanna make an API endpoints. What's the design should be? Well, we've got request and response. Like, it should obviously be that. What's the way to link and embed JSON and CSS and HTML? Well, there's specs and standards for that.
Owen Buckley [00:32:23]:
So, hopefully, from the other side of it, like the maintainer side of it, it helps us 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.
Owen Buckley [00:32:51]:
Now you've got a j JS file that is not owned entirely by one better framework. Right? So, so, yeah, the the predictability, the the learning aspect, and, you know, I'll just say it for myself, like, the the maintenance aspect of it as amazing as things like Next and 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 Mhmm. To the degree that it can before maybe it hits the tipping point of your particular application that says, like, okay. Yeah. Maybe I need a a reactor or something like that. So I think it's mostly ultimately, I think it just comes down to providing that option.
Owen Buckley [00:33:48]:
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 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 components 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.
Dan Shappir [00:35:01]:
Yeah. I I definitely agree that, this, interoperability between, JavaScript run times, like, would be it BUN or Deno or Node, obviously, but also Cloudflare workers and Vercel workers and whatnot. You know, that that's a really big plus. And and if you because you are so simple and 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 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 of being really close to the web standards.
Dan Shappir [00:36:11]:
And I think, you know, the fact that it's called, evergreen kind of reflects this because it's evergreen knowledge.
Charles Max Wood [00:36:19]:
Mhmm.
Dan Shappir [00:36:20]:
I mean, you know, frameworks. Like, we have we 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. 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'll be supported on 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 he constantly talks about how we are overengineering, the, the solutions that we're coming up with for the existing problems.
Dan Shappir [00:37:13]:
And 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.
Owen Buckley [00:37:31]:
Exactly. Yeah. And but as I've 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. It's not to disparage anything that I have used, but it gave me it did give me opportunities to work with Angular for a year few years, then work with React for a few years. And, you know, I I think, I'm not tribalistic in 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, the you if, going through Greenwood's docs and whatnot like that, you'll probably see a lot of inspiration from things like SvelteKit from things like Next.
Owen Buckley [00:38:47]:
And so it's just like, well, you know, the web can have those too, but we'll just substitute a React component model with a web component model. Instead of Webpack to bundle all your assets, we'll 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 the browser. Right? So, yeah, hopefully, it, yeah, could just be part of the 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's 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 JSON? Couple years later, you can now have a standards based way to import CSS and JSON. Right? And there's kind of a lot of what Webpack gave us that we didn't realize it was, and we kinda took it for granted.
Owen Buckley [00:40:10]:
And now it's just there for the the taking, and, that's the next big feature I'm trying to get in, which I think is gonna be really, really great. And, yeah, and it'll work, Node. Js browser, Vercel, all that all those places that you'd want it to. So And I didn't have to come up with anything. Yeah.
Charles Max Wood [00:40:34]:
Yeah. It sounds it 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're 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.
Owen Buckley [00:40:54]:
Yeah. There is a there is a story, about, maybe, I guess at this point, maybe 3 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 the, like, the framework or the server rendering of the MDN docs itself. So they had a discussion, and people are participating. And a lot of people suggested use web components. And one of the first things they said is we can't serve or render web components. I was like, there it is. There it is. And it just started with that.
Owen Buckley [00:41:43]:
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 serverless, we're like, well, puppeteer is really not gonna scale that well. I realized there wasn't like, a a lit HTML SSR version of just regular HTML element. And so about 2 years about, yeah, 2 years ago, I created WCC, which is just the lower level tool of the like, the very familiar, like, render to string kind of API that you'd get from a React SSR if the the homages are sprinkled everywhere. But in that sense, you could say, here's a path to a web component. Give me the HTML. And then that became the the default foundation for Greenwood and did a talk about running web server rendering web components in, I did, Netlify and AWS, and that just kinda really, really made it click for me, like, what the project's, like, potential could be.
Owen Buckley [00:43:03]:
And that's when I really started getting heavy into the web post community group and started contributing to our annual report to the w three c about kinda what are the the the latest and greatest needs from the community with web components. Like, what are some of the the gaps that we could fill up and then led to winter CG because of the SSR and serverless 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 kinda 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 the web standards advancements work. They really rely on the community to help identify and prototype and kinda 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, little double curlies.
Charles Max Wood [00:44:36]:
Yep.
Owen Buckley [00:44:36]:
Like, there are proposals for that. So, you might be able to get, like, that card component. You might just be able to do double curlies, 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. Mhmm. 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 web spec? You want me to prototype it? Here's a couple examples.
Owen Buckley [00:45:13]:
Someone else has that. And then now you got a conversation going and you got a couple browser vendors in the, in the room and just kinda goes from there.
Charles Max Wood [00:45:25]:
Nice. One other question I have is, are there other people who are using this, like, to build for for I want a not professional production application somewhere?
Owen Buckley [00:45:37]:
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, the a a better vision for the project. One thing that I'm working on right now is the, a new website with a new home page and some, just because it's been a couple of years since we wrote that, and we've grown so much that, I wanna make sure that it accurately, you know, 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 HTML demo just like that and being able to get, like, lit and SSR working has kind of shown that, okay, the the base foundation is sound. I can at least start delivering on this promise of bring your own if you want and it'll still work. And so that's kinda really the the plan for the rest of this year is to kinda finalize those kinda standards and conventions about the project and at least kinda nail down what that first one dot o kind of specification would look like and kinda start rolling it out and seeing what, people people think. So, hoping to get there, but was just kinda cautious because things move so fast, and I didn't kinda wanna, overextend myself just being in my own bubble.
Owen Buckley [00:47:27]:
So, and also just I've got a couple more projects I wanna 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 stakes that are fairly common. I just wanna make sure we've got at least a good answer if not an implementation. So just, yeah, just kinda touch and go, but, definitely open for anybody to try it. We've got Slack and Discords and GitHub discussions. So it's it's definitely there to use. There's definitely examples, but it is pre one dot o at the moment.
Dan Shappir [00:48:07]:
One more thing or two more things that I noticed, is the the significant emphasis, at least in the documents, on markdown. And the other thing is the use of YAML as a kind of a server side scripting language in a sense. The fact that you can put YAML blocks at, if I understood correctly, at the top of files to to set all sorts of, values for inside the files, or am I or am I or did I misunderstand?
Owen Buckley [00:48:41]:
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 Jack Wolf. Yeah. And, and, yeah, the the little YAML blocks that you see at the top of markdown files are, what, what they refer to as front matter. So
Charles Max Wood [00:49:08]:
Uh-huh.
Owen Buckley [00:49:09]:
There are ways to like, in one of the examples, if I wanna 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 100 that this page template might be generating, I do want to throw in this, like, counter demo or a specific title. So it just adds adds a little more customizability to the markdown, but, yeah, we, Yeah. You can do a markdown file as well. So the the the core, I guess, formats out of the box for pages are HTML markdown in JavaScript. I'm working on a PR now, because we do have a plug in for TypeScript, but it, doesn't yet 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 dot ts as well or anything you can write a plug in for. That's one of our philosophies too is we do have plug ins, and those are basically ways to help differentiate kinda what is standard versus what isn't standard.
Owen Buckley [00:50:29]:
Right? So one maybe, questionable decision we made is we made TypeScript a plug in instead of being in the core, just like we made importing CSS and JSON a plug in instead of the core. But now that import attributes exist, this is one of the Visions' plugins could become the core because they become web standards. And in the next release, I'll be able to deprecate 2 plugins entirely because the thing now is just a web standard. So, maybe when, types' comments become a standard, we won't need a type script plugin anymore. So if we're still around then, I'll keep that one in backlog.
Dan Shappir [00:51:14]:
It seems like you shouldn't hold your breath for that one.
Owen Buckley [00:51:18]:
Yeah. Probably not.
Charles Max Wood [00:51:19]:
Yeah.
Owen Buckley [00:51:19]:
But in the meantime, you've got TSC as a plug in, so you can still, take advantage of that.
Dan Shappir [00:51:26]:
Cool. Now in terms of, of data access, any particular story there, or is it basically just NPMI?
Owen Buckley [00:51:36]:
Yeah. And 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 or development. We basically just look at the dependencies in your package JSON and basically just walk all their, like, main and entry point files and use that to build up a, an import map that is then inserted 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 wanna 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 JSON. So we cache that result in memory while you're developing so we don't have to keep hitting node modules every time you reload the page.
Owen Buckley [00:52:39]:
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 wanna benchmark a 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, if 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 unbundle local development, but we would like to give you the option to go unbundled for production, at some point.
Dan Shappir [00:53:28]:
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, about if you have any preferences or or guidelines or whatnot about accessing the data layer, like the database or something like that.
Owen Buckley [00:53:47]:
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 little YouTube, music streaming show I do myself, we use a, we use Contentful for, like, all the event posts. And, in that project, I statically build the home page that has, like, the upcoming events in it. And so in that, like, index dot JS file, I could just call using their SDK and grab those events and, you know, build that all out as HTML.
Owen Buckley [00:54:35]:
So, yeah, you're, entirely capable of hitting a database, hitting a CMS, hitting the file system. So if you wanna, like, build up a bunch of static content that way or, you know, or if you wanna do it at request time, that's, totally possible. And, we do wanna 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, to kinda flesh out. Yeah. So in tools like, Next. Js, it'll say you have a template for your blog post.
Owen Buckley [00:55:21]:
Right? So you've got, and you've got, like, 100 blog posts, but you only want 1 JS file, and you basically just pass in, like, the title, the head hero image, and stuff like that. The way that next supports that is, in your pages directory, instead of, say, like, blog dot JS, you would put, square brackets.
Dan Shappir [00:55:46]:
Oh, yeah. Yeah. Yeah.
Owen Buckley [00:55:47]:
Yeah. Yeah. Yeah. Yeah. Of course. Because we have a plug in that allows you to fetch external content and kinda feed that into Greenwood, but that next paradigm's a lot more, I believe, ergonomic because instead of having a plug in via your content fetching over here, You could just literally have it in the page, where, you know, you're also defining the the template. So, we wanna kinda refine refine that. But, yeah, I've I've got some projects that use Contentful.
Owen Buckley [00:56:19]:
I've got another project that just calling regular, SQL 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.
Charles Max Wood [00:56:39]:
Alright. I'm gonna push this 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, 2 questions. 1 is if somebody wants to start using, Evergreen or Greenwood, is there kind of a getting started guide somewhere that people can pick up?
Owen Buckley [00:57:00]:
Yeah, sure. If you go to greenwoodjsdot io, we've got a getting started, button right there on the home page. We have compatibility with stack. So from that page,
Charles Max Wood [00:57:14]:
you
Owen Buckley [00:57:14]:
can just jump right into it on stack and run it. You can clone, the companion repo that we have, or, you know, if you wanna jump right in the code or follow along with the the guide. So we got a few different options to get you up and running just to play with it. Cool.
Charles Max Wood [00:57:34]:
And then the other question is if people wanna connect with you on the Internet, where where do they find
Owen Buckley [00:57:39]:
you? Yeah. Sure. So I am on twitter/xat the greenhouse I o, 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 wanna see what the next release of Greenwood's gonna have, yeah, my Twitter will probably be showing all those little code snippets sporadically.
Charles Max Wood [00:58:16]:
Awesome. Alright. Well, let's go ahead and do our picks. Dan, you wanna start us out?
Dan Shappir [00:58:22]:
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 a war going on here. It's not as high intensity as it was before, but it's still ongoing. That's the the war in Gaza, between Israel and Hamas, 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, and the Palestinians and whatnot.
Dan Shappir [00:59:21]:
With him on on his side of the debate, you might say call it the, Israeli side perspective, even though he's not Israeli, was the the YouTuber or streamer Destiny. I don't know how familiar you are with him, Chuck. He does, 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 I yeah. He it's I'd still did. I guess they kind of presented the Israeli narrative, although both of them are very much opposed as I am to the current Israeli government.
Dan Shappir [01:00:03]:
On the other side of the of the discussion were, Finkelstein and, Rabani who presented the Palestinian narrative, and they talked about anything and everything from, 1948, Zionism, the founding of Israel, all the way to the current conflict and their different positions and take on the situation. It got pretty heated at 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 5 hours long. It is divided into chapters. So, you know, if you're only interested in certain parts or wanna watch it in parts or, you know, watch it until you have you've had enough of it, then you you definitely can.
Dan Shappir [01:00:51]:
So I will share the link to that. I haven't watched
Charles Max Wood [01:00:55]:
all the comments. I found Yeah.
Dan Shappir [01:00:57]:
I I 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.
Charles Max Wood [01:01:25]:
Awesome. I'm gonna jump in with my picks. A couple of things. First of all, I always do a board game pick. So little light lighter fare, 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 kinda consume it in pieces. Because I I've yeah.
Charles Max Wood [01:01:50]:
I've heard like like I told Dan, I've heard some of the names involved and, you know, they they seem to know in-depth certain aspects of this. And so you'll you'll definitely come out of it understanding better what the debates are, what the arguments are. So I'm gonna 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 to free you to try and win. And some of these are a little more involved. This one's a little bit more involved.
Charles Max Wood [01:02:27]:
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 3, different kinds of, what, workers, I guess. I mean, your dice are your workers in this game. It's a fairly complicated game. BoardGameGeek weights it at 3.01, which is probably one of the more complicated games I've ever picked. I've picked a couple that are in the fours, but, anyway, so just be aware that 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.
Charles Max Wood [01:03:05]:
And some of the benefits are that you get to place your farmer, your courtesan, 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 courtesan and then you move the courtesan up through the house up to the, the, the top level. And when you get to the top level, you get more points, you get a benefit. And then I'm really slimming this down because it would take me forever to explain to you all how to play it. But it was, it was really kind of fun and I kind of wish I could could play it again. A couple more times. I played it at salt con a couple of weeks ago, which is the board game conference that I went to.
Charles Max Wood [01:03:44]:
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 courtesan was, I don't even remember what it was, but the, 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 you pull the dice off the bridge and then place them, when you're getting ready to do that kind of placement, then, 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 was pretty good and, definitely some interesting and different mechanics to it.
Charles Max Wood [01:04:33]:
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 worker placement 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 had 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 and other people can prep and say, okay, here's the answer to your question or where we just sit down and talk.
Charles Max Wood [01:05:18]:
Right? And we're just like, Hey, you know, we're going to do a breakout room for 5 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'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 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 18th. So, yeah, March 20th, 21st,
Dan Shappir [01:06:01]:
you
Charles Max Wood [01:06:01]:
know, keep an eye out. Go to, javascriptgeniuses.com and you can sign up. And, I'm definitely interested in doing that. If you wanna talk to me about it first, you can do that too. Just email me chuck@topendevs.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 podcastplaybook.com.
Charles Max Wood [01:06:22]:
Again, similar time frame. I have to get some stuff together, you know, before you could sign up, but we're we're definitely gonna be doing that. It's gonna be a 6 week program since it's the pilot. I've seen programs like this priced in the, like, 2 1,000. But since it's my pilot program and I'm gonna be, you know, ironing out ironing out some of the wrinkles, I'm charging $500 ahead. So if you want to join in to start your own podcast, then go to podcastplaybook.com and you could sign up for $500. And that's that's what I got. Owen, what are
Owen Buckley [01:06:53]:
your thoughts? Yeah. I got 2. One coming out of, somewhat related to our conversation today is I actually just finished Hypermedia Systems, the book that, was coauthored 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 the history lesson aspects of it. And the cover is really, really cool. So, you can actually just get the cover as a poster.
Owen Buckley [01:07:51]:
Is that cool? And so, yeah, give that a a shot if you're interested in HTML or the history of HTML a little bit. And, yeah, the 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 Radiohead. The new album is called Wall of Eyes. Really nice album. Some really great production on that. So if you like Radiohead or Thom Yorke, and you haven't heard of that album, by all means, give it a a try. Different producer than they normally work with just because of timing conflicts, but, have no fear.
Owen Buckley [01:08:37]:
It sounds great as you would expect. And, this is a follow-up to their first album from a couple 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 for the show.
Charles Max Wood [01:08:56]:
Awesome. I just posted our interview with Carson Gross from
Owen Buckley [01:08:59]:
October
Charles Max Wood [01:09:00]:
of last year. So yeah, if you're, if you're into, HTMLX, you want to know a little bit more about it, definitely check that one out.
Dan Shappir [01:09:07]:
I think we got them all twice.
Charles Max Wood [01:09:10]:
We did. The other one was quite a long time ago. Mhmm.
Owen Buckley [01:09:14]:
We got 2.0 coming out soon, so maybe
Dan Shappir [01:09:17]:
come back. Yeah. That was that was the main topic of our last conversation with the the upcoming 2.0 version of HTML.
Charles Max Wood [01:09:26]:
Yep. We also had him in December of 2021, and it it was when he was switching HTMX over from intercooler. Mhmm. I'll I'll post that link here real quick too.
Owen Buckley [01:09:38]:
Yeah.
Charles Max Wood [01:09:38]:
Alright. 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.
Embracing Web Standards with Owen Buckley - JSJ 626
0:00
Playback Speed: