Learn how to choose a fullstack JavaScript framework by asking questions about your web app in a flow chart. If you're crazy enough, you can even build your own JS framework from scratch like me. 

#js #webdevelopment #programming 

🔗 Resources

Flamethrower on GitHub https://github.com/fireship-io/flamethrower
Web Components https://developer.mozilla.org/en-US/docs/Web/Web_Components
JS frameworks comparison https://youtu.be/cuHDQhDhvPE

🔥 Get More Content - Upgrade to PRO

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font

🔖 Topics Covered

- What is a JS framework?
- How to choose a JS framework?
- Top frameworks for web development
- Tools to build a web app
- How to make static sites faster
2024-02-04T05:21:40.753Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
b0d00242-2505-4226-9d01-3271e0d02a42
a1a7691c1b7923db34df2b50a342f45e3437d507a89dae2bc4de7283bb31eb9d
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
JavaScript is a nearly perfect programming language.
The only thing it's missing is a good framework for building websites.
Now I've got a body count like Wilt Chamberlain when it comes to JavaScript frameworks.
I've tried nearly all of them and each one does some nice tricks, but none of them are marriage material.
They all have their trade offs, which I'll explain throughout this video.
So you can understand what drives a developer to the point of madness, where they're left with no choice but to create their own JavaScript framework.
It's alive.
In my case, God told me to do it.
Allow me to introduce you to Holy JS.
Actually, never mind.
Somebody already took that name on MPM.
Let's let's go ahead and pivot to the devil and call it flamethrower.
I think that really captures the essence of JavaScript programming.
Now, at this point, you may be wondering if I'm joking.
The sad reality Gizno.
I did actually create a game changing platform for building blazingly fast, highly interactive experiences on the Jamstack.
I also raised 1,000,000 of dollars for my company, Flamethrower Inc, to hype it up.
I stole 99% of my ideas from other tools, but I'm going to tell you that everything else sucks, give it an MIT license, and then call you out if you try to steal Gillette, so one day I might be as successful as Remix.
Alright.
That part was a joke about some Twitter drama, but what I really wanna teach you in this video is the trade offs between all the different major JavaScript frameworks out there.
Here's the normal flowchart I would go through when choosing a framework for a new project.
The first question to ask is, is the project highly interactive?
Giv.
Like, are you building an app with user authentication with all kinds of data that can be manipulated by the current user?
If the answer is no, it sounds like you're building a regular website, in which jcase, you don't need a JavaScript framework.
Life will be much easier with a static site generator like Hugo or 11ty, and if you do end up needing the script.
You can always drop in something like alpine or petite view, as opposed to a heavyweight framework.
Or an even better option could be Astro, which generates static HTML, but allows you to bring in interactivity from any framework as needed.
Now if you are building a highly interactive app, the next question you might ask is, does it need to be search engine friendly or does it need to render HTML and data on a server?
If the answer is no, then just use your favorite framework to build a single page application.
If you don't need to render content in advance for search bots, then you can focus 100% on the front end UX.
However, if you do need SEO, then your next question will be, how often does the content change.
If it's like a blog where the content doesn't change very often, it sounds like you have a jamstack location.
It typically makes more sense to pre render your content and cache it on a CDN, then allow a JavaScript framework to hydrate it and take over after the initial page load.
Frameworks like Next.
Js Syspeltkit can do this in SSG mode, but you also have tools like Gatsby that are dedicated to this use case, although it's kind of fallen from grace recently.
Now if your content is highly dynamic being constantly changing, then you'll likely need full server side rendering to regenerate the static content on the server whenever a new request comes in.
This is what tools like Next.
Js, Nuxt, and SvelteKit are designed to do.
And if you're not exactly sure how your project is going to evolve, I would default to a full SSR framework.
That gives you a simple framework for choosing the right framework, but things can get a lot more complicated from here.
What I'm building is a platform to host my courses.
This.
It requires user authentication and is highly interactive and also needs to have really good SEO.
The content doesn't change all that often, so that would lead us to the jam the stack option.
I started working on the project with SvelteKit, which is an awesome framework, but is more general purpose and doesn't have a ton of features for content management compared to something like Hugo.
That leads to the question of how do I manage tons of content.
One option is I could stick with Sveltekit and just reimplement all these content management features on my don't get me wrong.
I love reinventing the wheel as much as the next JavaScript developer, but one other issue is that I'm worried these frameworks won't be fast enough when rendering a lot of markdown.
The creator of Eleventy made a good benchmark comparing them.
Option b would be to pay for a headless CMS like Contentful or Sanity, Gmail, but then I have to add another paid service to my stack.
Strapi is another good option that you can self host, but then I have to manage a separate server and database just to manage my content.
What I really want to do is just write all my content and markdown and manage it in a git repository.
GitHub is actually an awesome free content management system for developers, although that's not its intended use.
That line line of thinking takes me back to static site generators, which are the best at handling markdown and templating.
Astro seems like a perfect choice here, but it brings up one other question, which is how do I share data your state between different routes.
On Astro, you'll notice that when you navigate, you get a full page load for each route.
That means the JavaScript reboots, and even if you use something like Nano stores or Svelte stores, the information from the previous route is lost.
It's not like Next.
Js where the client side router takes over and renders the UI with JavaScript on all routes after the initial page load.
This can be a problem if you're managing authentication date with JSON Web Tokens in something like Firebase and want to show the current user up in the navbar along with some data from a database that might update in real time.
So basically, play.
That leads us back to Next.
Js or any other framework that fully hydrates after the initial page load.
There's also new cutting edge frameworks like quick and solid start that could be good options in the future, but I just need to get this project done as ASAP as possible.
And, of course, the most efficient way to do that is to build your own JavaScript framework.
The question that led to this is how do I take a static site and share JavaScript functionality and data between routes with a zero latency on the page transition, and without the need for a framework to take over the entire DOM.
In other words, I want a SPA like router for static sites, and that's basically what I built.
It has 0 dependencies and relies entirely on browser native technology like Fetch.
A long time ago, when I first started working as a web developer, there was a library called Pjax that would asynchronously fetch fragments of HTML from your server and update the DOM rather than do a full page reload.
This approach evolved into a library hold Turbolinks, which is still very popular today and receives more npm downloads than most JavaScript frameworks out there.
The way it works is when you click on a link, it prevents that default behavior, then uses fetch to grab the page you want to navigate to.
It swaps out the body of the page, then updates the head with the delta or changes on the new page.
That means if you already executed JavaScript on the previous page, like a global state management library.
It doesn't need to be re executed on the next page load.
That's really interesting behavior, and I'll explain why in just a minute, but was the main duration for my framework.
Well, actually, it's just a library technically.
The reason I didn't just use Turbolinks is because it's rather large and does a bunch of stuff that I don't really need.
And there's the few special features that I wanted to add to my library to create a truly next gen holistic platform.
One of the biggest things that annoys me about modern web development is that when you're building a big content driven site, 99% of the UI is static HTML that doesn't do anything.
However, the common approach is to take this HTML and manage 100% in a JavaScript framework.
There are some definite benefits to doing that, but it requires all kinds of special tooling, things like virtual DOM, and requires you to stay married to just one framework.
As a polygamist, I demand more for my framework.
We can actually take an entirely different approach that's natively supported in browsers using web components.
A lot of people like to talk shit about web components for various reasons, but basically, it's just a browser API for creating custom elements that encapsulate their own JavaScript and CSS.
There are frameworks dedicated to building web components like Lit and Stencil, but all the major frameworks can compile to web components it as well.
One awesome thing about web components is that you can use them anywhere, like regular HTML elements.
You can even use them in markdown without any extra plugins or dependencies.
On top of that, you can use them between frameworks.
For example, I could build a web component with Svelte and then access it from a React and Angular that.
In my case, web components are awesome because I can use a static site generator, then add interactivity to my templates by simply declaring my custom elements.
Ghent.
It's kind of like the islands architecture where you have islands of interactivity, but one thing to keep in mind is that web components will never be server rendered.
They're only rendered on the client.
Although interestingly, you can project server rendered content in a web component, which I think would be perfectly indexable by search engines.
Now here's where things get really cool.
When you combine web components with the router, they render instantly between route changes.
What I have here is a statically generated site with a counter web component generated by Svelte that gets its data from a Svelte store.
When the router is disabled, it does a full page load and the current count is lost when we go to the next page.
Now if we enable the router, notice how the count data is not lost between route changes, just like a single page application.
Not to mention, the page transition feels much faster for the end user.
In this code base, I have an Eleventy project, inside of which as an extra app directory that contains a Svelte app configured to compile 2 custom elements.
From a development standpoint, the only thing you really need to do differently is define a tag for each component, then you export each component individually.
The last thing I'm doing is starting the flamethrower router by calling it as a function.
The the router has a couple of extra features that you wouldn't find in something like Turbolinks.
For 1, it will find all of the visible links on the page and automatically tell the browser to prefetch them.
The browser will automatically download these pages in the background, so they're ready to render as soon as a user clicks on a link.
That's made possible with prefetch link tags, and I also use the intersection observer API to only prefetch the links that are visible on the screen because those are the ones the user is more likely to click.
In other words, as you scroll down, it will lazily prefetch the links that come into view.
If you wanna see the actual latency between route changes, set log to true, and it will add a timer to every fetch operation.
It should be blazingly fast, like well under a 100 milliseconds.
In addition, I threw in a little bonus feature that takes advantage of the new page transitions API.
This API isn't supported in browsers yet, and you'll need to enable it with a flag, but basically, it allows you to animate natively between page transitions, kind kind of like you would expect in a native mobile app.
As you can see, by default, it does a cross fade animation.
The bottom line though is that this router has allowing me to create my own little meta framework using Svelte compiled to web components, along with Hugo, a static site generator, which gives me awesome CMS features with extremely fast builds with routing that feels like a single page application.
That's pretty much it.
The real question is Who's coming with me?
Who's coming with me?
Who's coming with me?
This is a proven technique and used on big sites like dev 2 with turbo, but currently flamethrower is in meme status, and I wouldn't recommend using it in production Gint till it reaches alpha.
I have the luxury of doing weird experimental stuff like this, but if you're building a serious app for yourself, don't go chasing waterfalls.
Stick to the libraries and frameworks that you're used to, like Next, Sveltekit, Astro, and so on.
Now that I've hyped up my game changing JavaScript framework, my next step is to abandon it, then ask for donations via Open Collective to start an SEO link farm, which is the most reliable way to fund open source.
I've gotta feed my family somehow.
Thanks for watching, and I will see you in the next one.

Speaker 0: JavaScript is a nearly perfect programming language. The only thing it's missing is a good framework for building websites. Now I've got a body count like Wilt Chamberlain when it comes to JavaScript frameworks. I've tried nearly all of them and each one does some nice tricks, but none of them are marriage material. They all have their trade offs, which I'll explain throughout this video.

So you can understand what drives a developer to the point of madness, where they're left with no choice but to create their own JavaScript framework. It's alive. In my case, God told me to do it. Allow me to introduce you to Holy JS. Actually, never mind.

