Full-stack Web Components
A future-friendly way to build websites and apps using native browser features.
Familiar with HTML & JavaScript?
You'll 🧡 Crossbow
<main>
<h1>Welcome back ${user.name}</h1>
<router-outlet></router-outlet>
</main>
The future's here
Built on web tech for ultimate portability
What do developers need to learn to be productive with Crossbow? Just a few APIs on top of standard browser features... That's it!
For example, let's say you wanted to highlight a code snippet on the server-side only, so that the client side doesn't need any Javascript...
In Crossbow that would look something like this:
const code = fs.readFileSync("snippet.ts");
return html`<app-highlight .code=${code}></app-highlight>`
Web Tech
Many of the problems that React, Vue, Svelte & Angular are trying to solve can be done natively now with the Browser's own Component model.
Web Components + SSR
This solves one of the longest standing objections to the adoption of Web Components. With Crossbow you can use the same Web Components on the server as the ones that run the Browser.
Selective hydration
Often you need to decide at a page-level whether to enable or disable JavaScript. With Crossbow you can choose to hydrate the entire App for a SPA experience, or just a single component for that tiny piece of JS you wish you had on an otherwise static page.
What people are saying
It's similar to Next, Nuxt, Sveltekit & Remix, but for people who want to build with Web Components instead 👌
Shadow + Light DOM
Cutting edge, with a graceful fallback if needed
With Crossbow you get to choose which pieces of an application will be delivered as either Declarative Shadow DOM or Light Dom.
This flexibility allows apps to make the move to Web Components right now, even though Chrome is the only browser that fully supports Declarative Shadow DOM.
Consider the following component: it's children elements can be styled globally with regular CSS selectors and it requires ZERO Javascript in any browser.
<app-page>
<h1 class="mb-7">This is 'light' Dom</h1>
<p>Elements here can be styled globally</p>
</app-page>
Whereas the following makes use of Shadow DOM and enjoys the benefits of encapsulation. This needs a tiny (<1kb) polyfill.
<app-page>
<template shadowroot="open">
<h1 class="mb-7">This is 'light' Dom</h1>
<p>Elements here can be styled globally</p>
</template>
</app-page>
Static sites
Turn JavaScript off completely for Blogs, Marketing sites or any other content-heavy pages that don't need it.
Full SPA experience
Does your app qualify for a full SPA experience? - that's supported too! Import the code for our router and you can have nested-layouts that update independently.
Islands Architecture
So many pages on the internet right now would benefit from being mostly static, but with a little JavaScript sprinkled in. This concept is a first-class citizen with Crossbow.
Routing as it should be
Middleware-based routing for greater flexibility
Crossbow is designed from the ground up to support your complex routing needs. Being middleware driven at it's core, it allows things such as file-system based routing, config-based routing and dynamic runtime routing to all be used within the same application.
Since the middlewares can be registered for each nested level of routing, it means you can handle complex scenarios with ease.
A great example being a user's account section, where nested routes are being used to control the page, but you'd like parent routes to be able to invalidate/redirect a user when a session has expired.
/* /pages/user.js */
export async function middleware() {
return [
{
kind: 'global',
middleware: [
authMiddleware({ redirect: "/" })
]
}
]
}
File-system routing
You can build out your routing strategy by just placing your Web Component files in a certain folder structure. Easy.
Config-based routing
Prefer to define all your routes up front? Crossbow supports being completely configuration-based.
Mix & Match
Because each routing solution is just another middleware, it means you can easily mix and match file-system routing with config based routing.
There's more... much more
Building the framework of the future
Server-side data fetching, client-side routing, animations... We haven't even begun to scratch the surface of what's possible.