First-class support for full-stack web development

[mattvr]

Deno, despite being marketed as a modern runtime built around web technology and standards, is not well suited for deploying full-stack websites, e.g. using common ingredients like React, Server-side Rendering (SSR), and Hot Module Reloading (HMR) – features expected from modern web frameworks especially when building with JavaScript.

I'm a strong advocate for Deno, and see lots of promise in the current Deno-first web frameworks, however, given the current state, I can't confidently recommend Deno for building websites due to the lack of well-supported, easy-to-use, and actively developed frameworks that meet 2023 web development requirements.

Looking at the top 3 frameworks:

1/ Fresh (https://fresh.deno.dev/)
Though Fresh is the premier Deno web framework, it has significant drawbacks:

• Islands architecture, while a great feature, can confuse beginners and prevents complex use-cases.
• Preact-only, which limits portability and integrations.
• Lacks some basic features like nested islands, configurable middleware and routing, and struggles with state sharing (ref)
• Discrepancies between Deno Deploy and the standard runtime causes simple pages to break in my experience
• It's largely a solo project with limited active investment.

2/ Aleph (https://alephjs.org/)
Aleph is promising as a Next.js alternative supporting React, SSR, and HMR, but has issues:

• Frequently errors occur out of the box, even causing crashes during bundling with basic imports.
• It's not yet stable or recommended for production. The sole dev currently lacks the time for active project investment (ref)
• (Note that Aleph also used to support Solid, Vue, etc. but was removed recently.)

3/ Ultra (https://ultrajs.dev/)
Ultra, though the most reliable and flexible of the bunch, also struggles:

• It's not beginner-friendly due to low documentation and the need for rolling everything yourself.
• It lacks a live development feedback loop (e.g. HMR) and shows similar dev activity to the above two projects.

---

The main takeaway is that these frameworks are experimental side projects led by solo developers, making them less viable for building substantial projects or businesses with Deno.

---

While compatibility is in progress for NextJS (#16679) & Remix (#18326), the timeline and extent of this support is unclear.

I think getting to either (1) a stable, fully featured Deno web framework or (2) full compatibility for NextJS/Remix, may be one of the most impactful improvement to Deno today. This would significantly broaden the appeal of Deno, attract more web apps, and support a top use case for JavaScript server runtimes.

[reggi]

I empathize with the Deno team. Creating a competitive runtime with backwards compatibility with Node is a challenging task. Think about it: Deno has implemented web standards through and through and defaults to what browsers do, as seen in things like URL imports, fetch, request, response, etc. In contrast the world of modern web development is pretty non-standard. Pretty much all modern frameworks create their own flavor of JavaScript (specialized module exports) and have their own ways of bundling and code splitting first with webpack and now vite. The popularity of Next.js Server Components blur the lines between where things run (server and client) in even more non-standard ways.

Would I want to see Next.js run perfectly with Deno? It would be interesting but what's the point? I think Next.js is kind of close to feeling like its own runtime, especially with the changes coming with turbo pack. Running Next.js outside of vercel already comes with it's own drawbacks, not benefiting from the way the infrastructure deploys the code.

The team has taken a pretty hard stance against "build steps" for a myriad of reasons, it's slow, complicated, and obfuscates standard runtime operations. Once you start messing around with Deno Deploy, specifically the playground you see the the benefit of easily running a server in real-time with no build step, and it's really nice. It just feels simple. I think that Deno has the opportunity to think through the front-end landscape and implement its own suite of "standards" using web fundamentals, perhaps Web Components, module URLs, web APIs, etc. I think Fresh has great potential (even though I have problems with it too). I personally don't think of the use of preact as anything outside of a glorified JSX string renderer.

Just another thought, this should probably be in "discussions" and not an "issue". It might be best to close and migrate over to alleviate the "issues" backlog.

[dsherret]

They'll be some announcements around Fresh in the coming weeks.

Just another thought, this should probably be in "discussions" and not an "issue". It might be best to close and migrate over to alleviate the "issues" backlog.

Yeah, going to convert this to a discussion. Follow the other issues mentioned for those updates.

[dsherret]

Announcement: https://deno.com/blog/fresh-1.2

[zwn]

It seems support for qwik should be almost there. See

• Support for Qwik #19854

[j0of]

Is this post still correct? I've been trying to get into web development recently and I'm trying to decide between Fresh and Next. I messed around with both, and I haven't necessarily formed a preference on either, but that's probably because I haven't spent enough time on it yet. Can I get some thoughts on this?

[cknight]

Not sure what you are looking for, but things have moved on. The biggest is that Fresh is now a fully supported front end framework for Deno. The Deno team have hired a full time maintainer Marvin Hagemeister, who is also a maintainer of Preact and generally super helpful chap. As a framework, Fresh is probably easier to pick up than Next as it's less complex, unless you are coming from a strong Node/React background. Deno will definitely offer a better developer experience than working with node/next.js, but is less popular. There's a #fresh channel in the Deno Discord if you get stuck or have any questions.