Somebody already took that name on MPM. Let's let's go ahead and pivot to the devil and call it flamethrower. I think that really captures the essence of JavaScript programming. Now, at this point, you may be wondering if I'm joking. The sad reality Gizno.

I did actually create a game changing platform for building blazingly fast, highly interactive experiences on the Jamstack. I also raised 1,000,000 of dollars for my company, Flamethrower Inc, to hype it up. I stole 99% of my ideas from other tools, but I'm going to tell you that everything else sucks, give it an MIT license, and then call you out if you try to steal Gillette, so one day I might be as successful as Remix. Alright. That part was a joke about some Twitter drama, but what I really wanna teach you in this video is the trade offs between all the different major JavaScript frameworks out there.

Here's the normal flowchart I would go through when choosing a framework for a new project. The first question to ask is, is the project highly interactive? Giv. Like, are you building an app with user authentication with all kinds of data that can be manipulated by the current user? If the answer is no, it sounds like you're building a regular website, in which jcase, you don't need a JavaScript framework.

Life will be much easier with a static site generator like Hugo or 11ty, and if you do end up needing the script. You can always drop in something like alpine or petite view, as opposed to a heavyweight framework. Or an even better option could be Astro, which generates static HTML, but allows you to bring in interactivity from any framework as needed. Now if you are building a highly interactive app, the next question you might ask is, does it need to be search engine friendly or does it need to render HTML and data on a server? If the answer is no, then just use your favorite framework to build a single page application.

If you don't need to render content in advance for search bots, then you can focus 100% on the front end UX. However, if you do need SEO, then your next question will be, how often does the content change. If it's like a blog where the content doesn't change very often, it sounds like you have a jamstack location. It typically makes more sense to pre render your content and cache it on a CDN, then allow a JavaScript framework to hydrate it and take over after the initial page load. Frameworks like Next.

Js Syspeltkit can do this in SSG mode, but you also have tools like Gatsby that are dedicated to this use case, although it's kind of fallen from grace recently. Now if your content is highly dynamic being constantly changing, then you'll likely need full server side rendering to regenerate the static content on the server whenever a new request comes in. This is what tools like Next. Js, Nuxt, and SvelteKit are designed to do. And if you're not exactly sure how your project is going to evolve, I would default to a full SSR framework.

That gives you a simple framework for choosing the right framework, but things can get a lot more complicated from here. What I'm building is a platform to host my courses. This. It requires user authentication and is highly interactive and also needs to have really good SEO. The content doesn't change all that often, so that would lead us to the jam the stack option.

I started working on the project with SvelteKit, which is an awesome framework, but is more general purpose and doesn't have a ton of features for content management compared to something like Hugo. That leads to the question of how do I manage tons of content. One option is I could stick with Sveltekit and just reimplement all these content management features on my don't get me wrong. I love reinventing the wheel as much as the next JavaScript developer, but one other issue is that I'm worried these frameworks won't be fast enough when rendering a lot of markdown. The creator of Eleventy made a good benchmark comparing them.

Option b would be to pay for a headless CMS like Contentful or Sanity, Gmail, but then I have to add another paid service to my stack. Strapi is another good option that you can self host, but then I have to manage a separate server and database just to manage my content. What I really want to do is just write all my content and markdown and manage it in a git repository. GitHub is actually an awesome free content management system for developers, although that's not its intended use. That line line of thinking takes me back to static site generators, which are the best at handling markdown and templating.

Astro seems like a perfect choice here, but it brings up one other question, which is how do I share data your state between different routes. On Astro, you'll notice that when you navigate, you get a full page load for each route. That means the JavaScript reboots, and even if you use something like Nano stores or Svelte stores, the information from the previous route is lost. It's not like Next. Js where the client side router takes over and renders the UI with JavaScript on all routes after the initial page load.

This can be a problem if you're managing authentication date with JSON Web Tokens in something like Firebase and want to show the current user up in the navbar along with some data from a database that might update in real time. So basically, play. That leads us back to Next. Js or any other framework that fully hydrates after the initial page load. There's also new cutting edge frameworks like quick and solid start that could be good options in the future, but I just need to get this project done as ASAP as possible.

And, of course, the most efficient way to do that is to build your own JavaScript framework. The question that led to this is how do I take a static site and share JavaScript functionality and data between routes with a zero latency on the page transition, and without the need for a framework to take over the entire DOM. In other words, I want a SPA like router for static sites, and that's basically what I built. It has 0 dependencies and relies entirely on browser native technology like Fetch. A long time ago, when I first started working as a web developer, there was a library called Pjax that would asynchronously fetch fragments of HTML from your server and update the DOM rather than do a full page reload.

This approach evolved into a library hold Turbolinks, which is still very popular today and receives more npm downloads than most JavaScript frameworks out there. The way it works is when you click on a link, it prevents that default behavior, then uses fetch to grab the page you want to navigate to. It swaps out the body of the page, then updates the head with the delta or changes on the new page. That means if you already executed JavaScript on the previous page, like a global state management library. It doesn't need to be re executed on the next page load.

That's really interesting behavior, and I'll explain why in just a minute, but was the main duration for my framework. Well, actually, it's just a library technically. The reason I didn't just use Turbolinks is because it's rather large and does a bunch of stuff that I don't really need. And there's the few special features that I wanted to add to my library to create a truly next gen holistic platform. One of the biggest things that annoys me about modern web development is that when you're building a big content driven site, 99% of the UI is static HTML that doesn't do anything.

However, the common approach is to take this HTML and manage 100% in a JavaScript framework. There are some definite benefits to doing that, but it requires all kinds of special tooling, things like virtual DOM, and requires you to stay married to just one framework. As a polygamist, I demand more for my framework. We can actually take an entirely different approach that's natively supported in browsers using web components. A lot of people like to talk shit about web components for various reasons, but basically, it's just a browser API for creating custom elements that encapsulate their own JavaScript and CSS.

There are frameworks dedicated to building web components like Lit and Stencil, but all the major frameworks can compile to web components it as well. One awesome thing about web components is that you can use them anywhere, like regular HTML elements. You can even use them in markdown without any extra plugins or dependencies. On top of that, you can use them between frameworks. For example, I could build a web component with Svelte and then access it from a React and Angular that.

In my case, web components are awesome because I can use a static site generator, then add interactivity to my templates by simply declaring my custom elements. Ghent. It's kind of like the islands architecture where you have islands of interactivity, but one thing to keep in mind is that web components will never be server rendered. They're only rendered on the client. Although interestingly, you can project server rendered content in a web component, which I think would be perfectly indexable by search engines.

Now here's where things get really cool. When you combine web components with the router, they render instantly between route changes. What I have here is a statically generated site with a counter web component generated by Svelte that gets its data from a Svelte store. When the router is disabled, it does a full page load and the current count is lost when we go to the next page. Now if we enable the router, notice how the count data is not lost between route changes, just like a single page application.

Not to mention, the page transition feels much faster for the end user. In this code base, I have an Eleventy project, inside of which as an extra app directory that contains a Svelte app configured to compile 2 custom elements. From a development standpoint, the only thing you really need to do differently is define a tag for each component, then you export each component individually. The last thing I'm doing is starting the flamethrower router by calling it as a function. The the router has a couple of extra features that you wouldn't find in something like Turbolinks.

For 1, it will find all of the visible links on the page and automatically tell the browser to prefetch them. The browser will automatically download these pages in the background, so they're ready to render as soon as a user clicks on a link. That's made possible with prefetch link tags, and I also use the intersection observer API to only prefetch the links that are visible on the screen because those are the ones the user is more likely to click. In other words, as you scroll down, it will lazily prefetch the links that come into view. If you wanna see the actual latency between route changes, set log to true, and it will add a timer to every fetch operation.

It should be blazingly fast, like well under a 100 milliseconds. In addition, I threw in a little bonus feature that takes advantage of the new page transitions API. This API isn't supported in browsers yet, and you'll need to enable it with a flag, but basically, it allows you to animate natively between page transitions, kind kind of like you would expect in a native mobile app. As you can see, by default, it does a cross fade animation. The bottom line though is that this router has allowing me to create my own little meta framework using Svelte compiled to web components, along with Hugo, a static site generator, which gives me awesome CMS features with extremely fast builds with routing that feels like a single page application.

That's pretty much it. The real question is Who's coming with me? Who's coming with me? Who's coming with me? This is a proven technique and used on big sites like dev 2 with turbo, but currently flamethrower is in meme status, and I wouldn't recommend using it in production Gint till it reaches alpha.

