Simon MacDonald: [00:00:00] So I’m here today to talk to you about server side rendering web components and we’re gonna get into that. Unfortunately, we’re gonna have to do some background information first in order to get to there, but we’ll build up to it. As John said, I’m Simon McDonald. I am the head of developer experience at Begin.
If you need to get in touch with me after this talk please hit me up at Mastodon. That’s the the link for my Mastodon account. You could probably find me on Twitter. I still have a Twitter account, but it’s getting scary over there, so Mastodons probably the best way to get ahold of me.
Anyhow, I’m gonna start off my talk by asking a very silly question. Have you ever had a dependency break on. Okay. Yeah it’s a stupid question. Dependencies are unstable and they could be a time sink, and this kind of unplanned work keeps you from iterating on your product and it’s really frustrating.
I realized when I was putting together this slide that I was thinking in, that office space came out in 2006 or 2007. But in actuality it was [00:01:00] 1999 and that was. Check my math 23 years ago, which is scary. So some of you may not know about this movie or may not even been born then, which is scary to me.
But it’s a classic movie about tech workers and a cube farm. And if you get nothing else outta this talk, at least you got one really good movie recommendation. So try and remember that. There’s a really good quote here from Jeff Bezos and people ask him all the time, what’s gonna change in the next 10 years?
How do we prepare for this stuff? But the thing that they rarely ask is, what’s not gonna change in 10 years? What’s gonna be stable? and he thinks that the second question is way more important because the things that are stable, you can build a business, you can build a strategy around, and I would argue the same thing.
It’s way easier to predict the things that aren’t gonna change over the next couple of years. And that’s what you can really use to build your business on top of. Why do we want to build businesses ontop on top of things that don’t change? It’s because, software is really complicated and it is certainly [00:02:00] not made less complicated by adding a lot of dependencies to your software.
Arguably it’s made way worse because these dependencies often conflict with one another, and that can be a huge pain. Now we’ve seen this kind of thrash before. Web browsers used to be very broken. The browser ecosystem used to change all of the time. It was not uncommon for these different browsers to interpret capabilities differently.
And therefore they would break different websites. You know what I’m looking at this slide here. It’s a little bit outta date, so lemme just fix it really quick. Yeah, okay. That’s a little bit more accurate. Even though Apple is making a lot of noise about 2023 being the year of Safari, and I really hope that they do fix a lot of things in their browser.
But I’m a little skeptical because they do have a, a monetary reason not to make their web browser better, but, we have hope. But. Why browsers really don’t break. When it comes down to it, the web standards that we have evolved to now give [00:03:00] you consistent behavior right across a bunch of different browsers, as long as you, those standards are implemented in which they are in most cases and the browsers automatically update themselves so that they are evergreen.
You never have to worry about them being like terribly be behind. And in order to remain competitive in the browser marketplace, they have to maintain this backwards compatibility. So you know that these things are gonna be working at all times. So web browsers are backwards compatible. A so yeah, in case you didn’t notice, I’m Canadian.
I was really gonna prove it. I think there’s a lot of Canadians here today, which is great. We are infiltrating everywhere anyway. What we really mean by this backwards compatibility is that if you look at sites and code that were written over 25 years ago, you’ll see that they still work perfectly well in today’s modern browsers.
One example of this is jQuery. So jQuery was used in many sites in order to, Smooth over a lot of the differences that existed in these browsers. And over time as the browsers became more [00:04:00] and more standard compliant, we didn’t really need jQuery anymore. So we were able to drop that functionality and use what was in the platform.
But if you have a site that was written in 2003, it’ll still work even with an old version of jQuery, cuz the browsers will take care of that for. So we have to ask ourselves if the browsers can be that stable, can our own source code be that stable as well? And I would posit that breaking changes are optional.
Unfortunately, we tend to eagerly opt into them. Just because, you’re picking a framework that compiles to a web standard, it doesn’t mean that you’re enjoying those web standards. So you might wanna think about that just a little bit more. So when it comes to changes, there’s, two kinds of change.
And of course the answer to my previous question is, yeah, of course we can opt into things so that our service code doesn’t break and it’s very stable. But there are two kinds of changes that we have to look out for. The first, the bad one is breaking changes. That’s [00:05:00] when we see the removal of APIs or interfaces or behaviors.
And of course, in some cases if you are removing something because it’s a security issue, then that makes perfect sense to get rid of it. But some, a lot of times there’s. Breaking changes are for the sake of being a breaking change. Many times the package is handling things using sim correctly.
Updating a major, introducing breaking changes is good. Updating a minor or a patch and introducing major changes is bad. Cuz that is not the way that is supposed to work. Those of us that had been around long enough, probably remember the giant breaking change from going from Angular one to two was a complete rewrite of your application.
And then they did it to us again in a later version of Angular. And I think a lot of people were, burnt too many times there and moved on to other platforms. React 18 has some breaking changes in it as well. It’s handling it quite well because it’s breaking things on a major. One of these things includes the way that they do updates.
They’re batched. And of course TypeScript 4.8, which is a minor update, also included [00:06:00] breaking changes, which is not really what you wanna see. You want those changes to be introduced on majors. So if you’re generally following SIM and you’re seeing like, oh, TypeScript 4.8 is out, I’ll just upgrade it because.
It’s only a minor change. It shouldn’t have any breaking issues. And there you go. It introduces breaking changes on you and you’ve got a whole bunch of unplanned work because of it. So you really wanna pick dependencies and frameworks that properly handle these changes for you and make sure that they’re using SIM properly.
The other kind of change or the good change as the additive change, and it’s just that it adds any, it adds new functionality without removing any of the old stuff. So the change from HDP one to two is, is great. It gives us new capabilities, but doesn’t break any of the old protocol. When we were back doing XML HTP requests, our AJA stuff and that was like a pretty good API I to start with, but we’ve refined it into fetch and that’s a much better a p i for developer ergonomics.
Anyway. . These are all examples of additive changes that have been added into the platform without breaking anything else, and that’s just. . Now, the front end itself is also very complicated. . Yeah, it’s a, the front end is this vast ecosystem that has many compatibility problems, so it’s very common for you to transpire code.
Okay, let’s take a look at some of the compilers. All right. The problem with ERs is that the obfuscated, the runtime code it’s bad and it gets worse. You take a look at this code example that’s not very readable. Any kind of bugging in this will be extremely hard to diagnose, and you’re not sure where things are coming from because this isn’t the code you wrote.
It has no bearing on the code that you actually wrote. now a 12,000 line of code. File is totally normal for a trivial bundle, and that’s not very efficient and it’s really terrible developer experience for you to debug. Lots of people will think that, object source maps will fix this problem, but quite often they don’t work.
And [00:10:00] especially when you’re, doing things in an environment like no js, which is not filled for this type of thing. And then of course when you introduce something like a transf step, do you even really know what your tools are doing? You’re really just counting on them to do the right thing for you.
How is that optimizing code for you? How, why is that better? I don’t understand. It saves me typing for characters, but I would argue that having to go through this every time I need to call something that is in the platform is probably a bad idea that’s gonna add overhead anyway. So [00:11:00] check what your tools are doing folks.
What can we get rid of? , can we simplify this situation? What are the root causes of the complexity? How do we avoid this kind of stuff? And one of the ways that we can avoid this [00:12:00] is by going back to the way webpages and websites were previously written. We have a new case for progressive enhancement.
And progressive enhancement went outta style. But we really should bring it back and think about it more because there are many reasons. First, the ethical reason. For inclusivity, we want as many people as possible to be using our websites and applications. And when you build with progressive enhancement, when you start with a working HTML format, it is the most accessible application that you could start with.
Now, of course, there’s also business reasons as well if you need to make that argument. The bigger your audience the more devices, the more people who can use it, the more money that they will generally spend on your products or services. And then there’s the selfish [00:13:00] developer reason as well.
I hate fixing broken stuff. I like it when stuff works. So if I have some way that it’s gonna work for, screen readers, it’s gonna work for old web browsers, it’s gonna work for the evergreen web browsers, it’s gonna work, on some sort of new device that’s coming out that is a virtual voice assistant or something like that.
That will make your life a lot better. Now there’s a lot of next generation front-end frameworks that are HTML first 11, which I think there is a talk on tomorrow remix Astro. All of these[00:15:00] these frameworks are looking at doing HTML first. And I would say that HT m L first is the new marketing way of saying progressive enhancement because as I mentioned earlier, somehow progressive enhancement.
Bad reputation that went out of style, not that it ever should have. So you could look at any of these frameworks and see how they’re doing things as well. For us at begin we’ve had this opensource project since 2017. We’ve had, tens of thousands of apps built on top of it and.
We’ve been doing this for at least five, almost six years now, and some of the things that we learned about that and inferred what we would be doing later with the enhanced framework, which I will talk about shortly. [00:16:00] So what if the entire backend was just pure cloud functions?
So architect, the opensource project is mostly concerned with the backend. So it’s responsible for saying instead of balancing or low balancing a whole bunch of web servers, let’s just make all of the backend things like small cloud functions that we can manage using architect.
It’s been working pretty amazing so far. . Now with the modern JS ecosystem, we’ve got some major problems. First it’s brittle. The, it’s, you got these ecosystems that are incompatible with each other and they often are failing. We also had these non-standard template libraries or worse, and opaque programming languages that we have to add on top of things.
Adding more complexity onto building web applications. And quite often they are static, so not dynamic. You’re not getting the content that the user is wanting for right from the very beginning. [00:17:00] And it results in all of these kind of, spinners and skeleton screens and really bad metrics on your time to first interaction.
Use the platform . Like I said earlier, back in the day we used to use jQuery for everything. But now we rarely need to reach for it since the most important parts [00:18:00] of jQuery have become part of the platform. I mean it made it so much easier to do query selectors in jQuery. But now we have query selector all built into the platform and it is because of the popularity of jQuery that we have those things.
We have web components and web components is a suite of different technologies that allows you to create reasonable custom elements and utilize them in your web applications. So these. Custom elements are all encapsulated away from the rest of your code. So all of the styling and the behavior can be, just encapsulated into a single file so that you can reuse it in different projects and it doesn’t affect other parts of your application as well.
There’s three main [00:19:00] specifications that are used when you’re building web components. The first is the custom elements. It basically allows you to define a new tag that represents your reusable component. We have the shadow dom, which allows you to encapsulate your styles and your dom away from the rest of your application so that it doesn’t affect things.
And we use things like slots and templates in order to be able to compose components out of other components. So you can really get granular and have some very small leaf components that you build up together into a giant tree. So web components are, amazingly enough. I think somebody said earlier today that, react is about to have its 10th birthday in or late 20 or mid 2023.
Web components has already had its 10th birthday because it’s been out since 2012. The difference is it was an evolving standard and for many years I. Wouldn’t say that it was ready for primetime, but we’ve really reached a point now where web components are available across all of the [00:20:00] effort green browsers, and there’s no reason not to use them right now.
That custom element. So you’ll get this kind of white box and then it will flash into what it actually should look like. And that’s called the flash of one style. Custom element. So those are a couple of things that you have to be aware of when you’re dealing with web components that there are common problems.
So the fun thing about Enhance is that we’re gonna be able to, you write your web component as a pure cloud function using enhance, and then it is expanded on the server. So we are actually will go through and figure out what actually needs to be as part of the web component, send it down the wire so that when the initial H G M L is loaded, For the browser, that, that custom element, we don’t have to worry about the defined thing because all of the all of the HTML insider has already expanded.
I’m gonna see what, the weather is for my particular area because I already know that stuff before it gets to the server. And that’s also gonna help your metrics for your time to first. Interactive is gonna be a lot quicker. Your time to first. Content full paint is gonna be better as well because the data is already there in the HTML.
All right. I have already created a sample enhanced application, and I’ve done that because nobody wants to see N P M install running. That’s not a good use of your [00:24:00] time. In the enhanced application, we have a couple of things. Under the app folder, we have our APIs, our elements, our models, and our pages.
So basically anytime that you hit a page For instance, the conferences page, it will look for a corresponding api to call as well. So it will call the conferences API wrote, get the data for you, pass it onto your page, which can then be used in your elements, which are part of your page. I think the really, the best way to show this kind of stuff is to start with building up a page.
All right, so let’s just start with let’s call it about html. And so we have our brand new page here, and let me just grab some code from the other side of my screen because I am one of the world’s worst typers. I will spend I think 33% of my time hitting the backspace key alright. So we’re just gonna have this HTML fragment.
We have a section, we have a header one we’ve got a boat, me, and then we’ve got this custom element called social link. So if we take a [00:25:00] look at that in the browser. . If we go to our about page we can see that we have that title is there, and if we open up that section, we can see there is social links.
Hey the browser knows that there’s a custom element, but since there’s no definition for it, it’s just not showing anything at all. All right, so let’s fix that. We’re gonna go over into our elements folder and we’re gonna create a new a new file. And it’s, see how I can’t type, always call it social links.
Mjs. And one of the things to note here is that your custom element should have a dash in it. Basically the way that web components work is you can’t give it a one word name because that could conflict with the tags that are already registered in the browser. So that is a requirement when you’re naming your tags.
All right, so I’m just gonna like copy in this pure cloud function here. What is happening? Is when this function gets called we’re gonna take a look in our state to grab our store in our store to [00:26:00] grab our socials, and then we have an unordered list and we’re just gonna map through that unordered list printing out some list items with all of the different socials that we have programmed.
But the problem that we have right now is we have no data. So if we flip over to our API folder and we create a new one called about mjs, so this is our API I route that is gonna be run. When we hit the about HTML page and in this case we can use any of the verbs that we want to since we are gonna be getting the page, we’ll use the get verb, but we support post, put patch, delete, et cetera for your API routes as well.
So we are just gonna return some, Jason [00:27:00] gonna have a socials array, which has all of my different socials. And if I go back over here the hot reload is already taken care of it. So our unordered list is populated with all of the different allies, which is all of the different places you can find me on the interwebs.
and I am terrible at c s, so I’m gonna do something like incredibly ugly. So for our let’s see, for our honor list component, let’s just make the background color red because I am terrible at c s s. [00:28:00] And there we go. One of the things that you’ll notice, With Enhance is that we are hoisting those styles up to the header for you?
It’s called K Fu, and that’s the date. But I realized that, oh yeah, I should probably [00:29:00] add this conference in as well. So let’s just put in the jam dev and let’s see. It’s today. And there we go. All right. So we have these things in, and basically what’s happening is using Enhance, we have run the Scaffold generator, which is a lot like, what you would see in Rubion Rails.
And we’ve created this, CRUD interface for you so that you can create, read, update, delete list your objects, and we’re having all this into a backend database. And in this case, we’re using DynamoDB in order to store all of this data. . So I’m like, oh, actually the date on K Fu is wrong. So let me just go ahead and, whoops.
But in a lot of cases you may find that you don’t even need to progressively enhance these things. And a lot of cases, especially if you’re working for a large multinational corporation and you need to like do these kind of one-off things, you may want something like this instead of having to get into way more complicated code.
Any kind of reusable components you want could be done using custom elements, using your web components. We have this built in c s utility class thing called enhanced styles. You can use it you can pull in your own type of c s if you want, or you can even add tailwind in.
But we give you a default way of doing utility based CSS to start with. I know that [00:31:00] is. A topic that not everybody loves. And then of course the API route that I showed you you don’t have to worry about passing in these props to ivory component any, anything that is at that route. In this case, we use the about page.
And underneath the hood we’re using architect to deploy this thing. We’re using AW s to run your cloud functions [00:32:00] DynamoDB in order to be able to do your database. So it’s a fully functional web app. So it has your infrastructure as code. It has your cloud database that is completely managed.
Everything is pretty much being done for you. So with enhanced.dev, we are doing a pretty good job of bringing together both the front end and the back end. They can really agree upon things in this situ. Now if you want some more information on this, I think the best thing to do is to check out, enhance you can read the docs at enhance dot dev slash docs.
You can join our Discord and ask us questions. We’re happy to hear from them. And of course, follow us on Mastodon not Twitter because it’s a terrible accessible now. So anyway, that’s that’s pretty much where I’ve got on this talk. Please let me know what questions you.
Sean C Davis: Thanks Simon. I love that presentation. I have so many questions and we really only have a few minutes, and so just a reminder to you folks in the audience, if you do have a question, click [00:33:00] that, add a question link at the bottom of your screen, add your question there, and we will try to get to it in the next few minutes.
Now, I’ve got this long list, so I’m gonna jump right in. So at the, at JM Dev we’re often talking about JAMstack and different trends and JAMstack, and I know that folks are generally we’re still holding on in some ways to the more traditional static site generators, but we’re seeing more server side rendered content.
And so I imagine a lot of folks are watching your presentation and thinking, is it just, is it like exclusively ssr. Are, can, do you have an option to pre-runner content with enhance is that in the works or you’ve solely focused on the server? .
Simon MacDonald: Yeah we’re exclusively focused on the server side rendering piece.
One of the things that I neglected to show is that there is a public bucket, which basically ends up mapping to an N S3 bucket. So if you wanted to run a process outside of enhanced that would populate that bucket with your static site generated content, you can definitely do that. One of the [00:34:00] traditional.
Things that I’ve seen people use JAMstack for is reading a bunch of markdown files and converting them into HTML and storing that in your bucket. We’ve had a lot of success with actually. Just automatically generating that HTML on the fly. It does not take very long at all. Enhanced.dev itself is done using that.
All of the documentation it’s an open service project. You can see how we did it. We’ve written articles on it. Before as well. There’s not really a performance penalty on that. And one of the nice things about rendering things this way is that if you have to insert any kind of dynamic content or personalization based upon the user that’s logged in you can query that on the server side and send it down the wire with the initial page load and not have to wait for another API call to be done after the fact.
And, It’s where this stuff fits into the new definition of JAMstack because there’s no one right way to do it anymore, eh?
Sean C Davis: Exactly. So I imagine that you’re gonna be able to [00:35:00] use this in conjunction with begin, but what about a lot of those other cloud providers? Can you pretty much deploy an enhance application anywhere?
Simon MacDonald: Right now the enhanced applications are deployable to aws. It’s based upon architect is the underlying functionality for it. So we’re gonna give you the best experience possible on begin to be able to deploy to our infrastructure. But. If you do not feel like using begin, you can use architect to deploy directly to aws.
And of course, if you are really feeling like you wanna manage it all yourself, you can eject from architect and deploy directly to AWS as well. In that case, you’ve gotta manage a lot of, cloud, cloud formation stuff yourself. And I do not recommend that. You definitely wanna use a tool to do your infrastructure as code because you.
10, 10 lines in an architect file where you have a maybe five API calls, a static bucket ends up being Yeah. 1400 lines of cloud formation. And you don’t wanna write that. That’s just terrible.
Sean C Davis: Yeah. A case where the using the [00:36:00] abstraction layer Totally. Okay. Yeah,
Simon MacDonald: exactly.
Sean C Davis: Okay, so I also noticed that there were a handful of mjs files in the project.
And I know this is very, , very polarizing topic, but I’m curious about your opinion and enhances opinion on type script. Is that something that you have native support for? Do you feel like that kind of goes against the idea of getting back to the basics using native libraries,
Simon MacDonald: et cetera?
And so you don’t have to worry about doing all the translation and stuff like that.
Sean C Davis: That makes sense. Yeah. Yeah. Now in the chat a little while ago we had a message looking back here from Anri, and he mentioned that he profiled the, oh, it was the CBS sports website and said that they’re currently running Jary version 1.8 0.3, which was launched all the way back in November, 2012.
And I, I really loved the beginning of your, where you had the quote from Jeff Bezos on, what isn’t going to change in the next 10 years? And getting back to, what really focusing on what is going to be stable. And so I’m just curious kind of from a general perspective, do you see it as bad [00:38:00] practice to use old libraries?
If jQuery still works, is that okay to still use, how do we balance that with all the new shiny stuff that’s. .
Simon MacDonald: Yeah I don’t have any problem with using jQuery. My recommendation in that particular qua case would be to stop using it because a lot of the things that were in jQuery have ended up in the platform.
We’ll see what happens. But the nice thing is like if started a business 10 years ago building WordPress and using jQuery you’re still making a lot of money doing that right now. It may not be sexy. It may not be the most technically difficult thing, but you’re still making a living [00:39:00] on it because, The platform isn’t breaking on you.
And if you started five years ago or seven years ago using React, and you decided that you went from create element to JSX, to hooks, to whatever is the new thing, like every, every 18 months or so, react kind of reinvents itself and you’re chasing those changes nonstop and you have to ask yourself.
Did I just waste a lot of time that I could have been, building functionality for my customers and making money instead of just chasing these unplanned outages. Anyway, I try not to slack and react too much. I used it for many years, but I think I have seen the light.
Sean C Davis: Yes to. Totally fair.
Totally fair. Now there are mixed opinions on this, but you mentioned web components had their 10th birthday already. And I felt like there was a lot of noise in the first couple years and then, fell off for a while. React got super popular and really still is, but really within the [00:40:00] last six to 12 months, personally, I have seen a lot more noise around web components in this space.
And and I know that you are betting on it. I think I’m curious on your perspective of, so you’re, you seeing some trend that. I guess what I’m trying to ask is are you seeing this approach resonate with folks? Do you feel like we’re gonna start to see some other frameworks pop up as well?
Is this a trend that we’re seeing getting back to the basics?
Simon MacDonald: I totally believe that. We see things like not just enhance, but astro 11 with Web C also using web components. You’ve got major companies like Google has built YouTube using web components. Adobe has built all of their creative cloud web stuff using web components.
It’s ready for primetime right now. When it was initially. The problem is when it was initially announced, it was a spec that was still evolving and it wasn’t quite ready yet. And when it comes to the evolution of specs, it takes a while before these [00:41:00] things actually solidify and get all of the use cases.
That’s where client side libraries are super useful because. They’re able to iterate rather quickly. So jQuery is an example. It iterated quickly and eventually those things added up in the platform. Phone gap, Apache Cordova on the mobile side, they implemented a bunch of the the APIs for connecting to the camera and other mobile APIs that eventually made their way into the platform.
And why. Some of the things that react and view and Angular are done migrating into the platform or being replaced with what the platform already has available, and that’s web components. So I think you’ll see a lot of people starting to switch in that direction.
Sean C Davis: That makes a lot of sense.
Yeah. I’m gonna keep an eye on it cuz this is I just, I love the concept of getting back to the basics using native libraries and I’m really excited for what you’ve got going on at Enhance. Now, one last kind of off topic question from the audience before we wrap up. It’s from Brian and says, when will the [00:42:00] HEBs finally, when another Stanley.
Simon MacDonald: I feel and I know this is coming from Brian LaRue, so the Habs will defeat the hapless Vancouver Connects in 2027. That’s my rock solid guarantee. Okay. That’s,
Sean C Davis: that’s the prediction for you folks. So yeah, , keep keep it ben eye. I can’t,
Simon MacDonald: I can’t back that up. .
Sean C Davis: That’s all right. I love it.