You can put a small website’s server setup, routes, and page components in one JavaScript file. That does not make the site one static HTML document: the example behind Bytes #120 renders HTML on the server and returns a response for each request. Its one-file layout is a compact teaching example, not a rule that production applications should keep all their code together.
What the one-file example actually contains
Bytes issue #120, published September 19, 2022, points to Leo Kettmeir’s Deno walkthrough, “A Whole Website in a Single JavaScript File”. The sample combines three jobs in one source file: starting a server, mapping request paths to handlers, and defining the page components those handlers render.
As an Amazon Associate I earn from qualifying purchases.
The original example imports serve from Deno’s standard library, router from crux.land, and h and ssr from nanossr. A render helper wraps each route’s content in a shared App component. That shared component supplies the common page structure and navigation, while route handlers provide the individual content.
The router uses URLPattern underneath, according to the article. The nanossr callback turns JSX into a Response; the article also says the library uses twind for styling. In practical terms, this is server-side templating: JavaScript defines the page, the server renders it, and the browser receives HTML.
#1 Best Overall
Which routes the original sample demonstrates
The first version has a small set of fixed routes and a fallback for anything unmatched:
/serves a landing page./statsserves a stats page./bagelsserves a bagel page.- Unmatched paths are handled by a fallback handler.
The structure makes the central idea easy to see: keep the route table near the components it calls, and use a shared wrapper instead of repeating the site-wide navigation on every page. Kettmeir’s April 5, 2022 article says, “Everything mentioned here can be viewed on a playground.”
Rank #2
What the follow-up adds
A later continuation extends the demo rather than describing features already present in the first post. It adds request-dependent content, a route parameter, and a search form in “A Whole Website in a Single JavaScript File, cont’d”.
Recommended Free Tools
Dynamic location and local time
The continuation renders a visitor’s location and local time dynamically. This illustrates a distinction between a page whose content is fixed and one whose output depends on request or visitor context.
Parameterized bagel pages
It adds /bagels/:id routes, allowing a route segment to identify an individual bagel rather than sending every visitor to the same bagel page.
Search with a GET form
The search form submits using GET, so the entered value appears in a search query parameter. The route reads that parameter and filters the bagel list. As the continuation puts it: “This is all great, but how can I find what bagels there are?” This is a concrete example of a form-driven interaction without changing the demo’s one-file organization.
Rank #4
When keeping a website in one file is useful
A single file can be a clear format when the goal is to understand the whole request-to-page path at a glance. It works especially well for a small demonstration with a short route table, a shared layout, and a limited amount of behavior. The example also shows that a compact server-rendered site can include dynamic output and basic search; “one file” does not mean “static page.”
As a project grows, decide based on the shape of its code rather than treating the example as a prescribed architecture. Consider these questions:
- Routes: Are there only a few known paths, or are route patterns and handlers multiplying?
- Content: Is most output fixed, or does it depend on request data, location, or other context?
- Behavior: Does the site need only a few forms and route handlers, or is its API and interaction logic becoming substantial?
- Shared code: Does keeping components together make the relationships easier to follow, or does the file become harder to navigate and change?
- Deployment: Does the hosting platform meet the project’s runtime and deployment requirements?
These are maintainability and fit criteria, not measured conclusions from the walkthrough. The source does not compare frameworks or hosting providers.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to read the 2022 Deno sample today
The imports and module versions in the original article are a snapshot from 2022, not current dependency recommendations. Before reusing its code, check that the pinned modules and runtime APIs remain compatible with the Deno version and deployment target you plan to use.
Hosting context has also changed. Deno’s current documentation describes Deno Deploy as a serverless platform for JavaScript and TypeScript applications in the cloud, and distinguishes it from Deploy Classic. The documentation, last updated July 9, 2026, says Deploy Classic and the subhosting v1 API were scheduled to shut down on July 20, 2026. The original walkthrough’s hosting example should therefore not be mistaken for an endorsement of Deploy Classic as a current service. See Deno Deploy documentation for the current product context.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The original post reported that its hosted example was served through an anycast IP from 29 data centers and described its result as a “perfect pagespeed score.” Those are Deno’s statements about the example in 2022, not current network or performance measurements: the post gives no reproducible test setup for the score. Its claim of zero-cost availability is likewise historical, not a statement of present pricing or availability.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
