HTML Foundation, Progressive Enhancement (Enhance.dev)
Simon MacDonald from Begin introduces Enhance, an HTML-first web framework built on web standards, custom elements, and progressive enhancement.
Episode Description
Simon MacDonald from Begin introduces Enhance, an HTML-first web framework built on web standards, custom elements, and progressive enhancement.
Episode Summary
In this JavaScript Jam Live episode, Simon MacDonald, head of developer experience at Begin, walks through the company's layered technology stack—from AWS at the base, through the Architect infrastructure-as-code tool, up to the Enhance web framework. He explains that Begin simplifies AWS deployment by offering sensible defaults, while Architect condenses thousands of lines of CloudFormation into a concise configuration file. The conversation then shifts to Enhance's origin story: after watching customers repeatedly struggle with build failures and breaking changes from popular JavaScript frameworks, the Begin team distilled their own recurring patterns into a framework that prioritizes server-side rendering of custom elements, delivering fully functional HTML before any client-side JavaScript loads. Simon illustrates the cost of over-relying on JavaScript with a memorable anecdote about a 4.7-megabyte shopping cart that wouldn't let him buy pants, and he contrasts that with Enhance's philosophy of progressive enhancement and web standards stability. The discussion covers where Enhance fits best—dynamic, personalized applications rather than purely static sites—and how it compares to frameworks like Eleventy and Next.js. Simon also outlines Begin version 2's upcoming CLI-driven deployment, flexible CI/CD options, and forthcoming helpers for writing web components with less boilerplate, all aimed at making standards-based development accessible to beginners and experienced developers alike.
Chapters
00:00:00 - Welcome and Guest Introduction
Scott Steinlage opens the JavaScript Jam Live session, inviting listeners to participate and noting the show's weekly Wednesday schedule. He introduces the co-hosts and sets the tone for an open, interactive conversation where beginners and experienced developers alike are encouraged to raise their hands and join the stage.
Ishan Anand then formally introduces the guest, Simon MacDonald from Begin, previewing the discussion around the Enhance framework and its blend of modern JavaScript concepts with web standards like custom elements and progressive enhancement. Simon shares his background—over 25 years in tech, starting with CGI scripts and Perl in 1995—before explaining Begin's mission to simplify AWS by offering reasonable defaults that spare developers from navigating 140 confusing services.
00:06:10 - AWS Philosophy and the Architect Layer
Simon explains why AWS has so many seemingly overlapping services: the company avoids breaking changes by creating new services rather than modifying existing ones, giving developers long-term stability. This leads into a discussion of Architect, the open source infrastructure-as-code tool donated to the OpenJS Foundation, which compresses thousands of lines of CloudFormation into a concise configuration format.
The group discusses how Architect eliminates "click ops"—manually deploying through the AWS console—and enables reliable rollbacks through commit-based staging and tag-based production deployments. Anthony draws a comparison to the Serverless Framework, and Simon notes that Architect is more opinionated in its commitment to AWS, reflecting Begin's philosophy of providing clear, well-considered defaults rather than multi-cloud flexibility.
00:14:57 - The Origin Story of Enhance
Simon traces Enhance's origins to recurring customer pain points on Begin's platform: frequent build failures, framework breaking changes, and unplanned dependency updates that disrupted applications. The team recognized that the patterns they kept using internally—server-side rendering of custom elements that arrive as fully functional HTML—could be formalized into a framework.
He introduces the concept of functional web apps, an architectural pattern built on three pillars: cloud functions for all logic, modern on-demand databases with sub-10-millisecond latency, and infrastructure as code for immutable deployments. Simon explains that Enhance serves as the UI layer for functional web apps, handling server-side rendering and progressive enhancement while Architect and Begin cover the infrastructure and deployment pillars.
00:20:06 - Enhance's HTML-First Philosophy
Simon lays out the core philosophy behind Enhance: start with HTML and CSS to deliver a fully working page, then layer on JavaScript only where genuinely needed. He illustrates the problem with a story about trying to buy pants from a site running 4.7 megabytes of JavaScript—a React-based shopping cart with broken state management that failed entirely when JavaScript was disabled.
The conversation turns to web components and their limitation of requiring JavaScript to register custom elements, which Simon calls a specification mistake. He cites statistics suggesting one to two percent of page loads experience JavaScript failures, meaning thousands of users on high-traffic sites encounter broken experiences. Enhance addresses this by expanding custom elements on the server so they arrive as working HTML, with event listeners attached only after the page is already functional.
00:27:30 - Web Standards Stability and the Platform Getting Good
Ishan highlights how the Enhance documentation's counter example drove home the framework's commitment to progressive enhancement—a button that works entirely through server-side cookie management before any JavaScript is added. Simon argues that the web platform improved enormously over the past decade while developers were focused on client-side frameworks, and many features previously requiring heavy JavaScript bundles are now available natively in HTML and CSS.
The discussion evolves into a comparison of framework churn versus platform stability. Simon points out that a web page from 1995 still loads in modern browsers, while React has cycled through createElement, JSX, class components, functional components, and hooks in just a few years. The group agrees that web standards offer a long-term reliability that framework conventions struggle to match, and that the ecosystem is beginning to swing back toward server-side rendering informed by lessons learned during the client-side era.
00:33:00 - Comparing Enhance to Other Frameworks
At the midway point, Ishan asks how Enhance compares to post-React frameworks like Eleventy and Astro. Simon frames it as a right-tool-for-the-job question: Eleventy excels at static site generation, while Enhance shines for dynamic, personalized applications that benefit from on-demand server-side rendering against modern databases with minimal latency.
Simon shares a personal example—a hockey management app he built with Enhance that handles player tracking, spare notifications, and email automation with virtually zero client-side JavaScript. He notes that even the mobile hamburger menu uses a CSS checkbox trick rather than JavaScript, demonstrating how far native HTML and CSS capabilities have come for building interactive multi-page applications.
00:45:23 - Begin Version 2 and Deployment Options
Simon outlines what's coming with Begin version 2, including a new CLI for streamlined deployment and flexible CI/CD options via GitHub Actions or developers' preferred solutions. He explains that while Begin v1 was highly opinionated about CI/CD, customer feedback—especially from larger teams with existing infrastructure—drove the decision to make it configurable.
The conversation explores the relationship between Enhance and Begin as analogous to the Next.js and Vercel pairing, with Simon acknowledging that tighter framework-platform integration yields a better developer experience. He emphasizes that Enhance can be deployed independently via Architect to AWS or through other services, maintaining the escape-hatch philosophy that prevents vendor lock-in while still offering the best experience through the full Begin stack.
00:55:51 - Audience Q&A and Web Components in Practice
Nick joins the stage and shares his experience with Enhance, appreciating how understanding web fundamentals is sufficient to get started without learning framework-specific abstractions. Simon discusses authentication support, noting that the Begin CLI includes generators for OAuth and Magic Link auth flows that handle boilerplate setup.
The group explores the tension between Enhance's accessibility for experienced developers who find it refreshing and newer developers who may lack exposure to underlying web platform mechanics. Simon emphasizes that raw HTML is accessible by default and that native elements like input type date eliminate the need for complex JavaScript date pickers, reinforcing the framework's philosophy of leveraging the platform before reaching for scripts.
01:09:13 - Cross-Pollination, Community, and Closing
Simon describes Enhance's target audience as a pincer movement: beginners learning web standards for a durable career foundation and experienced developers frustrated by over-complicated tooling that prioritizes developer experience at the expense of user experience. He expresses enthusiasm for the cross-pollination happening across the framework ecosystem, where projects like Astro, Solid, Eleventy, and Enhance are learning from one another.
The session wraps with Simon sharing key resources—enhance.dev for documentation and blog.begin.com for an upcoming "12 Days of Enhance" blog series—and encouraging listeners to reach out with feedback or complaints. Scott thanks all participants, previews next week's guest from Uniform, and reminds listeners to subscribe to the JavaScript Jam newsletter at javascriptjam.com.
Transcript
00:00:01 - Scott Steinlage
Ishan, I sent you a co-host invite. There you go. Welcome, everyone. Simon, what's up, dude? You're in here. Let me bring you up here. Invite to speak. Here we go. All right, definitely lagging a little bit today. There we go. And now a speaker. All right, awesome, everybody, welcome. Thank you all so much for joining us today. This is JavaScript Jam Live. We do this every Wednesday at 12:00 PM Pacific Standard Time. However, I do want to throw this out there real quick: we will not be doing this on the 28th of December. That is a Wednesday, just in observance of the holidays. But prior to that, we will be having one next week on the 21st, so that's exciting stuff. Stay tuned for more information on that. But as for today, we have Simon with us, Simon MacDonald with Begin, and he's part of the Enhance.dev team over there. He's the dev advocate for that as well. So super exciting stuff. Really excited to have him here. And remember, guys, if you're a beginner or if you've been doing this for a very long time, it doesn't matter. We want to hear from everybody, right?
00:01:23 - Scott Steinlage
So if you're out there, you're listening in, please raise your hand or request to come up, and we'll be more than happy to bring you up. You can ask questions, state an opinion. We're going to try and flow a little more freely with this. Yes, we're going to have specific questions and conversations with Simon here about this, but we want you to feel like you have the ability to come up here and say something. So we will definitely allow that to happen, and we're going to have some fun with it. Thank you all so much. Let's have some fun. Let me introduce you to Ishan, our co-host, and Anthony just joined us here as well. There we go. Let me add him up here. Perfect. Let's get this rolling.
00:02:10 - Ishan Anand
Yeah. Thank you, Scott. Welcome to JavaScript Jam Live. We like to call it an open mic night for anything JavaScript- and web-development-related. Today we have our guest, Simon MacDonald from Begin. He's going to walk us through yet another new web framework, Enhance, which you've probably heard of coming out of CascadiaJS earlier this year. Enhance is really interesting because it blends inspiration from modern JavaScript frameworks, things like pure functional components, file-based routing, single-file components, with web standards, custom elements, and progressive enhancement. Really excited to talk to Simon today. Then also here with us is Anthony, who is here actually a little early, but starting next year he will be one of our permanent co-hosts on JavaScript Jam Live. We're really excited. Welcome, Simon.
00:03:19 - Simon MacDonald
Yeah. Thank you all for having me. I really appreciate you giving me the time to speak today.
00:03:24 - Ishan Anand
Yeah. Before we jump into Enhance, I'd like to just start with yourself. Tell us a little bit about your background and how you came to arrive at Begin and Enhance.
00:03:39 - Simon MacDonald
Sure. Well, I think the first thing I should start off with is I'm Canadian, so if you hear some really weird pronunciations of words, then just chalk it up to that and we'll all get along fine. I've been doing tech for over 25 years. That was scary when I realized that. I'm like, wow, I'm now that gray-beard guy that I used to look up to when I started in tech. So that was very scary. I got started doing a lot of telecommunication stuff here in Canada, but I've always messed around with the web since 1995, when we were doing dynamic web pages using CGI then, and Perl scripts and C binaries instead of all the fancy stuff that we have today. That's pretty much been my journey to where I am today.
00:04:28 - Ishan Anand
Cool. When did you land at Begin?
00:04:33 - Simon MacDonald
Oh yeah, very good point. Yeah. So I'm the head of developer experience at Begin. I started there last September, so September 2021. Begin is a small startup company. And what you guys were mentioning earlier is, any beginners that are listening to this, please come up with questions. We literally named the company Begin because we love beginners. We want people to get started building things for the web. But Begin is... I don't know, the elevator pitch for Begin is, imagine you log into the AWS console and then you are presented with 140 different choices of how to get started. There's all these different services and you're like, oh my God, which one do I actually use? I don't want to make the wrong decision. This could really sink my company if I do the wrong thing. And there's a lot of anxiety around that. So with Begin, we've put together a good set of reasonable defaults for you to get started with. So you can do Lambda functions, you can do DynamoDB, and you can set up your S3 buckets just using Begin. So as a beginner, you don't have to worry about all of these different things that you would have to learn normally with AWS. You just get started building your application.
00:05:41 - Simon MacDonald
So it takes a lot of the anxiety away from things and keeps you from shooting yourself in the foot with a bazooka, which you literally could do with AWS.
00:05:49 - Ishan Anand
Yeah, there's a lot of different tools in there. I don't know if you know the guy who does a lot of commentary on AWS cost optimization, but he often talks about how the naming conventions alone are going to confuse you.
00:06:06 - Anthony Campolo
Corey Quinn.
00:06:06 - Ishan Anand
Yeah.
00:06:07 - Simon MacDonald
Corey Quinn, yeah.
00:06:08 - Ishan Anand
Yeah, exactly.
00:06:10 - Simon MacDonald
Yeah.
00:06:11 - Simon MacDonald
So here's the other thing. It sounds like I was a little complaining about AWS a bit there, but the reason that there's 140 different services that you have to choose from, and it seems like there's not that much difference between service A and service B, is because AWS does not release breaking changes. So if you pick a service, you can be guaranteed going into the future that that service will continue to work without breaking your code. When they introduce breaking changes, they create a new service with a new name. And that's why there's so many services and so many weird names. So you only have to switch over to that breaking change if you really want to. You're not forced into this kind of unplanned work with AWS, and that's one of the reasons that we picked it up.
00:06:55 - Ishan Anand
That's a really good point. I mean, that's a lot different than some other of the FAANGs that will go unmentioned.
00:07:02 - Simon MacDonald
Oh no, I will totally mention them.
00:07:07 - Ishan Anand
Feel free to name names. We're not going to muzzle any host.
00:07:11 - Simon MacDonald
Yeah, I will try not to let my [unclear] show too much. But you know, it's okay.
00:07:18 - Anthony Campolo
You're not running Kubernetes, so you can say whatever you want about them.
00:07:23 - Simon MacDonald
Yeah.
00:07:24 - Scott Steinlage
Oh, man.
00:07:25 - Simon MacDonald
That's Kubernetes. Honestly, I'm still looking for a situation in which I need to use Kubernetes to solve a problem. I haven't run into that yet. I'm not the right person to talk about it.
00:07:38 - Ishan Anand
It's like that old joke. It's like, now if you add Kubernetes to solve a problem, now you have two problems.
00:07:47 - Simon MacDonald
I've got this problem. It could be fixed with a regex. Oh, now I've got two problems.
00:07:53 - Ishan Anand
So that's really helpful for setting the stage. Do you want to then help us understand the origin story for Enhance before we jump into the philosophy of it? Maybe, like, why did you guys create Enhance? And I know it's tied to... I don't know if you call it Begin 2.0, but you guys are changing Begin. You're going through a relaunch.
00:08:20 - Anthony Campolo
We can't forget about ARC too, because they have an infrastructure-as-code thing that underlies this as an important piece here as well.
00:08:27 - Ishan Anand
Architect, I think you're referring to, right? Yeah. So maybe help us understand all those pieces and how they relate.
00:08:36 - Simon MacDonald
Sure, no problem. Let's start with Architect. And the way that I look at this whole thing is it's like a layer cake. So you start with AWS, which is the base layer. That is the bare metal. That is where you have your Lambda, your DynamoDB. If you've ever had to deploy it to AWS, you've probably noticed it's a little difficult. And so they've built stuff on top of it, like CloudFormation, to make these immutable deployment artifacts easier to understand. But CloudFormation, you know, you can set up 10 Lambdas, a couple of database tables, and an S3 bucket, and that CloudFormation can be 1,200 lines of JSON or XML that is really difficult to write by hand. So then you're getting into building a tool. Anyway, that's the reason that Architect exists. And so Architect is an open-source project that you can use whether or not you plan on using Begin, but it allows you to deploy your applications to AWS way easier. So you don't have to worry about doing all the CloudFormation yourself. There's the ARC format for defining your application, so you can define your tables, your Lambdas, your S3 buckets, your events, your cron jobs.
00:09:50 - Simon MacDonald
You put them all in an ARC file and just say deploy, and it will take care of writing the CloudFormation for you and doing the deploy to AWS.
00:09:59 - Anthony Campolo
And your CloudFormation file will go from 10,000 lines to about 100 lines of ARC.
00:10:06 - Simon MacDonald
Oh yeah. I mean, I have a fairly large application which is, I think, about 40 lines of ARC, and it's about 1,700 lines of CloudFormation. And just the ability to look at the ARC file and understand what your application is doing is so much nicer than looking at a CloudFormation file and trying to figure out what the heck is going on. And some people might be wondering, well, why are you getting into CloudFormation and playing with that sort of stuff? And it's like we like to try to avoid what we call click ops. And that's where you go into the AWS web GUI and you just start clicking around and deploying stuff. If you do that, you don't actually know what you have deployed to production, and that can be a real problem if you have to roll back to a previously known good state. Using Architect, which you can set up so that on a commit it goes to your staging, on a branch, or sorry, on a tag it goes to production, then you can always easily roll back to a specific commit or a specific tag in order to get to the last known working state.
00:11:09 - Ishan Anand
Yeah, I've heard it before, but I like that term, click ops. And I think, just to pop back to what you said, I don't know, especially for frontend developers who have come of age on platforms that are frontend-friendly, like the Jamstack platforms, including Netlify, Vercel, ourselves at NGO, Begin, they don't realize actually just setting things up on AWS, how difficult it can be. Like, if it's larger than a certain size, you've got to zip up the file and then coordinate how it gets...
00:11:44 - Anthony Campolo
I think they do realize that. That's why both Netlify and Vercel built functions, which are just AWS Lambdas.
00:11:51 - Ishan Anand
Yeah, exactly. Well, maybe they... I don't know. I sometimes encounter people who don't realize how much pain is being taken away from it. They know it's easy.
00:11:58 - Anthony Campolo
Developers don't. People building the platforms do.
00:12:00 - Ishan Anand
Oh, the people who build the platforms certainly do. I agree. I guess I'm saying the people who have come of age with those already, like kids today, don't know how good they have it in a sense. Right.
00:12:10 - Simon MacDonald
They've never uploaded a JAR file over FTP in order to get your servlets running.
00:12:16 - Ishan Anand
Yeah. Yeah, exactly. Or had to put it on S3 in order to then pull it into Lambda. So a couple of things on Architect I think are worth highlighting for the audience. So first of all, Architect's open source, but it's also OpenJS Foundation, right? So it's true open source. You guys, I think that was like a year or two ago you guys donated it over to the OpenJS Foundation. Is that correct?
00:12:41 - Simon MacDonald
Yeah, I think it's probably two years ago now, but yes, it is under the OpenJS Foundation's stewardship. You know, myself and Brian LeRoux, who's the CEO of the company, we cut our teeth doing open-source development and we really believe that most of what we produce at Begin should be open source. One of our core tenets is we want to give you escape hatches. If you went all the way and used Begin, that's great. You're going to give us money. We love you. But if you decided that you only wanted to use Enhance, that's cool too. That's an open-source project. You can do that. If you just wanted to use Architect, that's great. You can do that. There's all these different things where you can walk your way back down closer to raw AWS. You can escape. You're not going to be locked into Begin.
00:13:34 - Ishan Anand
Yeah, that's obviously, I think, going to resonate with a lot of developers who don't want to be locked in. And if we have time at the end, I'd love to come back and revisit what that process was like. But the next follow-up question is, how do you compare Architect to something like Flightcontrol, if you're familiar with that offering?
00:13:58 - Simon MacDonald
Yeah, I honestly can't say that I am familiar with it.
00:14:01 - Anthony Campolo
Serverless Framework is a better comparison.
00:14:03 - Simon MacDonald
Oh yeah, Serverless Framework. I mean, they're six of one, half a dozen of the other. They're just different ways of approaching it. With the Serverless Framework and your ability to select whether you're going to be using AWS or Azure or GCP, you can kind of get that set up. With Architect, we've decided to be a lot more opinionated and go with AWS as the platform that underlies everything.
00:14:33 - Anthony Campolo
You gotta say "maxi," AWS maxi. That's the term.
00:14:36 - Ishan Anand
Yeah.
00:14:37 - Simon MacDonald
Thank you, Anthony.
00:14:38 - Ishan Anand
You're right. That's a better comparison. Yeah, okay, that makes a lot of sense. Okay, so then help me with the origin story on Enhance and why you guys felt you need to create the framework, and then we can talk about the philosophy of enhancement as well.
00:14:57 - Simon MacDonald
Sure. So let me talk a little bit. We'll skip the Enhance layer for a second and we'll go to Begin. Because for many years we were building applications on Begin and you were deploying all of your assets to your S3 bucket. You could potentially be using React or Vue or Angular or some other UI framework of your choice, and everything was great, except we started seeing common customer issues all the time. That was people running into build issues where they couldn't compile their JavaScript source code into something that could be deployed to S3. We were seeing a lot of breaking changes from the different frameworks that people were using. We were seeing a lot of unplanned changes that were being forced upon people. So it was very difficult for people to keep things running. What we had realized as we were building out not only the Begin website, but some other websites we had done, is that we had these common patterns that just kept coming up over and over again. And that was kind of the germ of the idea for Enhance, and that is using functions as a service in order to generate components on the server side, having them land on the client side as completely working HTML.
00:16:13 - Simon MacDonald
And that way you can just progressively enhance it on the client side in order to provide more interactive functionality.
00:16:22 - Ishan Anand
And if there was a... does this relate to, I know Brian had been giving talks on a concept he calls functional web apps. Is that close, would you say? What's the overlap there between, first of all, how you define functional web apps and Enhance?
00:16:43 - Simon MacDonald
Sure. Functional web apps is an architectural pattern that you can use in order to build web applications. So there's three main pillars for your functional web app. And the first is that everything is done using cloud functions. So all of your functionality is being done on the cloud in a cloud function. It doesn't matter if you're using... this could apply to AWS, it could apply to Azure, it doesn't matter. But you keep everything in cloud functions. You don't have any servers running. Secondly, you need a modern database that is on demand as the second pillar in order to store your state and all of your data. We've really found that these modern databases, with their sub-10-millisecond latency, are incredibly good for building web applications, and that you don't really need to get into doing a lot of static-site generation and storing it on the S3 bucket, because you can do personalization directly from the Lambdas or the cloud functions just by hitting the databases. Instead of the old days where we used to hit Oracle or Postgres or MySQL and it would take a whole minute just to set up a connection.
00:18:00 - Simon MacDonald
And then we get into connection pooling and many other things that just added to the complexity of things. And then the last part, the last pillar, of functional web apps is infrastructure as code. So we use ARC. You could use CloudFormation, but basically you need to have this immutable deployment so that you know exactly what got deployed to production. It's so important so that if you run into issues, you can, like I said, revert back to a previously known good state. And with Enhance, it's just our way of doing functional web apps for the UI layer. You can build a functional web app without Enhance. But all Enhance apps are functional web apps, if that makes any sense.
00:18:51 - Ishan Anand
Yeah, so this is your answer starting from the frontend, less so from the backend. Because obviously the CI/CD part of it, Enhance doesn't have an opinion on. That's more in your infrastructure platform provider. But it covers at least two out of the three, it sounds like. Your API endpoints and the like are covered. Those two out of the three requirements for functional web apps also would be covered by Enhance. Is that an accurate way of saying it?
00:19:22 - Simon MacDonald
Well, really, Enhance applications via Begin, you would get all three of them because we would use Architect to deploy them.
00:19:32 - Ishan Anand
Yes. Okay.
00:19:32 - Simon MacDonald
But if you were building an Enhance application and you just wanted to deploy it yourself, then you would have to take care of the infrastructure-as-code portion.
00:19:41 - Ishan Anand
Sure. Okay.
00:19:42 - Simon MacDonald
Because you can use Enhance in order to server-side render custom elements. You don't have to buy... we're infinitely hoping that people will just buy into the entire concept of Enhance. But if you just want to use it as a server-side renderer of custom elements, you can use it as that as well.
00:20:06 - Ishan Anand
Okay, so I think that takes us to... it's a good setup for the philosophy of Enhance. The common issues you saw with people, with breaking changes coming from frameworks, using functions as a service to generate components server-side. How would you like... it's actually the first page on the docs. But could you just walk us through those core tenets of the philosophy for Enhance?
00:20:31 - Simon MacDonald
Sure. One of the things with Enhance is it's an HTML-first, web-standards-based... One of the things that we really noticed is that with a lot of the modern web frameworks, they pour a lot of JavaScript down the pipeline, ends up on your client. I don't want anybody listening to think that I'm anti-JavaScript because, okay, so JavaScript hasn't bought my house, but it has helped put a reasonable down payment on it. So I'm quite happy with JavaScript. But I've been working with JS since, I guess, 1997, and I would like to say that, I think I'm kind of borrowing this from Michael Pollan, it's like: use JavaScript, not a lot, mostly on the server side. Because we have really overreacted into doing all of this client-side rendering of things. To divert away from your question, I'm going to just... quick anecdote. I was trying to buy a pair of pants the other day and I could not get the checkout to work. It said that I did not type in my first name and last name. I could clearly see in the input text fields that my first name and last name were in there, and nothing I could do would allow me to buy this pair of pants.
00:21:50 - Simon MacDonald
I even changed to a bunch of different browsers, and I knew in my heart of hearts that as soon as I started to debug this, it would be a React application with controlled inputs, and they had a bug in their state management. And so that was really frustrating, especially since when I looked, that shopping cart was 4.7 megabytes of JavaScript. I can't imagine why you need 4.7 megabytes of JavaScript for a shopping cart, but apparently you do. It's also a shopping cart that didn't work. I thought, okay, it's cool, I will just disable JavaScript. It will go back to using a regular old form and I'll be able to submit this.
00:22:31 - Ishan Anand
No such luck.
00:22:33 - Simon MacDonald
And I'll submit the shopping cart. It'll take care of it on the server side, because that's the way we're supposed to do things. We're supposed to validate on the client side and validate on the server side. As soon as I turned off JavaScript, the whole page didn't work. Nothing worked. It's like, that is so bad. That is so bad for our users. That's so bad for accessibility. I don't know how we got to this, but that's one of the reasons that we came out with Enhance. It's web-standards-based. It's HTML-first. We're trying to get people to use HTML and CSS as much as possible so that the page that lands at your client is already fully workable. And then you add things, or you enhance your page, with some JavaScript to make it more interactive. People really want to be able to use reusable components when we're building applications. That's why we settled upon using web components. Now, if you know anything about web components, there's a couple of specifications in there. There's the custom elements specification, the Shadow DOM specification, and there's slots and templates. The first one, the custom elements, this is what we really wanted to do, is take your custom element definitions and server-side render them so you could send them down to the client.
00:23:51 - Simon MacDonald
Because the problem with web components and custom elements is they don't work unless you have JavaScript, because basically you have to call customElements.define in order to register your custom element with the browser. In my opinion, that was a mistake that the W3C made when they were coming out with the specification, because you could have a custom element that doesn't have any JavaScript in it and it should theoretically work on the client anyway.
00:24:22 - Ishan Anand
That's actually a really subtle but really good point.
00:24:25 - Simon MacDonald
Yeah. A lot of people... I mean, we love web components, don't get me wrong. But a lot of people are like, oh yeah, they're going to solve all these problems. And it's like, yeah, but if JavaScript fails... And I'm not talking about the crazy people like me who occasionally turn off JavaScript just to see what happens, because I like to watch the world burn. But there's lots of reasons why JavaScript might fail. It could be you're at an airport and the Wi-Fi that you're on is just messing with things. You could have some issues with screen readers. You could have issues with an extension that's in your browser. Like, an ad blocker could take things out. And I think the stats are somewhere between 1 and 2% of every page load, something goes wrong with JavaScript. And that doesn't...
00:25:10 - Ishan Anand
Oh, wow.
00:25:10 - Simon MacDonald
Yeah. For some people, yes. So you're like, wow, that's a lot. Some people are like, oh, that's not that big of a deal. But if you have like a million visits to your page and like 10,000 to 20,000 people are being turned away, that's going to affect you quite a bit, with how much you're able to get in touch with people and able to sell things from your website. Yeah, it's bad. If we think in an HTML-first way and we say, okay, we're going to take these custom elements, we are going to look at what they would look like if JavaScript was enabled on the client, we're going to expand them at the server, and then we're going to send that expanded custom element over the wire down to the client. So then when it lands on the client, it's already workable. Then any additional functionality that you need to add, you can attach your event listeners if JavaScript is working at that point in time. But if it isn't, it's okay because it'll still work because you've got good HTML there. And that is just good web development, because plain old HTML is quite accessible.
00:26:16 - Ishan Anand
Yeah, this progressive enhancement, which for the audience who aren't familiar with it, it's basically the site works with JavaScript turned off would be the simplest definition, although it's more that you progressively enhance depending on the features that are in the browser. But this emphasis in Enhance on progressive enhancement was really... I read the philosophy, but as I read through the documentation, what really drove it home for me was you have an example of a counter, just a button, and it shows a little indicator of how many times you've hit the button. The way you guys had implemented it, the canonical way you do this would say something like React is you'd have some state, you'd hit the button and it would increase the count, and it'd entirely be in client-side JavaScript. But your first part of the example works without any JavaScript. You'd start with a server-side implementation, it goes to the server, the server changes the cookie, it comes back. So it could work without any JavaScript whatsoever. That really is the example, if you're looking at the documentation, that really drove home for me how deeply embedded this is in the Enhance philosophy.
00:27:30 - Simon MacDonald
Yeah. And actually, I think that was a blog post I wrote, so I'm glad you found it useful. But I think what people have missed over the past five to 10 years, when we were busy working with React or Angular or Vue, is that underneath the hood the platform got really good. You can do a lot of things now without JavaScript. So if you start from an HTML-first perspective and take advantage of what HTML and CSS give you, you will find that you don't need as much JavaScript as you initially thought. And sometimes you have to ask yourself, why am I adding 280 kilobytes or 4.7 megabytes of JavaScript onto this page when the HTML-first approach would work just as well?
00:28:16 - Anthony Campolo
Well, that's why no one does that. Use any of the six other client-side frameworks that don't give you a bundle that large.
00:28:24 - Simon MacDonald
I mean, some of the client-side frameworks let you do stupid stuff.
00:28:29 - Anthony Campolo
With React. But I think that's a people problem. People doing stupid stuff, not a problem with client-side JavaScript. But don't worry, I've said that many, many times.
00:28:42 - Simon MacDonald
Yeah, I think with some of these client-side frameworks, they make it very easy for you to overuse JavaScript. And we're looking at it from the other perspective. We really want you to think about how much JavaScript you're using on the page.
00:28:57 - Anthony Campolo
I don't even think it's a tool problem at all. It's the way we teach people to use them. The problem with React is that the vast majority of React code is written by people who learned how to code in the last three years.
00:29:09 - Simon MacDonald
Yeah. And so this is where I will complain about React a little bit. How many years of experience would you say you have with React right now?
00:29:20 - Anthony Campolo
About three. I am that student.
00:29:23 - Simon MacDonald
Okay.
00:29:23 - Scott Steinlage
Fair.
00:29:24 - Simon MacDonald
For me, who's been coding forever, and I probably started using React seven years ago, I would say that I have about one and a half years of experience with React currently, because React went from createElement, it went to JSX, it went to class components, it went to functional components, it went to hooks. Every year, year and a half, React completely changes itself. And it is backwards compatible, but a lot of the client libraries that you depend upon, they don't work with the older versions.
00:29:59 - Anthony Campolo
So you keep writing class components like it's... Nothing works if you want to actually migrate to hooks. But people do because they want to be able to decouple their logic through composable stuff. So I think hooks... I'm not sure I can imagine where it's going to go next to change. I think right now hooks are going to stay and they're going to figure out the backend. But I think Enhance is cool because you're like, we need to build a React meta-framework for web components. So it's like, I get it.
00:30:29 - Simon MacDonald
Yeah, we're pretty happy with it.
00:30:32 - Ishan Anand
But I think what you were saying, Simon, is this idea that it's not a bug, it's a feature in a sense. Like you said with AWS, it might look like it's a confusing set of services, but it's because they don't do breaking changes. I think what you're saying here is with web standards, yeah, you may think they move slow, but you can rely on them in the same type of way. That's harder to rely on than the framework conventions of something like React that has been changing really important foundational ways on how you architect an app and use the library or framework, depending on your definition. I think that's what you were getting at, correct?
00:31:10 - Simon MacDonald
Oh yeah, you said that way more succinctly than I have. The platform does not break. The web platform is backwards compatible. If you wrote a web page from 1995, you could load it up in today's web browser and it would just work. You can't...
00:31:26 - Ishan Anand
I have done that experiment.
00:31:28 - Simon MacDonald
Yeah. Wild, isn't it?
00:31:30 - Ishan Anand
Yeah. Tim Berners-Lee's first thing, and it's even responsive, funny enough. Right? Yeah, sorry.
00:31:37 - Simon MacDonald
You can take that application you wrote in 2002 that was using jQuery, and it still works. It's amazing. But it's hard to say that with some of our more modern frameworks. It's like things change so rapidly and they don't worry as much about backwards compatibility that you're kind of on this hedonistic treadmill of having to update your dependencies all the time just so that your application doesn't break, even though you don't do anything to it.
00:32:04 - Ishan Anand
Not to be overly precise, but I think there's value in it because I think for the developer audience it'll resonate. It's not just that it works. You could take something that was written in React in 2013 or 2015 and it probably will still run, but to go in and actually change it and maintain it is going to be like the whole ground is out from under you. You're like, I just better rewrite this whole thing. Whereas if you wanted to go to Tim Berners-Lee's first version of the web page, or even a jQuery-based website, depending on its level of complexity, how you modify it is probably going to be the same way you'd do it now versus the way you would have done it then. You're just building on very clear standards. That's part of, at least for me, what the definition of "works" is, that I can not only have it run there, but I can go back to it and I can easily modify it and come back to a project and, at least on the frontend, be able to get enough there that I can change it. It's a really important value.
00:33:00 - Ishan Anand
I feel like the ecosystem is starting to wake up to this problem, this idea that you said earlier: the web platform got good while we weren't necessarily paying attention. It seems to me you and Enhance are part of these, for lack of a better word, post-React frameworks that are coming out. They're more web-standards-based, they don't rely on a virtual DOM. How would you compare and contrast Enhance versus, say, some of the other post-React frameworks? I'm going to pause, since we're right at the halfway mark, and let you think about how you're going to answer that. And I'll just pause for what I call our station break, because we're at the halfway mark, to, A, encourage anybody who's a listener to think about raising their hand and asking a question, because we now transition to the more audience-driven part, and then also let Scott jump in and give the station break.
00:34:01 - Scott Steinlage
Awesome. Yeah, thank you so, so much. Greatly appreciate it. Thank you also for showing up today. Simon, thanks for coming on here and chatting about Enhance and Begin and this wonderful stuff. We really do love it. Thank you so, so much. Remember, if you're a beginner at this or maybe you're just an advanced user, it doesn't matter. We want to hear from everybody, so please feel free. Like Ishan said, we want to promote people coming up, asking questions or statements or whatever it might be, opinions. We'd love to hear it. It just brings more value to everybody in the room and just makes this a lot more fun. So please feel free to request to come up and we'll bring you right on up. It'll be a good time. Yeah. So don't forget, we do this every Wednesday, 12:00 PM Pacific Standard Time. However, and we will be here next week as well, but just want to throw this out there, we will not be here on the 28th of December, just in observance of the holidays. So with that being said, we're about to get back here to our wonderful guest, Simon, to go over what Ishan just said.
00:35:07 - Scott Steinlage
Maybe you should restate what he said there after the break. But I do want to mention, hey, we have this awesome newsletter. If you haven't heard of it, it's called JavaScript Jam. Yeah, kind of makes sense with what we're doing here, JavaScript Jam. So head on over to javascriptjam.com if you haven't already subscribed to the newsletter, because you don't want to miss out, because there we are talking about everything web-development- and JavaScript-related, pushing out different links to trending things and shout-outs. So yeah, feel free to get in the know. Don't be left out. All right.
00:35:44 - Ishan Anand
Okay. Yeah, thank you, Scott. So, before we left off, the question I basically posed to you is a more complex one, of a very simple question, which is: how does Enhance compare to whatever framework you might name as your favorite framework? In this case, though, I tweaked it a little and said, well, let's... we've talked a lot about the differences with, say, something like React, which is the 900-pound gorilla, but there's been a bunch of these post-React frameworks coming out. A, do you agree that there's this trend toward more standards-based, that the ecosystem is finally recognizing a lot of things that align with your philosophy? And then B, how would you compare against say something like Eleventy or Astro or any of these other kinds of post-React frameworks?
00:36:28 - Simon MacDonald
Yeah. So the A part of that question is, I do 100% agree. I mean, web development, again, 25 years of doing this stuff, it is a pendulum that swings from one direction to another. I mean, we went really far in the direction of doing client-side rendering. We learned a lot from that. But now it's swinging back more toward the server-side rendering piece. And we're taking a lot of the things that we learned in CSR and applying them to SSR and doing this kind of standards-based approach. So, you know what, we'll probably do this for a few years and then the client will get a lot better and the pendulum will swing back to CSR again. And that's just the way that things get better. So the two approaches definitely inform each other. I mean, what did Steve Jobs say? It's like, good artists copy and great artists steal. And that's what we've done in tech for a million years, where we say, oh, that was a great idea. I'm going to adopt that into my framework and then make my framework better. And then the second part, how would I compare it to other frameworks like Eleventy and WebC?
00:37:31 - Simon MacDonald
So I think you really have to look at it yourself, like what makes sense for your project. I'm always a right-tool-for-the-right-job type of thing. So Enhance is really good for building a certain class of applications, and we can talk more about what Enhance is good for doing. With Eleventy, where you're doing a lot of static-site generation and having these pages stored in an S3 bucket, that makes a lot of sense if that's what you want to do. But with Enhance, because it's purely server-side rendering, we don't do a lot of static-site generation. Most of our static assets are images. They're not fully formed web pages, because we want you to be able to get the freshest information out of the database, apply personalization based upon who the logged-in user is, and send that data down to the client. So neither approach is the correct one. It just depends on what problem you're trying to solve.
00:38:33 - Ishan Anand
Yeah, I think that's actually a good segue for the next question, which is... you actually set it up. What are the apps that you think Enhance is good for, and what are the apps that you think it's not good for, or less of a fit?
00:38:48 - Simon MacDonald
Yeah, any application that you need dynamic personalization for, it's a really good setup. Now, I ran a very large documentation site for a company I used to work for. And for a long period of time it was just static pages. There was no personalization. So it was like, okay, that's fine. We have the source data, we build it into web pages, we store it in a bucket, we display it to people. If that's what your application needs, Enhance is not a good fit because it is server-side rendered on demand. It's very dynamic. But if you're starting to get into something where you have a whole bunch of different products and you're loading them from your database and you need to do some price adjustments depending upon what region you're in or what country you're in, that kind of stuff, Enhance is incredibly good at because of its dynamic ability just to build that web page on the fly as required. With our modern on-demand databases, there's really no latency for being able to do this on-demand building of the web page.
00:40:02 - Ishan Anand
If I was to summarize, we've got documentation, highly static site, not necessarily a good fit. Maybe that'd be something that Eleventy would be a better fit for. But something that has, say, an ecommerce site with a lot of personalization, or even a content site with a lot of personalization, that would be a better fit. Where would you put something like a dashboard or Gmail or something like that?
00:40:30 - Simon MacDonald
I put that firmly into something that Enhance is really good at doing. So, I'm going to again show my Canadianness here. Yeah, I play a lot of hockey. Not just because I'm Canadian, but because I love hockey. And on Friday nights I manage a bunch of guys and we get together and we play hockey. So I built a site using Enhance just to make my life easier. So when somebody emails me and says like, oh, I can't make the game, I just check their name off as missing. Then that goes off and checks to see, do I need to find a spare for this person? If I need to find a spare, it looks at my database table of spares, it pulls one off there, and it sends them an email that they can click, yeah, I'm going to play, or no, I'm not going to play. This dynamic application I built using Enhance, it was just ridiculously simple to do. The next step, I need to convince these guys... unfortunately, we've been doing this for probably 15 years, emailing me stuff. I just want them to go into the website and click a button so I don't even have to be involved in it anymore.
00:41:33 - Simon MacDonald
But, you know, it's hard to teach an old dog new tricks.
00:41:41 - Ishan Anand
You know, I just want to call out again that this is what we call the second half, the audience-driven half. So anybody in the audience, I want to encourage you to raise your hand. We're happy to bring anyone to the stage. You can ask a question or just have a comment. We'd love to have this be as audience-driven as possible. Let me segue, though, in the meantime to another question for you. Earlier you had said Enhance is really built for building off of functions as a service and modern databases. You referenced DynamoDB. Can you elaborate on what you meant by modern databases? Are you talking about NoSQL? Are you talking about something else?
00:42:29 - Simon MacDonald
No, it doesn't have to be NoSQL, but when I say modern databases, I mean the on-demand ones. Again, we talked about kids these days. They never built a socket connection pool for connecting to a database. Folks, connecting to a database is an expensive operation, and it used to take quite a number of seconds to do. So much so that we would create connection pools and then we would create a whole bunch of connections. And then anytime you needed to query the database, we'd pull one out of the pool, we'd do our query or our update, and then we'd put it back in the pool. And every so often we'd have to kill that connection because it would grow stale or too many executions would happen and things would go wrong. I'm thinking exactly me dealing with Oracle back in the day. So that was a huge pain in the butt. With our modern databases, you don't have to worry about this. You're connecting to the database, the latency on that, like I said, is sub-10 milliseconds in order to make that connection. So you don't have to worry about building a connection pool in order to do stuff like this.
00:43:37 - Simon MacDonald
The other thing that I think of when I talk about modern databases is that I don't have to manage that database. Somebody else is taking care of that for me. So anytime there needs to be a patch applied to that database, I don't have to do it. If there's a security fix, I don't have to worry about it. All of that stuff is handled for me. Backups are also done.
00:44:00 - Ishan Anand
So let me get, let me see if I can rephrase. So for you it's, shall we call it serverless-compatible databases? Ones where you don't have to worry about connection pooling, and then ones where the management is handled for you. Is Postgres not meeting that definition? But maybe it does when it's inside RDS with an RDS Proxy managed by AWS.
00:44:30 - Simon MacDonald
Yeah, you could use it in the situation that you talked about where it's Postgres inside AWS. Then you could use it. We tend to use DynamoDB and NoSQL databases because we do a lot of work with JSON and it models quite nicely. But if your application is built on relational data, then yeah, you could use Postgres under a situation like that.
00:44:55 - Ishan Anand
Okay. I guess I'm saying, would it meet your definition of a modern database in that situation?
00:45:02 - Simon MacDonald
It completely would.
00:45:04 - Ishan Anand
Okay, so it's more about how you relate to it rather than any database structure itself. Okay, yeah, that makes sense. Can you tell us a little bit about how Enhance relates to the new version of Begin?
00:45:23 - Simon MacDonald
Sure. In Begin version one, we made... it was pretty opinionated. The CI/CD was all set up for you. You had to kind of opt into all the different ways that Begin said, oh, this is how you deploy a new application. With Begin version 2, you'll be able to build the application and just use the deploy command. So we're coming out with a CLI that will make your life a lot easier. CI/CD, we've heard from a lot of people that they want to take care of it themselves. We've built some GitHub Actions that you can just use right out of the box in order to make deployment a lot easier. But there's no reason you couldn't use your own CI/CD solution as well and just script it using our CLI. With Enhance, we just think that this is a better way of building applications going forward.
00:46:26 - Scott Steinlage
But...
00:46:28 - Simon MacDonald
You can still deploy Architect applications to Begin version 2 without Enhance as well.
00:46:38 - Ishan Anand
Okay, and what's the timeline for Begin version 2?
00:46:43 - Simon MacDonald
We're hoping in Q1 of 2023, and that's calendar year Q1, that we'll be able to roll out more of the Begin 2 functionality. We're currently in beta with a lot of friends and family right now, just gathering a bunch of responses back from folks on what they like and what they don't like.
00:47:03 - Scott Steinlage
Okay.
00:47:04 - Ishan Anand
It's interesting, that comment on CI/CD. We have definitely noticed that as well, that people want to take care of it themselves. I guess in my experience, it's a little subtler than that. It's that beginners want it just handled. People who are completely new to the web, or newer to the ecosystem, or they're just trying the platform for the first time, they're like, I want that taken care of and you just integrate like some of the other platforms do. But when you talk to larger-size teams and enterprises, they already have something legacy and they're like, let's integrate with that. Does that reflect your experience, or would you even say beginners... I have a different view on what beginners want than what maybe you've experienced.
00:47:53 - Simon MacDonald
No, I think you've hit the nail on the head right there. That seems to line up quite well with the feedback that we're getting. And that is one of the reasons why we wanted to have those escape hatches in Begin, so that you could adopt Begin fully, or Enhance, or Architect, so you could pick which level of the stack that you wanted to kind of work with. But yeah, when we had Begin v1, people would say, oh, your CI/CD is great, but now that I've been building apps here for three months, it's like I want to use my own stuff instead. And that's something that we saw quite frequently. So going forward, you'll be able to pick your CI/CD solution. Like I said, we already have GitHub Actions which you can use in order to make that easier. We're looking at CircleCI and Jenkins and other different CI/CD solutions, just to be able to give you some things to get started. But it'll be up to you how you want to do your CI/CD.
00:48:53 - Ishan Anand
Got it. That makes a lot of sense. Like I said, that gels with what we've seen in the market as well. Speaking of the market, I'm curious how you explain to folks what maybe is a common question you get, and tell me if it's not a common question, but like, how do you compare and contrast Begin to the other Jamstack platforms in the market?
00:49:19 - Simon MacDonald
Yeah, we don't solve kind of the same problems as the Jamstack platforms that are out in the market. And really what we're trying to get to people is that we're going to use a standards-based JS approach. We're not adding in some frameworks with any kind of special syntax, so that any code that you write that would work with Begin and Enhance will be able to work as a normal web application itself. So we're really trying to get away from that lock-in.
00:49:55 - Ishan Anand
Do you think that... I mean, there seems to be at least an undercurrent that a platform sometimes has a preferred framework in order to get attention in the market, in the ecosystem. Is the Begin/Enhance pairing evidence for that, or do you view it differently? You get what I'm saying? To name names, there's the Next/Vercel pairing.
00:50:29 - Simon MacDonald
Yeah.
00:50:31 - Ishan Anand
Is it accurate to make the same Enhance/Begin comparison there?
00:50:37 - Simon MacDonald
I think it's a fair comparison, certainly. But really what we're trying to do with the Enhance side of things is, again, to get back to JavaScript standards and not have to worry about adopting a larger framework, and to kind of look at things more from an HTML-first approach. So we're just coming at it from a different angle. If you have learned Next and you've learned a lot of React and that makes a lot of sense to you, you should definitely use Vercel for that. But if you want to kind of approach this from more of an HTML-first type of scenario and back to web standards, then Enhance would be a really good fit. So again, right tool for the right
00:51:25 - Ishan Anand
job, really. Would you say... let me take that a step further. What would you say to somebody on Next, but isn't necessarily on Vercel yet? Would you say they should consider Begin, or would you say maybe you wouldn't say that? Because what I'm trying to get to is a deeper question, which is: does a frontend-catering platform also need a corresponding framework that it is tightly integrated with in order to really either get attention or to fulfill that mission of being frontend-developer-friendly? Does that make sense?
00:52:06 - Simon MacDonald
Yeah, that does make sense. And again, I think you're really getting to the core of these things. In order to provide that better developer experience, you start to have to tie your frontend framework to the platform itself. That's what we've done with Enhance and Begin. You can use Enhance without Begin, though, which is nice, but you'll get a much better developer experience if you're using the entire stack.
00:52:34 - Ishan Anand
Got it. So would it be fair to say that for the new version of Begin you've mentioned, you can take existing Architect apps and deploy them on Begin 2.0, but Begin 2.0 really is going to be the sun, right? The center of the solar system will be the new Enhance framework, correct?
00:52:56 - Simon MacDonald
Yeah. We want people to be able to use Enhance, and a lot of it comes down to what we have learned from our customers, that they were running into a lot of issues with already existing JavaScript frameworks, and that's why we built Enhance. One of the things that we ran into a lot, customers would say, well, I picked Vue or I picked Angular, and it's like, just tell me what to do. And what we noticed is we had built a lot of applications using the same kind of patterns, and then those patterns became Enhance. And now we just want to share that with the world so that people don't run into these same problems that we had seen over and over again with a lot of our customers.
00:53:41 - Ishan Anand
Okay, interesting. What does that mean if you're... let's talk about then deploying Enhance on non-Begin. Can I deploy Enhance... presumably I can deploy with Architect directly to AWS. Is that accurate? Like, what is the non-Begin option for non-lock-in for deploying Enhance? What does that picture look like?
00:54:09 - Simon MacDonald
With the non-lock-in, you could use Architect to deploy directly to AWS. And Architect, again, as we discussed, is an OpenJS Foundation project. It's open source. You'll always be able to do that. We think that we're going to try to make Begin as enticing as possible with a lot of functionality. You would have dashboards around some insights, your logs, all sorts of fun stuff in there that we're planning on building in 2023. But you'll be able to deploy to other services as well. I think currently there's a bug with the Netlify deploy. One of the things that we run into is the other platforms, we're not as plugged into, so they tend to change things and our integrations break, and it might take us a while to get back to it. But you could also use Fastify in order to be able to deploy as well.
00:55:04 - Ishan Anand
If somebody wanted to deploy on, say, Vercel or Netlify, is that possible? Is there a plugin for that?
00:55:14 - Simon MacDonald
There doesn't currently exist a plugin, but we could definitely explore that. And I forget, is Vercel running on top of AWS?
00:55:23 - Ishan Anand
Parts of it do run on top of AWS. I don't want to speak for them. My next one is, where I work, NGO, we could also be interested in supporting Enhance as well as a supported framework, so I'm not completely agnostic in asking the question.
00:55:44 - Simon MacDonald
Yeah. Well, we would love to have as many different deployment options as possible, so get in touch.
00:55:51 - Ishan Anand
Yeah, okay, awesome. So I do want to do a time check. I have a hard stop in four minutes. I don't know if you're available. I believe Scott and Anthony are available as well. Is that correct, to keep going?
00:56:05 - Scott Steinlage
Yeah, I believe Anthony... we have it scheduled for another 30 minutes.
00:56:09 - Ishan Anand
Okay.
00:56:09 - Simon MacDonald
Yeah, I can definitely stick around. Don't worry about it. I've got time.
00:56:14 - Ishan Anand
Okay, great. Well, thank you. I'll just say, before I disappear and turn to a pumpkin, thank you for joining us. This has been a very interesting discussion. Really exciting always to see an interesting framework and what it brings to the table, and really excited to see where Enhance goes. I usually close with this, but I'll ask it since it might be my last question before I disappear. What should people look forward to for Enhance? What's coming down the pipeline that has you most excited?
00:56:46 - Simon MacDonald
Yeah, well, one of the things that we're most excited about, and we should be releasing that in early 2023, is some progressive enhancement helpers around writing web components. So if you've ever written a web component, you'll notice that there's a lot of boilerplate code in there. So we're going to make that easier so that folks don't have to write as much code when they're building their web components. Of course, because it's coming from Enhance, we're going to make sure that it server-side renders as well as gets progressively enhanced on the client.
00:57:21 - Ishan Anand
That's great. Very cool. Well then I will turn you over to Scott and Anthony. Thank you again. And I will thank everyone for attending, and see you all next week.
00:57:34 - Simon MacDonald
Awesome.
00:57:35 - Scott Steinlage
Thank you. Thank you so much. Anthony, yo, man, I know you had some things that you were wanting to chat about with Enhance, several questions I'm sure.
00:57:45 - Anthony Campolo
Oh, I mean, I would definitely encourage anyone to come hop up, either Brian or Nick. I think you guys both have a lot of interesting things to say as well.
00:57:53 - Scott Steinlage
I invited Brian up for sure. Cool.
00:57:57 - Simon MacDonald
This Brian guy, don't let him talk. I mean, you just don't have enough time left.
00:58:01 - Scott Steinlage
I just invited Nick too. Absolutely. We'd love to hear from everybody.
00:58:09 - Simon MacDonald
I think you're being invaded by Canadians right now with Brian and Nick here.
00:58:14 - Scott Steinlage
Is that right? True.
00:58:15 - Simon MacDonald
It's true.
00:58:16 - Scott Steinlage
Yeah. You know what I want to do? I was thinking about this while we were talking and you keep bringing that up. I was thinking I really want to ask ChatGPT to use "Bob's your uncle" in a sentence and see what it comes up with.
00:58:32 - Simon MacDonald
Oh, I can... man, I used to remember the actual Bob that "Bob's your uncle" refers to. That's going to bother me for the rest of the day. Thanks, man.
00:58:42 - Scott Steinlage
You're welcome.
00:58:44 - Anthony Campolo
Have you tried ChatGPT, Simon?
00:58:47 - Simon MacDonald
No. Okay, so my coffee-addled brain is remembering it's a Robert, Sir Robert something from England, and it has to do with nepotism. And that's where the saying came from. It was like, oh yeah, Bob's your uncle. And it was an explanation like, oh yeah, you just got this job or whatever because Sir Robert whoever is your uncle. Guys, it's really bothering me now. I gotta look it up.
00:59:20 - Scott Steinlage
Yeah, that's interesting. The first time I ever heard it was from an old boss of mine, and he was telling me a story and then he was like, yep, and Bob's your uncle. And I'm like, what? What? Did you just say what?
00:59:31 - Anthony Campolo
Yeah, I've heard a bunch of people say it. I've never known the origin. Anyway, what's up, Nick? You've tried Enhance before?
00:59:40 - Ishan Anand
Yeah, yeah.
00:59:41 - Nick
Hey, how's it going, man?
00:59:44 - Scott Steinlage
Good, good.
00:59:45 - Anthony Campolo
Do you have any questions for the panel or thoughts on Enhance you'd like to share?
00:59:50 - Nick
I think, I mean, I'm a little long in the tooth too. So one of the things I kind of appreciated with Enhance is like, kind of... I think Simon said this when we streamed together, but it's the original single-file component, you know, an index.html file.
01:00:08 - Simon MacDonald
And...
01:00:10 - Nick
I don't know. I think the neat thing about frameworks like Enhance is you don't really need to learn the framework per se. As long as you understand web fundamentals, you should be able to get up and running pretty quick. So, where with other frameworks you might need to dig in a bit more to understand how the lifecycle of the page works or the app works, I found that it made it more approachable.
01:00:37 - Simon MacDonald
Made it more approachable.
01:00:41 - Scott Steinlage
Yeah, that's exciting. I think it was Simon and Brian were on with Rizel Scarlett from GitHub and we were talking about Enhance, and we were talking about how it's just so much easier, or potentially easier, for folks who are just getting started. And you kind of alluded to that, Simon, in the beginning, with Begin, saying how it's more friendly, I guess you could say, potentially for folks who are just getting started because HTML, CSS, kind of the beginnings of these things, you can really get started with it and grow and progressively enhance with it, right? It's very much similar to... I can't think of the other framework now. But yes, there's some awesome things you could do there. And one other thing I was...
01:01:40 - Simon MacDonald
Progressive enhancement instead of graceful degradation.
01:01:43 - Scott Steinlage
Right. Another thing I was thinking of is, I don't even know if we really mentioned it much, at least I didn't think I heard anybody mention it, was accessibility. That was another thing we had in conversation, that you guys really designed and wanted to have inclusivity and accessibility, for people to more easily have accessibility in there.
01:02:11 - Simon MacDonald
Yeah. And I think that's kind of what you get from taking this as an HTML-first approach. I mean, raw HTML is accessible by default, and it's only when we start adding a whole bunch of JavaScript and changing the semantic meanings of various tags that we have to start putting in a whole bunch of aria-labelledby and other ARIA elements in there in order to make it accessible to other tools. But if you're starting with proper semantic HTML from the very beginning, it's just kind of accessible by default, which is amazing. And one of the things, if you've ever built a date component in JavaScript, it's like that takes quite a bit just to get the date component right. And then to make a date component that's actually accessible, then you're adding another layer of complexity onto this. When now you can just take an input and say it's type date and you get this wonderful date picker, and you didn't have to add in any JavaScript to that and you didn't have to worry about making it accessible because it's accessible by default in the browser.
01:03:22 - Simon MacDonald
That's what we want people to look at and see, some of the things that the platform has come out with that they may have missed while they were busy doing a bunch of other things.
01:03:35 - Scott Steinlage
Yes, absolutely. Accessibility is definitely an important piece to think about, so I can appreciate that. Anybody else? Go ahead.
01:03:46 - Nick
I was just going to say, another... to my point, what I was saying before, how it made it pretty easy to get up and running. Conversely, I think people that might be new to web development might be like, what is all this? In the sense that they've had guardrails of frameworks and not necessarily know how the platform actually works. I can give a perfect example. This is older, but I used to work with ASP.NET. It's a Microsoft framework, and they gave the impression that the web was stateful by the way they used ASP.NET. They tried to make web development programming like a desktop application in Windows. And you see other stuff like that too. Not exactly the same thing, but like React, for example, people just know, okay, this component has an onClick. But they don't necessarily understand, okay, well, when I click onClick, that's doing a React synthetic event, which at that point is actually... you know, there's an addEventListener to a particular element. At some point that got all wired up and stuff. And so I think for some people it might be kind of eye-opening, like, oh wow, there's all this stuff on the web that I didn't know because I had all these guardrails of my framework.
01:05:15 - Nick
So I'm kind of being hypocritical. For me, I've found it refreshing, but I think it could also confuse some people. I don't mean this in a bad way. I just mean there's a lack of education from existing... people coming out of a boot camp that just know React, for example, is what I meant.
01:05:32 - Anthony Campolo
Well, if you write good docs, though, I found that you can pretty much teach anyone anything if you just take it in the right sequence. So I think that this is a good path because you can get pretty far with it. I would imagine, though, at a certain point, once you start throwing in the serverless functions and stuff, that's not like... it's JavaScript, but that's not the web. That's when you start to get into some of the weirder stuff. And luckily ARC makes it pretty dang simple, though, for the most part. I've never used it with the database.
01:06:04 - Simon MacDonald
The nice thing about Enhance is that the serverless function is pretty much hidden from you. You're writing HTML pages, you're writing web components, and so the serverless function is just underneath the hood. You never really have to touch it. It's only when you want to branch out and do things like a cron job or an event, then you start building serverless functions in your application.
01:06:30 - Anthony Campolo
Sorry, has anyone ever done auth with it?
01:06:32 - Simon MacDonald
Oh yeah. In fact, in the Begin CLI we have a number of generators, and one of the generators is auth. And so currently we're supporting OAuth and Magic Link. And so we basically set you up with a bunch of boilerplate code that you can tweak.
01:06:50 - Anthony Campolo
But yeah, is that using Cognito?
01:06:54 - Simon MacDonald
So the OAuth, you would basically set up some environment variables to point to your OAuth provider. With the Magic Link, we create everything for you and then we fire an event which gives you the magic link in the event. But then it's up to you how you're going to get that magic link to your user. Probably you're going to send it via an email at that point.
01:07:15 - Anthony Campolo
So in both cases, are you just running other AWS services but adding in that kind of functionality yourself?
01:07:24 - Simon MacDonald
We don't even need to hit other AWS services at that point in time.
01:07:28 - Anthony Campolo
So you're reaching out to a non-AWS service. Like, where is the OAuth thing?
01:07:32 - Simon MacDonald
Well, the OAuth, it depends on where you want to set it up. So if you wanted to set up an OAuth app on GitHub in order to authenticate your application, you could do that.
01:07:40 - Anthony Campolo
But if you wanted to pull it off from somewhere else...
01:07:43 - Simon MacDonald
Yeah, gotcha.
01:07:44 - Anthony Campolo
Yeah.
01:07:45 - Scott Steinlage
Cool.
01:07:46 - Anthony Campolo
Yeah, I was just curious. I feel like there would be ways to do that with AWS, but that's...
01:07:51 - Simon MacDonald
Oh, there definitely is. Yeah, there's multiple ways to do that with AWS, which is the beauty and the curse of AWS, as we discussed.
01:08:06 - Scott Steinlage
Very true.
01:08:07 - Simon MacDonald
Something that I think Nick was just saying a couple of minutes ago was that from a beginner's perspective, it's nice. And when I look at Enhance, I always tell people that the two groups that we're trying to target are, A, the people who are just getting started with web development, that hopefully we can teach them web standards and they can have a long and fruitful career, and then the other folks that we're trying to target are old graybeards like me who have grown up with the web and have been building on it for a long time, and we've noticed that it's gotten really overly complicated at this point in time. And especially, in my opinion, we've over-indexed on making the developer experience better at the expense of making the user experience worse. That is: I couldn't buy a pair of pants. So we can build these wonderful applications just by pulling in this framework, but we really end up punishing the users in that way. And we're hoping that this becomes like a pincer movement, and as these two groups grow, they'll eventually get the people in the middle to start taking a look at this HTML-first approach as well.
01:09:13 - Simon MacDonald
And we don't even care if it's Enhance. If you want to use another project, that's great. We just love the web.
01:09:20 - Scott Steinlage
Yes, absolutely. I do love it. I really, really, really do. I mean, even, you know, like you say, if you want to use another one... something like Astro or whatever, they're HTML-first too, as well. So I was just thinking, maybe... I'm just pushing this out there again. But it's like, you guys said that... maybe... Nick, you're just kind of playing devil's advocate, or whatever you call it, where you were saying...
01:09:57 - Scott Steinlage
People who have maybe started using React first and they're stuck in this framework, essentially, and then they go and use something like Enhance and now they're like, wait, what? Like, oh, you have to put an event listener in here and then over here, and then now you have this click here that happens. And it's like, oh, okay. And now they're relearning stuff, I guess. Right? But I mean, me personally, I don't have a ton of experience coding, not like some amazing developer by any means. But I would say that honestly, I don't know if it's just the way my brain works, but I love to break things down and learn, like, why is this working this way? Why is this doing that? So really, when I see something like Enhance, it actually really excites me to be able to add on. Because when I would do a project, say something simple, like I was just building out my own profile or something on a website, I would start, obviously, with HTML, CSS, and then as I'm building this out I'd say, oh, you know what? Actually, I want to add this feature, right?
01:11:24 - Scott Steinlage
I want to do this thing. And then I would have to discover, okay, well, that's going to require some JavaScript to actually... and so then I would look into how you would do that with JavaScript. Right? And so it's very similar to using Enhance and progressively increasing that. So I don't know. For me personally, I really do like that model that Astro and Enhance use.
01:11:52 - Simon MacDonald
Yeah. And I mean, the hockey app that I talked about earlier, I took it as a challenge. I was like, I'm going to build this with as close to zero JavaScript as possible. And it's kind of a challenge to myself. Instead of reaching for various things, like, let me use buttons, let me use forms, let me use these HTML elements, and let's just have them do what they're supposed to do. And I built this multi-page application which manages players, games, spares, sends... none of the UI on the client side has any JavaScript whatsoever. I was like, what? How did I do that? It was pretty wild. Right down to the mobile menu with the hamburger. You click that, it's like, I don't need JavaScript to show and hide that menu. I can use a checkbox in CSS to show and hide that menu. It's just wild what we can do now.
01:12:47 - Scott Steinlage
Yeah. And that's interesting you say that because, and I just want to build on that, there's a lot of people that know some CSS, and then there's also several people that actually start to kind of have your mindset and say, oh, you know what? I want to discover how to do this in CSS. Can CSS do this? Right? And then they start to create more and more things or come up with ad hoc ways of doing things, interestingly enough. And sometimes it's the right thing to do, other times maybe there might be a better way to do it. But yeah, I mean, I love doing that. That's how I learned more advanced CSS things that not everybody messes with, like animations and all these other things, right? It's by getting in and digging in like that and not just going to the next framework that's going to help me do it with a simple script or something like that.
01:13:42 - Simon MacDonald
Yeah, exactly. Because sometimes when you reach for that framework, you're opting into a lot more JavaScript than you're ever going to need in order to do the very simple thing that you want to do. Back in the day, when I used to do a lot of mobile web development on a different project, I used to get people mad at me because I would tell them, do not put jQuery into this mobile web application. It was 280 kilobytes of JavaScript, and on a low-end Android device that would absolutely kill the device. And all people were actually using it for was the dollar-sign selector. And it's like, okay, but you can just use document.querySelectorAll, which is available in all of the mobile browsers, so you don't need jQuery. And people are like, you hate jQuery. And I'm like, no, I don't hate jQuery. I think jQuery is awesome. I think it makes a lot of sense on the client, or on the desktop side, where we had a lot of different browsers that we had to smooth over the inconsistencies. But with Android and iOS, they were basically running off the same source for the web browser, so you didn't need to worry about it so much.
01:14:50 - Simon MacDonald
So it was something you could opt out of. And that's something that I think we've missed a little bit in the web over the past 10 years, is as the platform gets better, the pieces of framework that duplicate the platform are supposed to get dropped in favor of the platform, but it seems like we just keep on adding to the frameworks instead.
01:15:14 - Nick
Yeah, that's a good point, Simon. And I mean, speaking of jQuery, jQuery is a perfect example of something that was built that kind of had itself... I know it's still across the web a lot, but we have querySelectorAll and querySelector to thank because of jQuery. So that literally got baked into the platform. It's just so prevalent still, jQuery. But yeah, there's other things, like you said, that they could just... and the thing is, if you do it at the framework level, like, hey, we no longer need to do this because the platform supports it, you do the cleanup in the framework and then everybody gets that benefit, and they might not even have to do anything about it if they're using that particular framework. But it's... I don't know. We've talked about this before, but I think it's a really great time to be a web dev right now. I mean, I've been excited about the web forever. But even, Scott, you were mentioning about the amount of tooling and stuff.
01:16:19 - Nick
I still have found it all exciting. I know people have had JavaScript fatigue, framework fatigue, but it's still exciting because at least nowadays you see a lot of the frameworks riffing off of each other too, which is nice to see. I mean, I'm generalizing, but I think the general ethos of what I've seen in a lot of the frameworks is there. Astro's talking, Solid... I know Enhance has spoken with my coworker Zach, who works on Eleventy. There's just a lot of cross-pollination going on. So there's just a lot of good stuff happening, I think, on the web. I didn't really have a point to this aside from just saying it's pretty awesome to be a web dev.
01:17:08 - Simon MacDonald
Yeah, it sure is. And I can't wait till the first framework that is built off the ideas that Enhance came up with comes out, and I'll be like, oh, that's validation. I love that. And then we'll learn from them and add that kind of functionality into Enhance as well.
01:17:28 - Scott Steinlage
Yeah, I mean, just the amount, like you're saying, Nick, I mean the amount of people that are coming together and, like you said, kind of riffing off each other and building off each other and collaborating, right? That's the beautiful thing here, is there's always been a very big community factor in development, right, and working together, even with a lot of competition still in the market. Which is great because that inspires newer, bigger, better, faster things. There's still a lot of collaboration, which is superb. I love that. So it's definitely one of the cool things about being in development, and that is really exciting, is the collaborative effect of it all. Awesome. Well, we don't have to go a full 30 minutes over, but if other people do have any questions, concerns, opinions, things that they want to state, topics regarding things around what we've been talking about here, web development, JavaScript, please feel free. Request to come up. We want to hear from you and we'll bring you up and we can continue the conversation.
01:19:07 - Simon MacDonald
It would be great to hear from anybody else in the audience, but if people don't feel like talking in this public forum, they can always hit me up @mcdonaldst on Twitter. If you want to ask me a question after this session, I'd be more than happy to hear from you and hear your comments or your questions or, if you've got a problem with Enhance, I definitely want to hear about it because we're always looking for ways to make things better.
01:19:32 - Scott Steinlage
Absolutely. So there you go. Give them the best way to connect. Number one, DMs, it sounds like. Any other way that they can connect with you, or any other links you want to shout out?
01:19:46 - Simon MacDonald
I think probably the most important one is enhance.dev, which is the website where you can read all about Enhance, all of our documentation. Also, you might want to follow blog.begin.com. I'm kind of working on something that'll be called the 12 Days of Enhance. So over the holidays, I'm just going to release very small, bite-sized blog posts that will help you go from zero to a deployed Begin application by the end of the 12 days.
01:20:17 - Scott Steinlage
Nice. That's awesome. Yeah, that kind of reminds me of what a lot of people are doing, like the Advent thing, right?
01:20:26 - Simon MacDonald
Yeah, the Advent of Code, right? Yeah. I once did this back in the day when I was working on the PhoneGap project. I did the 12 Days of PhoneGap and people found it pretty good. So I'm rehashing old ideas because why not?
01:20:42 - Scott Steinlage
Absolutely. No, I love it. That's cool. Yeah, I'd like to see it. Maybe I'll try and go through it. That'd be awesome. So, blog.begin.com. Okay, yeah, check it out, folks. And obviously check out enhance.dev, all the lovely docs there for you guys. And yeah, try it out. See if you like it.
01:21:08 - Simon MacDonald
Yeah, tell us how wrong we are. I mean, if it doesn't make sense to you, I want to hear about it. I love when people complain because I am a negative person and I love to hear complaints, because then I know that you really care enough to complain, and I would love to make the product better.
01:21:23 - Scott Steinlage
So there you go, 100%. All right, Anthony, you have anything else to say?
01:21:33 - Anthony Campolo
Yeah, I'll be curious to check it out and see what it's like. I've already seen it on a bunch of streams, and yeah, it's a good reason to dive into web components for me for sure.
01:21:44 - Scott Steinlage
Lots of talk about it. I'm sure there's lots of people trying it, and I'm excited to see the advancement of it, sure. Thank you so much, Simon, for joining us today, man. I really appreciate all the time that you've given us here today. It was definitely valuable for me and I really had a great time listening to everything you guys are talking about and partaking in this. By the way, folks, if you got value from Simon or anybody else that came up here on stage, please feel free to click on their image there and follow them. Because if you got value from them here, guess what? You're probably going to get value from them elsewhere too. So yeah, do that. And then Enhance is at @enhance_dev. That is their Twitter profile there. Begin is... I think it's just @begin, or am I wrong?
01:22:38 - Simon MacDonald
No, you're correct. It's just @begin.
01:22:40 - Scott Steinlage
Right? Okay, cool. And then yeah, if you want to give JavaScript Jam a little follow too, we would love that because we will continue to have more people on here and in the future. In fact, actually next week we're going to be having our dear friends over at Uniform. Tim Benniks is going to be joining us next Wednesday at 12:00 PM Pacific Standard Time. So feel free to join us then as well, and we look forward to it. Simon, thank you so much again, man. Appreciate you. Thank you to everybody coming in here and joining us and listening in and speaking as well. Nick, thank you for coming up, dude. Appreciate it. Anthony, thanks for helping co-host. And Ishan, who is now gone, thank you for all the wonderful conversation and co-hosting as well. And to our regulars, B. Ro, Nifty, Brad, Matt, thank you all. And Paul, I think I've seen you in here a few times, but thanks for coming, dude. That's all who's here right now. Thank you all so much. Appreciate it.
01:23:48 - Simon MacDonald
I just want to say thank you so much for having me on. I really appreciate the opportunity to speak with everyone. And yeah, have a great holiday if I'm not chatting with you people before then.
01:23:59 - Scott Steinlage
Absolutely. Let's give a big round of applause, some hands, some hearts, some love to Simon, Enhance. All right, thank you all so much. And we'll see y'all in the next one.
01:24:29 - Anthony Campolo
Yeah.
01:24:32 - Scott Steinlage
All right, y'all, I'll see you in the next one. Peace.