Mini ep 6/30/23
===

Emily: [00:00:00] Happy Friday developers. Today is June 30th, 2023, and welcome back to our Roundup episode where you can catch up on episodes you missed, or get a quick rundown of the past two weeks from Pod Rocket. So let's get started. 

Last Friday we welcomed on Jeff Rich, one of the Mainers of Sphe 

Who came on to introduce S Felt's newest release? Sphe four.

Geof: Let's just jump right into it. Sphe four launch today.

It's been, I think four years coming since Sphe three. Yeah. So I'm really curious about the kind of mindset that you guys had. It's been a long time and I know this is not going to be like a, a massive launch, so I want to preemptively tell that to the audience, but it is a really important launch for the future.

So I wanna cast it off to you to talk about what are the new features installed for, what can we expect? Right. So like you said, this is mainly a, let's get rid of the old cret kind of launch. So spelt three, four years ago, the laws changed in the JavaScript ecosystem since then, and we've learned a [00:01:00] lot working on spelt kit.

Like how we like to work in the spelt repo itself. So some of the biggest changes in this release were behind the scenes, so restructuring this s felt repo in a way that will make sense and really empower us to move faster when it comes time to work on the next version of spelt. As far as large features go, pretty minimal breaking changes.

There are some smaller things with maybe some obscure features, but we really wanted to make this as drop in as possible. Just a no-brainer upgrade. We have increased the minimum versions required. So node 16 is now the standard. You can't use anything before that. Also, increasing versions of Webpack and ve, so those are a lot of the breaking changes you'll encounter.

As far as features go, I would say the main. Like big feature release in this is the custom elements refactor not used by a lot of the spelt community, but there are a core group of people who really rely on this feature, and it's great if you haven't used it before. Custom elements let you take your spelt components and compile them [00:02:00] to a custom element that can be dropped on any page.

Just got self-contained. Web component is another word for it. Um, and that feature really got a overhaul and a redesign just to make it a little bit nicer to work with. So I can go to into that a little bit more if you want. Yeah, absolutely. So the web components thing was really interesting. I was reading about it and before I think there were a few kind of buggy things and I think actions was a big part of just being a pain point of web components.

So can you explain, Not only just like what's been changed, I think we don't need to get into the nitty gritty there. Can you explain the main like focus of web components and a little bit about what we should use them for in the future? For like junior developer out there? What are web components? Why should we care?

Yeah, so I would, I would say it spelt with web components. The main use case for that is if you're trying to. Incrementally migrate your site away. Maybe it's built in some older technology. You want to start using a component framework like S felt, but you don't have time to completely rewrite the whole site from [00:03:00] scratch and S felt kit or whatever with a web component you can compile to this web component and then incrementally move over just parts of your site.

So let's say you have a sidebar. You could turn, just rewrite the sidebars spell component and then compile it to a web component and just drop that in on your preexisting site and not have to, you know, rip out all the guts of your architecture. Yeah, that's a really good explanation actually, I think. I think it is a really useful little feature or not little feature.

It's a pretty big part of maybe even the future of web development. I know. My thought process always goes to what's next for web, what's next in the JavaScript world? And I think web components are one step closer to maybe having a built-in framework right in the browser. Maybe spelt is another step there too.

Emily: Ken see DODs returned to the pod to introduce his newest project to the web development community, the epic stack.

Here, he explains what the epic stack is and why he decided to create it.

kent: The Epic stack, and I'm hinting at, it's a [00:04:00] little bit different than like a basket of four technologies. So what is it in its essence, the epic stack? Totally. First on that basket of four technologies thing, what's interesting about that is as technology evolves, you're unable to. Evolve the tech stack as well because you've pinned your name to the tech that you're using.

So that's why we have all of those different named stacks. But uh, that's why it's, the epic stack doesn't actually stand for anything as far as the technologies that it uses, cuz there are just so many. Technologies you need for an app. So anyway, to summarize the idea, I gave this talk at, uh, remix Comp that described where the idea of Epics stat came from.

So I'd refer anybody to go check out that talk later. But the basic idea is that. First of all, there are a lot of really awesome choices when building web applications these days. And regardless of which you choose, you're probably going to be okay because there aren't really like necessarily bad options.

There are some bad [00:05:00] options for some use cases, but most of the time, like you just throw a dart at a dart dartboard and you'll probably be fine with that technology choice. And so given that the time that you spend. Making decisions on these different technologies is probably not really well spent. And what's interesting is we agonize over this decision a lot, and it's just a really challenging process to go through all of that when we're really just trying to build our apps.

And the primary reason why we agonize over this, even though we all acknowledge all these technologies are great, and we could use any of them and probably be fine, but we still agonize over it because. The fear is that if we make the wrong choice, we're gonna have to dig ourselves out of that wrong choice in the future, or it will just send our company under.

