Perseus is a blazingly fast frontend web development framework built in Rust with support for major rendering strategies

Related tags

rust ssr ssg


BookCrate PageAPI DocumentationContributing

Perseus is a blazingly fast frontend web development framework built in Rust with support for major rendering strategies, reactivity without a virtual DOM, and extreme customizability. It wraps the lower-level capabilities of Sycamore and provides a NextJS-like API!

  • Supports static generation (serving only static resources)
  • Supports server-side rendering (serving dynamic resources)
  • Supports revalidation after time and/or with custom logic (updating rendered pages)
  • Supports incremental regeneration (build on demand)
  • Open build matrix (use any rendering strategy with anything else, mostly)
  • CLI harness that lets you build apps with ease and confidence
  • Full i18n support out-of-the-box with Fluent

How to use

Check out the docs here for how to use Perseus.


Support every major rendering strategy and provide developers the ability to efficiently create super-fast apps with Rust and a fantastic developer experience!


There is a sore lack of Rust frameworks for frontend development that support more than just SPAs and client-side rendering, and so Perseus was born. We need something like NextJS for WASM.



These tasks still need to be done before Perseus can be pushed to v1.0.0.

  • Create a custom CLI as a harness for apps without ridiculous amounts of configuration needed
  • Support custom template hierarchies
  • Support i18n out of the box
  • (Maybe) Implement custom router
  • Pre-built integrations for Actix Web (done) and AWS Lambda (todo)


These tasks will be done after Perseus is stable.

  • Integrations for other platforms


We appreciate all kinds of contributions, check out our contributing guidelines for more information! Also, please be sure to follow our code of conduct.

