Three days ago, Deno announced their new full stack web framework called Fresh. The framework looks great. It has a shiny new home page with clean colours and a cool animation, and it uses Preact. The web framework has zero runtime overhead and ships no JavaScript to the browser by default, it has no build step, supports TypeScript out of the box, and uses island based client hydration.

In this article, we'll be talking about everything Fresh! The features it has to offer, breaking down those features, comparing it with other frameworks and perhaps most importantly determining if it's something worth your time and energy. Let's get into it!

What is Deno?

Before we begin talking about Fresh, I think it's good to get a foundational knowledge of what Deno is beforehand as many people aren't familiar with it.

Deno is a modern runtime for JavaScript and TypeScript -- and brand new way and modern way to write server-side code. It solves nearly all of the same problems as Node.js and uses the V8 JavaScript Engine under the hood. In fact, it's even created by the same person, Ryan Dahl. Think of it as a newer and upgraded version of Node.js. The reason behind Deno is simply all of the problems and issues in Node.js.

Although it uses the V8 JavaScript engine, the rest of the runtime is implemented in Rust. The framework also has built-in TypeScript support, which is a huge step up from configuring a TypeScript environment in Node.js. Under the hood, Deno still technically still compiles it into JavaScript but you do not have to worry about configuring your whole environment to work with TypeScript.

Deno also recently raised a $21M series A investment round to build the Deno Deploy distributed web deployment platform along with their other open-source projects at github/denoland.

There are a million interesting things about Deno -- from how it handle browser-compatibility to the built-in security features. For the sake of keeping this article brief, we'll stop here as you now have some underlying information about how the runtime works and move onto what exactly the Fresh web framework is.

What is Fresh?

Fresh is created by Deno -- so it's no surprised that it's also built on-top of it. You write your applications in TypeScript. Fresh calls itself a next-gen fullstack web framework for server-side rendering, which I'll explain later in this article. It's similar to other fullstack web frameworks like Django, Ruby on Rails, Symfony or Larvel.

Essentially, Fresh is a routing framework that uses Preact (a lightweight React alternative) as a templating engine. A template engine enables you to use static template files in your application. Essentially, Fresh replaces variables in a template file with their actual values, and transforms the template into an HTML file sent to the client.

Let's get into the main problem that Fresh aims to solve. For this, let's take a look at a few paragraphs from the Deno blog,

React (and React-like) pages allow programs to build very complex UIs with relative ease. The popularity shows in the current web framework space: it is dominated by React based frameworks.

But client-side rendering is expensive; the framework often will ship hundreds of kilobytes of client-side JavaScript to users on each request. These JS bundles often do little more than rendering static content that could just as well have been served as plain HTML.

Some newer frameworks also have support for server side rendering. This helps reduce page load times by pre-rendering on the server. But most current implementations still ship the entire rendering infrastructure for the full application to every client so the page can be fully re-rendered on the client.

This is a bad development - client-side JavaScript is really expensive: it slows down the user experience, drastically increases power consumption on mobile devices, and is often not very robust.

How exactly does this work differently than other JavaScript frameworks like Next.js or Remix? Well, let's take the example of Next.js. It pre-renders every page -- essentially meaning it generates the HTML for the page in-advance, instead of having the client do it. This results in better performance and SEO as bots are able to 'crawl' through your content more effectively. Basically, when a page is loaded by the browser, its JavaScript code runs and makes the page fully interactive through a process called hydration.

Fresh also works similarly. Similar to Next.js, instead of sending JavaScript code to the browser, you render everything into static HTML on the server.

With that being said, most of us need interactivity, and just static HTML won't cut it. This is where the 'islands' architecture comes in, as mentioned. Fresh has an islands directory which includes any components that're interactive and might need to ship JavaScript to the browser. All the other components will be rendered as static HTML. This process is called partial hydration. I could go on talking about this for days, but I think we should move on 😅.

The Features of Fresh

Just like all other JavaScript frameworks, Fresh has a cool new feature set which it uses to attract developers. Let's talk about what those features actually are, and what they do.

Just-in-time rendering on the edge

As mentioned above, Fresh renders everything into static HTML on the server. On-top of that, when you create API routes in Fresh, it's based on the Fetch API interface allowing it to be deployed to serverless Edge functions such as Deno Deploy.

Island based client hydration

Essentially, the island based client hydration model works with small portions of your application which need JavaScript in-order to be interactive. For example, on the Fresh homepage they have this counter at the bottom which was hydrated to provide interactivity.

Attached below is an image comparing the islands architecture to SSR and progressive hydration from patterns.dev. Other frameworks such as Astro adopt this approach with server-side rendering.

Zero runtime overhead

This next feature derives from the "Island based client hydration" we talked about earlier. By default, in your application, Fresh ships no JavaScript to the browser. Just a static HTML file.

No build step

Fresh has absolutely no build step! Unlike a lot of other frameworks, Fresh builds can just be directly deployed to the edge with Deno Deploy.

No configuration necessary

This is rather self-explanatory. You don't need to configure anything really in-order to begin developing your application with Fresh. Just use their CLI and begin right away!

TypeScript support out of the box

I believe this one's also pretty self-explanatory. You don't need to configure TypeScript separately in Fresh like you'd need to do in Node.js. It's also very similar to the out of the box TypeScript support in Deno itself.

Conclusion

The feature-set is quite impressive, although at the end of the day, as I've mentioned, it's still technically yet another JavaScript framework. If you're exhausted from learning new JavaScript frameworks, you perhaps might not probably feel very enthusiastic about this, although I think it's best to remember that in the end, it's competition that pushes innovation.

I believe, in particular, JavaScript web frameworks are a place which could greatly benefit from more competition with new players such as Fresh. So, regardless of you using Fresh in your applications, it's bound to push other JavaScript web frameworks to do better -- in the end, you're a winner!

Anyways, that wraps it up for the article. In this article, we discussed everything about Fresh! From getting a brief background of Deno and Fresh to actually breaking down how it works under the hood and understanding what it has to offer in-terms of technology. I hope this article helped you get some foundational knowledge of what exactly Fresh is, and if it makes a worthy candidate for you to start using in your applications.

Until next time 👋.

Thanks to the author of Fresh, Luca Casonato for reviewing an early draft of this article.