I have the luxury of doing weird experimental stuff like this, but if you're building a serious app for yourself, don't go chasing waterfalls. Stick to the libraries and frameworks that you're used to, like Next, Sveltekit, Astro, and so on. Now that I've hyped up my game changing JavaScript framework, my next step is to abandon it, then ask for donations via Open Collective to start an SEO link farm, which is the most reliable way to fund open source. I've gotta feed my family somehow. Thanks for watching, and I will see you in the next one.
JavaScript is a nearly perfect programming language. The only thing it's missing is a good framework for building websites. Now I've got a body count like Wilt Chamberlain when it comes to JavaScript frameworks. I've tried nearly all of them and each one does some nice tricks, but none of them are marriage material. They all have their trade offs, which I'll explain throughout this video.
So you can understand what drives a developer to the point of madness, where they're left with no choice but to create their own JavaScript framework. It's alive. In my case, God told me to do it. Allow me to introduce you to Holy JS. Actually, never mind. Somebody already took that name on MPM. Let's let's go ahead and pivot to the devil and call it flamethrower. I think that really captures the essence of JavaScript programming.
god
Now, at this point, you may be wondering if I'm joking. The sad reality Gizno. I did actually create a game changing platform for building blazingly fast, highly interactive experiences on the Jamstack. I also raised 1,000,000 of dollars for my company, Flamethrower Inc, to hype it up.
I stole 99% of my ideas from other tools, but I'm going to tell you that everything else sucks, give it an MIT license, and then call you out if you try to steal Gillette, so one day I might be as successful as Remix. Alright. That part was a joke about some Twitter drama, but what I really wanna teach you in this video is the trade offs between all the different major JavaScript frameworks out there. Here's the normal flowchart I would go through when choosing a framework for a new project. The first question to ask is, is the project highly interactive? Giv. Like, are you building an app with user authentication with all kinds of data that can be manipulated by the current user? If the answer is no, it sounds like you're building a regular website, in which jcase, you don't need a JavaScript framework. Life will be much easier with a static site generator like Hugo or 11ty, and if you do end up needing the script.
youtube
software development
visualization
You can always drop in something like alpine or petite view, as opposed to a heavyweight framework. Or an even better option could be Astro, which generates static HTML, but allows you to bring in interactivity from any framework as needed. Now if you are building a highly interactive app, the next question you might ask is, does it need to be search engine friendly or does it need to render HTML and data on a server?
If the answer is no, then just use your favorite framework to build a single page application. If you don't need to render content in advance for search bots, then you can focus 100% on the front end UX. However, if you do need SEO, then your next question will be, how often does the content change. If it's like a blog where the content doesn't change very often, it sounds like you have a jamstack location. It typically makes more sense to pre render your content and cache it on a CDN, then allow a JavaScript framework to hydrate it and take over after the initial page load.
google
blogging
Frameworks like Next. Js Syspeltkit can do this in SSG mode, but you also have tools like Gatsby that are dedicated to this use case, although it's kind of fallen from grace recently. Now if your content is highly dynamic being constantly changing, then you'll likely need full server side rendering to regenerate the static content on the server whenever a new request comes in.
This is what tools like Next. Js, Nuxt, and SvelteKit are designed to do. And if you're not exactly sure how your project is going to evolve, I would default to a full SSR framework. That gives you a simple framework for choosing the right framework, but things can get a lot more complicated from here. What I'm building is a platform to host my courses. This. It requires user authentication and is highly interactive and also needs to have really good SEO. The content doesn't change all that often, so that would lead us to the jam the stack option.
networking
software development
I started working on the project with SvelteKit, which is an awesome framework, but is more general purpose and doesn't have a ton of features for content management compared to something like Hugo. That leads to the question of how do I manage tons of content. One option is I could stick with Sveltekit and just reimplement all these content management features on my don't get me wrong. I love reinventing the wheel as much as the next JavaScript developer, but one other issue is that I'm worried these frameworks won't be fast enough when rendering a lot of markdown.
The creator of Eleventy made a good benchmark comparing them. Option b would be to pay for a headless CMS like Contentful or Sanity, Gmail, but then I have to add another paid service to my stack. Strapi is another good option that you can self host, but then I have to manage a separate server and database just to manage my content.
microsoft
customer support
networking
What I really want to do is just write all my content and markdown and manage it in a git repository. GitHub is actually an awesome free content management system for developers, although that's not its intended use.
That line line of thinking takes me back to static site generators, which are the best at handling markdown and templating. Astro seems like a perfect choice here, but it brings up one other question, which is how do I share data your state between different routes. On Astro, you'll notice that when you navigate, you get a full page load for each route.
astrology
That means the JavaScript reboots, and even if you use something like Nano stores or Svelte stores, the information from the previous route is lost. It's not like Next. Js where the client side router takes over and renders the UI with JavaScript on all routes after the initial page load. This can be a problem if you're managing authentication date with JSON Web Tokens in something like Firebase and want to show the current user up in the navbar along with some data from a database that might update in real time. So basically, play. That leads us back to Next. Js or any other framework that fully hydrates after the initial page load. There's also new cutting edge frameworks like quick and solid start that could be good options in the future, but I just need to get this project done as ASAP as possible. And, of course, the most efficient way to do that is to build your own JavaScript framework. The question that led to this is how do I take a static site and share JavaScript functionality and data between routes with a zero latency on the page transition, and without the need for a framework to take over the entire DOM. In other words, I want a SPA like router for static sites, and that's basically what I built. It has 0 dependencies and relies entirely on browser native technology like Fetch. A long time ago, when I first started working as a web developer, there was a library called Pjax that would asynchronously fetch fragments of HTML from your server and update the DOM rather than do a full page reload. This approach evolved into a library hold Turbolinks, which is still very popular today and receives more npm downloads than most JavaScript frameworks out there. The way it works is when you click on a link, it prevents that default behavior, then uses fetch to grab the page you want to navigate to. It swaps out the body of the page, then updates the head with the delta or changes on the new page. That means if you already executed JavaScript on the previous page, like a global state management library. It doesn't need to be re executed on the next page load. That's really interesting behavior, and I'll explain why in just a minute, but was the main duration for my framework. Well, actually, it's just a library technically. The reason I didn't just use Turbolinks is because it's rather large and does a bunch of stuff that I don't really need.
And there's the few special features that I wanted to add to my library to create a truly next gen holistic platform. One of the biggest things that annoys me about modern web development is that when you're building a big content driven site, 99% of the UI is static HTML that doesn't do anything.
architecture
software development
However, the common approach is to take this HTML and manage 100% in a JavaScript framework. There are some definite benefits to doing that, but it requires all kinds of special tooling, things like virtual DOM, and requires you to stay married to just one framework. As a polygamist, I demand more for my framework. We can actually take an entirely different approach that's natively supported in browsers using web components. A lot of people like to talk shit about web components for various reasons, but basically, it's just a browser API for creating custom elements that encapsulate their own JavaScript and CSS. There are frameworks dedicated to building web components like Lit and Stencil, but all the major frameworks can compile to web components it as well. One awesome thing about web components is that you can use them anywhere, like regular HTML elements. You can even use them in markdown without any extra plugins or dependencies. On top of that, you can use them between frameworks. For example, I could build a web component with Svelte and then access it from a React and Angular that.
In my case, web components are awesome because I can use a static site generator, then add interactivity to my templates by simply declaring my custom elements. Ghent. It's kind of like the islands architecture where you have islands of interactivity, but one thing to keep in mind is that web components will never be server rendered. They're only rendered on the client. Although interestingly, you can project server rendered content in a web component, which I think would be perfectly indexable by search engines.
architecture
websites
Now here's where things get really cool. When you combine web components with the router, they render instantly between route changes. What I have here is a statically generated site with a counter web component generated by Svelte that gets its data from a Svelte store. When the router is disabled, it does a full page load and the current count is lost when we go to the next page. Now if we enable the router, notice how the count data is not lost between route changes, just like a single page application. Not to mention, the page transition feels much faster for the end user. In this code base, I have an Eleventy project, inside of which as an extra app directory that contains a Svelte app configured to compile 2 custom elements. From a development standpoint, the only thing you really need to do differently is define a tag for each component, then you export each component individually. The last thing I'm doing is starting the flamethrower router by calling it as a function. The the router has a couple of extra features that you wouldn't find in something like Turbolinks. For 1, it will find all of the visible links on the page and automatically tell the browser to prefetch them. The browser will automatically download these pages in the background, so they're ready to render as soon as a user clicks on a link. That's made possible with prefetch link tags, and I also use the intersection observer API to only prefetch the links that are visible on the screen because those are the ones the user is more likely to click. In other words, as you scroll down, it will lazily prefetch the links that come into view. If you wanna see the actual latency between route changes, set log to true, and it will add a timer to every fetch operation. It should be blazingly fast, like well under a 100 milliseconds. In addition, I threw in a little bonus feature that takes advantage of the new page transitions API.
This API isn't supported in browsers yet, and you'll need to enable it with a flag, but basically, it allows you to animate natively between page transitions, kind kind of like you would expect in a native mobile app. As you can see, by default, it does a cross fade animation.
animation
The bottom line though is that this router has allowing me to create my own little meta framework using Svelte compiled to web components, along with Hugo, a static site generator, which gives me awesome CMS features with extremely fast builds with routing that feels like a single page application. That's pretty much it. The real question is Who's coming with me? Who's coming with me? Who's coming with me? This is a proven technique and used on big sites like dev 2 with turbo, but currently flamethrower is in meme status, and I wouldn't recommend using it in production Gint till it reaches alpha. I have the luxury of doing weird experimental stuff like this, but if you're building a serious app for yourself, don't go chasing waterfalls. Stick to the libraries and frameworks that you're used to, like Next, Sveltekit, Astro, and so on. Now that I've hyped up my game changing JavaScript framework, my next step is to abandon it, then ask for donations via Open Collective to start an SEO link farm, which is the most reliable way to fund open source.
I've gotta feed my family somehow. Thanks for watching, and I will see you in the next one.
JavaScript is a nearly perfect programming language. The only thing it's missing is a good framework for building websites. Now I've got a body count like Wilt Chamberlain when it comes to JavaScript frameworks. I've tried nearly all of them and each one does some nice tricks, but none of them are marriage material. They all have their trade offs, which I'll explain throughout this video. So you can understand what drives a developer to the point of madness, where they're left with no choice but to create their own JavaScript framework. It's alive. In my case, God told me to do it. Allow me to introduce you to Holy JS. Actually, never mind. Somebody already took that name on MPM. Let's let's go ahead and pivot to the devil and call it flamethrower. I think that really captures the essence of JavaScript programming. Now, at this point, you may be wondering if I'm joking. The sad reality Gizno. I did actually create a game changing platform for building blazingly fast, highly interactive experiences on the Jamstack. I also raised 1,000,000 of dollars for my company, Flamethrower Inc, to hype it up. I stole 99% of my ideas from other tools, but I'm going to tell you that everything else sucks, give it an MIT license, and then call you out if you try to steal Gillette, so one day I might be as successful as Remix. Alright. That part was a joke about some Twitter drama, but what I really wanna teach you in this video is the trade offs between all the different major JavaScript frameworks out there. Here's the normal flowchart I would go through when choosing a framework for a new project. The first question to ask is, is the project highly interactive? Giv. Like, are you building an app with user authentication with all kinds of data that can be manipulated by the current user? If the answer is no, it sounds like you're building a regular website, in which jcase, you don't need a JavaScript framework. Life will be much easier with a static site generator like Hugo or 11ty, and if you do end up needing the script. You can always drop in something like alpine or petite view, as opposed to a heavyweight framework. Or an even better option could be Astro, which generates static HTML, but allows you to bring in interactivity from any framework as needed. Now if you are building a highly interactive app, the next question you might ask is, does it need to be search engine friendly or does it need to render HTML and data on a server? If the answer is no, then just use your favorite framework to build a single page application. If you don't need to render content in advance for search bots, then you can focus 100% on the front end UX. However, if you do need SEO, then your next question will be, how often does the content change. If it's like a blog where the content doesn't change very often, it sounds like you have a jamstack location. It typically makes more sense to pre render your content and cache it on a CDN, then allow a JavaScript framework to hydrate it and take over after the initial page load. Frameworks like Next. Js Syspeltkit can do this in SSG mode, but you also have tools like Gatsby that are dedicated to this use case, although it's kind of fallen from grace recently. Now if your content is highly dynamic being constantly changing, then you'll likely need full server side rendering to regenerate the static content on the server whenever a new request comes in. This is what tools like Next. Js, Nuxt, and SvelteKit are designed to do. And if you're not exactly sure how your project is going to evolve, I would default to a full SSR framework. That gives you a simple framework for choosing the right framework, but things can get a lot more complicated from here. What I'm building is a platform to host my courses. This. It requires user authentication and is highly interactive and also needs to have really good SEO. The content doesn't change all that often, so that would lead us to the jam the stack option. I started working on the project with SvelteKit, which is an awesome framework, but is more general purpose and doesn't have a ton of features for content management compared to something like Hugo. That leads to the question of how do I manage tons of content. One option is I could stick with Sveltekit and just reimplement all these content management features on my don't get me wrong. I love reinventing the wheel as much as the next JavaScript developer, but one other issue is that I'm worried these frameworks won't be fast enough when rendering a lot of markdown. The creator of Eleventy made a good benchmark comparing them. Option b would be to pay for a headless CMS like Contentful or Sanity, Gmail, but then I have to add another paid service to my stack. Strapi is another good option that you can self host, but then I have to manage a separate server and database just to manage my content. What I really want to do is just write all my content and markdown and manage it in a git repository. GitHub is actually an awesome free content management system for developers, although that's not its intended use. That line line of thinking takes me back to static site generators, which are the best at handling markdown and templating. Astro seems like a perfect choice here, but it brings up one other question, which is how do I share data your state between different routes. On Astro, you'll notice that when you navigate, you get a full page load for each route. That means the JavaScript reboots, and even if you use something like Nano stores or Svelte stores, the information from the previous route is lost. It's not like Next. Js where the client side router takes over and renders the UI with JavaScript on all routes after the initial page load. This can be a problem if you're managing authentication date with JSON Web Tokens in something like Firebase and want to show the current user up in the navbar along with some data from a database that might update in real time. So basically, play. That leads us back to Next. Js or any other framework that fully hydrates after the initial page load. There's also new cutting edge frameworks like quick and solid start that could be good options in the future, but I just need to get this project done as ASAP as possible. And, of course, the most efficient way to do that is to build your own JavaScript framework. The question that led to this is how do I take a static site and share JavaScript functionality and data between routes with a zero latency on the page transition, and without the need for a framework to take over the entire DOM. In other words, I want a SPA like router for static sites, and that's basically what I built. It has 0 dependencies and relies entirely on browser native technology like Fetch. A long time ago, when I first started working as a web developer, there was a library called Pjax that would asynchronously fetch fragments of HTML from your server and update the DOM rather than do a full page reload. This approach evolved into a library hold Turbolinks, which is still very popular today and receives more npm downloads than most JavaScript frameworks out there. The way it works is when you click on a link, it prevents that default behavior, then uses fetch to grab the page you want to navigate to. It swaps out the body of the page, then updates the head with the delta or changes on the new page. That means if you already executed JavaScript on the previous page, like a global state management library. It doesn't need to be re executed on the next page load. That's really interesting behavior, and I'll explain why in just a minute, but was the main duration for my framework. Well, actually, it's just a library technically. The reason I didn't just use Turbolinks is because it's rather large and does a bunch of stuff that I don't really need. And there's the few special features that I wanted to add to my library to create a truly next gen holistic platform. One of the biggest things that annoys me about modern web development is that when you're building a big content driven site, 99% of the UI is static HTML that doesn't do anything. However, the common approach is to take this HTML and manage 100% in a JavaScript framework. There are some definite benefits to doing that, but it requires all kinds of special tooling, things like virtual DOM, and requires you to stay married to just one framework. As a polygamist, I demand more for my framework. We can actually take an entirely different approach that's natively supported in browsers using web components. A lot of people like to talk shit about web components for various reasons, but basically, it's just a browser API for creating custom elements that encapsulate their own JavaScript and CSS. There are frameworks dedicated to building web components like Lit and Stencil, but all the major frameworks can compile to web components it as well. One awesome thing about web components is that you can use them anywhere, like regular HTML elements. You can even use them in markdown without any extra plugins or dependencies. On top of that, you can use them between frameworks. For example, I could build a web component with Svelte and then access it from a React and Angular that. In my case, web components are awesome because I can use a static site generator, then add interactivity to my templates by simply declaring my custom elements. Ghent. It's kind of like the islands architecture where you have islands of interactivity, but one thing to keep in mind is that web components will never be server rendered. They're only rendered on the client. Although interestingly, you can project server rendered content in a web component, which I think would be perfectly indexable by search engines. Now here's where things get really cool. When you combine web components with the router, they render instantly between route changes. What I have here is a statically generated site with a counter web component generated by Svelte that gets its data from a Svelte store. When the router is disabled, it does a full page load and the current count is lost when we go to the next page. Now if we enable the router, notice how the count data is not lost between route changes, just like a single page application. Not to mention, the page transition feels much faster for the end user. In this code base, I have an Eleventy project, inside of which as an extra app directory that contains a Svelte app configured to compile 2 custom elements. From a development standpoint, the only thing you really need to do differently is define a tag for each component, then you export each component individually. The last thing I'm doing is starting the flamethrower router by calling it as a function. The the router has a couple of extra features that you wouldn't find in something like Turbolinks. For 1, it will find all of the visible links on the page and automatically tell the browser to prefetch them. The browser will automatically download these pages in the background, so they're ready to render as soon as a user clicks on a link. That's made possible with prefetch link tags, and I also use the intersection observer API to only prefetch the links that are visible on the screen because those are the ones the user is more likely to click. In other words, as you scroll down, it will lazily prefetch the links that come into view. If you wanna see the actual latency between route changes, set log to true, and it will add a timer to every fetch operation. It should be blazingly fast, like well under a 100 milliseconds. In addition, I threw in a little bonus feature that takes advantage of the new page transitions API. This API isn't supported in browsers yet, and you'll need to enable it with a flag, but basically, it allows you to animate natively between page transitions, kind kind of like you would expect in a native mobile app. As you can see, by default, it does a cross fade animation. The bottom line though is that this router has allowing me to create my own little meta framework using Svelte compiled to web components, along with Hugo, a static site generator, which gives me awesome CMS features with extremely fast builds with routing that feels like a single page application. That's pretty much it. The real question is Who's coming with me? Who's coming with me? Who's coming with me? This is a proven technique and used on big sites like dev 2 with turbo, but currently flamethrower is in meme status, and I wouldn't recommend using it in production Gint till it reaches alpha. I have the luxury of doing weird experimental stuff like this, but if you're building a serious app for yourself, don't go chasing waterfalls. Stick to the libraries and frameworks that you're used to, like Next, Sveltekit, Astro, and so on. Now that I've hyped up my game changing JavaScript framework, my next step is to abandon it, then ask for donations via Open Collective to start an SEO link farm, which is the most reliable way to fund open source. I've gotta feed my family somehow. Thanks for watching, and I will see you in the next one.
JavaScript
javascript
is
is
a
a
nearly
nearly
perfect
perfect
programming
programming
language.
language
The
the
only
only
thing
thing
it's
it's
missing
missing
is
is
a
a
good
good
framework
framework
for
for
building
building
websites.
websites
Now
now
I've
i've
got
got
a
a
body
body
count
count
like
like
Wilt
wilt
Chamberlain
chamberlain
when
when
it
it
comes
comes
to
to
JavaScript
javascript
frameworks.
frameworks
I've
i've
tried
tried
nearly
nearly
all
all
of
of
them
them
and
and
each
each
one
one
does
does
some
some
nice
nice
tricks,
tricks
but
but
none
none
of
of
them
them
are
are
marriage
marriage
material.
material
They
they
all
all
have
have
their
their
trade
trade
offs,
offs
which
which
I'll
i'll
explain
explain
throughout
throughout
this
this
video.
video
So
so
you
you
can
can
understand
understand
what
what
drives
drives
a
a
developer
developer
to
to
the
the
point
point
of
of
madness,
madness
where
where
they're
they're
left
left
with
with
no
no
choice
choice
but
but
to
to
create
create
their
their
own
own
JavaScript
javascript
framework.
framework
It's
it's
alive.
alive
In
in
my
my
case,
case
God
god
told
told
me
me
to
to
do
do
it.
it
Allow
allow
me
me
to
to
introduce
introduce
you
you
to
to
Holy
holy
JS.
js
Actually,
actually
never
never
mind.
mind
Somebody
somebody
already
already
took
took
that
that
name
name
on
on
MPM.
mpm
Let's
let's
let's
let's
go
go
ahead
ahead
and
and
pivot
pivot
to
to
the
the
devil
devil
and
and
call
call
it
it
flamethrower.
flamethrower
I
i
think
think
that
that
really
really
captures
captures
the
the
essence
essence
of
of
JavaScript
javascript
programming.
programming
Now,
now
at
at
this
this
point,
point
you
you
may
may
be
be
wondering
wondering
if
if
I'm
i'm
joking.
joking
The
the
sad
sad
reality
reality
Gizno.
gizno
I
i
did
did
actually
actually
create
create
a
a
game
game
changing
changing
platform
platform
for
for
building
building
blazingly
blazingly
fast,
fast
highly
highly
interactive
interactive
experiences
experiences
on
on
the
the
Jamstack.
jamstack
I
i
also
also
raised
raised
1,000,000
1,000,000
of
of
dollars
dollars
for
for
my
my
company,
company
Flamethrower
flamethrower
Inc,
inc
to
to
hype
hype
it
it
up.
up
I
i
stole
stole
99%
99%
of
of
my
my
ideas
ideas
from
from
other
other
tools,
tools
but
but
I'm
i'm
going
going
to
to
tell
tell
you
you
that
that
everything
everything
else
else
sucks,
sucks
give
give
it
it
an
an
MIT
mit
license,
license
and
and
then
then
call
call
you
you
out
out
if
if
you
you
try
try
to
to
steal
steal
Gillette,
gillette
so
so
one
one
day
day
I
i
might
might
be
be
as
as
successful
successful
as
as
Remix.
remix
Alright.
alright
That
that
part
part
was
was
a
a
joke
joke
about
about
some
some
Twitter
twitter
drama,
drama
but
but
what
what
I
i
really
really
wanna
wanna
teach
teach
you
you
in
in
this
this
video
video
is
is
the
the
trade
trade
offs
offs
between
between
all
all
the
the
different
different
major
major
JavaScript
javascript
frameworks
frameworks
out
out
there.
there
Here's
here's
the
the
normal
normal
flowchart
flowchart
I
i
would
would
go
go
through
through
when
when
choosing
choosing
a
a
framework
framework
for
for
a
a
new
new
project.
project
The
the
first
first
question
question
to
to
ask
ask
is,
is
is
is
the
the
project
project
highly
highly
interactive?
interactive
Giv.
giv
Like,
like
are
are
you
you
building
building
an
an
app
app
with
with
user
user
authentication
authentication
with
with
all
all
kinds
kinds
of
of
data
data
that
that
can
can
be
be
manipulated
manipulated
by
by
the
the
current
current
user?
user
If
if
the
the
answer
answer
is
is
no,
no
it
it
sounds
sounds
like
like
you're
you're
building
building
a
a
regular
regular
website,
website
in
in
which
which
jcase,
jcase
you
you
don't
don't
need
need
a
a
JavaScript
javascript
framework.
framework
Life
life
will
will
be
be
much
much
easier
easier
with
with
a
a
static
static
site
site
generator
generator
like
like
Hugo
hugo
or
or
11ty,
11ty
and
and
if
if
you
you
do
do
end
end
up
up
needing
needing
the
the
script.
script
You
you
can
can
always
always
drop
drop
in
in
something
something
like
like
alpine
alpine
or
or
petite
petite
view,
view
as
as
opposed
opposed
to
to
a
a
heavyweight
heavyweight
framework.
framework
Or
or
an
an
even
even
better
better
option
option
could
could
be
be
Astro,
astro
which
which
generates
generates
static
static
HTML,
html
but
but
allows
allows
you
you
to
to
bring
bring
in
in
interactivity
interactivity
from
from
any
any
framework
framework
as
as
needed.
needed
Now
now
if
if
you
you
are
are
building
building
a
a
highly
highly
interactive
interactive
app,
app
the
the
next
next
question
question
you
you
might
might
ask
ask
is,
is
does
does
it
it
need
need
to
to
be
be
search
search
engine
engine
friendly
friendly
or
or
does
does
it
it
need
need
to
to
render
render
HTML
html
and
and
data
data
on
on
a
a
server?
server
If
if
the
the
answer
answer
is
is
no,
no
then
then
just
just
use
use
your
your
favorite
favorite
framework
framework
to
to
build
build
a
a
single
single
page
page
application.
application
If
if
you
you
don't
don't
need
need
to
to
render
render
content
content
in
in
advance
advance
for
for
search
search
bots,
bots
then
then
you
you
can
can
focus
focus
100%
100%
on
on
the
the
front
front
end
end
UX.
ux
However,
however
if
if
you
you
do
do
need
need
SEO,
seo
then
then
your
your
next
next
question
question
will
will
be,
be
how
how
often
often
does
does
the
the
content
content
change.
change
If
if
it's
it's
like
like
a
a
blog
blog
where
where
the
the
content
content
doesn't
doesn't
change
change
very
very
often,
often
it
it
sounds
sounds
like
like
you
you
have
have
a
a
jamstack
jamstack
location.
location
It
it
typically
typically
makes
makes
more
more
sense
sense
to
to
pre
pre
render
render
your
your
content
content
and
and
cache
cache
it
it
on
on
a
a
CDN,
cdn
then
then
allow
allow
a
a
JavaScript
javascript
framework
framework
to
to
hydrate
hydrate
it
it
and
and
take
take
over
over
after
after
the
the
initial
initial
page
page
load.
load
Frameworks
frameworks
like
like
Next.
next
Js
js
Syspeltkit
syspeltkit
can
can
do
do
this
this
in
in
SSG
ssg
mode,
mode
but
but
you
you
also
also
have
have
tools
tools
like
like
Gatsby
gatsby
that
that
are
are
dedicated
dedicated
to
to
this
this
use
use
case,
case
although
although
it's
it's
kind
kind
of
of
fallen
fallen
from
from
grace
grace
recently.
recently
Now
now
if
if
your
your
content
content
is
is
highly
highly
dynamic
dynamic
being
being
constantly
constantly
changing,
changing
then
then
you'll
you'll
likely
likely
need
need
full
full
server
server
side
side
rendering
rendering
to
to
regenerate
regenerate
the
the
static
static
content
content
on
on
the
the
server
server
whenever
whenever
a
a
new
new
request
request
comes
comes
in.
in
This
this
is
is
what
what
tools
tools
like
like
Next.
next
Js,
js
Nuxt,
nuxt
and
and
SvelteKit
sveltekit
are
are
designed
designed
to
to
do.
do
And
and
if
if
you're
you're
not
not
exactly
exactly
sure
sure
how
how
your
your
project
project
is
is
going
going
to
to
evolve,
evolve
I
i
would
would
default
default
to
to
a
a
full
full
SSR
ssr
framework.
framework
That
that
gives
gives
you
you
a
a
simple
simple
framework
framework
for
for
choosing
choosing
the
the
right
right
framework,
framework
but
but
things
things
can
can
get
get
a
a
lot
lot
more
more
complicated
complicated
from
from
here.
here
What
what
I'm
i'm
building
building
is
is
a
a
platform
platform
to
to
host
host
my
my
courses.
courses
This.
this
It
it
requires
requires
user
user
authentication
authentication
and
and
is
is
highly
highly
interactive
interactive
and
and
also
also
needs
needs
to
to
have
have
really
really
good
good
SEO.
seo
The
the
content
content
doesn't
doesn't
change
change
all
all
that
that
often,
often
so
so
that
that
would
would
lead
lead
us
us
to
to
the
the
jam
jam
the
the
stack
stack
option.
option
I
i
started
started
working
working
on
on
the
the
project
project
with
with
SvelteKit,
sveltekit
which
which
is
is
an
an
awesome
awesome
framework,
framework
but
but
is
is
more
more
general
general
purpose
purpose
and
and
doesn't
doesn't
have
have
a
a
ton
ton
of
of
features
features
for
for
content
content
management
management
compared
compared
to
to
something
something
like
like
Hugo.
hugo
That
that
leads
leads
to
to
the
the
question
question
of
of
how
how
do
do
I
i
manage
manage
tons
tons
of
of
content.
content
One
one
option
option
is
is
I
i
could
could
stick
stick
with
with
Sveltekit
sveltekit
and
and
just
just
reimplement
reimplement
all
all
these
these
content
content
management
management
features
features
on
on
my
my
don't
don't
get
get
me
me
wrong.
wrong
I
i
love
love
reinventing
reinventing
the
the
wheel
wheel
as
as
much
much
as
as
the
the
next
next
JavaScript
javascript
developer,
developer
but
but
one
one
other
other
issue
issue
is
is
that
that
I'm
i'm
worried
worried
these
these
frameworks
frameworks
won't
won't
be
be
fast
fast
enough
enough
when
when
rendering
rendering
a
a
lot
lot
of
of
markdown.
markdown
The
the
creator
creator
of
of
Eleventy
eleventy
made
made
a
a
good
good
benchmark
benchmark
comparing
comparing
them.
them
Option
option
b
b
would
would
be
be
to
to
pay
pay
for
for
a
a
headless
headless
CMS
cms
like
like
Contentful
contentful
or
or
Sanity,
sanity
Gmail,
gmail
but
but
then
then
I
i
have
have
to
to
add
add
another
another
paid
paid
service
service
to
to
my
my
stack.
stack
Strapi
strapi
is
is
another
another
good
good
option
option
that
that
you
you
can
can
self
self
host,
host
but
but
then
then
I
i
have
have
to
to
manage
manage
a
a
separate
separate
server
server
and
and
database
database
just
just
to
to
manage
manage
my
my
content.
content
What
what
I
i
really
really
want
want
to
to
do
do
is
is
just
just
write
write
all
all
my
my
content
content
and
and
markdown
markdown
and
and
manage
manage
it
it
in
in
a
a
git
git
repository.
repository
GitHub
github
is
is
actually
actually
an
an
awesome
awesome
free
free
content
content
management
management
system
system
for
for
developers,
developers
although
although
that's
that's
not
not
its
its
intended
intended
use.
use
That
that
line
line
line
line
of
of
thinking
thinking
takes
takes
me
me
back
back
to
to
static
static
site
site
generators,
generators
which
which
are
are
the
the
best
best
at
at
handling
handling
markdown
markdown
and
and
templating.
templating
Astro
astro
seems
seems
like
like
a
a
perfect
perfect
choice
choice
here,
here
but
but
it
it
brings
brings
up
up
one
one
other
other
question,
question
which
which
is
is
how
how
do
do
I
i
share
share
data
data
your
your
state
state
between
between
different
different
routes.
routes
On
on
Astro,
astro
you'll
you'll
notice
notice
that
that
when
when
you
you
navigate,
navigate
you
you
get
get
a
a
full
full
page
page
load
load
for
for
each
each
route.
route
That
that
means
means
the
the
JavaScript
javascript
reboots,
reboots
and
and
even
even
if
if
you
you
use
use
something
something
like
like
Nano
nano
stores
stores
or
or
Svelte
svelte
stores,
stores
the
the
information
information
from
from
the
the
previous
previous
route
route
is
is
lost.
lost
It's
it's
not
not
like
like
Next.
next
Js
js
where
where
the
the
client
client
side
side
router
router
takes
takes
over
over
and
and
renders
renders
the
the
UI
ui
with
with
JavaScript
javascript
on
on
all
all
routes
routes
after
after
the
the
initial
initial
page
page
load.
load
This
this
can
can
be
be
a
a
problem
problem
if
if
you're
you're
managing
managing
authentication
authentication
date
date
with
with
JSON
json
Web
web
Tokens
tokens
in
in
something
something
like
like
Firebase
firebase
and
and
want
want
to
to
show
show
the
the
current
current
user
user
up
up
in
in
the
the
navbar
navbar
along
along
with
with
some
some
data
data
from
from
a
a
database
database
that
that
might
might
update
update
in
in
real
real
time.
time
So
so
basically,
basically
play.
play
That
that
leads
leads
us
us
back
back
to
to
Next.
next
Js
js
or
or
any
any
other
other
framework
framework
that
that
fully
fully
hydrates
hydrates
after
after
the
the
initial
initial
page
page
load.
load
There's
there's
also
also
new
new
cutting
cutting
edge
edge
frameworks
frameworks
like
like
quick
quick
and
and
solid
solid
start
start
that
that
could
could
be
be
good
good
options
options
in
in
the
the
future,
future
but
but
I
i
just
just
need
need
to
to
get
get
this
this
project
project
done
done
as
as
ASAP
asap
as
as
possible.
possible
And,
and
of
of
course,
course
the
the
most
most
efficient
efficient
way
way
to
to
do
do
that
that
is
is
to
to
build
build
your
your
own
own
JavaScript
javascript
framework.
framework
The
the
question
question
that
that
led
led
to
to
this
this
is
is
how
how
do
do
I
i
take
take
a
a
static
static
site
site
and
and
share
share
JavaScript
javascript
functionality
functionality
and
and
data
data
between
between
routes
routes
with
with
a
a
zero
zero
latency
latency
on
on
the
the
page
page
transition,
transition
and
and
without
without
the
the
need
need
for
for
a
a
framework
framework
to
to
take
take
over
over
the
the
entire
entire
DOM.
dom
In
in
other
other
words,
words
I
i
want
want
a
a
SPA
spa
like
like
router
router
for
for
static
static
sites,
sites
and
and
that's
that's
basically
basically
what
what
I
i
built.
built
It
it
has
has
0
0
dependencies
dependencies
and
and
relies
relies
entirely
entirely
on
on
browser
browser
native
native
technology
technology
like
like
Fetch.
fetch
A
a
long
long
time
time
ago,
ago
when
when
I
i
first
first
started
started
working
working
as
as
a
a
web
web
developer,
developer
there
there
was
was
a
a
library
library
called
called
Pjax
pjax
that
that
would
would
asynchronously
asynchronously
fetch
fetch
fragments
fragments
of
of
HTML
html
from
from
your
your
server
server
and
and
update
update
the
the
DOM
dom
rather
rather
than
than
do
do
a
a
full
full
page
page
reload.
reload
This
this
approach
approach
evolved
evolved
into
into
a
a
library
library
hold
hold
Turbolinks,
turbolinks
which
which
is
is
still
still
very
very
popular
popular
today
today
and
and
receives
receives
more
more
npm
npm
downloads
downloads
than
than
most
most
JavaScript
javascript
frameworks
frameworks
out
out
there.
there
The
the
way
way
it
it
works
works
is
is
when
when
you
you
click
click
on
on
a
a
link,
link
it
it
prevents
prevents
that
that
default
default
behavior,
behavior
then
then
uses
uses
fetch
fetch
to
to
grab
grab
the
the
page
page
you
you
want
want
to
to
navigate
navigate
to.
to
It
it
swaps
swaps
out
out
the
the
body
body
of
of
the
the
page,
page
then
then
updates
updates
the
the
head
head
with
with
the
the
delta
delta
or
or
changes
changes
on
on
the
the
new
new
page.
page
That
that
means
means
if
if
you
you
already
already
executed
executed
JavaScript
javascript
on
on
the
the
previous
previous
page,
page
like
like
a
a
global
global
state
state
management
management
library.
library
It
it
doesn't
doesn't
need
need
to
to
be
be
re
re
executed
executed
on
on
the
the
next
next
page
page
load.
load
That's
that's
really
really
interesting
interesting
behavior,
behavior
and
and
I'll
i'll
explain
explain
why
why
in
in
just
just
a
a
minute,
minute
but
but
was
was
the
the
main
main
duration
duration
for
for
my
my
framework.
framework
Well,
well
actually,
actually
it's
it's
just
just
a
a
library
library
technically.
technically
The
the
reason
reason
I
i
didn't
didn't
just
just
use
use
Turbolinks
turbolinks
is
is
because
because
it's
it's
rather
rather
large
large
and
and
does
does
a
a
bunch
bunch
of
of
stuff
stuff
that
that
I
i
don't
don't
really
really
need.
need
And
and
there's
there's
the
the
few
few
special
special
features
features
that
that
I
i
wanted
wanted
to
to
add
add
to
to
my
my
library
library
to
to
create
create
a
a
truly
truly
next
next
gen
gen
holistic
holistic
platform.
platform
One
one
of
of
the
the
biggest
biggest
things
things
that
that
annoys
annoys
me
me
about
about
modern
modern
web
web
development
development
is
is
that
that
when
when
you're
you're
building
building
a
a
big
big
content
content
driven
driven
site,
site
99%
99%
of
of
the
the
UI
ui
is
is
static
static
HTML
html
that
that
doesn't
doesn't
do
do
anything.
anything
However,
however
the
the
common
common
approach
approach
is
is
to
to
take
take
this
this
HTML
html
and
and
manage
manage
100%
100%
in
in
a
a
JavaScript
javascript
framework.
framework
There
there
are
are
some
some
definite
definite
benefits
benefits
to
to
doing
doing
that,
that
but
but
it
it
requires
requires
all
all
kinds
kinds
of
of
special
special
tooling,
tooling
things
things
like
like
virtual
virtual
DOM,
dom
and
and
requires
requires
you
you
to
to
stay
stay
married
married
to
to
just
just
one
one
framework.
framework
As
as
a
a
polygamist,
polygamist
I
i
demand
demand
more
more
for
for
my
my
framework.
framework
We
we
can
can
actually
actually
take
take
an
an
entirely
entirely
different
different
approach
approach
that's
that's
natively
natively
supported
supported
in
in
browsers
browsers
using
using
web
web
components.
components
A
a
lot
lot
of
of
people
people
like
like
to
to
talk
talk
shit
shit
about
about
web
web
components
components
for
for
various
various
reasons,
reasons
but
but
basically,
basically
it's
it's
just
just
a
a
browser
browser
API
api
for
for
creating
creating
custom
custom
elements
elements
that
that
encapsulate
encapsulate
their
their
own
own
JavaScript
javascript
and
and
CSS.
css
There
there
are
are
frameworks
frameworks
dedicated
dedicated
to
to
building
building
web
web
components
components
like
like
Lit
lit
and
and
Stencil,
stencil
but
but
all
all
the
the
major
major
frameworks
frameworks
can
can
compile
compile
to
to
web
web
components
components
it
it
as
as
well.
well
One
one
awesome
awesome
thing
thing
about
about
web
web
components
components
is
is
that
that
you
you
can
can
use
use
them
them
anywhere,
anywhere
like
like
regular
regular
HTML
html
elements.
elements
You
you
can
can
even
even
use
use
them
them
in
in
markdown
markdown
without
without
any
any
extra
extra
plugins
plugins
or
or
dependencies.
dependencies
On
on
top
top
of
of
that,
that
you
you
can
can
use
use
them
them
between
between
frameworks.
frameworks
For
for
example,
example
I
i
could
could
build
build
a
a
web
web
component
component
with
with
Svelte
svelte
and
and
then
then
access
access
it
it
from
from
a
a
React
react
and
and
Angular
angular
that.
that
In
in
my
my
case,
case
web
web
components
components
are
are
awesome
awesome
because
because
I
i
can
can
use
use
a
a
static
static
site
site
generator,
generator
then
then
add
add
interactivity
interactivity
to
to
my
my
templates
templates
by
by
simply
simply
declaring
declaring
my
my
custom
custom
elements.
elements
Ghent.
ghent
It's
it's
kind
kind
of
of
like
like
the
the
islands
islands
architecture
architecture
where
where
you
you
have
have
islands
islands
of
of
interactivity,
interactivity
but
but
one
one
thing
thing
to
to
keep
keep
in
in
mind
mind
is
is
that
that
web
web
components
components
will
will
never
never
be
be
server
server
rendered.
rendered
They're
they're
only
only
rendered
rendered
on
on
the
the
client.
client
Although
although
interestingly,
interestingly
you
you
can
can
project
project
server
server
rendered
rendered
content
content
in
in
a
a
web
web
component,
component
which
which
I
i
think
think
would
would
be
be
perfectly
perfectly
indexable
indexable
by
by
search
search
engines.
engines
Now
now
here's
here's
where
where
things
things
get
get
really
really
cool.
cool
When
when
you
you
combine
combine
web
web
components
components
with
with
the
the
router,
router
they
they
render
render
instantly
instantly
between
between
route
route
changes.
changes
What
what
I
i
have
have
here
here
is
is
a
a
statically
statically
generated
generated
site
site
with
with
a
a
counter
counter
web
web
component
component
generated
generated
by
by
Svelte
svelte
that
that
gets
gets
its
its
data
data
from
from
a
a
Svelte
svelte
store.
store
When
when
the
the
router
router
is
is
disabled,
disabled
it
it
does
does
a
a
full
full
page
page
load
load
and
and
the
the
current
current
count
count
is
is
lost
lost
when
when
we
we
go
go
to
to
the
the
next
next
page.
page
Now
now
if
if
we
we
enable
enable
the
the
router,
router
notice
notice
how
how
the
the
count
count
data
data
is
is
not
not
lost
lost
between
between
route
route
changes,
changes
just
just
like
like
a
a
single
single
page
page
application.
application
Not
not
to
to
mention,
mention
the
the
page
page
transition
transition
feels
feels
much
much
faster
faster
for
for
the
the
end
end
user.
user
In
in
this
this
code
code
base,
base
I
i
have
have
an
an
Eleventy
eleventy
project,
project
inside
inside
of
of
which
which
as
as
an
an
extra
extra
app
app
directory
directory
that
that
contains
contains
a
a
Svelte
svelte
app
app
configured
configured
to
to
compile
compile
2
2
custom
custom
elements.
elements
From
from
a
a
development
development
standpoint,
standpoint
the
the
only
only
thing
thing
you
you
really
really
need
need
to
to
do
do
differently
differently
is
is
define
define
a
a
tag
tag
for
for
each
each
component,
component
then
then
you
you
export
export
each
each
component
component
individually.
individually
The
the
last
last
thing
thing
I'm
i'm
doing
doing
is
is
starting
starting
the
the
flamethrower
flamethrower
router
router
by
by
calling
calling
it
it
as
as
a
a
function.
function
The
the
the
the
router
router
has
has
a
a
couple
couple
of
of
extra
extra
features
features
that
that
you
you
wouldn't
wouldn't
find
find
in
in
something
something
like
like
Turbolinks.
turbolinks
For
for
1,
1
it
it
will
will
find
find
all
all
of
of
the
the
visible
visible
links
links
on
on
the
the
page
page
and
and
automatically
automatically
tell
tell
the
the
browser
browser
to
to
prefetch
prefetch
them.
them
The
the
browser
browser
will
will
automatically
automatically
download
download
these
these
pages
pages
in
in
the
the
background,
background
so
so
they're
they're
ready
ready
to
to
render
render
as
as
soon
soon
as
as
a
a
user
user
clicks
clicks
on
on
a
a
link.
link
That's
that's
made
made
possible
possible
with
with
prefetch
prefetch
link
link
tags,
tags
and
and
I
i
also
also
use
use
the
the
intersection
intersection
observer
observer
API
api
to
to
only
only
prefetch
prefetch
the
the
links
links
that
that
are
are
visible
visible
on
on
the
the
screen
screen
because
because
those
those
are
are
the
the
ones
ones
the
the
user
user
is
is
more
more
likely
likely
to
to
click.
click
In
in
other
other
words,
words
as
as
you
you
scroll
scroll
down,
down
it
it
will
will
lazily
lazily
prefetch
prefetch
the
the
links
links
that
that
come
come
into
into
view.
view
If
if
you
you
wanna
wanna
see
see
the
the
actual
actual
latency
latency
between
between
route
route
changes,
changes
set
set
log
log
to
to
true,
true
and
and
it
it
will
will
add
add
a
a
timer
timer
to
to
every
every
fetch
fetch
operation.
operation
It
it
should
should
be
be
blazingly
blazingly
fast,
fast
like
like
well
well
under
under
a
a
100
100
milliseconds.
milliseconds
In
in
addition,
addition
I
i
threw
threw
in
in
a
a
little
little
bonus
bonus
feature
feature
that
that
takes
takes
advantage
advantage
of
of
the
the
new
new
page
page
transitions
transitions
API.
api
This
this
API
api
isn't
isn't
supported
supported
in
in
browsers
browsers
yet,
yet
and
and
you'll
you'll
need
need
to
to
enable
enable
it
it
with
with
a
a
flag,
flag
but
but
basically,
basically
it
it
allows
allows
you
you
to
to
animate
animate
natively
natively
between
between
page
page
transitions,
transitions
kind
kind
kind
kind
of
of
like
like
you
you
would
would
expect
expect
in
in
a
a
native
native
mobile
mobile
app.
app
As
as
you
you
can
can
see,
see
by
by
default,
default
it
it
does
does
a
a
cross
cross
fade
fade
animation.
animation
The
the
bottom
bottom
line
line
though
though
is
is
that
that
this
this
router
router
has
has
allowing
allowing
me
me
to
to
create
create
my
my
own
own
little
little
meta
meta
framework
framework
using
using
Svelte
svelte
compiled
compiled
to
to
web
web
components,
components
along
along
with
with
Hugo,
hugo
a
a
static
static
site
site
generator,
generator
which
which
gives
gives
me
me
awesome
awesome
CMS
cms
features
features
with
with
extremely
extremely
fast
fast
builds
builds
with
with
routing
routing
that
that
feels
feels
like
like
a
a
single
single
page
page
application.
application
That's
that's
pretty
pretty
much
much
it.
it
The
the
real
real
question
question
is
is
Who's
who's
coming
coming
with
with
me?
me
Who's
who's
coming
coming
with
with
me?
me
Who's
who's
coming
coming
with
with
me?
me
This
this
is
is
a
a
proven
proven
technique
technique
and
and
used
used
on
on
big
big
sites
sites
like
like
dev
dev
2
2
with
with
turbo,
turbo
but
but
currently
currently
flamethrower
flamethrower
is
is
in
in
meme
meme
status,
status
and
and
I
i
wouldn't
wouldn't
recommend
recommend
using
using
it
it
in
in
production
production
Gint
gint
till
till
it
it
reaches
reaches
alpha.
alpha
I
i
have
have
the
the
luxury
luxury
of
of
doing
doing
weird
weird
experimental
experimental
stuff
stuff
like
like
this,
this
but
but
if
if
you're
you're
building
building
a
a
serious
serious
app
app
for
for
yourself,
yourself
don't
don't
go
go
chasing
chasing
waterfalls.
waterfalls
Stick
stick
to
to
the
the
libraries
libraries
and
and
frameworks
frameworks
that
that
you're
you're
used
used
to,
to
like
like
Next,
next
Sveltekit,
sveltekit
Astro,
astro
and
and
so
so
on.
on
Now
now
that
that
I've
i've
hyped
hyped
up
up
my
my
game
game
changing
changing
JavaScript
javascript
framework,
framework
my
my
next
next
step
step
is
is
to
to
abandon
abandon
it,
it
then
then
ask
ask
for
for
donations
donations
via
via
Open
open
Collective
collective
to
to
start
start
an
an
SEO
seo
link
link
farm,
farm
which
which
is
is
the
the
most
most
reliable
reliable
way
way
to
to
fund
fund
open
open
source.
source
I've
i've
gotta
gotta
feed
feed
my
my
family
family
somehow.
somehow
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The speakers discuss the trade-offs between framework options for building websites and recommend using a full server side rendering and content management system like Gatsby. They also suggest using a full SSR framework for search engine optimization and a full web UI tool like GitHub. The use of full server side rendering and a full SSR framework for dynamic content management is recommended, along with the use of a static site generator for web components and a web UI tool like GitHub. The speakers emphasize the importance of managing all routes and using a framework like Tur safer for static site generators. They also mention their upcoming SEO link farm and encourage viewers to use the framework for their own projects.
I built a JavaScript framework
JavaScript is a nearly perfect programming language. The only thing it's missing is a good framework for building websites. Now I've got a body count like Wilt Chamberlain when it comes to JavaScript frameworks. I've tried nearly all of them and each one does some nice tricks, but none of them are marriage material. They all have their trade offs, which I'll explain throughout this video. So you can understand what drives a developer to the point of madness, where they're left with no choice but to create their own JavaScript framework. It's alive. In my case, God told me to do it. Allow me to introduce you to Holy JS. Actually, never mind. Somebody already took that name on MPM. Let's let's go ahead and pivot to the devil and call it flamethrower. I think that really captures the essence of JavaScript programming. Now, at this point, you may be wondering if I'm joking. The sad reality Gizno. I did actually create a game changing platform for building blazingly fast, highly interactive experiences on the Jamstack. I also raised 1,000,000 of dollars for my company, Flamethrower Inc, to hype it up. I stole 99% of my ideas from other tools, but I'm going to tell you that everything else sucks, give it an MIT license, and then call you out if you try to steal Gillette, so one day I might be as successful as Remix. Alright. That part was a joke about some Twitter drama, but what I really wanna teach you in this video is the trade offs between all the different major JavaScript frameworks out there. Here's the normal flowchart I would go through when choosing a framework for a new project. The first question to ask is, is the project highly interactive? Giv. Like, are you building an app with user authentication with all kinds of data that can be manipulated by the current user? If the answer is no, it sounds like you're building a regular website, in which jcase, you don't need a JavaScript framework. Life will be much easier with a static site generator like Hugo or 11ty, and if you do end up needing the script. You can always drop in something like alpine or petite view, as opposed to a heavyweight framework. Or an even better option could be Astro, which generates static HTML, but allows you to bring in interactivity from any framework as needed. Now if you are building a highly interactive app, the next question you might ask is, does it need to be search engine friendly or does it need to render HTML and data on a server? If the answer is no, then just use your favorite framework to build a single page application. If you don't need to render content in advance for search bots, then you can focus 100% on the front end UX. However, if you do need SEO, then your next question will be, how often does the content change. If it's like a blog where the content doesn't change very often, it sounds like you have a jamstack location. It typically makes more sense to pre render your content and cache it on a CDN, then allow a JavaScript framework to hydrate it and take over after the initial page load. Frameworks like Next. Js Syspeltkit can do this in SSG mode, but you also have tools like Gatsby that are dedicated to this use case, although it's kind of fallen from grace recently. Now if your content is highly dynamic being constantly changing, then you'll likely need full server side rendering to regenerate the static content on the server whenever a new request comes in. This is what tools like Next. Js, Nuxt, and SvelteKit are designed to do. And if you're not exactly sure how your project is going to evolve, I would default to a full SSR framework. That gives you a simple framework for choosing the right framework, but things can get a lot more complicated from here. What I'm building is a platform to host my courses. This. It requires user authentication and is highly interactive and also needs to have really good SEO. The content doesn't change all that often, so that would lead us to the jam the stack option. I started working on the project with SvelteKit, which is an awesome framework, but is more general purpose and doesn't have a ton of features for content management compared to something like Hugo. That leads to the question of how do I manage tons of content. One option is I could stick with Sveltekit and just reimplement all these content management features on my don't get me wrong. I love reinventing the wheel as much as the next JavaScript developer, but one other issue is that I'm worried these frameworks won't be fast enough when rendering a lot of markdown. The creator of Eleventy made a good benchmark comparing them. Option b would be to pay for a headless CMS like Contentful or Sanity, Gmail, but then I have to add another paid service to my stack. Strapi is another good option that you can self host, but then I have to manage a separate server and database just to manage my content. What I really want to do is just write all my content and markdown and manage it in a git repository. GitHub is actually an awesome free content management system for developers, although that's not its intended use. That line line of thinking takes me back to static site generators, which are the best at handling markdown and templating. Astro seems like a perfect choice here, but it brings up one other question, which is how do I share data your state between different routes. On Astro, you'll notice that when you navigate, you get a full page load for each route. That means the JavaScript reboots, and even if you use something like Nano stores or Svelte stores, the information from the previous route is lost. It's not like Next. Js where the client side router takes over and renders the UI with JavaScript on all routes after the initial page load. This can be a problem if you're managing authentication date with JSON Web Tokens in something like Firebase and want to show the current user up in the navbar along with some data from a database that might update in real time. So basically, play. That leads us back to Next. Js or any other framework that fully hydrates after the initial page load. There's also new cutting edge frameworks like quick and solid start that could be good options in the future, but I just need to get this project done as ASAP as possible. And, of course, the most efficient way to do that is to build your own JavaScript framework. The question that led to this is how do I take a static site and share JavaScript functionality and data between routes with a zero latency on the page transition, and without the need for a framework to take over the entire DOM. In other words, I want a SPA like router for static sites, and that's basically what I built. It has 0 dependencies and relies entirely on browser native technology like Fetch. A long time ago, when I first started working as a web developer, there was a library called Pjax that would asynchronously fetch fragments of HTML from your server and update the DOM rather than do a full page reload. This approach evolved into a library hold Turbolinks, which is still very popular today and receives more npm downloads than most JavaScript frameworks out there. The way it works is when you click on a link, it prevents that default behavior, then uses fetch to grab the page you want to navigate to. It swaps out the body of the page, then updates the head with the delta or changes on the new page. That means if you already executed JavaScript on the previous page, like a global state management library. It doesn't need to be re executed on the next page load. That's really interesting behavior, and I'll explain why in just a minute, but was the main duration for my framework. Well, actually, it's just a library technically. The reason I didn't just use Turbolinks is because it's rather large and does a bunch of stuff that I don't really need. And there's the few special features that I wanted to add to my library to create a truly next gen holistic platform. One of the biggest things that annoys me about modern web development is that when you're building a big content driven site, 99% of the UI is static HTML that doesn't do anything. However, the common approach is to take this HTML and manage 100% in a JavaScript framework. There are some definite benefits to doing that, but it requires all kinds of special tooling, things like virtual DOM, and requires you to stay married to just one framework. As a polygamist, I demand more for my framework. We can actually take an entirely different approach that's natively supported in browsers using web components. A lot of people like to talk shit about web components for various reasons, but basically, it's just a browser API for creating custom elements that encapsulate their own JavaScript and CSS. There are frameworks dedicated to building web components like Lit and Stencil, but all the major frameworks can compile to web components it as well. One awesome thing about web components is that you can use them anywhere, like regular HTML elements. You can even use them in markdown without any extra plugins or dependencies. On top of that, you can use them between frameworks. For example, I could build a web component with Svelte and then access it from a React and Angular that. In my case, web components are awesome because I can use a static site generator, then add interactivity to my templates by simply declaring my custom elements. Ghent. It's kind of like the islands architecture where you have islands of interactivity, but one thing to keep in mind is that web components will never be server rendered. They're only rendered on the client. Although interestingly, you can project server rendered content in a web component, which I think would be perfectly indexable by search engines. Now here's where things get really cool. When you combine web components with the router, they render instantly between route changes. What I have here is a statically generated site with a counter web component generated by Svelte that gets its data from a Svelte store. When the router is disabled, it does a full page load and the current count is lost when we go to the next page. Now if we enable the router, notice how the count data is not lost between route changes, just like a single page application. Not to mention, the page transition feels much faster for the end user. In this code base, I have an Eleventy project, inside of which as an extra app directory that contains a Svelte app configured to compile 2 custom elements. From a development standpoint, the only thing you really need to do differently is define a tag for each component, then you export each component individually. The last thing I'm doing is starting the flamethrower router by calling it as a function. The the router has a couple of extra features that you wouldn't find in something like Turbolinks. For 1, it will find all of the visible links on the page and automatically tell the browser to prefetch them. The browser will automatically download these pages in the background, so they're ready to render as soon as a user clicks on a link. That's made possible with prefetch link tags, and I also use the intersection observer API to only prefetch the links that are visible on the screen because those are the ones the user is more likely to click. In other words, as you scroll down, it will lazily prefetch the links that come into view. If you wanna see the actual latency between route changes, set log to true, and it will add a timer to every fetch operation. It should be blazingly fast, like well under a 100 milliseconds. In addition, I threw in a little bonus feature that takes advantage of the new page transitions API. This API isn't supported in browsers yet, and you'll need to enable it with a flag, but basically, it allows you to animate natively between page transitions, kind kind of like you would expect in a native mobile app. As you can see, by default, it does a cross fade animation. The bottom line though is that this router has allowing me to create my own little meta framework using Svelte compiled to web components, along with Hugo, a static site generator, which gives me awesome CMS features with extremely fast builds with routing that feels like a single page application. That's pretty much it. The real question is Who's coming with me? Who's coming with me? Who's coming with me? This is a proven technique and used on big sites like dev 2 with turbo, but currently flamethrower is in meme status, and I wouldn't recommend using it in production Gint till it reaches alpha. I have the luxury of doing weird experimental stuff like this, but if you're building a serious app for yourself, don't go chasing waterfalls. Stick to the libraries and frameworks that you're used to, like Next, Sveltekit, Astro, and so on. Now that I've hyped up my game changing JavaScript framework, my next step is to abandon it, then ask for donations via Open Collective to start an SEO link farm, which is the most reliable way to fund open source. I've gotta feed my family somehow. Thanks for watching, and I will see you in the next one.
The speakers discuss the trade-offs between framework options for building websites and recommend using a full server side rendering and content management system like Gatsby. They also suggest using a full SSR framework for search engine optimization and a full web UI tool like GitHub. The use of full server side rendering and a full SSR framework for dynamic content management is recommended, along with the use of a static site generator for web components and a web UI tool like GitHub. The speakers emphasize the importance of managing all routes and using a framework like Tur safer for static site generators. They also mention their upcoming SEO link farm and encourage viewers to use the framework for their own projects.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : I built a JavaScript framework 
        and a small summary : The speakers discuss the trade-offs between framework options for building websites and recommend using a full server side rendering and content management system like Gatsby. They also suggest using a full SSR framework for search engine optimization and a full web UI tool like GitHub. The use of full server side rendering and a full SSR framework for dynamic content management is recommended, along with the use of a static site generator for web components and a web UI tool like GitHub. The speakers emphasize the importance of managing all routes and using a framework like Tur safer for static site generators. They also mention their upcoming SEO link farm and encourage viewers to use the framework for their own projects.
        [/INST]
        
        Generate the video : JavaScript is a nearly perfect programming language. The only thing it's missing is a good framework for building websites. Now I've got a body count like Wilt Chamberlain when it comes to JavaScript frameworks. I've tried nearly all of them and each one does some nice tricks, but none of them are marriage material. They all have their trade offs, which I'll explain throughout this video. So you can understand what drives a developer to the point of madness, where they're left with no choice but to create their own JavaScript framework. It's alive. In my case, God told me to do it. Allow me to introduce you to Holy JS. Actually, never mind. Somebody already took that name on MPM. Let's let's go ahead and pivot to the devil and call it flamethrower. I think that really captures the essence of JavaScript programming. Now, at this point, you may be wondering if I'm joking. The sad reality Gizno. I did actually create a game changing platform for building blazingly fast, highly interactive experiences on the Jamstack. I also raised 1,000,000 of dollars for my company, Flamethrower Inc, to hype it up. I stole 99% of my ideas from other tools, but I'm going to tell you that everything else sucks, give it an MIT license, and then call you out if you try to steal Gillette, so one day I might be as successful as Remix. Alright. That part was a joke about some Twitter drama, but what I really wanna teach you in this video is the trade offs between all the different major JavaScript frameworks out there. Here's the normal flowchart I would go through when choosing a framework for a new project. The first question to ask is, is the project highly interactive? Giv. Like, are you building an app with user authentication with all kinds of data that can be manipulated by the current user? If the answer is no, it sounds like you're building a regular website, in which jcase, you don't need a JavaScript framework. Life will be much easier with a static site generator like Hugo or 11ty, and if you do end up needing the script. You can always drop in something like alpine or petite view, as opposed to a heavyweight framework. Or an even better option could be Astro, which generates static HTML, but allows you to bring in interactivity from any framework as needed. Now if you are building a highly interactive app, the next question you might ask is, does it need to be search engine friendly or does it need to render HTML and data on a server? If the answer is no, then just use your favorite framework to build a single page application. If you don't need to render content in advance for search bots, then you can focus 100% on the front end UX. However, if you do need SEO, then your next question will be, how often does the content change. If it's like a blog where the content doesn't change very often, it sounds like you have a jamstack location. It typically makes more sense to pre render your content and cache it on a CDN, then allow a JavaScript framework to hydrate it and take over after the initial page load. Frameworks like Next. Js Syspeltkit can do this in SSG mode, but you also have tools like Gatsby that are dedicated to this use case, although it's kind of fallen from grace recently. Now if your content is highly dynamic being constantly changing, then you'll likely need full server side rendering to regenerate the static content on the server whenever a new request comes in. This is what tools like Next. Js, Nuxt, and SvelteKit are designed to do. And if you're not exactly sure how your project is going to evolve, I would default to a full SSR framework. That gives you a simple framework for choosing the right framework, but things can get a lot more complicated from here. What I'm building is a platform to host my courses. This. It requires user authentication and is highly interactive and also needs to have really good SEO. The content doesn't change all that often, so that would lead us to the jam the stack option. I started working on the project with SvelteKit, which is an awesome framework, but is more general purpose and doesn't have a ton of features for content management compared to something like Hugo. That leads to the question of how do I manage tons of content. One option is I could stick with Sveltekit and just reimplement all these content management features on my don't get me wrong. I love reinventing the wheel as much as the next JavaScript developer, but one other issue is that I'm worried these frameworks won't be fast enough when rendering a lot of markdown. The creator of Eleventy made a good benchmark comparing them. Option b would be to pay for a headless CMS like Contentful or Sanity, Gmail, but then I have to add another paid service to my stack. Strapi is another good option that you can self host, but then I have to manage a separate server and database just to manage my content. What I really want to do is just write all my content and markdown and manage it in a git repository. GitHub is actually an awesome free content management system for developers, although that's not its intended use. That line line of thinking takes me back to static site generators, which are the best at handling markdown and templating. Astro seems like a perfect choice here, but it brings up one other question, which is how do I share data your state between different routes. On Astro, you'll notice that when you navigate, you get a full page load for each route. That means the JavaScript reboots, and even if you use something like Nano stores or Svelte stores, the information from the previous route is lost. It's not like Next. Js where the client side router takes over and renders the UI with JavaScript on all routes after the initial page load. This can be a problem if you're managing authentication date with JSON Web Tokens in something like Firebase and want to show the current user up in the navbar along with some data from a database that might update in real time. So basically, play. That leads us back to Next. Js or any other framework that fully hydrates after the initial page load. There's also new cutting edge frameworks like quick and solid start that could be good options in the future, but I just need to get this project done as ASAP as possible. And, of course, the most efficient way to do that is to build your own JavaScript framework. The question that led to this is how do I take a static site and share JavaScript functionality and data between routes with a zero latency on the page transition, and without the need for a framework to take over the entire DOM. In other words, I want a SPA like router for static sites, and that's basically what I built. It has 0 dependencies and relies entirely on browser native technology like Fetch. A long time ago, when I first started working as a web developer, there was a library called Pjax that would asynchronously fetch fragments of HTML from your server and update the DOM rather than do a full page reload. This approach evolved into a library hold Turbolinks, which is still very popular today and receives more npm downloads than most JavaScript frameworks out there. The way it works is when you click on a link, it prevents that default behavior, then uses fetch to grab the page you want to navigate to. It swaps out the body of the page, then updates the head with the delta or changes on the new page. That means if you already executed JavaScript on the previous page, like a global state management library. It doesn't need to be re executed on the next page load. That's really interesting behavior, and I'll explain why in just a minute, but was the main duration for my framework. Well, actually, it's just a library technically. The reason I didn't just use Turbolinks is because it's rather large and does a bunch of stuff that I don't really need. And there's the few special features that I wanted to add to my library to create a truly next gen holistic platform. One of the biggest things that annoys me about modern web development is that when you're building a big content driven site, 99% of the UI is static HTML that doesn't do anything. However, the common approach is to take this HTML and manage 100% in a JavaScript framework. There are some definite benefits to doing that, but it requires all kinds of special tooling, things like virtual DOM, and requires you to stay married to just one framework. As a polygamist, I demand more for my framework. We can actually take an entirely different approach that's natively supported in browsers using web components. A lot of people like to talk shit about web components for various reasons, but basically, it's just a browser API for creating custom elements that encapsulate their own JavaScript and CSS. There are frameworks dedicated to building web components like Lit and Stencil, but all the major frameworks can compile to web components it as well. One awesome thing about web components is that you can use them anywhere, like regular HTML elements. You can even use them in markdown without any extra plugins or dependencies. On top of that, you can use them between frameworks. For example, I could build a web component with Svelte and then access it from a React and Angular that. In my case, web components are awesome because I can use a static site generator, then add interactivity to my templates by simply declaring my custom elements. Ghent. It's kind of like the islands architecture where you have islands of interactivity, but one thing to keep in mind is that web components will never be server rendered. They're only rendered on the client. Although interestingly, you can project server rendered content in a web component, which I think would be perfectly indexable by search engines. Now here's where things get really cool. When you combine web components with the router, they render instantly between route changes. What I have here is a statically generated site with a counter web component generated by Svelte that gets its data from a Svelte store. When the router is disabled, it does a full page load and the current count is lost when we go to the next page. Now if we enable the router, notice how the count data is not lost between route changes, just like a single page application. Not to mention, the page transition feels much faster for the end user. In this code base, I have an Eleventy project, inside of which as an extra app directory that contains a Svelte app configured to compile 2 custom elements. From a development standpoint, the only thing you really need to do differently is define a tag for each component, then you export each component individually. The last thing I'm doing is starting the flamethrower router by calling it as a function. The the router has a couple of extra features that you wouldn't find in something like Turbolinks. For 1, it will find all of the visible links on the page and automatically tell the browser to prefetch them. The browser will automatically download these pages in the background, so they're ready to render as soon as a user clicks on a link. That's made possible with prefetch link tags, and I also use the intersection observer API to only prefetch the links that are visible on the screen because those are the ones the user is more likely to click. In other words, as you scroll down, it will lazily prefetch the links that come into view. If you wanna see the actual latency between route changes, set log to true, and it will add a timer to every fetch operation. It should be blazingly fast, like well under a 100 milliseconds. In addition, I threw in a little bonus feature that takes advantage of the new page transitions API. This API isn't supported in browsers yet, and you'll need to enable it with a flag, but basically, it allows you to animate natively between page transitions, kind kind of like you would expect in a native mobile app. As you can see, by default, it does a cross fade animation. The bottom line though is that this router has allowing me to create my own little meta framework using Svelte compiled to web components, along with Hugo, a static site generator, which gives me awesome CMS features with extremely fast builds with routing that feels like a single page application. That's pretty much it. The real question is Who's coming with me? Who's coming with me? Who's coming with me? This is a proven technique and used on big sites like dev 2 with turbo, but currently flamethrower is in meme status, and I wouldn't recommend using it in production Gint till it reaches alpha. I have the luxury of doing weird experimental stuff like this, but if you're building a serious app for yourself, don't go chasing waterfalls. Stick to the libraries and frameworks that you're used to, like Next, Sveltekit, Astro, and so on. Now that I've hyped up my game changing JavaScript framework, my next step is to abandon it, then ask for donations via Open Collective to start an SEO link farm, which is the most reliable way to fund open source. I've gotta feed my family somehow. Thanks for watching, and I will see you in the next one.
        