Why Preact?

[FeldrinH]

I guess this is kind of a mean question, but I am qurious:
From what little I know about Preact, it is not particularly widely used and its market share doesn't seem to be growing either, so why use it as the basis of a new web framework?

[zicklag]

Other people can probably answer better, but I believe the choice of Preact has something to do with it's smallness and it's ability to operate in the isolated islands that Fresh is built on.

When using React, I think you often need the compiler, and the build toochain and all of this extra tooling just to use it, but with Preact you can insert it into just one component on you page to get some client-side reactivity. So it fits well for both the island and the no-build-step nature of Fresh.

Related ( short ) discussion: #598.

Also, from what little I've seen, Preact is extremely compatible with many react components, so it kind of inherits a lot of useful ecosystem compatibility from React.

[lucacasonato]

Because Preact is excellent. It strikes a great balance between size, usability, simplicity, familiarity and customisability.

[rschristian]

From what little I know about Preact, it is not particularly widely used and its market share doesn't seem to be growing either

Out of curiosity, what makes you say this? A particular write up or survey?

While NPM download counts are hardly the most scientific of values, Preact is solidly in fourth when it comes to JS framework usage (behind React, Vue, and Angular), and has been growing pretty quickly (up 2.25x for the year). I totally get that, even if we say growing downloads == growing user numbers, that doesn't necessarily mean a growth in market share, but it should be more than popular enough to keep its ecosystem going.

[rschristian]

Thanks!

With the surveys there's some discomfort with recommending/telling users to go fill them in, and I think Preact is in the slump between "early fervent evangelists" and "has influencers in the ecosystem instructing to do what maintainers might not themselves". Just my experience though.

FWIW, as of the start of the year, Preact could be found on 4% of websites. There's a non-zero % chance you're using it without realizing.

[TranquilMarmot]

For what it's worth, I thought Preact was more of a 1:1 replacement for React and that's why it's never shown on surveys- they would basically be listing the same thing twice.

Trying out fresh, I definitely see that Preact is quite a bit different from React.

I'd love to see a world where preact-compat and npm-based React libraries are easier to use with Fresh, since that would unblock some pretty huge roadblocks to building significantly sized apps.

[vicary]

I am a big fan of the new paradigm and the performance it brings, deno deploy also plays a big role in the beautiful performance!

I tried porting quite a few of my hobby projects into fresh, and honestly found the ecosystem is no match unless fresh brings preact to the light.

Many commonly used modules has a hard dependency on React, even loaded with skypack and/or esm.sh. For example, MUI and Formik. To resolve this issue, either these popular libraries need to include preact because enough voices are made, or the hosting platforms above allows local import maps to forcibly substitute their react dependencies similar to "resolutions" field in yarn's package.json. i.e. { "react": "https://esm.sh/preact/compat" }

[rschristian]

@vicary What do you mean by "brings preact into the light"? Again, it's not like it's a niche project.

esm.sh also has aliasing built-in, see: #432

[vicary]

@rschristian Thanks for sharing. While the alias is a nice touch, dependencies are usually more than that. For example Formik expects a SyntheticEvent/FormEvent AND ReactElement as children, while preact works on native DOM events and has it own VNode interface. This is only one example on how far the ecosystem is away from a trivial alias.

No matter how popular we want preact to be, it is just not (yet) the default.

I see that pnpm is actually gaining support for many packages, I hope preact will have it's place in the market just like pnpm.

[katopz]

Let's the data say for itself https://krausest.github.io/js-framework-benchmark/current.html

Anyway, I did try Svetle but I don't feel right for some reason.

[RussellPekko]

I know preact is excellent, but what if i just want to use native react ? Some react-based libs such as framer-motion could not run well in preact. It would be better if users could freely choose react or preact

[rschristian]

However, a person may not care about the island model for the react part of a page or route

To put it simply, if you don't care about Fresh's main selling point, Fresh probably isn't the best choice for you. And that's fine, there are other tools out there that will make you much happier.

I disagree, not an issue Fresh should care about.

It doesn't look like you've maintained anything in the way of OSS, so you probably can't appreciate the workload that going off the beaten path brings. The React team have been quite open with their dislike of tools like Astro and preference of Next, so if you're creating a tool in the space, you need to be aware of what the future looks like. For non-RSC islands, it looks pretty bleak w/ React.

It doesn't hurt Fresh to be open to client side frameworks.

Another instance of not being able to appreciate the workload if you haven't done OSS: it massively increases the maintenance burden to support multiple frameworks, and also limits features greatly, as you're limited by the least common denominator.

[AddictArts]

@rschristian I am tempted to be snarky, but I digress. We don't know each other and any GitHub searches or other don't really let you know anything about me. Regardless of what I do or have done a different point of view shouldn't be shot down by guessing about me personally.

[rschristian]

I have no power to shoot down anything here, just to be clear. I'm unaffiliated with Deno and Fresh, at best I might've made a docs PR once?

What you do or have done certainly affects your outlook on the viability of different features, and that's why I was hinting your (appearance of) lack of experience here isn't helping you appreciate the complexity. I have maintained OSS build tooling for years, and users always want to expand support, it's a constant ask. But it's difficult enough to support a singular external library alongside the features that really defined the tool -- adding other frameworks on top can quickly become a nightmare. It's a really hard thing to understand until you've been there, I certainly struggled with it.

It would hurt Fresh as what you suggest is to water down the identity ("a person may not care about the island model") and take resources away from some features in order to figure out React compat; not to mention, all future work also need to then support React too. It's always a balancing act.

For what it's worth, Aleph might be closer to what you're looking for from the sounds of it.

[AddictArts]

@rschristian et all.

I didn't suggest, never did .... I am not suggesting Fresh do anything, don't know why that was assumed. Just making the observation that the client, not fresh server can run any js it wants. Its a browser and it is not owned or controlled by fresh. Sure they miss out on features, no integration like the preact story. This does not hurt fresh in anyway.

[kylesloper]

Totally with @AddictArts here. A framework is pretty personal to the developer. To expect to move away from that to use the features Fresh provides is beyond unrealistic and unreasonable. Whilst it does increase complexity, allowing custom client-side frameworks far outweighs the bad in my opinion. I hope a system a little less opinionated (client-side) is considered by the team.

[ooker777]

Quoting @marvinhagemeister from discord discussion:

Lots of frameworks support TypeScript or could be used as underpinnings for the island architecture (see Astro). Fresh mainly picked Preact because it makes it easy to integrate with because it's pretty much the only framework that has a pluggable API to hook into the rendering mechanism at the time. For all other Frameworks you'd need to enhance the framework itself to support islands, but with Preact you can add it without having to change Preact itself. The fact that it's small and has a familiar API for many web developers helps too.

What Fresh gives you compared to using Preact alone is:

• routing automatic
• bundling of islands and the machinery to make them interactive on page load (remember Preact is just a JS lib not a build tool)
• a serialization layer that supports preact signals to transfer island props to the browser
• an API layer
• dev stuff like reloading the page when a component changes
• a server in general

All in all Fresh is a somewhat minimal wrapper around Preact. It's a similar relationship as Next.js has with React.

Two talks of @lucacasonato about Fresh:

• Fresh: a new full stack web framework for Deno with Luca Casonato - YouTube on Nick Taylor channel. This one focuses on introducing Fresh
• Deno's Fresh new web framework with Luca Casonato (JS Party Live!) - YouTube on Changelog channel. This one deeps dive into design rationale I guess

I also make this as a PR: b7408a3