And so the impact of a incorrect choice is really big, even if the likelihood is very low. And so it can be really nice if somebody just comes along and says, Hey, these are the tools and [00:06:00] technologies that worked really well for me, they'll probably work fine for you. So, Skip the whole decision process and jump right into a something like this.

And another really nice benefit of doing that is you can really optimize a lot of things when you know all of the different tools and technologies that you're using. I know I'm gonna be combining these tool tools together, so I'll wire those up and people don't have to worry about doing that themselves.

The Epic stack is basically a project generator and reference implementation, so, For people because people aren't like starting new projects all the time. So it's also very much useful as a reference for people to get going really quickly and not be so concerned about which technologies to choose, because whatever you choose, it'd probably be fine.

Um, it's based on the apps that I have built and shipped from. Small app internal applications at big and small companies to consumer facing applications that are shipped to millions of users all over the world every day. So I've had a really [00:07:00] broad range of experience. I am up to date on the latest technologies and um, I have very well formed opinions about what technologies to use.

So if you want to build apps the way that I build apps, then you can get started with this and you'll be. Off to the races on a really solid foundation. That's the premise. 

Emily: And finally, Mateo Collina, co-founder and C T O of Matic returned as well to talk about modular monoliths and how long running projects run into issues because they're not structured in a scalable, maintainable way. In this clip, Mateo describes the problems that come from this, 

Matteo: I have worked for eight years and a half as a consultant helping companies implement using no js.

What I have noticed is one single pattern. It's most of the problems that teams and and developers have in no JS applications and long running projects. Is that they [00:08:00] structure their project in an unscalable, unmaintainable way. Essentially, they end up developing their code in more or less in a spaghetti bold fashion.

Why? The key problem is that, and sorry, putting the things on express, the original express tutorial at event express generator creates an application and treats it as a singleton. Running inside your process. And more importantly than that, it has all the bootstrapping of that application done, more or less synchronously along the way for those of us who maybe didn't go to a computer science school, A singleton?

Yes. So what is a singleton? It's an object that you have only an instance of that object. Ok. Now what it happens is you create your database connection. And store it inside the module that is required everywhere you put your not JS application, the server as an object that's gets loaded and [00:09:00] used everywhere.

And so everything is run via these global ish components that you only have one instance of that. Now, why is this problematic and why Singleton is basically this one of the biggest antipater that you can essentially find everywhere. Because it's very hard to test this, okay? Every time you want to test your application, you need to basically, oh, but I have all these single lessons to tear down and relaunch, and so on and so forth.

Making it your test low, making your test harder to run, and also exposing yourself to all sort of bugs when developing the application. The other problem is that you think that node modules are singletons so that when you do an export or something, it's a singleton. Okay. And you just have that one instance of that specific module.

This is not true. The Nojs ecosystem is built around the concept that you can have two different instance of the same module [00:10:00] loaded from two different paths, and they could potentially contain very similar code or do the similar things and. The moment you define them. In that way, you are clearly defining your code.

Uh oh. I'm never going to take part a chunk of my library and move it inside a module, inside a package that then can be reused somewhere else. What this causes is as a result of this problem, there is the fact, the result of this train of thought is, What you're doing in that express tutorial that you showed at the beginning is essentially doing you at the service because it's actually a very great tutorial.

So you get to learn something very quick, but you're learning something that does not age very well. Okay? And every single person that has built a complex application will tell you that. Now, what is the other complex is whenever you start adding, for example, ORMs, that use the concept [00:11:00] of a global connection.

Then you become even less likely that you'll ever be able to split your application or decouple your application over time as much you add code, everything pass through the same singletons, okay? And you are very quickly not able to split your code anymore. So everything become more or less coupled with each other.

And leads to essentially a big bowl of mud and everything becomes coupled to each other because they all depend on this one instance, this one singleton. Typically, this is part of the biggest problem. Yes. Right. And then you get a giant monolith, and we all know that microservices, or at least we were told that micro the problem is not really about monolith versus microservices.

The problem is about coupling between a different part of your applications. You want the different domains inside your application, the different components, different things that you are built, the parts that are built by different human beings, ultimately, okay? If you have true human being, you probably [00:12:00] want to have them working on two different things, not at the same thing at the same time.

So if you want their two parts to have as minimal interaction as possible. If you do, that's easy to then scale your team and not block everything. But most large JS application has seen a lot, quite a lot. They become hard to maintain because they're not built on top of that stuff. 

Emily: and that's it for today, Friday, June 30th.

You can check out the full episodes linked in our show notes or on our feed, and if you like what you hear, follow Pod Rocket for more great web development content. See you at the next Roundup. This episode was brought to you by Log Rocket. Try it for free today@logrocket.com.