10 ms·

Perseus – NextJS alternative in Rust

198 points by erlend_sh 4y ago

erlend_sh 4y ago
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.
- 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.
quantumwoke 4y ago
Congrats on the release. I have to admit looking at the code samples, this looks like some pretty tough to swallow ergonomics for real-world usage. Is this inherent to Rust web libraries?
- __pache__ 4y ago
  I was pretty horrified, myself :(
  - re-thc 4y ago
    Definitely didn't feel anything like NextJs to me.
Freedom2 4y ago
This is great! I've had a bit of a play around and the code examples are nice and easy to follow. Definitely liking it more than the JSX route that a lot of modern frameworks are taking these days - this way is much cleaner and easier to read.
- sergiomattei 4y ago
  I’m struggling to see how this is cleaner and easier to read than JSX. JSX resembles web technologies, it “smells and looks like” HTML and JavaScript. It’s easy to pick up and read. If you know HTML and JavaScript, onboarding to React isn’t bad. However, this framework looks like an abomination for real world usage. It’s in WASM, written in Rust (!?). It doesn’t resemble any sort of web technology other than the tag names. How do you onboard a frontend team to this? Perhaps to rust-aceans, this makes sense. Is there something I’m not seeing here?
  - deleted 4y ago
    [deleted]
  - dzikimarian 4y ago
    I think that whole point is to not resemble Javascript. I kinda like it, in my experience current state of JS is layers and layers of tools stitched together over language that was designed for much simpler times. Compared to other stacks I worked with it's often unstable, slow and poorly documented. I tend to avoid doing fronted if I can. Fresh and different look at this topic is something I would very much like to see. Of course for people working with front end today may have different perspective.
    - avx56 4y ago
      It still targets the browser though, so you still get all the complexities anyway, just without well supported syntax. Idk man I like Rust but this doesn't seem like the right way here.
  - rwalle 4y ago
    I agree with you. I don't think anyone who has spent enough time with React/Vue.js would want to switch to something like this. I cannot imagine what the code would like when you have a lot more components and nesting. I would write frontend code like this if I really want to punish myself.
elAhmo 4y ago
If I were looking for an alternative in NextJS, looking for something built in Rust would definitely not be in top of my mind. I would assume this kind of movement from JS -> Rust would be quite rare.
- Gigachad 4y ago
  The versatility of Rust is quite impressive. Its looking like given a few years for these frameworks to mature, Rust could end up being a great job for just about every task.
  - szundi 4y ago
    There will always be some better tool for a given niche task than a general one.
  - rapsey 4y ago
    I do not think so. There will always be way more mental overhead in using Rust compared to higher level languages.
    - pkolaczk 4y ago
      Rust is both a low level but also a high level language. There aren't many mainstream languages that can go higher level than Rust with its traits, sum types, generics and macros. Haskell, Scala, maybe C++ to some degree, what else?
      - pjmlp 4y ago
        OCaml, F#, Kotlin, Ada, Swift.
        pas 4y ago
        Those are not real languages! After all what can you do with OCaml for ex? A compiler for a Rust-like language at best? :)
pachico 4y ago
I have this feeling that I am wasting my time by not learning Rust. I am a proficient Go programmer but I have this sensation I cannot really describe about that not being enough. I feel something similar with Zig. Am I the only one?
- impulser_ 4y ago
  I'm the opposite. Everytime I'm using Rust I feel like I'm wasting my time not using Go.
  - Patrickmi 4y ago
    Honestly I get that feeling, when it comes to compile times it feels like a thousand years, it’s discouraging
- truthsayer123 4y ago
  Do you think moving to Rust would help you make enough money to retire in the next 3 years? If yes do it. It will definitely help you save the rest of your life and spend more time with your loved ones. If you think Rust doesn't really matter for that and you can even do that with PHP and it's the problem and the execution that matters then focus on building a great product instead of getting into the Hype wagon and missing out on the bigger picture of what really matters.
  - pachico 4y ago
    Believe it or not, this sensation isn't about a professional uplift but as engineering. I don't even code much anymore since I work mostly on platform related issues. And, BTW, I have a high respect for PHP and what you can achieve with it.
  - dzikimarian 4y ago
    Sometimes you need to understand broader surrounding to make sure you're building something great. I think every mature developer should understand tooling in his/her area and possibilities it brings. Do you want, in the next 20 years, to have cardiologist that's focused on early retirement, not on the result?
