Flamethrower.js: Why I Built *Another* JavaScript Framework (And You Might Too!)



Introduction

The endless search for the ideal JavaScript framework. It's a journey many web developers embark on, often finding themselves facing trade-offs and compromises that leave them wanting more. What happens when frustration boils over? Sometimes, you build your own. This post explores the reasoning behind creating a new JavaScript library (not a framework!), dubbed "Flamethrower," and dives into the considerations and choices that led to its creation.


Choosing the Right Tool: A Framework Flowchart

The first step in any project is selecting the right tool for the job. A good starting point is to ask if the project is "highly interactive." If not, a static site generator like Hugo or Eleventy might be a better fit. For simple JavaScript needs, Alpine.js or Petit Vue can be dropped in. Astro offers a hybrid approach, generating static HTML while allowing the integration of interactive components from various frameworks.

However, if the project requires a high level of interactivity, the next question is whether SEO and server-side rendering are necessary. If not, a single-page application (SPA) built with your favorite framework is a valid choice. If SEO is important, you'll need to consider how often the content changes. For infrequently updated content, a Jamstack approach using frameworks like Next.js or SvelteKit in SSG mode, or a dedicated tool like Gatsby (though its popularity has waned), can be effective. For highly dynamic content, full server-side rendering (SSR) with frameworks like Next.js, Nuxt, or SvelteKit is often required. When in doubt, defaulting to a full SSR framework provides flexibility.


The Genesis of Flamethrower: A Solution to a Specific Problem

The author's project—a platform for hosting courses—presented a unique challenge. It needed user authentication, high interactivity, and strong SEO. This initially pointed towards a Jamstack solution. While SvelteKit was a strong contender, it lacked built-in content management features compared to static site generators like Hugo. The trade-offs of content management became a central issue.

Options considered were re-implementing content management features in SvelteKit, using a headless CMS like Contentful or Sanity (adding a paid service), or self-hosting Strapi (requiring server management). The desire to manage content as markdown files within a Git repository led back to static site generators.


Bridging the Gap: SPA-like Routing for Static Sites

The key problem was how to share JavaScript functionality and data between routes in a static site with minimal latency, without a full framework takeover. The solution: a SPA-like router for static sites, hence Flamethrower. This library, built without dependencies, leverages native browser technologies like Fetch. The inspiration came from libraries like PJax and Turbolinks, which asynchronously fetch HTML fragments and update the DOM.

Flamethrower builds upon this concept, offering similar functionality to Turbolinks, but with a smaller footprint and added features. One key feature is prefetching visible links using the Intersection Observer API to minimize latency.


Web Components: Islands of Interactivity

Flamethrower embraces web components as a way to add interactivity to static HTML. Web components are custom HTML elements with encapsulated JavaScript and CSS. While frameworks like LIT and Stencil are dedicated to building web components, major frameworks can also compile to them. Web components can be used anywhere, including in Markdown, and can be shared between frameworks. The presenter provided some very basic code. The only thing required is to define a tag for each component, then export each component individually:

<my-counter></my-counter>

Web components are rendered on the client-side. When combined with Flamethrower's router, they render instantly between route changes, preserving state. This allows for a seamless user experience similar to an SPA, even within a static site.


Conclusion

The development of Flamethrower highlights the trade-offs inherent in choosing a JavaScript framework and offers a solution for a very specific problem: adding SPA-like routing and interactive components to static sites. By combining a lightweight router with web components, Flamethrower offers a compelling alternative for projects that require both SEO and interactivity, without the overhead of a full-fledged framework.

Keywords: JavaScript framework, static site generator, web components, SPA, Jamstack, Flamethrower

Post a Comment

0 Comments