What's next for Fresh?

[lucacasonato]

TL;DR: Fresh is now in it's own org so that more people can have review and PR access to it, and so that we can build a public governance structure for it. Deno folks will continue to contribute. Fresh will become Vite-only, and gain a bunch of features in the process. I'm also working on new features around signals and serializable functions to make Fresh even easier to use. Finally, the Fresh website will soon be https://usefresh.dev/.

---

Hey everyone,

This is a little status update of what's going on with Fresh recently, and what's happening next.

As you may have heard, both @marvinhagemeister and I left our jobs at Deno recently. Because Marvin was the primary person working on Fresh at Deno, this has left a bit of a maintainance gap over the last couple months. I'm happy to report that with @bartlomieju's help, we've now moved Fresh into it's own organization on GitHub, where we can build up a governance structure that is not tied as closely to Deno as it was previously. In the short term, you can expect more active reviews and PRs, as more people can now have review/push access to the repo. The Deno company is still using Fresh all over the place, so folks like @crowlKats will continue to contribute to Fresh where it makes sense.

In the longer term, this enables me to put some well needed love into Fresh. We're just off the heels of the Fresh 2 release, but I already have some big new things lined up. The main one, is that I'd like to discontinue Fresh-without-Vite, and move to a world where all Fresh projects use Vite. This unlocks some great simplifications inside of Fresh around asset handling (and asset imports), CSS, HMR of islands, smart HMR of server routes, and much more. It will also enable Fresh to be deployed to non-Deno systems, like Node or Cloudflare Workers, and integrate with various deployment platforms using Nitro. As part of this I have also figured out what makes current Fresh-on-Vite so dreadfully slow on startup of the dev server. It will be fixed!

I am also in the process of prototyping some very cool new features based on signals, and serializable functions: you'll soon be able to directly render signals into text nodes or element attributes on the client, without having to wrap your components in an island. You'll also be able to write functions that can be placed into element event handlers or island props, without having to wrap the component into another island. These new foundational building blocks will make it even easier to use Fresh.

Finally, Fresh is going to move to a new domain. Instead of https://fresh.deno.dev, the home page will soon be https://usefresh.dev/. We'll make this move in the coming days.

That's all for now!

- Luca

[CertainLach]

Just wondering, given that support for non-vite builds will be dropped... Will you still accept pull requests that are only useful for non-vite builds?

Context: Since the deprecation of legacy builder, I have developed https://github.com/CertainLach/freshpack for my own personal/work projects (I can give you more links to freshpack usage in the wild, but here is a couple of public ones: https://delta.rocks https://git.delta.rocks/r/jrsonnet/-/rev/master/tree). It works very well for me, and keeps the simplicity promised by the legacy builder, while giving HMR and some other stuff.

It allows to run the server without any bundling with embedded dev server, maintaining better compatibility with other packages (fresh on vite has bitten me many times due to its handling of ESM/CSM modules etc), not requiring node_modules, and some other pros that are here due to the implementation being much closer to native (E.g it does not need any workarounds to support websockets in dev mode (#3823), prod mode and dev mode are handled identically: https://github.com/CertainLach/freshpack/blob/trunk/packages/webpack/fresh.ts#L260-L278)

[eaallen]

just discovered fresh and I am in love. glad to see it under active dev

[adamgreg]

This is a very nice surprise! When I saw everyone that had left Deno, I thought that might be the end for Fresh. Thank you for the continued support!

[brettchalupa]

Hi there. I'm an active Fresh user with Fresh 1 and Fresh 2 apps in production. We're almost 3 months out from this announcement, and I have some questions and concerns.

we've now moved Fresh into it's own organization on GitHub, where we can build up a governance structure that is not tied as closely to Deno as it was previously

What will this governance structure be? Is discussion for this happening in any open spaces?

In the short term, you can expect more active reviews and PRs, as more people can now have review/push access to the repo.

There hasn't been anything merged in almost 3 months, since the date of this announcement and the repo organization change. Why is this/is there anything that can be done to help/assist?

And lastly, I opened an issue in May of this year and the response was from an AI bot thanking me for the detailed report... (#3806 (comment)) This was cringe and distinctly different than previous experiences I had with actual humans maintaining Fresh. Should users and contributors of Fresh expect continued heavy use of AI bots for communication and triage of the framework? If so, I will investigate other options as the best part of open source is the community and using bots like this deteriorates that experience.

I really enjoy using Fresh and Deno, but I've got concerns about both lately, and I hope to see Fresh continue to be maintained.

[Hajime-san]

I think it's necessary that establishing new guidelines for regarding the useage of AI.
While Fresh's internal implementation is relatively minimal, integrating it with Preact or Vite requires not a few understanding.

[SisyphusZheng]

I’ve been looking fairly closely at the Fresh repository recently, including both main and next. One thing I think is worth clarifying is that Fresh does not appear to have stopped development altogether. Fresh 3 is clearly still being actively developed on next, and it already has a fairly clear new architectural direction.

From what I’ve seen so far, Fresh 3 is not just an incremental update to Fresh 2, but a much more substantial redesign. I personally like this direction, especially the move toward Vite + Nitro, multi-runtime support, and letting Fresh itself focus more on islands, signals, navigation, and framework semantics. Fresh 3 looks very promising, and I’m looking forward to seeing it mature.

At the same time, precisely because Fresh 3 still appears to have quite a bit of work ahead of it, I think Fresh 2 may still need a clearer maintenance policy during this transition period.

Fresh 2 is still the stable line today, while Fresh 3 is still under active development. If Fresh 2 effectively becomes frozen before Fresh 3 is stable, I think that could be difficult both for existing users and for outside contributors who would like to help.

I completely understand that maintaining Fresh 2 while also pushing Fresh 3 forward creates a lot of additional work, so I’m not suggesting that Fresh 2 should continue receiving new features indefinitely.

A natural approach might be to put Fresh 2 into an explicit maintenance mode: accept important bug fixes, compatibility fixes, and necessary maintenance, while keeping new features and architectural work focused on Fresh 3. That would avoid taking too much attention away from Fresh 3 while still giving Fresh 2 users a reasonably stable migration window.

I think it would be very helpful to clarify a few things:

• What is the intended maintenance policy for Fresh 2 until Fresh 3 reaches stable?
• Will existing bug-fix and maintenance PRs against main still be reviewed?
• If someone wants to contribute to Fresh 3, what is the recommended contribution and review process today?

A clearer maintenance policy and contribution path would not only reduce some of the current uncertainty around the project, but also make it easier for people who want to help to know where to start — whether that means maintaining Fresh 2 or contributing to Fresh 3.

Finally, I also want to thank Luca for continuing to push Fresh forward. After changes in maintainership, rethinking both the architecture and the future direction of the framework is not an easy task. I also hope more people will be able to get involved in maintaining Fresh 2 and developing Fresh 3 over time.