noobcoder 4y ago
This seems to be faster than Svelte. I guess its because of Sycamore under the hood https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...
unconed 4y ago
I don't know why I would replace JS code I can quickly mod and extend with a stack I have to compile and write in a whole different language in. How am I supposed to ship plugins for these new rustified frameworks and build systems?
jbandela1 4y ago
I went down this Rust front end route with my trivia web app [0], but ended up abandoning it. There were just too many points of friction. * The tooling is not nearly as good as JavaScript for the front end. * Every time you want to use a front end library, you have to figure it out yourself as there won’t be any documentation for how to use it with your framework. * Rust compile times really break your flow when working on front end code. At least for me, for front end coding, there is a lot of interactive development where you look at the web app on desktop/mobile and adjust element size/spacing etc to make sure things look nice. Doing this in real-time with JavaScript/html/css is nice. Having a Rust compile between each step is a pain. * For front-end code, Rust’s borrow checker really gets in the way. The JavaScript garbage collector works really well front front-end code. Rust’s borrow checker is not bringing any performance advantages for this use case and brings a lot of complexity. On the backend, you can justify the complexity of Rust with appeals to efficiency/scalability/server cost. With front end code which is running on the client, you lose that justification. I ended up going with React/TailwindCSS and have been happy so far. 0. triviarex.com
- aww_dang 4y ago
  >Doing this in real-time with JavaScript/html/css is nice. Having a Rust compile between each step is a pain. I'm more of a JS-lite builder. Typically I will only decorate pages with the necessary JS for interactivity. Happier using traditional SSR. Pages load with no spinner or reflow. Sometimes I inline a JSON blob for state. For the layout tweaks you describe, I typically edit the displayed page in Chrome's developer tools. Once I am satisfied I apply those changes to the template and JS. This feels more ergonomic than refreshing the page. I imagine the same technique would apply to the unified Rust front-end/back-end experience. Just edit the rendered page in developer tools. I've never been an early adopter. Let's see how this shapes out for version 1.0 or if another framework overtakes it.
  - cowsandmilk 4y ago
    Hot reloading is still a widely loved feature for server side rendering. It is part of what mad PHP widely popular and many other frameworks have auto recompilation and reloading on watching changes. The smoothness of automatic recompilation falls apart the longer it takes to compile and rust is not known for fast compiles.
sesm 4y ago
If it’s a NextJS alternative then it supports client-side components too? Is client-side code written in Rust? Is it then compiled to JS or to WASM? Couldn’t find those answers from quick look at the website and GitHub page.
- lyjackal 4y ago
  Yes, it’s full stack framework that compiled front end to wasm. They mention it in the QuickStart https://framesurge.sh/perseus/en-US/docs/0.4.x/quickstart https://framesurge.sh/perseus/en-US/docs/0.4.x/quickstart
sbmthakur 4y ago
Next.js itself uses a compiler written in Rust. https://nextjs.org/docs/advanced-features/compiler https://nextjs.org/docs/advanced-features/compiler
lucasyvas 4y ago
Great project! Tangential, but I've been thinking about this a lot lately and have an idea of what I'd like to see attempted next in this area. Like many have said, the JS framework ecosystem (ok, while kind of a meme much of the time) is a total juggernaut. I wouldn't mind seeing some kind of.. unholy combination of SSR for JS frameworks with a Rust (or even other language) backend if it was feasible. JS is still a lot more mature and ergonomic for front-end. Rust is kind of a chore for this kind of work currently. It works, but wasn't designed for it and it feels a bit clumsy. On the flip side, Rust is a safe and super fast server language (Go a great choice as well, or others too). I suppose I'd like to see some kind of framework that makes it easier to pair the two, instead of insisting that a single language isomorphic approach is best. This might not be practical - I feel like routing might end up being a nightmare. I'm more just saying it seems harder to pair peanut butter with jelly than it should be and someone smarter than me could probably figure it out :). I'm naively guessing that as long as you had a JS interpreter on the server side, it could be made to work (no problem in Rust for either Node or Deno since embedding those is possible). We've got thing like Next, SvelteKit, and Fresh. We've also got things like LiveView - there may be a further middleground between the two.
- clintonb 4y ago
  What problem are you solving with this “unholy combination”? Typescript gives you the relative safety. If you need faster compilation than tsc, you can use swc.
