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)