On CQS... my first programming language was Pascal which had CQS in the language level 'command' are 'procedures', queries are 'functions'. It also had types. It took me a long time to understand how to program without those 2 ideas... interestingly decades later they are becoming cool again. The spiral way things evolve...
This clarified a bunch of confusion I had from the original announcement. Specifically the clarification around derived/effect and how those both related to '$:' statements.
”If I […] would enforce the command/query separation at the programming language level..” 44.05 Rust? ..Web Assembly.. could do that with the mutable control. // Planning to do Svelte 5 + Rust WA
I would really like to switch to Svelte, but the missing IDE support in Intellij is really holding me back. Vscode really sucks in refactoring/renaming and I'm not switching back. Using string search and replace each to to rename a single component is unacceptable to me.
@@n3v3rd1e Yeah and it reliably only works 8 of 10 times. The other 2 times it leads to compile errors everywhere. This Problem may not come out if you only have like
My understanding: Because vscode relies heavily on the LSP (Language Server Protocol) it sometimes get confused with Files/Components already opened in different tabs. It then either ignores file changes or overwrites them (with already open file content) -> this leads to inconsistent and unreliable renaming/refactoring.
I will still never understand why we had to add the +page convention. Don't put your components in the routes folder. It's not that hard. Taking away simplicity for the sake of fixing an issue caused by poor planning just doesn't feel like a good enough idea to me. The rest of Svelte 5/SvelteKit 2 looks great though.
@@LeFlamel Still not a good idea to co-locate routes and components in Svelte 5 anyway so that's not a good reason. Plus you have to import the components anyway, you might as well put them in a lib folder so you can reuse them. That way you don't end up with "././route/component" imports or having to refactor whenever you want to reuse something.
I've had to work with both kinds of codebases. Having components that are only used in one page close to them is amazing. Waaay better way to structure your files. Best practices like separation of concerns are suggestions, not gospel. We are always learning new things and we need to keep an open mind.
@@1DJRikkiBee For the same reason Svelte got it right with the styles inside the component. The information is more localized and we learn at a glance what is being used. In fact, sometimes I want a small component and svelte 4 forced me to put it in another file and now with svelte5 snippets this is partially solved. Don't get me wrong, I still use the lib folder but only for components that are shared between routes (which usually are not that many). The code is still organized, just in a different way. Closer to where it is needed. In my editor I don't have to jump around in the file explorer. I can just have the route folder open and work right there.
Why would we want Laravel style framework for JavaScript... I preferred when these frameworks were UI specific, all these server components are getting super crazy - seems the industry is looking to try and simplify all the UI server madness with things like HTMX. Hope Sveltekit keeps things simple.
@@learnwithjason loved the episode, Rich Harris is a OG of the frontend space now. I quoted his talk on reactivity at a job interview and I think that went a long way in securing the position;) cheers Rich.
Svelte won't have dependency arrays, since it uses a compiler to detect dependencies automatically. Totally different model than React (although React might go in that direction eventually)
I actually asked Rich about this during the episode - he gives a great explanation of how $effect() and useEffect() are different and what Svelte is doing to make it less of a trap for devs to fall into
@@AttilaButurla Haven't used Svelte 5 tbh, only earlier versions. Just putting all hopes that Svelte team will stick to the core principles and won't "expand" framework into dangerous functionality.
Svelte is best Framework ever, lightweight , fast, a very loved syntax with its unbeaten stores.
On CQS... my first programming language was Pascal which had CQS in the language level 'command' are 'procedures', queries are 'functions'. It also had types. It took me a long time to understand how to program without those 2 ideas... interestingly decades later they are becoming cool again. The spiral way things evolve...
This clarified a bunch of confusion I had from the original announcement. Specifically the clarification around derived/effect and how those both related to '$:' statements.
Anybody knows when svelte 5.0 is scheduled to be released?
Two of my fav devs together :)
”If I […] would enforce the command/query separation at the programming language level..” 44.05
Rust? ..Web Assembly.. could do that with the mutable control. // Planning to do Svelte 5 + Rust WA
57:14 what browser is it?
probably Arc
yep, Arc
I would really like to switch to Svelte, but the missing IDE support in Intellij is really holding me back.
Vscode really sucks in refactoring/renaming and I'm not switching back. Using string search and replace each to to rename a single component is unacceptable to me.
ehm, vscode has renaming
@@n3v3rd1e Yeah and it reliably only works 8 of 10 times. The other 2 times it leads to compile errors everywhere.
This Problem may not come out if you only have like
My understanding:
Because vscode relies heavily on the LSP (Language Server Protocol) it sometimes get confused with Files/Components already opened in different tabs.
It then either ignores file changes or overwrites them (with already open file content) -> this leads to inconsistent and unreliable renaming/refactoring.
I use it in IntelliJ. What issue do you have?
Seems like someone was to lazy to check vscode features before writing this comment😂
ok this is a total tangent but you're not using OSX's split screen functionality for your windows, are you?
sometimes I do, but usually I use yabai. but honestly I think Raycast window management is probably better/more friendly to use
@@learnwithjason dude, I have fallen in love with Yabai - thank you for the recommendation and for this video!
Nice to see u @Rich
I will still never understand why we had to add the +page convention. Don't put your components in the routes folder. It's not that hard. Taking away simplicity for the sake of fixing an issue caused by poor planning just doesn't feel like a good enough idea to me. The rest of Svelte 5/SvelteKit 2 looks great though.
Locality of behavior
@@LeFlamel Still not a good idea to co-locate routes and components in Svelte 5 anyway so that's not a good reason. Plus you have to import the components anyway, you might as well put them in a lib folder so you can reuse them. That way you don't end up with "././route/component" imports or having to refactor whenever you want to reuse something.
I've had to work with both kinds of codebases. Having components that are only used in one page close to them is amazing. Waaay better way to structure your files.
Best practices like separation of concerns are suggestions, not gospel. We are always learning new things and we need to keep an open mind.
@@adrianjdelgado In what ways is it better than having the components in a lib folder of the same name as you route?
@@1DJRikkiBee For the same reason Svelte got it right with the styles inside the component. The information is more localized and we learn at a glance what is being used.
In fact, sometimes I want a small component and svelte 4 forced me to put it in another file and now with svelte5 snippets this is partially solved.
Don't get me wrong, I still use the lib folder but only for components that are shared between routes (which usually are not that many).
The code is still organized, just in a different way. Closer to where it is needed. In my editor I don't have to jump around in the file explorer. I can just have the route folder open and work right there.
"Special occasion foo" 🤣
Rich, we're still mad about the + 😂😂😂😂😂
Why would we want Laravel style framework for JavaScript... I preferred when these frameworks were UI specific, all these server components are getting super crazy - seems the industry is looking to try and simplify all the UI server madness with things like HTMX. Hope Sveltekit keeps things simple.
I was pretty impressed with the changes in Svelte 5 - to me, it felt like the API got simpler and more clear
@@learnwithjason loved the episode, Rich Harris is a OG of the frontend space now. I quoted his talk on reactivity at a job interview and I think that went a long way in securing the position;) cheers Rich.
None of the svelte 5 changes have anything to do with servers or apis. It's only on the front end , and you can even use it with laravel
Great less full stack madness in javascript, less server components and more UI goodness!@@isaacfink123
Ui framework !== Web app framework
Hey, delete Deno, reinstall it, and you won't be having those errors popping up again :)
thank you!
Jason the sounds you make during the call is very distracting both to us and the speaker. Please stop
appreciate the feedback. I just watched this back and I see what you mean - in the future I'll try to "active listen" with my eyes instead 😆
SvelteKit is too opinionated (for us, at least). Especially routing, which is file system based.
All of this runes stuff looks cool and all, but I'm sticking to Svelte 4.
Why?
Ok, boomer
Bring dependency array into effects and soon you will have React
Svelte won't have dependency arrays, since it uses a compiler to detect dependencies automatically. Totally different model than React (although React might go in that direction eventually)
I actually asked Rich about this during the episode - he gives a great explanation of how $effect() and useEffect() are different and what Svelte is doing to make it less of a trap for devs to fall into
If you have actually tried Svelte 5 you should know how far off that assertion is.
@@AttilaButurla Haven't used Svelte 5 tbh, only earlier versions. Just putting all hopes that Svelte team will stick to the core principles and won't "expand" framework into dangerous functionality.
You should watch a few videos on how signals work before commenting.
You are amazing bro