You can also chat about Perseus at our Gitter link, or (for Sycamore-related stuff) on our channel on Sycamore's Discord server.



  • Update Sycamore to v0.6.0

    Update Sycamore to v0.6.0

    Updates sycamore to 0.6.0, removes patch dependencies

    opened by lukechu10 9
  • Possible project renaming

    Possible project renaming

    This project was originally named Perseus because of the inspiration as an extension of Percy, but Sycamore turned out to be much better for the job, and 'Sycamoreus' didn't quite flow off the tongue, so I stuck with Perseus.

    The beta version of this project is now ready, but before I publish it, I want to decide on a name for the project for now. This is a tracking issue for that.

    opened by arctic-hen7 8
  • Router not executed on page changes

    Router not executed on page changes

    This is a tracking issues for a series of bugs in Perseus related to the custom routing systems.

    • Locale detection routes to blank page that only renders on reload, going back triggers panic
    • Clicking a link will do nothing, panicking in the background, but it works the second time

    These bugs are all to do with the way Sycamore currently handles its ContextProvider system (detailed here), and they should all be fixed by this PR in Sycamore, which will be released shortly with Sycamore v0.6.0.

    After that, those updates will be integrated into Perseus for v0.2.0, and this issue should then be closable. This primarily exists to forewarn anyone who has decided to compile the main branch and is experiencing these issues.

    opened by arctic-hen7 7
  • Improve SEO and initial load

    Improve SEO and initial load

    This is a big change to the existing initial render model, and one that I've wanted to make for a while.

    Presently, on first load, the user is sent a generic HTML file, no matter what page they asked for, which includes the app shell, which then fetches the appropriate content. However, this means two round trips to load the first page, and then the app shell smoothly takes over from there. This also means that any crawlers that don't execute Wasm won't get anything except a blank screen, which is atrocious SEO.

    The solution I propose is instead performing the app shell process on the server for the first time a user requests a page, then rendering the page as normal on the server and injecting it into that generic HTML file. That way, the user will always be served a complete page on first render, and then the app shell takes over.

    I should clarify that this problem only applies to the first render. All further navigations are handled internally by the app shell, which makes things much smoother, almost like an SPA (but much better on the server).

    This approach is also friendlier to a future exporting system, because this process could be performed for every page in an export stage, and thus a fully static site could be created, eliminating the need for the server for projects that don't need more complex request-time strategies.

    opened by arctic-hen7 6
  • Remove/Replace Rollup.js

    Remove/Replace Rollup.js

    It would be good to have the option to do without Rollup.js and npm entirely. At least in my case i am searching for Rust frontend tools because i want to stay away from npm and its ecosystem. I don't want to go into details about the "why" here, but i am wondering what alternatives we have. I am not very familiar with perseus yet and going through the book Building Your First App i was unpleasantly surprised to see npm i -g rollup which is a show-stopper in my case. I don't want to elevate this as a major problem for the project, because its just my personal taste – but i am wondering if we could have an easy to integrate (rusty) alternative that is as powerful as Rollup.js yet and can serve the same needs. I am very happy with Trunk and Sycamore/seed-rs/yew and was wondering what exactly is different here that make Rollup.js mandatory.

    opened by pythoneer 5
  • Add native i18n support

    Add native i18n support

    Perseus should be able to support i18n effortlessly and without increasing build times.

    I propose this is done by not changing any part of the existing build mechanism (yet), but simply by adding a section on the server that replaces all translation IDs, indicated maybe by <>, with their translation at request-time, then caching the translated HTML/JSON files for future usage for that page and locale combination. This is essentially a very specialized use-case of incremental rendering combined with the build paths strategy, that I would propose deliberately isolating from the rest of the build matrix to improve simplicity and maintainability. Caching as described would also mean that build times wouldn't increase at all, unless some particular locales need to be pre-rendered for for certain pages, which could be specified in the define_app! macro.

    The problem with this find-and-replace approach is of course that any translations dynamically added on the client by the Wasm code won't be translated. So, a struct could be passed to every template that provides a method for translation and stores the translations for the current locale (the app shell would instantiate this on loading a new locale). Then, every translation is wrapped in this (as in just about every other i18n library ever), and it then works! But, we optimize even further by combining this with the previous strategy and then simply checking in the function if its parameter is properly indicated as a translation ID. If not, it's been replaced at build and so we don't need to do anything.

    This would also be friendly to a future exporting system because the request-time translation process could simply be performed for every page in an exporting process, leaving the user with a purely static site if they don't need more complex request-time rendering strategies.

    • [x] Add support for translators
    • [x] Feature-gate translator API to prevent locking users in
    • [x] Integrate with Fluent
    • [x] Make changes necessary to app definition systems
    • [x] Implement translations caching
    • [x] Create macros to make translation easy
    • [x] Create locale detection systems
    opened by arctic-hen7 2
  • First-time CLI builds are really slow

    First-time CLI builds are really slow

    The first time the CLI builds, it takes a very long time to complete. These are the stages it goes through for perseus serve:

    • Build all dependencies and the user's code (long)
    • Run static generation (almost instantaneous)
    • Build for Wasm (long)
    • Organize bundle (very quick)
    • Build all server dependencies and the user's code (long)
    • Run the server (almost instantaneous)

    There are a few infrastructure changes I want to propose to shorten first-time builds (and all further builds for that matter). First, a workspace should be constructed in the preparation stage so that the two subcrates share a target/ directory, which means the server doesn't need to rebuild everything. Second, run the build for static generation and the Wasm build in parallel (which can be done for different targets).

    These changes should significantly reduce initial build times, and further reduce later builds, making Perseus even faster in development. By increasing iteration time, we increase develop productivity, meaning people focus more on their own code and less on waiting at their terminals.

    • [x] Create workspace at runtime
    • [x] Parallelize builds
    enhancement performance 
    opened by arctic-hen7 2
  • CLI single-threaded mode

    CLI single-threaded mode

    Having set up the CLI to be perfectly asynchronous and parallelized, it occurs to me that there are most definitely systems that will have difficulty with this, or scenarios in which sequential execution may be preferred. I'm thinking particularly of systems with older Intel processors.

    In light of this, I think it's perfectly reasonable to create a single-threaded mode for the CLI to make execution less straining on these systems (though it will be considerably slower). This won't affect performance of the multi-threaded mode in any way, which will remain the default. I suggest specifying single threaded mode with --sequential.

    opened by arctic-hen7 1
  • New routing system

    New routing system

    Perseus currently actually has two routing systems: one for the client (which is based on Sycamore), and an unrelated system on the server. However, the latter is all that's actually required.

    The rationale behind this is that we already know everything about every page in the user's app except for the pages rendered with ISR, which are already handled by the old server-side algorithms. By using those, we'll be able to only perform routing on the client-side, and the server can act as an intermediary to static files (with request-time rendering strategies being applied there).

    This will achieve much tighter integration between templates and routing, as it requires no specification of any paths like /post/<slug..> whatsoever (again, Perseus isn't an SPA, we already know almost everything about routing at build-time from the templates). This means that the system of template root paths is now far more important, as it defines exactly how routing will work. This will be documented closely for v0.2.0.

    The only caveat of this approach that I see right now is no (current) support for dynamic parameters that come before the template root path, like i18n. As with that system, this would have to be implemented at a lower level outside the router. I'll think on possible ways to integrate this into the template-based routing systems.

    opened by arctic-hen7 1
  • Metadata modification

    Metadata modification

    Right now, modifying the <head> in Perseus is pretty painful, and it needs to be done directly with web_sys. Especially in light of #2, Perseus should support a new property on a Template<G> that creates a Sycamore template for the document head. That should then be rendered to a string and interpolated directly into the head after any existing elements there.

    This allows the user greater flexibility, and also allows the definition of universal properties on the <head>, which will be delimited from ones that are added with interpolation by a delimiter comment injected on the server-side.

    opened by arctic-hen7 1
  • Add capsules system

    Add capsules system

    This is a more ambitious feature, but I think it's doable! I want Perseus to be able to re-render only parts of content, say, keeping a sidebar and a header around while other content changes. The system to do this is too complex to explain here, but I'll publish a formalized document of how it will work soon.

    The central idea is that a page should be able to have a structure like Header -> Sidebar -> Content, and each new Content shouldn't trigger a re-render of Header and Sidebar. Moving to a new Sidebar equally shouldn't re-render the Header.

    opened by arctic-hen7 1
Hi! I'm a human that likes building cool stuff with code!
Actix Web is a powerful, pragmatic, and extremely fast web framework for Rust.

Actix Web is a powerful, pragmatic, and extremely fast web framework for Rust.

Actix 12.1k Sep 14, 2021
Seed is a Rust front-end framework for creating fast and reliable web apps with an Elm-like architecture.

Seed is a Rust front-end framework for creating fast and reliable web apps with an Elm-like architecture.

null 2.6k Sep 18, 2021
A html document syntax and operation library written in Rust, use APIs similar to jQuery.

Visdom A server-side html document syntax and operation library written in Rust, it uses apis similar to jQuery, left off the parts thoes only worked

轩子 34 Apr 22, 2021
Thruster - An fast and intuitive rust web framework

A fast, middleware based, web framework written in Rust

null 815 Sep 12, 2021
A full-featured and easy-to-use web framework with the Rust programming language.

Poem Framework A program is like a poem, you cannot write a poem without writing it. --- Dijkstra A full-featured and easy-to-use web framework with t

Poem Web 437 Sep 16, 2021
Sauron is an html web framework for building web-apps. It is heavily inspired by elm.

sauron Guide Sauron is an web framework for creating fast and interactive client side web application, as well as server-side rendering for back-end w

Jovansonlee Cesar 1.4k Sep 13, 2021
Rust / Wasm framework for building client web apps

Yew Rust / Wasm client web app framework Documentation (stable) | Documentation (latest) | Examples | Changelog | Roadmap | 简体中文文档 | 繁體中文文檔 | ドキュメント A

Yew Stack 17k Sep 13, 2021
A Rust web framework

cargonauts - a Rust web framework Documentation cargonauts is a Rust web framework intended for building maintainable, well-factored web apps. This pr

null 175 Feb 10, 2021
A rust web framework with safety and speed in mind.

darpi A web api framework with speed and safety in mind. One of the big goals is to catch all errors at compile time, if possible. The framework uses

null 30 Aug 25, 2021
A web framework for Rust.

Rocket Rocket is an async web framework for Rust with a focus on usability, security, extensibility, and speed. #[macro_use] extern crate rocket; #[g

Sergio Benitez 14.7k Sep 15, 2021
Rustypaste is a minimal file upload/pastebin service.

Rustypaste is a minimal file upload/pastebin service.

Orhun Parmaksız 49 Sep 14, 2021
Cross platform community web fingerprint identification tool

ObserverWard_0x727 English | 中文简体 category describe author 三米前有蕉皮 team 0x727 Open source tools will be available in the future. what for? Communalizat

0x727 116 Sep 9, 2021
Murasaki is a Fast, Secure, and Reliable Webkit based web browser.

Murasaki is a Fast, Secure, and Reliable Webkit based web browser. Table of Contents Goals Status Usage License Goals Security: Be secure, and not com

Moon Laboratories 3 Sep 6, 2021
Volt - A powerful, fast and memory safe package manager for the web

Volt - A powerful, fast and memory safe package manager for the web

Volt Package Manager 419 Sep 19, 2021
📮 An elegant Telegram bots framework for Rust

teloxide A full-featured framework that empowers you to easily build Telegram bots using the async/.await syntax in Rust. It handles all the difficult

teloxide 820 Sep 15, 2021
A super-easy, composable, web server framework for warp speeds.

warp A super-easy, composable, web server framework for warp speeds. The fundamental building block of warp is the Filter: they can be combined and co

Sean McArthur 5.3k Sep 13, 2021
Silkenweb - A library for writing reactive single page web apps

Silkenweb A library for building reactive single page web apps. Features Fine grained reactivity using signals to minimize DOM API calls No VDOM. Call

null 61 Jun 30, 2021
A fast static site generator in a single binary with everything built-in.

zola (né Gutenberg) A fast static site generator in a single binary with everything built-in. Documentation is available on its site or in the docs/co

Zola 7.4k Sep 18, 2021
Oso is an open source policy engine for authorization that’s embedded in your application

Oso What is Oso? Oso is an open source policy engine for authorization that’s embedded in your application. It provides a declarative policy language

oso 1.4k Sep 16, 2021