Support preact

[lucacasonato]

I would like to use preact instead of react :-)

[ije]

in fact you can replace the react import url to preact/compat in the aleph.config.js

export default {
  reactUrl: 'https://esm.sh/preact/compat',
  reactDomUrl: 'https://esm.sh/preact/compat',
  ...
}

but the SSR and fast refresh may break. i'm planning to use esbuild or swc instead of tsc in v0.3, also needs a stable fast refresh plugin in the new compiler, preact should be supported straightway in the future.

[lucacasonato]

Awesome. FYI preact has a hot refresh plugin too: https://github.com/JoviDeCroock/prefresh

[ije]

i see, thanks

[mohsenkhanpour]

@ije
It's interesting that the first issue (#1) with Aleph.js is preact support. I sometimes feel SSR frameworks build React too much into the framework that when it is replaced by Preact some functionality would not work as expected.

According to Dan Abramov:

It seems like the common thread is that you use React in development and Preact in production. To me, this sounds like an extremely fragile setup because Preact is known to have behavior differences and incompatibilities with React, but that's your call. What I think is happening here is that Gatsby detects React supports the new JSX transform (so it uses it), but it isn't aware of the Preact override, and I think maybe Preact doesn't support it yet (?)

There are many frameworks that do the same thing but just with another templating library. Take Next.js, Nuxt.js and Gatsby/Gridsome and sapper.

There are many things in this SSG/SSR game that are not framework dependent:

Take PWA, it's just manifest attribute added to html tag, it doesn't depend necessarily on React it can be injected to final rendered html:

<link rel="manifest" href="manifest.webmanifest">

Take analytics for example with a simple plugin you can inject analytics to the final rendered html, whether it's rendered by React's render to string method or Preact's or Vue's.

Take serverless functions, image optimization, data sourcing...

Now that you are working on the compiler it would be wise to to implement architecture in a way that view layer is modulated and handles its own render to string method and rehydration. Having an architecture like that also makes it easy to support other frameworks such as preact or vue along the way.

I suggest renaming this issue (so it's not only limited to preact) to "Support other frameworks" so we can discuss the possibility of how such architecture can be achieved.

I think one way would be have an app.html instead of app.tsx and plugins can mount frameworks (React, Preact, Vue, etc) to app.html (similar to how sapper does it) after their relative components are rendered to strings.

A sample concept would be:

.
└── ./pages/
    ├── ./pages/[username]/
    │   ├── ./pages/[username]/index.tsx
    │   └── ./pages/[username]/settings.tsx
    ├── ./pages/blog/
    │   ├── ./pages/blog/index.vue
    │   └── ./pages/blog/post-[id].vue
    └── ./pages/index.tsx

after configuring plugins via aleph.config.js in a folder structure like this, .tsx pages are handled by react plugin or preact plugin if configured (so it's just not replacing the react package with preact and hoping everything would work), and .vue pages are handled by vue plugin and after they are rendered to string they are appended to app.html body, then all the analytics and PWA stuff are injected.

P.S:
Nuxt.js was created to bring something similar to Next.js to Vue.
Gridsome was created to bring something similar to Gatsby.js to Vue.
Sapper was created to bring SSR/SSG logic for Svelte.

Doing the architecture right is gonna save a lot of people from rewriting the same logic for another framework in Deno 🦖.

[ije]

@mohsenkhanpour interesting, it's a big challenge to implement SSR/SSG/Routing/HMR for hybrid frameworks. Aleph's goal is to implement production-ready full-stack framework with jsx in Deno, preact can be compatible easy but vue or other frameworks are not in the planning. i understand it is pain to bring Node ecosystem to Deno, but i need to focus on minimal implement for the framwork. i prefer to create a deno verison of nuxt for vue users in Deno.
thanks, that is helpful, i'm look for vue's Composition api to get more info about Vue with jsx syntax, maybe we can support vue in the future.

[mohsenkhanpour]

Yes, exactly.
I don't mean that Aleph.js should support vue out of the box.
What I am saying is if Aleph.js provides the right abstractions, and hooks into its lifecycle it would make it easier for the community to write up their own plugin to support other libraries.

SSG with these libraries is mainly focused on "render to string" method which most libraries already have.
SSR is static generation on the server side + the option to include the library on client side for rehydration.
For routing and HMR, most frameworks already have production ready libraries and they work very similar to each other in terms of abstractions.

It's really interesting that Aleph.js also supports markdown *.md files in pages, I suppose these markdown files are statically generated then injected to the app.tsx. I wonder if routing for these markdown pages are static or dependent on React.

One idea would be to check the extension of the files in 'pages' directory and according to extension Aleph.js process these extensions through their relative plugins. However for these plugins to be able to exist, some abstractions need to be exposed via Aleph.js

[shadowtime2000]

in fact you can replace the react import url to preact/compat in the aleph.config.js

export default {
  reactUrl: 'https://esm.sh/preact/compat',
  reactDomUrl: 'https://esm.sh/preact/compat',
  ...
}

but the SSR and fast refresh may break. i'm planning to use esbuild or swc instead of tsc in v0.3, also needs a stable fast refresh plugin in the new compiler, preact should be supported straightway in the future.

@ije Would this aliasing still work because most of the components such as links and head tag are importing directly from esm.sh/react.

[shadowtime2000]

Also @mohsenkhanpour we are moving to a system like you are proposing where plugins can hook into Aleph to add support for different frameworks - or so I think.

[ije]

@shadowtime2000 nope, the custom React URL has been removed. we should implement the a framework for it.

[shadowtime2000]

@ije Do you think we should start working on a framework system? Also, I think we could allow frameworks to allow passing options to them, so like with React we could allow changing the URLs of the libraries, or we could instead add aliasing to the compiler/bundler.