8 ms·

Perseus is a state-driven web development framework for Rust with full support for server-side rendering and static generation. v0.4.0 went stable today after

Perseus is a state-driven web development framework for Rust with full support for server-side rendering and static generation. v0.4.0 went stable today after a year of development: https://github.com/framesurge/perseus/discussions/270 https://github.com/framesurge/perseus/discussions/270

pc2g4d 4y ago
Congrats! Looks really interesting!
pavlov 4y ago
I have to confess I have no idea what “state-driven” means in this context, and the website doesn’t help: “Perseus apps can generate state whenever they like” So it’s a… computer program? It feels like the word “state” is overloaded with some meaning that eludes me.
- tmikaeld 4y ago
  They explain it in the docs, here: https://framesurge.sh/perseus/en-US/docs/next/state/intro https://framesurge.sh/perseus/en-US/docs/next/state/intro Seems like snapshots of the current data view, in this case.
eric-burel 4y ago
Please don't make the mistake of differentiating SSR and SSG, even Next slowly moves away from this arguably bad naming. There is only server-rendering, and it can happen on request, or be pre-computed at build-time, or everything in between. The SSR/SSG thing is historical, trips most beginners, and may mislead implementation. Otherwise cool initiative, many Next devs are learning Rust too since it's part of the codebase.
- eric-burel 4y ago
  Making i18n a special case is also something Next is moving away. I18n is just an example of personalization, like multi-tenancy, AB tests for instance. Support personalization and you get all those for free. From the readme it seems a good clone of Next 12, but a very small step behind the current rationales that explain Next 13 design choices. Again still very cool project!
- aww_dang 4y ago
  I always thought of static sites as prebuilt from templates, whereas traditional SSR sites populate the templates (think jsp or php) on demand. Depending on the framework, the SSR page might already be cached and be effectively static.
  - eric-burel 4y ago
    Yes seeing it as a cache, where the cache key is a transformation of the user request (including requests to "static" pages) is a better model that leads to a unified vision of SSR/SSG
    - anonymous_sorry 4y ago
      I get that you can see it that way. If you were going to use server-side rending (SSR) anyway you can claim that static site generation (SSG) is a special case supported by any SSR framework. Or perhaps even that SSR is a generalisation of SSG to support dynamic content. But it feels like a bit of a stretch. The whole point of SSG is to simplify your architecture and tooling by forgoing the ability to dynamically render content on the server. It is a trade-off that won't be suitable for every application, and that's absolutely fine. If you want to argue that SSR tooling can be so simple and cheap that the SSG trade-off isn't worth it, then I'm keen to learn about that. But to elide the distinction between the two seems unhelpful to me.
      - eric-burel 4y ago
        I mean the framework can of course differientiate those use cases clearly, static and dynamic still exist in Next 13 App Router. But making them totally separate is a mistake too. Namely what bothers me is that a few points made in the docs or by users in this comment section show a limited visions of static rendering. It is certainly not limited to generic content that is the same for all users, I've built enough counter-examples to prove it.
        anonymous_sorry 4y ago
- eric-burel 4y ago
  An example from the doc about state: "For instance, you can't generate personalized dashboard pages at build-time, because you don't know yet who your users are" That's an outdated take, it's been proven wrong, otherwise you wouldnt be able to implement static i18n. The extreme case where you have a version of the page for just 1 user is totally doable and can be relevant (say a version of the page just for the admin).
