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.
Top comments (34)
Seems good for building some apps, but the lack of embedded interactive components inside other interactive components would mean that most projects I work on would not be right for it, at least yet. Very interesting though.
That is true, and I think that'll be the main hinderance in the way of using this at scale. However I think it's still pushing innovation further regardless. The 'no build step' is something new and innovative I hadn't seen before, am interested to see how this pushes other frameworks such as Remix or Next.js.
Agreed, there are several things here which are very interesting.
Ah. You can't have a tree of interactive components? This is weird.
This part of the documentation is what I was referring to.
Indeed, I forgot that part.
This is quite limited then.edit: just changed my mind, ahah
There's a directory inside of Fresh for interactive components, I'm pretty sure you can have a tree of interactive components. Don't quote me on it though.
I know it is very minimalistic and hilarious... But basically we have moved backwards 10/20 years to PHP/Ruby where everything is/was SSR :D
BTW: very interesting and great article, I like the way you have "hydrated" the text with a lot of useful links!
I blame it on Next.js Overall, it is a good framework. I have no problems with Next.js as a codebase.
Vercel is a company that needs to sell a product, however. Since they are selling servers - the profit is to market the value of SSR and how easy it is to deploy to the Vercel platform.
While there are valid reasons for SSR. Static generation and data fetching via API patterns can offer the same performance and more flexibility (like as in building an offline-first "PWA" app)
I would love for Vercel to become better and improve their pricing along with add support for something such as custom serverless functions like AWS Lambda in runtimes other than Node.js -- regardless, Next.js has pretty good compatibility with things such as AWS Lambda or even Netlify.
Yeah -- I think it's not a good idea to make EVERYTHING server-side rendered for sure. I like how Next.js allows us to do a hybrid mix of both 😄
...and thank you! Glad you enjoyed.
This shares much of the core principles of the upcoming Webflo framework: SSR, zero build step, minimal-or-zero JS, etc.
But Webflo is taking a plunge to be a bit ahead of its time - none of the regular UI framework, just the use of native DOM APIs - both existing and proposed!
Overall goal is broad and far-reaching: demonstrate how, in addition to existing native APIs, some new proposals in this space fit together for some "futuristic" web-native approach to modern development!
I work on Webflo BTW
What you're building is very interesting. Just check it out, gave it a star. It looks very cool. Keep up the good work.
You got me excited! Thanks for your kinds words!
Curious to see how everything evolves!
Seems interesting, but will face issues while scaling, thanks for sharing.
What scaling issues will it face?
I personally think that if every page is server-side rendered, it's not a good idea in the long-term.
How does server side rendering prevent scalability? What difference is it to return json as compared to spitting out an HTML page?
Universal server side rendering is almost always a bad idea. I suggest you give this article a read: hyperbeam.com/blog/universal-rende...
Thanks for this awesome explaination
No problem. Thank you for reading.
Wow! I liked it. Thanks for your post.
Thanks for reading it :)
Introduce tech that was used 10-20 years ago and call it "Next-Gen" because the current gen has no idea about the old tech. Kudos.
Nuxt(3) already did the server+client side rendering what they call universal rendering and it works pretty well until now...
Cool. I'm interested to see how it'll play out for Fresh.
This is really an interesting article, Fresh sounds interesting and promising frame work.
I think it's in a very early stage right now, although there is some cool innovation that it's come out with such as the 'no build step'
Thanks for your article
I make a decision to learn about Deno, Fresh while I read this article.
Thanks again, bro
You're welcome. I'm glad this article helped you make the decision.
Hmmmmmm... sounds amusing
Well does it work alongside Node.js or it's a different entity entirely
I believe it's a different thing entirely, especially considering that Deno was meant to be a replacement for Node.js.
I don't see a web framework.
Not sure what you mean 😄