DEV Community

Cover image for Fresh – Is this new Javascript framework the Node-killer?
Saji Wang for Codesphere Inc.

Posted on

Fresh – Is this new Javascript framework the Node-killer?

The time has come once again to evaluate a new Javascript framework…but wait. This isn’t your run of the mill React clone with slight variations promising to change everything.

Fresh is a Deno-based web framework that sends no javascript to the client by default. All of the bulk rendering and computation can operate on the server, and the client only needs to render small islands of UI.

For those who don’t know, Deno is a runtime for Javascript built by the original creator of NodeJS as a solution to a lot of the problems with the original Node. While the ecospace is still quite underdeveloped, Fresh might just be the framework that puts Deno on the map.


Fresh Architecture

The two main parts of a Fresh application are routes and islands.

Routes are the way in which your web app responds to different requests. This can mean serving a response as part of an API, or serving HTML for your front end.

Islands are isolated preact (effectively a more lightweight version of React) components that are rendered on the client side. You can serve these to the client via routes. Fresh automatically handles the updating of Islands to minimize client load times.

You can create new routes and islands by creating files in the /routes and /islands folders respectively.

Since the bulk of processing is done on the server-side, Fresh can load pages considerably faster than most frameworks that use Client-Side rendering and even many Server Side Rendering(Since Fresh doesn’t ship the whole rendering infrastructure to the client)


Demo Application

Want to play around with a demo? First install Deno, and then create a demo project with:

deno run -A -r https://fresh.deno.dev my-project-name

And then run the project with:

deno task start


Our Review

Working with Fresh felt incredibly lightweight and simple compared to most of the new frameworks that we’ve tried for the blog.

The routing/island system is incredibly intuitive and solves a lot of the bloating issues that make web frameworks undesirable. I fully plan to use Fresh for some projects in the future.

Obviously, the biggest challenge when working with Fresh is the size of the Deno ecosystem, but Fresh honestly seems like a big enough step in the right direction to warrant putting up with the growing pains of Deno.

If enough people feel the way we do about it, it might just get enough people into the Deno ecosystem to finally kill Node.


Do you agree? Let us know down below!

As always, happy coding from your friends at Codesphere, the swiss army knife every development team needs!

Discussion (10)

Collapse
natescode profile image
Nathan Hedglin

So we're calling decades-old concepts and technology 'Fresh' now? Lol.

Collapse
pyrsmk profile image
Aurélien Delogu

The big thing is that it's an hybrid type of framework which can handle front reactivity directly, so it's a bit different than, for example, a Symfony website. But it's surely not new, the Phoenix framework does this for several years. And there's also Astro for Javascript.

Collapse
peerreynders profile image
peerreynders • Edited on

Ok, primed myself with

and running with it.

which can handle front reactivity directly

It handles hydration which is entirely different from reactivity.

(Sorry, acting a bit like a Ryan Carniato deadhead but his enthusiasm for these kind of topics is kind of infectious.)

Hydration is one solution to a problem that Paul Lewis raised way back in 2016

Phoenix LiveView (2018) is essentially a means of building a server-side-VDOM-based SPA implemented in Elixir (backed by the Erlang VM to handle client state on the server side) mostly in an attempt to decouple application development from the unstable nature of the JavaScript ecosystem.

As such LiveView is very clear about the constraints that it operates under.

And Astro drives the point home about how Node currently predominates.

However Astro supports a number of other client side frameworks as well. So anybody adopting Astro will stick to Node.js.

Perhaps sometime in the future they'll expand to the edge and perhaps it is then that Deno will become relevant to them.


Thread Thread
pyrsmk profile image
Aurélien Delogu

Oh boy... You clearly expanded my understanding on frontend frameworks 😅 Very interesting articles, thanks a lot for that !

It handles hydration which is entirely different from reactivity.

Indeed. Instead of talking about reactivity I should have said "interactivity" which was more what I have in mind.

Sorry, acting a bit like a Ryan Carniato deadhead but his enthusiasm for these kind of topics is kind of infectious.

Well... click Followed too.

Perhaps sometime in the future they'll expand to the edge and perhaps it is then that Deno will become relevant to them.

In fact, that was my point earlier, I'll try to explain it a bit. I think that there are a whole bunch of different frameworks out there and only the most knowns (or should I say: the most trendy) will be used. But TypeScript takes more and more space into companies' stacks. And adopting Deno instead of Node seems to be the fair suite to this. And then... Fresh. It would take some years for that but... I'm willing to take a gamble 😄

Collapse
natescode profile image
Nathan Hedglin

Great. Thanks.

Collapse
pyrsmk profile image
Aurélien Delogu

I would add that Deno is a TypeScript engine, not a Javascript one. I think its adoption (and the adoption of Fresh) will come from enterprises which place big bets on TypeScript because of its static typing nature. The future will tell.

Collapse
peerreynders profile image
peerreynders • Edited on

Deno will run JavaScript just fine and by default it simply strips the type annotations from TypeScript; it doesn't type check unless explicitly directed to do so. It's still based on V8 which is purely a JavaScript engine. I believe it's the WebAssembly portion where Deno leads the way. That's why there are opinions that WebAssembly will have a greater impact on the server/edge than on the client side.

So in a production deploy it still makes sense to output JavaScript.

TypeScript by default is seen as a plus but Deno can be successful even if TypeScript goes extinct.

Collapse
pyrsmk profile image
Aurélien Delogu

Interesting, I didn't know that, thanks!

Collapse
peerreynders profile image
peerreynders • Edited on

Look, I hope that Deno will eventually take over in the long run largely because they are aiming to unify the Web API between client and server.

But lets be realistic.

React in the client side rendering space makes it clear that the incumbent technology is very difficult to displace despite shortcomings and availability of better alternatives (at least from a technical perspective).

Typically a technology has to be obviously 10x better than the incumbent technology for a rapid migration to be triggered, something like 2.5x better just isn't good enough for most people to switch.

Deno has some chance to survive because of its adoption as an edge side processing environment but it remains to be seen how relevant that will be to the web as a whole over the long term.

What React is on the client side, Node is on the server side.

And as it, is most people don't care enough about "lightweight" on the client side yet; so most of them aren't even considering being lightweight on the server/edge side.

Collapse
nickytonline profile image
Nick Taylor

For anyone interested, the creator of Fresh will be joining me on my Twitch stream next Wednesday.