- Tehnix 4y ago
  IMHO it's a huuuge mistake to try and squash these two very distinctly different things into one word (SSR), and it has added a ton of confusion to many with Next.js's move away from it. - SSR: Dynamic rendering of paths, happening at runtime. - SSG: Static rendering of paths, happening at compile time. A separation makes it much clearer that the core difference here is that SSG can only take you as far as "something generic for everyone" and SSR will be able to render "a page unique for a specific user". Infrastructure-wise there is a world of difference between the two approaches and they are not even close to being related. - SSR: You'll need servers, scaling, load balancing, etc. - SSG: CDN + S3 and you're done EDIT: To add a bit, imagine the following "I'm using SSR.", "Ah, cool, like full SSR or only half SSR?", "Only half, serving static files" - at this point, it's clear that we've now overloaded SSR to be a less useful term to describe what it is, which I personally find quite unfortunate.
  - vlovich123 4y ago
    I don’t know. I think a good SSR library + some clever front end frameworks + an edge compute platform where you don’t have to worry about anny scaling and you’re done. I’ve seen some really impressive demos of stuff that is extremely dynamic (ie per request), rendered server side on first use for the immediate portion you need with transparent hydration in the background to download interactivity as needed. Sure it seems more complicated ha CDN + S3, but I think in actuality it’ll be simpler in application. It all works super slick and conceptually there’s actually very little complexity for those applying it (the frameworks take care of the difficult bits). Since this is happening at the edge (in Cloudflare’s case, where I work, within something like 50ms of transit time to 95% of the population), and you’re only doing the initial view, you can get websites that load large pieces of content much more quickly than rendering it client side which is dominated by less powerful devices (ie SSR+transfer time is competitive) with less bandwidth/higher latency if you’re collating responses from different backends. You could even see that extending where they prefetch the raw data you’ll need to render the rest of the page in the background and either prepare a rendering, just bring it closer into the cache as a prefetch, or even push it to your browser proactively. Now of course it’s possible this stuff won’t generalize but I don’t see any obvious obstacles. It feels like within 10 years this could be the dominant way client web apps will be written. I get that we originally used to do that but it’s about taking the best of both worlds (SSR let’s you get super high performance initial loads while dynamic client side handling let’s you handle interactivity better and doing it transparently makes your development process a heck of a lot simpler as you don’t really need to differentiate the code as much (whereas I think you would with SSG+SSR). For SSG you probably don’t need to find general pieces of content and set up a different layer vs changing some caching parameters / doing content based hashing transparently. I think that’s maybe the direction OP was heading with in his remark of the distinction not being helpful.
dbtc 4y ago
What is 'state-driven'? Thank you.
- eurasiantiger 4y ago
  Like React: view = component(state)
lionkor 4y ago
no semver?
allisdust 4y ago
Looks great. Is it possible to use css frameworks with it (let's say bootstrap etc). I'm trying to understand where this fits in the overall stack. Is it possible to use react libraries with it.
- theironhammer 4y ago
  You can use Tailwindcss with Leptos and get intellisense. See point number 3: https://github.com/leptos-rs/leptos/discussions/125 https://github.com/leptos-rs/leptos/discussions/125
KRAKRISMOTT 4y ago
It's funny that you named a framework for a language that emphasizes safety, "The Destroyer".
theironhammer 4y ago
It uses Signals as well and does not use a VDOM. Leptos is another frontend library that uses Signals and does not use a VDOM. https://github.com/leptos-rs https://github.com/leptos-rs I think the key feature of these frontend frameworks is they enable Rust developers to do full-stack web development in the same way Nodejs enabled front end developers to do full-stack.

pc2g4d 4y ago

Congrats! Looks really interesting!

pavlov 4y ago

I have to confess I have no idea what “state-driven” means in this context, and the website doesn’t help: “Perseus apps can generate state whenever they like” So it’s a… computer program? It feels like the word “state” is overloaded with some meaning that eludes me.

tmikaeld 4y ago
They explain it in the docs, here: https://framesurge.sh/perseus/en-US/docs/next/state/intro https://framesurge.sh/perseus/en-US/docs/next/state/intro Seems like snapshots of the current data view, in this case.

eric-burel 4y ago

Please don't make the mistake of differentiating SSR and SSG, even Next slowly moves away from this arguably bad naming. There is only server-rendering, and it can happen on request, or be pre-computed at build-time, or everything in between. The SSR/SSG thing is historical, trips most beginners, and may mislead implementation. Otherwise cool initiative, many Next devs are learning Rust too since it's part of the codebase.

eric-burel 4y ago
Making i18n a special case is also something Next is moving away. I18n is just an example of personalization, like multi-tenancy, AB tests for instance. Support personalization and you get all those for free. From the readme it seems a good clone of Next 12, but a very small step behind the current rationales that explain Next 13 design choices. Again still very cool project!
aww_dang 4y ago
I always thought of static sites as prebuilt from templates, whereas traditional SSR sites populate the templates (think jsp or php) on demand. Depending on the framework, the SSR page might already be cached and be effectively static.
- eric-burel 4y ago
  Yes seeing it as a cache, where the cache key is a transformation of the user request (including requests to "static" pages) is a better model that leads to a unified vision of SSR/SSG
  - anonymous_sorry 4y ago
    I get that you can see it that way. If you were going to use server-side rending (SSR) anyway you can claim that static site generation (SSG) is a special case supported by any SSR framework. Or perhaps even that SSR is a generalisation of SSG to support dynamic content. But it feels like a bit of a stretch. The whole point of SSG is to simplify your architecture and tooling by forgoing the ability to dynamically render content on the server. It is a trade-off that won't be suitable for every application, and that's absolutely fine. If you want to argue that SSR tooling can be so simple and cheap that the SSG trade-off isn't worth it, then I'm keen to learn about that. But to elide the distinction between the two seems unhelpful to me.
    - eric-burel 4y ago
      I mean the framework can of course differientiate those use cases clearly, static and dynamic still exist in Next 13 App Router. But making them totally separate is a mistake too. Namely what bothers me is that a few points made in the docs or by users in this comment section show a limited visions of static rendering. It is certainly not limited to generic content that is the same for all users, I've built enough counter-examples to prove it.
      - anonymous_sorry 4y ago
eric-burel 4y ago
An example from the doc about state: "For instance, you can't generate personalized dashboard pages at build-time, because you don't know yet who your users are" That's an outdated take, it's been proven wrong, otherwise you wouldnt be able to implement static i18n. The extreme case where you have a version of the page for just 1 user is totally doable and can be relevant (say a version of the page just for the admin).
Tehnix 4y ago
IMHO it's a huuuge mistake to try and squash these two very distinctly different things into one word (SSR), and it has added a ton of confusion to many with Next.js's move away from it. - SSR: Dynamic rendering of paths, happening at runtime. - SSG: Static rendering of paths, happening at compile time. A separation makes it much clearer that the core difference here is that SSG can only take you as far as "something generic for everyone" and SSR will be able to render "a page unique for a specific user". Infrastructure-wise there is a world of difference between the two approaches and they are not even close to being related. - SSR: You'll need servers, scaling, load balancing, etc. - SSG: CDN + S3 and you're done EDIT: To add a bit, imagine the following "I'm using SSR.", "Ah, cool, like full SSR or only half SSR?", "Only half, serving static files" - at this point, it's clear that we've now overloaded SSR to be a less useful term to describe what it is, which I personally find quite unfortunate.
- vlovich123 4y ago
  I don’t know. I think a good SSR library + some clever front end frameworks + an edge compute platform where you don’t have to worry about anny scaling and you’re done. I’ve seen some really impressive demos of stuff that is extremely dynamic (ie per request), rendered server side on first use for the immediate portion you need with transparent hydration in the background to download interactivity as needed. Sure it seems more complicated ha CDN + S3, but I think in actuality it’ll be simpler in application. It all works super slick and conceptually there’s actually very little complexity for those applying it (the frameworks take care of the difficult bits). Since this is happening at the edge (in Cloudflare’s case, where I work, within something like 50ms of transit time to 95% of the population), and you’re only doing the initial view, you can get websites that load large pieces of content much more quickly than rendering it client side which is dominated by less powerful devices (ie SSR+transfer time is competitive) with less bandwidth/higher latency if you’re collating responses from different backends. You could even see that extending where they prefetch the raw data you’ll need to render the rest of the page in the background and either prepare a rendering, just bring it closer into the cache as a prefetch, or even push it to your browser proactively. Now of course it’s possible this stuff won’t generalize but I don’t see any obvious obstacles. It feels like within 10 years this could be the dominant way client web apps will be written. I get that we originally used to do that but it’s about taking the best of both worlds (SSR let’s you get super high performance initial loads while dynamic client side handling let’s you handle interactivity better and doing it transparently makes your development process a heck of a lot simpler as you don’t really need to differentiate the code as much (whereas I think you would with SSG+SSR). For SSG you probably don’t need to find general pieces of content and set up a different layer vs changing some caching parameters / doing content based hashing transparently. I think that’s maybe the direction OP was heading with in his remark of the distinction not being helpful.

dbtc 4y ago

What is 'state-driven'? Thank you.

eurasiantiger 4y ago
Like React: view = component(state)

lionkor 4y ago

no semver?

allisdust 4y ago

Looks great. Is it possible to use css frameworks with it (let's say bootstrap etc). I'm trying to understand where this fits in the overall stack. Is it possible to use react libraries with it.

theironhammer 4y ago
You can use Tailwindcss with Leptos and get intellisense. See point number 3: https://github.com/leptos-rs/leptos/discussions/125 https://github.com/leptos-rs/leptos/discussions/125

KRAKRISMOTT 4y ago

It's funny that you named a framework for a language that emphasizes safety, "The Destroyer".

theironhammer 4y ago

It uses Signals as well and does not use a VDOM. Leptos is another frontend library that uses Signals and does not use a VDOM. https://github.com/leptos-rs https://github.com/leptos-rs I think the key feature of these frontend frameworks is they enable Rust developers to do full-stack web development in the same way Nodejs enabled front end developers to do full-stack.