Svelte 5 Release Candidate #327
Replies: 2 comments 3 replies
-
Hey @jamestagal, Great questions, the roadmap is still a bit up in the air, but I'll share my current thoughts here. I think Svelte is one of the best reactive frontend frameworks that exists and it makes manipulating the UI very ergonomic. That said, not all is perfect and after building several large production apps with it, there are definitely some aspects that are challenging. One of the main issues is that there is no top-level await that allows you to SSR dynamic components, which is at the heart of a content-driven framework like Plenti. We hacked around this with component signatures and the Another challenging aspect of using Svelte in Plenti is that we're loading a 60k line node app (the Svelte compiler) into V8 to create ssr and dom compilation targets. This process is extremely slow and finicky and has memory timeout issues when trying to compile large applications. To me this is a show stopping problem that I've been kicking down the road for a long time. I was hoping the Svelte core team would eventually move towards a Go/Rust compiler to help alleviate this, but it seems like there isn't much of an appetite to ever do this and arguably the project has moved farther away from this reality. Again, there are things we could do here to make build time improvements (component caching would be a big one #300), but we will always have a large amount of code massaging this process, when maybe it would be easier to have targeted code to create a new process that fits with the goals of the Plenti project better.
Yeah the dependencies make things difficult when running the compilation step in V8. Not only that, but npm modules make things like themes harder to implement because inheritance gets messy, so a long-term goal has been to remove npm entirely by default but allow people to roll their own JS pipeline if they'd like (we could also embed esbuild for convenience). Svelte used to wrap all their dependencies in the project, but moved to a more standard JS structure for v4. Unfortunately for us, we're purposely trying to avoid conventional JS project structure so using Svelte 4 is probably out of the cards. I'm also not entirely sold on runes and Svelte 5 reactivity - I'm sure there are great reasons for the changes, but to me it makes Svelte more similar to React/Vue, and loses some of the edge it has as a beginner framework that is easy for new developers to understand.
The templates would replace Svelte in Plenti. This is still just a dream, and would require a lot of work to become reality. I'm running some experiments in a throw away git repo (https://github.com/jimafisk/custom_go_template), but I'm still in the exploratory phase. Ideally it would work similarly to Svelte, but would have a lot less features. That sounds nice, but the Plenti CMS alone is using lots of features in Svelte that would hard to replicate without stores, 2-way binding, etc that Svelte provides. There are all sorts of other things to consider like language servers for IDE support, so it's an endeavor not for the faint of heart. It would provide a path to much faster compilation times and better stability in Plenti overall (we could probably cut 50% of the codebase that's dedicated to supporting a shaky V8 build process). Summary: Realistically Plenti is staying on Svelte v3 and not migrating to v4 or v5. Ultimately we may move to a custom templating solution that is Svelte-like, and this is something I'm actively working on, but it may still be a ways out from being pulled into the project officially. Does that make sense? Would love to hear your thoughts! |
Beta Was this translation helpful? Give feedback.
-
Thanks for the thoughtful response @jamestagal! It's really nice hearing your perspective on things that are important to you, I agree with your list as well!
Using a native Go-based solution would hopefully fix this. We will still need to evaluate JS however, and so far I've been Goja instead of v8go which executes JS more slowly but will potentially be more stable for purposes. So far I've been really impressed with the speed given the way that I'm using it while experimenting, but that could change as I flesh out more features. Either way, we should be able to fix these crashes, and we probably can and should fix this with the current Svelte implementation by passing context that cancels a current build if a new one is sent. I appreciate your list of things you enjoy about the project 😊. Here are some quick thoughts:
These would actually look very similar for Plenti users. I'm likely changing the syntax from
You would still have component files very similar to Svelte with scripts, markup, and style. These would all be scoped together, so it shouldn't be something you have to worry about manually importing yourself. The main difference would be that conceptually you would be generating static HTML and then sprinkling in interactive JS when needed vs making everything a JS component from the start. I having some thoughts about scoping the JS to components to make life easier (similar to scoped CSS) and creating boilerplate helpers when using things like
We're not actually taking any concepts directly from Astro, I've haven't really spent any time looking through their implementation, but I've heard them use the terms "islands" in their marketing. Basically the way we're building Svelte today is that we create both an SSR and DOM component for every single aspect of the website. Most of this is just static content that never changes, but we still build and interactive component that hydrates in the DOM and carries all the instructions to surgically manipulate that component if we needed to (even though we don't). Combine this with some of hacks we did to make content-driven dynamic components to work and now we're loading a ton of JS to the browser that can have all sorts of detrimental effects: slow initial pages loads, too many scripts that can block google from crawling clientside routes, hydration errors that make the app seem broken, having to bust client app cache with fingerprinting, canonical routes, etc. I'm just trying to take a step back and simplify this whole architecture because right now we're spending a lot of time solving problems that we're creating by loading too much JS in places it's not needed.
You still wouldn't need to have any knowledge of Golang to use Plenti. I've been calling this "custom go templates" because that's what I'm using to implement it, but at the end of the day the Plenti users should feel like they're using a very similar system to what they are using now. The template syntax and capabilities will change a bit, but should be familiar conceptually. They won't have to write any Go code and the logic in the templates will actually be JS (interpreted by Goja). Ultimately there's still a ton of work I need to do on my end to ensure this is actually a viable direction for the project. That is going to be a several phase process. The experiments so far have been going really well and I see a ton of promise, but everything looks good with simple examples and can become much more challenging when implementing with real world problems. I'll definitely try to keep everyone posted on progress! Thanks for the conversation! |
Beta Was this translation helpful? Give feedback.
-
Hi @jimafisk
I see that Svelte 5 is in release candiate. There are some significant changes but it will be have backward compatibility with version 4. You can read the post on it here.
However I see that you bumped a change to version 3.59.1 so Plenti probably will need to at least move to version 4 before going to 5. I remember you tested it version 4 but found a lot of new dependancies.
What are you plans re version 5 Svelte?
How does this all fit with your explorations with custom Go templates? If implemented would they be an alternative to Svelte templates for larger projects? Just curious 😄
Regards,
Ben
Beta Was this translation helpful? Give feedback.
All reactions