Fresh: The Next-Gen JavaScript Web Framework
Tags: deno, typescript, webdev, node
Published: 2022-07-04 14:45:41

![Fresh Homepage](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6dre0h7reim1xq9eg87b.gif)

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](https://preactjs.com/). 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](https://v8.dev/) under the hood. In fact, it's even created by the same person, [Ryan Dahl](https://github.com/ry). 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](https://v8.dev/), the rest of the runtime is implemented in [Rust](https://www.rust-lang.org/). 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](https://deno.com/blog/series-a) to build the [Deno Deploy](https://deno.com/) distributed web deployment platform along with their other open-source projects at [github/denoland](https://github.com/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](https://www.djangoproject.com/), [Ruby on Rails](https://rubyonrails.org/), [Symfony](https://symfony.com/) or [Larvel](https://laravel.com/).

Essentially, [Fresh] is a routing framework that uses [Preact](https://preactjs.com/) (a lightweight [React](https://reactjs.org) 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](https://deno.com/blog/fresh-is-stable),

> 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](https://ajcwebdev.com/what-is-partial-hydration-and-why-is-everyone-talking-about-it). 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.

![Fresh's stand out features](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9drbw4m6mj92e8bj5ltg.png) 

### 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](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) interface allowing it to be deployed to serverless Edge functions such as [Deno Deploy](https://deno.com).

### 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](https://fresh.deno.dev/) 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](https://www.patterns.dev/). Other frameworks such as [Astro](https://astro.build) adopt this approach with [server-side rendering](https://astro.build/blog/experimental-server-side-rendering/).

![SSR vs progressive hydration vs islands architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4ew4boqch6xn41cvudun.png) 

### 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](https://deno.com).

### 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](https://css-tricks.com/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](https://twitter.com/lcasdev) for reviewing an early draft of this article._

[Deno]: https://deno.land/
[Node.js]: https://nodejs.org
[Fresh]: https://fresh.deno.dev/
[TypeScript]: https://typescriptlang.org
[Next.js]: https://nextjs.org
[Remix]: https://remix.run