- POiNTx 4y ago
  I've been working on LiveSvelte[0] which might answer this in the LiveView example. It integrates LiveView with Svelte and has SSR support by calling Node from within Elixir, I wouldn't call it unholy, it's quite nice :) Routing is fully handled by Phoenix, and you can get quite fast page transitions with Live Navigation Events. It's just that whenever you need complex frontend state you can offload it to Svelte, while still maintaining that backend interopability, in this case with E2E reactivity. What's also really nice is that LiveView and Svelte are both very declarative in the way they handle the 'view' layer. And so they map really well onto eachother. I also wrote a blogpost[1] on the topic. [0]: https://github.com/woutdp/live_svelte https://github.com/woutdp/live_svelte [1]: https://wout.space/notes/live-svelte https://wout.space/notes/live-svelte
deleted 4y ago
[deleted]
jstummbillig 4y ago
What problem is this solving? It's easy to spot ones that it's introducing.
- satvikpendem 4y ago
  If you're going to mention problems, perhaps provide a more substantial comment about what problems you believe it's introducing.
  - rochak 4y ago
    When you are the only person leveraging stuff like this, it’s all good. The moment you try to bring in other people who don’t have much experience with Rust, you are done for. No matter what you think, people who are developing websites and people who prefer writing everything in Rust just don’t have much overlap.
    - satvikpendem 4y ago
      I agree, I don't see much overlap either, and when you run into problems, these Rust frontend frameworks will certainly have lower userbases to ask for help from than for, say, a React app. I'm building a web app with React (Next.js) on the frontend and Rust on the backend, no way I'd use a full Rust or full TypeScript stack.
dawnerd 4y ago
I'm looking at the examples but it just looks like a lot more boilerplate than what I have when building a normal page in Nextjs. But I also think their comparison table isn't very fair. You can easily have perfect lighthouse scores in Nextjs, and Nextjs supports both SSG and SSR in the same file... not sure why it says otherwise. https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration https://nextjs.org/docs/basic-features/data-fetching/increme... And for the internationalization note saying it's only partially supported https://nextjs.org/docs/advanced-features/i18n-routing https://nextjs.org/docs/advanced-features/i18n-routing
- rwalle 4y ago
  Yeah, if they cannot get even the "Hello World" example to be simple and straightforward, I don't know why anyone would switch from the status quo. It's a ton of added complexity.
iamgopal 4y ago
Equivalent to this in go ?
TobyTheDog123 4y ago
I truly do not understand this Rust-for-all-problems mentality. I was under the impression that Rust was essentially the next generation of C, meant for things like compilers, embedded systems, and other places where memory truly matters. Why are we shoehorning it into things like REST APIs and frontend frameworks? One look at that syntax and I'd think anyone could see it's not the right tool for the job, even if there room for disruption in those spaces.
- javcasas 4y ago
  Believe it or not, there are REST APIs and frontend frameworks for almost every programming language under the sun. And I mean EVERY. Example: this Prolog works in your browser https://github.com/SWI-Prolog/swish https://github.com/SWI-Prolog/swish, and this is the corresponding package to do the API https://www.swi-prolog.org/pldoc/man?section=http-running-server https://www.swi-prolog.org/pldoc/man?section=http-running-se... But I can agree Rust has better marketing than Prolog.
- rochak 4y ago
  +1. I’m all for using the right tool for the job. It seems like all these technologies are to cater to specific niche of engineers and that’s the exact reason why they don’t have the longevity.
marmee 4y ago
Can someone please explain how Rust and frontend converge so often? In my mind Rust is similar to C++ including the very ugly syntax and fixation on memory management, while frontend languages are well.. exactly not that. Why?
- dagmx 4y ago
  It’s fast to execute, easy to work with and easy to use a single binary distribution. All points that make it popular to replace slower tooling on the frontend
  - marmee 4y ago
    Fair enough, however there are a lot of other areas of CS I would use Rust before frontend. Also, easy to work with completely depends on personal preference but at least for me Rust isn’t too high on that ladder
