DEV Community

Cover image for Fresh: The Next-Gen JavaScript Web Framework
Harsh Singh
Harsh Singh

Posted on • Updated on

Fresh: The Next-Gen JavaScript Web Framework

Fresh Homepage

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.

Fresh's stand out features

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.

SSR vs progressive hydration vs islands architecture

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.

Discussion (34)

Collapse
miketalbot profile image
Mike Talbot

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.

Collapse
harshhhdev profile image
Harsh Singh Author

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.

Collapse
miketalbot profile image
Mike Talbot

Agreed, there are several things here which are very interesting.

Collapse
pyrsmk profile image
Aurélien Delogu

Ah. You can't have a tree of interactive components? This is weird.

Collapse
miketalbot profile image
Mike Talbot

Passing props to islands is supported, but only if the props are JSON serializable. This means that you can only pass primitive types, plain objects, and arrays. It is currently not possible to pass complex objects like Date, custom classes, or functions. This means that it is not possible to pass children to an island, as children are VNodes, which are not serializable.

It is also not supported to nest islands within other islands.

This part of the documentation is what I was referring to.

Thread Thread
pyrsmk profile image
Aurélien Delogu • Edited on

Indeed, I forgot that part. This is quite limited then.

edit: just changed my mind, ahah

Collapse
harshhhdev profile image
Harsh Singh Author

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.

Collapse
n3m3s7s profile image
Fabio Politi

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!

Collapse
brianmcbride profile image
Brian McBride

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)

Collapse
harshhhdev profile image
Harsh Singh Author

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.

Collapse
harshhhdev profile image
Harsh Singh Author

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.

Collapse
oxharris profile image
Oxford

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

Collapse
harshhhdev profile image
Harsh Singh Author

What you're building is very interesting. Just check it out, gave it a star. It looks very cool. Keep up the good work.

Collapse
oxharris profile image
Oxford

You got me excited! Thanks for your kinds words!

Curious to see how everything evolves!

Collapse
shshank profile image
Shshank

Seems interesting, but will face issues while scaling, thanks for sharing.

Collapse
morzaram0 profile image
Chris King

What scaling issues will it face?

Collapse
harshhhdev profile image
Harsh Singh Author

I personally think that if every page is server-side rendered, it's not a good idea in the long-term.

Thread Thread
morzaram0 profile image
Chris King

How does server side rendering prevent scalability? What difference is it to return json as compared to spitting out an HTML page?

Thread Thread
harshhhdev profile image
Harsh Singh Author

Universal server side rendering is almost always a bad idea. I suggest you give this article a read: hyperbeam.com/blog/universal-rende...

Collapse
mdmarufsarker profile image
Md. Maruf Sarker

Thanks for this awesome explaination

Collapse
harshhhdev profile image
Harsh Singh Author

No problem. Thank you for reading.

Collapse
ceoshikhar profile image
Shikhar Sharma

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.

Collapse
igortrindade profile image
Igor Trindade

Nuxt(3) already did the server+client side rendering what they call universal rendering and it works pretty well until now...

Collapse
harshhhdev profile image
Harsh Singh Author

Cool. I'm interested to see how it'll play out for Fresh.

Collapse
mhbaando profile image
Mohamud A. Abshir

This is really an interesting article, Fresh sounds interesting and promising frame work.

Collapse
harshhhdev profile image
Harsh Singh Author

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'

Collapse
lucasfpnt profile image
Lucas ferreira

Wow! I liked it. Thanks for your post.

Collapse
harshhhdev profile image
Harsh Singh Author • Edited on

Thanks for reading it :)

Collapse
manuelholar profile image
Teminijesu Olaleye

Hmmmmmm... sounds amusing
Well does it work alongside Node.js or it's a different entity entirely

Collapse
harshhhdev profile image
Harsh Singh Author

I believe it's a different thing entirely, especially considering that Deno was meant to be a replacement for Node.js.

Collapse
topninja profile image
Michael Jin

Thanks for your article
I make a decision to learn about Deno, Fresh while I read this article.
Thanks again, bro

Collapse
harshhhdev profile image
Harsh Singh Author

You're welcome. I'm glad this article helped you make the decision.

Collapse
610470416 profile image
NotFound404

I don't see a web framework.

Collapse
harshhhdev profile image
Harsh Singh Author

Not sure what you mean 😄

image