Perseus – NextJS alternative in Rust
framesurge.sh
framesurge.sh
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
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.
I tend to agree. I’ve also partaken in some Rusty frontend experiments that were discontinued. Rust is years behind on the JS ecosystem’s development velocity for frontend. That said, frameworks like NextJS are becoming incredibly complex, and Rust excels at taming complexity.
We’re already seeing Rust making major inroads at the lower levels of the JS stack, e.g. Deno, swc, turbo, parcel, react-relay.., even 3.5% of the next.js repo!
Not a lot of Rust folks agree with me on this because they delight in using Rust-lang as a universally applicable tool for app-making, but I think frameworks such as Perseus will reach their true potential once they incorporate JS/TS as a last-mile scripting language. Basically like a C++ engine with C#/Lua scripting for game logic.
There's a big difference between using it to write tooling, runtimes, etc. and using it to write application code (what GP was talking about). In the above examples, end users don't have to use a Rust workflow at all
They're great weekend project and prototyping things but yeah.
It was basically a one man startup and the argument to use Rust was because the guy wanted to use WASM on the frontend, because it was a mind mapping software (as far as I remember, and so information heavy, blablabla).
WASM might make sense or not, dunno. Figma somehow manages to be fast, I don't think they use WASM. (They are fast because of canvas, right?)
Are they? It is a small miracle it runs as well as it does on the browser, but if you compare it to Sketch it’s molasses.
Rust becomes more viable the simpler the API between it and your JS is, and "takes events and renders pixels" is a very simple API.
> Figma somehow manages to be fast, I don't think they use WASM.
Figma not only uses wasm but pioneered it. They're consulted be standards bodies, they implemented wasm features in browsers, ...
Likewise Ada makes your vacations possible, in case taking a plane or train is part of it.
Kotlin turns pixie dust into Android apps, while Swift does the same for iOS.
The others (except Swift) are barely mainstream.
Kotlin meta-programing is done via reflection and compiler plugins.
Traits are interfaces.
Similar thing with interfaces - while they serve the same purpose as traits, they are nowhere as flexible/expressive. E.g you cannot do blanket interface implementations - i.e. implement an interface for only the classes that implement another interface. You also cannot implement the same interface more than once, differing by generic parameters only. Or cannot define an interface with an associated type member (Scala is another language that can do it).
Yes they aren't 1:1 to Rust, so what.
Does any of them matter to ship better Android applications written in Rust? Nope.
There is definitely a mental overhead with rust but this has nothing to do with low level or high level concepts. The borrow checker is actually a high level feature that exists for safety, not performance.
How can you write that with a (I suppose) straight face? Rust makes you think about lifetime of every single variable, as anyone who's written a couple of lines of Rust knows... it' not just the lifetime annotations you will need when you get past the "copy everything" phase and start using or writing data structures, but the borrow checker making even the simplest stuff something you actually have to think through carefully (do you need to pass a reference, make a copy, use a mutable variation of some function, open a new block to limit the scope of the variable, assign it to a local variable to avoid it getting out of scope too early?). This is plainly "low level" stuff you need to worry about all the time which you just don't in any high level language.
It's a different style of programming but still high level. Make no mistake the abstractions are high level but the cost is zero, hence the term zero cost abstraction and the association with "low level."
One caveat - these are hello world programs without I/O. The maintainer plans to add I/O to the benchmarked code.
That’s one misconception you have about Go, when it comes to Cold start uptimes Go is one of the top garbage collected language to compete the likes of C, the go runtime is a progressive runtime it runs together with your code so it’s basically a Vlang code with added C codes
The fundamentals are very different but it’s a case of convergent evolution - and I’m happy to liberally sprinkle clone’s around my rust code
This is contrasted to Go, which I think turns away these developers (at least it did for me…) due to having null-pointer/non-existent nullability.
As opposed to Typescript's null, undefined, or optionally defined types? I don't use Go or Rust, but I do use Typescript so maybe I'm a bit confused by this statement. Go allowing nullability doesn't seem like a dramatic shift from Typescript's 3 different ways to represent a potentially ill defined object, and it wouldn't turn me away from the language.
Go having nullability isn’t the problematic part - it’s how nil is not type checked, so a value might secretly be nil and you won’t know until your program crashes at runtime.
Rust avoids this by just not having null, instead using things like Result and Option types, which is pretty neat with pattern matching.
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?
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.
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.
Do you want, in the next 20 years, to have cardiologist that's focused on early retirement, not on the result?
That said, I would still recommend learning Rust, because it will teach you about lifetimes and aliasing, even if you don't want to learn about them. When building for the web, I think Go's easier dynamic dispatch and GC will save you some headaches though.
Rust is definitely strongest on the system / tooling level, it is what it is built for and what gives the least friction. If you need to use a lot of macros to do your work, you basically throw away most LSP (Intellisense), which can be quite bothersome to work with.
Rust is definitely capable, but writing actual services and such in web rust, takes a lot of work, and isn't as friction-less as building tooling / low level code.
Btw, I used to teach jazz guitar for years, I know what you mean :)
Cheers
But if it doesn’t, that’s fine too. Go is a great language that works well in many domains. You won’t have trouble finding work in Go for years. It’s unlikely that you’ll have to solve a problem at work that can’t be solved in Go. You’ll be fine. Don’t guilt yourself about it.
Between it getting included in Kernel and the whole WASM thing it seems reasonably future safe
That being said. We recently build a replacement for Sharepoint because we sort of out-grew it and couldn’t find a decent headless CMS that fit our needs and also complied with the EU legislation for the Energy Sector, and since it had to be actually worth moving away from Sharepoint we actually did some thorough proof of concept testing before other needs basically dictated it needed to be ODATA and thus we ended up building it on C#. Anyway, two of the prototypes were Rust and Go, and I would never use Go professionally again if I could help it. Rust on the other hand seems like it’s genuinely a good language that sees actual real world adoption for major projects. I loved Go by the way, but we kept running into packages and libraries which can basically best be described like this: “Y needed to do X and build a library for it. Two years later Y got a new job and the library was semi-abandoned because nobody else really picked it up”. I know a lot of people are building a lot of things with Go, but we kept having to either reinvent the wheel with it, or to become guy X ourselves. Rust didn’t seem to have these issues, likely because it sees more adoption at more places which have similar requirements that we do.
I’m not convinced I’ll ever see Rust blow up in my part of the world though. Out of all the recent hyped languages going back to Ruby on Rails, however, I think Rust may have the biggest shot at it. But I fully expect Typescript, Java, C# and PHP with some Python to remain dominant for the next 10-30 years outside of the areas where they do C++.
It is the same for me too, almost zero Rust jobs where I live. However, I still benefited greatly from learning Rust, making me a better programmer overall. Now I think more about memory allocations, ownership, how I am passing the data around, and mutability.
Sure, it shouldn't be that way, but I prefer it when we design our systems for the code we write on a Thursday afternoon. You know, those days where you've been up all week because of the baby crying and you've spent too much of the day in meetings that shouldn't even have been an e-mail. Because that's the sort of code someone is going to hate 3 years down the line, and chances are that someone might even be yourself. Unfortunately things seem to be going in the opposite direction with some languages. I didn't work with C# for a while, and I was surprised to see "var" everywhere when I came back to it.
Started picking up Verilog instead... It doesn't risk overlapping in the Go/Rust/C++/C category.
There are so many things I want to learn and do, and so finite attention and lifespan. I'll have to rely on others doing great things with Rust. I'll focus on extracting more value out of the ones I know already.
Certainly not a better salary. Beyond that... Rust forces you to care about allocation, deallocation, borrowing, all the low level stuff, while not necessarily being faster.
To me it doesn't feel like Rust beats Typescript or Go as a higher level language at what Typescript is good at, and I don't see why that would change. Some performance critical things to port to WASM maybe...
It may not be a good enough reason to switch, but Rust is nearly always faster than Go. Most of the time orders of magnitude faster.
Plus, I already test a lot stuff (not just langs, but frameworks, etc). Learn from many langs that never use for more than their more basics tutorials (like kdb+) just to see what was the deal.
Is like a hobby to me! But mainly, because as solo-dev anything that give me an extra advantage AND is suitable for a the challenges of a solo-dev I wanna know.
So, learning not means "fully committing and betting my work on it". Is pretty certain you will learn very good stuff with Rust that will be valuable to know in general. Could be the same for Zig.
I know enough Rust to make myself usable coding in it, however it is mostly for hobby coding.
On my line of work there are zero reasons to move away .NET/JVM/JS stacks, unless driven by customer requirements.
What you're describing is FOMO, Fear Of Missing Out.
One of the things in the IT fashion industry is to learn what to invest right now, what to ignore, and what to keep an eye on for later times.
Thanks!
That said, there is value in learning a strongly typed language. If you like it you might want to introduce concepts in your Go work, if you really like it you will probably want to switch to one, and if not, that's also completely okay, and you'll know what you don't like about it.
For example I like Rust, Scala, TS, but Haskell always makes me cry a bit. Spent many years using Python (py2 to py3 migration was fun), but a few years ago I realized that it's a bad trade off for almost anything I work on, and makes me rage a bit every time I run into super dumb errors, so I avoid that too :)
For me, I see value in learning one systems-level language well to round out my generally higher level language focus.
I never used Go, so choosing Rust for this was easy. Go does not satisfy some tasks in the way that Rust does, but Go likely does just fine for the reasons you originally learned it.
However, I do see Rust as the best way to broaden my horizons and career opportunities. Suddenly, realms where C and C++ would be used exclusively, I can now more easily play in. Many times, Go would not qualify for these types of projects because of its garbage collector.
So from language tooling to browsers, learning Rust may help me debug issues down the stack or help me creatively solve performance issues by plugging it in, and that feels like a win to me and wholly worth the price (or is it pain?) of admission. First class WASM support doesn't hurt either.
What I learned is that Rust has by far the best runtime and memory performance, but .NET Native AOT was second best (even better than Go!) and JavaScript was 30x slower than Rust.
But Rust took me probably over 40hrs (hard to say because I worked on it little by little), the learning curve was steep. Its standard library is spare, and selecting the "best" community crate leads to decision fatigue. I banged out the same algorithm in my most proficient language (C#) in an afternoon.
In business, speed to deliver almost always trumps speed of code runtime. Some algorithm hot spots deserve the Rust treatment, but in general, just ship the code to your customers.
That's a long way to say, put some energy into learning Rust sure, but don't beat yourself up about it. It's not a general purpose language like Go or C#. It's a dream for performance critical algorithms.
v0.4.0 went stable today after a year of development: https://github.com/framesurge/perseus/discussions/270
“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.
https://framesurge.sh/perseus/en-US/docs/next/state/intro
Seems like snapshots of the current data view, in this case.
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.
Yes it is limiting, and it won't be appropriate for many use cases. But if you can do it, it makes things simpler, cheaper and more efficient.
That's not to say you can't combine SSG tooling with dynamic content too if you need it. But static-only is a perfectly valid choice if you can get away with it.
If you live in Tokyo and connect to a website in Oregon, this effectively static could be ~100ms (served by origin) vs actual static that's ~10ms (served by CDN local PoP).
Side note: this is why developers need to care about infrastructure and vice versa. I distinctly dislike the abstract separations as the implementation details always matter.
- 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.
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.
> edge compute platform
I would consider that quite a big difference in infrastructure. It can easily be done already right now, but the cost and performance equation between serverless compute (at edge or not) v.s. static file serving becomes noticeable at scale.
Let's make some pricing examples:
- We'll have 2 million "first page loads" per day (~60 million per month)
- Let's give our bundle a low estimate of 200KB
------------
Vercel's pricing (just to take a popular example)[0]:
- Pro tier: $20/month includes 1m execution units (EU, 50ms of CPU time) and 1TB bandwidth
- Then $2 per 1m EU and $40 per 100 GB bandwidth
- Let's ignore GB-hours for now (memory x runtime)[1]
- Let's assume you're always able to render your SSR page in 50ms or less (quite optimistic if you're doing any form of DB operations in your SSR)
AWS CloudFront pricing[2]:
- Always free tier: 1TB bandwidth, 10m requests
- Then $0.085 per GB bandwidth and $0.0100 per 10k requests
- (at scale you can get +50% discount on bandwidth by committing)
------------
We can then run the numbers:
- Estimate (200 KB) on Vercel:
- (60m requests - 1m free) * $2 per 1m = $118/month
- 200 KB * 60 million = 12,000,000,000 kb = 12TB
- (12TB - 1TB free) / 0.1 * $40 per 100GB = $4400/month (you'd probably want an Enterprise plan at this point unless I did the math wrong here. Their FAQ suggests to reach out to their sales team which you should definitely be doing at this scale!)
- = $118 + $4400 = $4,518/month
- (60m requests - 10m free) / 0.01 * $0.01 per 10k request = $50/month
- 200 KB * 60 million = 12,000,000,000 kb = 12TB
- (12TB - 1TB free) / 0.001 * $0.085 per GB = $935/month (which could be $440/month with reserved capacity)
- = $50 + $935 = $985/month
Totally open for having made a calculation error above, but this is the kind of thing that one needs to concern themselves about at scale. The above example is quite realistic, in fact it's a lot less than our usage at my current work.
Admittedly here we are seeing most of the cost come from bandwidth. If you substituted Vercel with AWS Lambda you would be able to benefit from the CloudFront pricing on this.
[0]: https://vercel.com/pricing
[1]: https://vercel.com/guides/what-are-gb-hrs-for-serverless-fun...
Cost isn't the only thing to care about but performance. Functions might not run in every data center that would have a CDN PoP. The SSR vs SSG comparisons always miss the point and claim SSR is faster but that's only true if you're in a big popular city. As you expand - what about the other customers?
Also what about security - that's probably even more important. Each request for Vercel has a higher cost than the equivalent from Cloudfront. What are the safeguards e.g. rate limiting or DoS protection? For Cloudfront you'd need to account for WAF and other expenses.
You don't even need a lot of customers - just a bad actor to easily take down your hosting on Vercel. There have been plenty of blogs of startups using serverless setups getting attacked that costed them 1000s - 10000s of dollars.
Side note: bandwidth costs vary. Vercel does it with 1 price, so things may vary depending on where your users are. Cloudfront costs can go up. You may also need Cloudfront functions to do a few things.
You can manage DDoS and rate limiting protections although I don’t know the pricing on those (could be free - I don’t recall).
Disclaimer: work at Cloudflare
For many workloads Cloudflare can be more expensive.
* The closest one may already be at capacity, requiring rerouting some traffic away.
* ISPs in some parts of the world are weirdly fragmented, not interconnecting with other ISPs in the same region. As a result, if you're on the "wrong ISP", the network distance to the local colo may be longer than to some other colo that is physically further away.
* To serve content from servers in China, you must have an ICP license from the Chinese government. If you don't have that, Cloudflare will send Chinese traffic to the closest non-Chinese colo.
* Probably other reasons I'm not thinking of off the top of my head.
Note that all these apply to Cloudflare in general regardless of whether you use Workers. Enabling Workers has no effect on what datacenter you get routed to. Cloudflare's infrastructure team is always working to improve these situations, e.g. adding more servers, negotiating more connectivity, etc.
A nice thing about building on Workers is you don't have to worry about any of this. E.g. you don't need to think about redirecting your traffic when a colo is over capacity... it happens automatically.
(I'm the tech lead for Workers.)
I'm referring to e.g. https://community.cloudflare.com/t/does-free-plan-cloudflare... where the poster says:
"For predominantly Australian traffic, you’d probably need CF Business or Enterprise plan. For India traffic, would need CF Enterprise plan."
Where do workers run in this instance and what impacts are there say if I'm not on a business or enterprise plan?
Point being if we do need an enterprise or business plan for these features it's not 100% free.
All I can say is that if you use Workers, the Worker always runs in the datacenter that receives your request, which is exactly the same datacenter that would have received your request if you weren't using Workers.
Disclaimer: work at Cloudflare.
That said, super interesting to see the CloudFlare dropped the egress costs![0] That would make the equation for them probably the most attractive, although that will only be the case as long as you are then not having your CloudFlare Workers talking with e.g. an AWS database which will then just move the egress costs there instead (internal traffic can sometimes be orders of magnitude higher than external).
If you only use it for SSR and only keep whatever SSR is using to offerings within CloudFlare, then it looks to be the most competitive offering for that so far. Your API can still go other places, so little downside there.
One concern I would have, having been quite deep in AWS Lambda, is the 128MB memory limit on CloudFlare workers (unless I misunderstood and it can go higher?). For JS frameworks, that very likely has performance implications, whereas for Rust frameworks, they will be able to perform well within the lower memory limits. Lambda is a bit different though, since the CPU scales with memory, so would be curious if there are any benchmarks on CF Workers with these frameworks?
[0]: https://blog.cloudflare.com/workers-now-even-more-unbound/
1. Last I checked (admittedly not recently), Lambda throttles CPU proportionally to memory size, e.g. as I recall a 128MB instance is throttled to 1/8 CPU core, 256MB is 1/4, etc. Workers never throttles.
2. The same code running on Workers will use far less memory than when running on Lambda. In fact, the average Worker uses around 3MB RAM. The difference here is that Lambda is counting the memory for the whole runtime process, e.g. a Node.js process, whereas with Workers the runtime is shared with other tenants and only the pure JavaScript heap usage counts against the memory limit.
So, 128MB goes further with Workers.
That said, obviously some apps need more. At present we don't have a way to increase this limit, but we're working on it.
(I'm the tech lead for Workers.)
If you consider Cloudflare Workers pricing, it becomes a lot more competitive. No egress + much lower per request fees + you can choose between per wallclock ms billing and per request billing (different slopes + intersection points).
I'm not claiming we're a good fit for every use-case out there. My root point though was about SSR and I think a platform like Cloudflare Workers is perfect for making SSR extremely simple.
Disclaimer: Work at Cloudflare. My opinions are my own.
Traditionally an SPA has been just one single bundle file that is downloaded. With SSG you pre-generate a file per path which gives the user many of the benefits of SSR on that first page load, before the SPA part takes over again.
It's good if your platform can support it.
We're now given something that has routing i.e. NextJs but then allowed a SSG option that behaves somewhat different.
Also I don't want to squash them either but dynamic vs static is for instance much more appropriate, it's a shortcut for request-time vs build-time server rendering.
So to me and many others whether a framework can do SSR or SSG is a very important distinction, critical for infrastructure planning. I often see it being downplayed together with a promotion of various proprietary platforms offering edge computing but this stuff is just not necessary for many cases.
Edit: No idea what terminology is used at NextJS, above is what I think is generally understood by SSG (static site) and SSR (server-rendered site).
I could get behind static vs dynamic, but “server-side” has no meaning then to me, since there is no server/backend men at to be involved for the static part then (at least in my mental model of it).
Any CDN (CloudFront, CloudFlare, etc) coupled with any blob storage (S3 and others) vs the following:
- Servers to run your node process
- Load balancing to handle distributing traffic between several servers for your SSR’ed app
How do you then run and update your servers? You now need to start thinking about zero-downtime rollouts, and grab something like ECS or the big hammer k8s. You can still handhold your own EC2 instances, but then you’re now home brewing a solution.
The simplification of infrastructure that “static files” bring is not to be underestimated :)
Sure, but in common parlance that’s not really a useful point. There are also servers involved in serverless, but we’ve largely accepted that here it is meant to indicate (on a gradient) who manages those servers :)
When you set up your infrastructure, it will matter quite a lot whether you’re able to utilize a CDN as the only thing you need to deploy to, or if you need to run your own code at runtime (and hence need a something to run it on).
It’s worth noting: You can absolutely go for all of these solutions! I do have a bit of a penchant for solutioning things that I know will scale up massively, but that is not always a priority early on, so I don’t want anyone to be discouraged by these approaches and the other benefits they can provide :)
> there is always a server and a user request around even when you render statically
I’d love to dive into that part a bit more, genuinely curious! Is the point that there is always dynamic information to act on to improve the user experience? Or what would be the goal or vision once you know that?
Leptos is another frontend library that uses Signals and does not use a VDOM. 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.
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.
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.
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.
But I can agree Rust has better marketing than Prolog.
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/increme...
And for the internationalization note saying it's only partially supported https://nextjs.org/docs/advanced-features/i18n-routing
How am I supposed to ship plugins for these new rustified frameworks and build systems?
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?
All points that make it popular to replace slower tooling on the frontend
Also, easy to work with completely depends on personal preference but at least for me Rust isn’t too high on that ladder
[. 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?
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.
I would write frontend code like this if I really want to punish myself.
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.