ckok 4y ago
I couldn't find it in the docs but does this also support working in a htmx like mode? Where the server renders pages and it does partial updates of parts? Or what some frameworks now call server components? Or is everything more like a initial render on the server and pure wasm from that time on?
fuddle 4y ago
Great to see more options for Rust on the front-end. I'm looking forward to this eco-system maturing before using it in a prod environment.
jbergens 4y ago
Not the best ad for a new framework when the web site looks like this [![image](https://www.linkpicture.com/q/Screenshot_20230409_233144_Materialistic_1.jpg)](https://www.linkpicture.com/view.php?img=LPic643330b25134b953465961) https://www.linkpicture.com/q/Screenshot_20230409_233144_Mat...
byyll 4y ago
This has nothing to do with NextJS (and never claims to, only the author of the post does) other than targeting the web.

198 points by erlend_sh 4y ago

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.
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.

quantumwoke 4y ago

Congrats on the release. I have to admit looking at the code samples, this looks like some pretty tough to swallow ergonomics for real-world usage. Is this inherent to Rust web libraries?

__pache__ 4y ago
I was pretty horrified, myself :(
- re-thc 4y ago
  Definitely didn't feel anything like NextJs to me.

Freedom2 4y ago

This is great! I've had a bit of a play around and the code examples are nice and easy to follow. Definitely liking it more than the JSX route that a lot of modern frameworks are taking these days - this way is much cleaner and easier to read.

sergiomattei 4y ago
I’m struggling to see how this is cleaner and easier to read than JSX. JSX resembles web technologies, it “smells and looks like” HTML and JavaScript. It’s easy to pick up and read. If you know HTML and JavaScript, onboarding to React isn’t bad. However, this framework looks like an abomination for real world usage. It’s in WASM, written in Rust (!?). It doesn’t resemble any sort of web technology other than the tag names. How do you onboard a frontend team to this? Perhaps to rust-aceans, this makes sense. Is there something I’m not seeing here?
- deleted 4y ago
  [deleted]
- dzikimarian 4y ago
  I think that whole point is to not resemble Javascript. I kinda like it, in my experience current state of JS is layers and layers of tools stitched together over language that was designed for much simpler times. Compared to other stacks I worked with it's often unstable, slow and poorly documented. I tend to avoid doing fronted if I can. Fresh and different look at this topic is something I would very much like to see. Of course for people working with front end today may have different perspective.
  - avx56 4y ago
    It still targets the browser though, so you still get all the complexities anyway, just without well supported syntax. Idk man I like Rust but this doesn't seem like the right way here.
- rwalle 4y ago
  I agree with you. I don't think anyone who has spent enough time with React/Vue.js would want to switch to something like this. I cannot imagine what the code would like when you have a lot more components and nesting. I would write frontend code like this if I really want to punish myself.

elAhmo 4y ago

If I were looking for an alternative in NextJS, looking for something built in Rust would definitely not be in top of my mind. I would assume this kind of movement from JS -> Rust would be quite rare.

Gigachad 4y ago
The versatility of Rust is quite impressive. Its looking like given a few years for these frameworks to mature, Rust could end up being a great job for just about every task.
- szundi 4y ago
  There will always be some better tool for a given niche task than a general one.
- rapsey 4y ago
  I do not think so. There will always be way more mental overhead in using Rust compared to higher level languages.
  - pkolaczk 4y ago
    Rust is both a low level but also a high level language. There aren't many mainstream languages that can go higher level than Rust with its traits, sum types, generics and macros. Haskell, Scala, maybe C++ to some degree, what else?
    - pjmlp 4y ago
      OCaml, F#, Kotlin, Ada, Swift.
      - pas 4y ago
        Those are not real languages! After all what can you do with OCaml for ex? A compiler for a Rust-like language at best? :)

pachico 4y ago

I have this feeling that I am wasting my time by not learning Rust. I am a proficient Go programmer but I have this sensation I cannot really describe about that not being enough. I feel something similar with Zig. Am I the only one?

impulser_ 4y ago
I'm the opposite. Everytime I'm using Rust I feel like I'm wasting my time not using Go.
- Patrickmi 4y ago
  Honestly I get that feeling, when it comes to compile times it feels like a thousand years, it’s discouraging
truthsayer123 4y ago
Do you think moving to Rust would help you make enough money to retire in the next 3 years? If yes do it. It will definitely help you save the rest of your life and spend more time with your loved ones. If you think Rust doesn't really matter for that and you can even do that with PHP and it's the problem and the execution that matters then focus on building a great product instead of getting into the Hype wagon and missing out on the bigger picture of what really matters.
- pachico 4y ago
  Believe it or not, this sensation isn't about a professional uplift but as engineering. I don't even code much anymore since I work mostly on platform related issues. And, BTW, I have a high respect for PHP and what you can achieve with it.
- dzikimarian 4y ago
  Sometimes you need to understand broader surrounding to make sure you're building something great. I think every mature developer should understand tooling in his/her area and possibilities it brings. Do you want, in the next 20 years, to have cardiologist that's focused on early retirement, not on the result?

noobcoder 4y ago

This seems to be faster than Svelte. I guess its because of Sycamore under the hood https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...

unconed 4y ago

I don't know why I would replace JS code I can quickly mod and extend with a stack I have to compile and write in a whole different language in. How am I supposed to ship plugins for these new rustified frameworks and build systems?

jbandela1 4y ago

I went down this Rust front end route with my trivia web app [0], but ended up abandoning it. There were just too many points of friction. * The tooling is not nearly as good as JavaScript for the front end. * Every time you want to use a front end library, you have to figure it out yourself as there won’t be any documentation for how to use it with your framework. * Rust compile times really break your flow when working on front end code. At least for me, for front end coding, there is a lot of interactive development where you look at the web app on desktop/mobile and adjust element size/spacing etc to make sure things look nice. Doing this in real-time with JavaScript/html/css is nice. Having a Rust compile between each step is a pain. * For front-end code, Rust’s borrow checker really gets in the way. The JavaScript garbage collector works really well front front-end code. Rust’s borrow checker is not bringing any performance advantages for this use case and brings a lot of complexity. On the backend, you can justify the complexity of Rust with appeals to efficiency/scalability/server cost. With front end code which is running on the client, you lose that justification. I ended up going with React/TailwindCSS and have been happy so far. 0. triviarex.com

aww_dang 4y ago
>Doing this in real-time with JavaScript/html/css is nice. Having a Rust compile between each step is a pain. I'm more of a JS-lite builder. Typically I will only decorate pages with the necessary JS for interactivity. Happier using traditional SSR. Pages load with no spinner or reflow. Sometimes I inline a JSON blob for state. For the layout tweaks you describe, I typically edit the displayed page in Chrome's developer tools. Once I am satisfied I apply those changes to the template and JS. This feels more ergonomic than refreshing the page. I imagine the same technique would apply to the unified Rust front-end/back-end experience. Just edit the rendered page in developer tools. I've never been an early adopter. Let's see how this shapes out for version 1.0 or if another framework overtakes it.
- cowsandmilk 4y ago
  Hot reloading is still a widely loved feature for server side rendering. It is part of what mad PHP widely popular and many other frameworks have auto recompilation and reloading on watching changes. The smoothness of automatic recompilation falls apart the longer it takes to compile and rust is not known for fast compiles.

sesm 4y ago

If it’s a NextJS alternative then it supports client-side components too? Is client-side code written in Rust? Is it then compiled to JS or to WASM? Couldn’t find those answers from quick look at the website and GitHub page.

lyjackal 4y ago
Yes, it’s full stack framework that compiled front end to wasm. They mention it in the QuickStart https://framesurge.sh/perseus/en-US/docs/0.4.x/quickstart https://framesurge.sh/perseus/en-US/docs/0.4.x/quickstart

sbmthakur 4y ago

Next.js itself uses a compiler written in Rust. https://nextjs.org/docs/advanced-features/compiler https://nextjs.org/docs/advanced-features/compiler

lucasyvas 4y ago

Great project! Tangential, but I've been thinking about this a lot lately and have an idea of what I'd like to see attempted next in this area. Like many have said, the JS framework ecosystem (ok, while kind of a meme much of the time) is a total juggernaut. I wouldn't mind seeing some kind of.. unholy combination of SSR for JS frameworks with a Rust (or even other language) backend if it was feasible. JS is still a lot more mature and ergonomic for front-end. Rust is kind of a chore for this kind of work currently. It works, but wasn't designed for it and it feels a bit clumsy. On the flip side, Rust is a safe and super fast server language (Go a great choice as well, or others too). I suppose I'd like to see some kind of framework that makes it easier to pair the two, instead of insisting that a single language isomorphic approach is best. This might not be practical - I feel like routing might end up being a nightmare. I'm more just saying it seems harder to pair peanut butter with jelly than it should be and someone smarter than me could probably figure it out :). I'm naively guessing that as long as you had a JS interpreter on the server side, it could be made to work (no problem in Rust for either Node or Deno since embedding those is possible). We've got thing like Next, SvelteKit, and Fresh. We've also got things like LiveView - there may be a further middleground between the two.

clintonb 4y ago
What problem are you solving with this “unholy combination”? Typescript gives you the relative safety. If you need faster compilation than tsc, you can use swc.
POiNTx 4y ago
I've been working on LiveSvelte[0] which might answer this in the LiveView example. It integrates LiveView with Svelte and has SSR support by calling Node from within Elixir, I wouldn't call it unholy, it's quite nice :) Routing is fully handled by Phoenix, and you can get quite fast page transitions with Live Navigation Events. It's just that whenever you need complex frontend state you can offload it to Svelte, while still maintaining that backend interopability, in this case with E2E reactivity. What's also really nice is that LiveView and Svelte are both very declarative in the way they handle the 'view' layer. And so they map really well onto eachother. I also wrote a blogpost[1] on the topic. [0]: https://github.com/woutdp/live_svelte https://github.com/woutdp/live_svelte [1]: https://wout.space/notes/live-svelte https://wout.space/notes/live-svelte

deleted 4y ago

[deleted]

jstummbillig 4y ago

What problem is this solving? It's easy to spot ones that it's introducing.

satvikpendem 4y ago
If you're going to mention problems, perhaps provide a more substantial comment about what problems you believe it's introducing.
- rochak 4y ago
  When you are the only person leveraging stuff like this, it’s all good. The moment you try to bring in other people who don’t have much experience with Rust, you are done for. No matter what you think, people who are developing websites and people who prefer writing everything in Rust just don’t have much overlap.
  - satvikpendem 4y ago
    I agree, I don't see much overlap either, and when you run into problems, these Rust frontend frameworks will certainly have lower userbases to ask for help from than for, say, a React app. I'm building a web app with React (Next.js) on the frontend and Rust on the backend, no way I'd use a full Rust or full TypeScript stack.

dawnerd 4y ago

I'm looking at the examples but it just looks like a lot more boilerplate than what I have when building a normal page in Nextjs. But I also think their comparison table isn't very fair. You can easily have perfect lighthouse scores in Nextjs, and Nextjs supports both SSG and SSR in the same file... not sure why it says otherwise. https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration https://nextjs.org/docs/basic-features/data-fetching/increme... And for the internationalization note saying it's only partially supported https://nextjs.org/docs/advanced-features/i18n-routing https://nextjs.org/docs/advanced-features/i18n-routing

rwalle 4y ago
Yeah, if they cannot get even the "Hello World" example to be simple and straightforward, I don't know why anyone would switch from the status quo. It's a ton of added complexity.

iamgopal 4y ago

Equivalent to this in go ?

TobyTheDog123 4y ago

I truly do not understand this Rust-for-all-problems mentality. I was under the impression that Rust was essentially the next generation of C, meant for things like compilers, embedded systems, and other places where memory truly matters. Why are we shoehorning it into things like REST APIs and frontend frameworks? One look at that syntax and I'd think anyone could see it's not the right tool for the job, even if there room for disruption in those spaces.

javcasas 4y ago
Believe it or not, there are REST APIs and frontend frameworks for almost every programming language under the sun. And I mean EVERY. Example: this Prolog works in your browser https://github.com/SWI-Prolog/swish https://github.com/SWI-Prolog/swish, and this is the corresponding package to do the API https://www.swi-prolog.org/pldoc/man?section=http-running-server https://www.swi-prolog.org/pldoc/man?section=http-running-se... But I can agree Rust has better marketing than Prolog.
rochak 4y ago
+1. I’m all for using the right tool for the job. It seems like all these technologies are to cater to specific niche of engineers and that’s the exact reason why they don’t have the longevity.

marmee 4y ago

Can someone please explain how Rust and frontend converge so often? In my mind Rust is similar to C++ including the very ugly syntax and fixation on memory management, while frontend languages are well.. exactly not that. Why?

dagmx 4y ago
It’s fast to execute, easy to work with and easy to use a single binary distribution. All points that make it popular to replace slower tooling on the frontend
- marmee 4y ago
  Fair enough, however there are a lot of other areas of CS I would use Rust before frontend. Also, easy to work with completely depends on personal preference but at least for me Rust isn’t too high on that ladder

ckok 4y ago

I couldn't find it in the docs but does this also support working in a htmx like mode? Where the server renders pages and it does partial updates of parts? Or what some frameworks now call server components? Or is everything more like a initial render on the server and pure wasm from that time on?

fuddle 4y ago

Great to see more options for Rust on the front-end. I'm looking forward to this eco-system maturing before using it in a prod environment.

jbergens 4y ago

Not the best ad for a new framework when the web site looks like this [![image](https://www.linkpicture.com/q/Screenshot_20230409_233144_Materialistic_1.jpg)](https://www.linkpicture.com/view.php?img=LPic643330b25134b953465961) https://www.linkpicture.com/q/Screenshot_20230409_233144_Mat...

byyll 4y ago

This has nothing to do with NextJS (and never claims to, only the author of the post does) other than targeting the web.