홈

I recently launched game-news.dev, a simple knowledge sharing community for the game developers. I built it with Deno because Primeagen's hour-long interview with Ryan Dahl on Deno sparked my interest and I had to try it. Along with Deno, I also tried Fresh, Turso DB and Deno Deploy for the first time.

This article is about how I ended up loving Deno, plus my honest thoughts on the tools I used: Deno Deploy, Fresh, and Turso DB. I've also open-sourced the entire project for those interested in the techs mentioned here.

Deno

It turns out Deno isn't just a runtime; it's part of a larger ecosystem the Deno team is building:

It felt like they were providing a comprehensive suite for building web services. I ended up trying all of these for game-news.dev. So, how did it go?

My experience with the Deno runtime itself was overwhelmingly positive. Honestly, I don't see myself wanting to go back to Node.js for new projects.

Features like,
built-in TypeScript support,
built-in formatting (deno fmt),
built-in linting (deno lint),
built-in testing (deno test),
built-in compilation (deno compile)

eliminate a lot of the configuration fatigue that follows when setting up a Node.js project. Almost everything is managed neatly within the deno.json configuration file - though I wish it uses .ts extension like deno.config.ts to allow for comments, which is a frustration I have with package.json.

Also, Node versions are tied to specific NPM versions. It creates different lockFileVersion based on what NPM version you used to install packages, and it is a MESS when you use the wrong version for the repo.

Despite my enthusiasm, I think adopting Deno in a corporate or large team setting might still present some hurdles. Deno team claims you can run Node apps seamlessly though. Here are a few things I met to be aware of:

  1. node_modules Path Dependency: Deno doesn't create a node_modules directory by default. This is generally a good thing, but some npm packages expect their dependencies to reside within a node_modules structure. The workaround is to configure deno.json to explicitly create this directory at the project root.
  2. Permission Flags: Deno's security model requires explicit flags for operations like network access (-allow-net) or file system access. While great for security, this can sometimes interfere with tools or scripts (like those run via npx) that don't expect these permission prompts.
  3. AWS Lambda Runtime: AWS Lambda doesn't offer native support for the Deno runtime yet. While you can create custom runtimes, it does add complexity.
  4. Database Driver Compatibility: I encountered issues with certain database drivers (like better-sqlite3) throwing errors when run with Deno. While you can often find alternative libraries or workarounds for personal projects, hitting such snags in your work causes a massive headache.

Overall, Deno is a well-crafted, absolutely recommended piece of software, but it seems like it still needs time to grow its ecosystem and community.

Deno Deploy

Deno Deploy is the Deno team's serverless hosting solution, offering first-class support for the Deno runtime and its features like Deno Cron, Deno KV (key-value store), and Deno Queue within a serverless architecture.

It does provide all the above seamlessly, but I had to leave Deno Deploy for:

  1. Performance Issues: In my "specific" case, I consistently experienced slow page load times, often taking 1-2 seconds even for warm requests, and over 5 seconds for cold starts. While testing other sites hosted on Deploy showed this wasn't universal, the performance for mine was problematic enough that I eventually had to migrate to Railway.app. I tested this in South Korea with Singapore as the region.*
  2. Silently Reducing Regions: The number of available edge regions decreased significantly over time - from 35 down to 6. Sudden changes like this destroys user trust in a platform's stability.

The hosting market is highly competitive. While features like KV stores and cron jobs offer some value, the Deno Deploy team should recognize that core performance, reliability, and a stable global infrastructure remain non-negotiable priorities.

It's interesting they chose the serverless model. Many hobby projects have low traffic, meaning most user visits would hit a cold start. This could hinder the possibility to go viral.

Fresh

Fresh is the web framework created by the Deno team. I found it to be lightweight, simple, and intuitive. If your project is not a client-heavy website, you should definitely check out Fresh. It will be one of my go-to stack for future projects.

What makes Fresh interesting is its fundamental difference from the mainstream SSR frameworks like Next.js or SvelteKit. While those frameworks are “Server-Rendered Single Page Apps (SPAs)”, rendering the initial load on the server but then taking over routing on the client, Fresh is a classic “Multi-Page App (MPA)”. It feels more like a reactive templating engine similar to HTMX.

Because of the client-side routing, the SSR Frameworks provide wrapper components around the standard <a> tag. Clicking it triggers the framework to fetch the JS file for the next page and "pretend" the page has changed.

Fresh doesn't do that. User clicks a link, a new document loads. Simple as that. I love it because I believe that client-side routing (CSR) adds significant complexity just to mock the user experience of the traditional websites.

e.g.

Fresh Partials does offer a way to achieve CSR in Fresh apps. It’s the same exact concept that’s in HTMX - hx-target and hx-swap. You can designate parts of the page to be replaced dynamically when certain links are clicked.

However, I'd caution against overusing Partials. If you find yourself needing them frequently across your application, it’s a sign that Fresh if not the right tool for you. Partials produce “magic strings”, making it harder to manage over time.

Lastly, I see a lot of “is Fresh dead?” comments. No, it's not. As mentioned earlier, the Deno team made a whole suite, and are just too busy with other priorities. Version 1.7 (latest) is stable enough for production. The roadmap for v2 hints a focus on solidifying its role as a server-centric framework, adopting syntax more aligned with backend frameworks like Express, moving away from its initial Next.js-like structure, which I think is good.

Turso DB

Turso is a cloud database service built on libSQL (a fork of SQLite). Database hosting can often be a cost burden for hobby projects. But Turso offers 500 DBs for the free users. How on earth is this possible? Well, according to them, since SQLite is fundamentally a single-file database, they can efficiently provide databases at a very low cost.

My favorite aspect of Turso is its Developer Experience (DX). Creating and connecting to a database is incredibly straightforward. It's clear the team prioritizes the DX.

I'm using Embeded Replicas in game-news.dev. It allows you to run a replica of your database directly on your application server instance, which synchronizes with the primary database periodically. It comes with pros and cons:

Pro: Response times for reads are near-zero.
Con: Write operations can become slower. Turso's Read-Your-Writes process syncs the writes to the local replica in near real-time, adding latency.

I've experienced occasional instability where the embedded replica crashes out of nowhere. It hasn't been frequent enough to be a major blocker yet, but it's something I'll need to investigate.

So..

I wrote this post in hopes to encourage more developers to explore Deno, Fresh, and Turso. If you have any questions about the project or the technologies used, feel free to reach out.

And, of course, please stop by game-news.dev.