Checkout the "astro" branch in the solid-start repo. Solid-start will be using Astro as base to build off instead of writing their own. Tan-stack start will do the same for react.
The client side router is about preserving page state across navigation. It still renders everything on the server and Islands are still Islands. Everything works the way it did the only change is that the page will not refresh on navigation so things like tabs and scroll positions are preserved without workarounds like using local storage. It makes the UX much better and adds support for features like the View transactions API which is super cool. No Astro is not turning into another meta framework. There are still no data loading patterns or mutation primitives. Astro components still render only on the server. The router just swaps the changed head and body elements that's it
What is dead is the MPA/SPA dichotomy. Now there can be a variable mix of server and client routing as required by any specific use case. Back in 2015 there was a Perficient blog post: “Mixing MPA and SPA: worst of both worlds”. But now the Gen 3 mantra is “what *can* be done of the server will be done on the server; what *needs* to be done on the client will be done on the client”. With Rails & Alpine you are grafting the Alpine application on top of the Rails application; “one web application for the price of two”. Gen 3 frameworks approach server and client as part of the same application.
@@aidantilgner that's how most of the SSR framework work, the inicial routing is on the server after that the client take the navigation. Next, Remix, SolidStart do that
@Freddx L. im sure im missing something, but isn't that how all javascript frameworks work? Even if you're using react with express, the client is handing the navigation (as an spa) and the server is handling the routing. I thought the only difference with an SSR framework is that it renders the page server side per navigation request and then sends it back to the client's browser.
@@neociber24 That's not how they work :) isomorphic frameworks have two copies of the same router, and run it twice, once on server and once on the client
But don't most of the SSR framework in JS work that way? The initial page is using file system routing and after that the client takes control. NextJS, RemixJS, SolidStart, SvelteKit work like that, helps to achieve smooth transitions.
Right! I know that the majority of frameworks were doing it like this. However, there was a lot of talk about not needing the client to take control of the navigation.
If astro manage to include an option to give the ability to activate the client routing, or even better, partial client routing between couple of page, well, astro will cover all the use case and in my opinion, it make no sence to choose another framework. It is a verry good idea for them, and i truly hope they will eneable this feature. I'm tired to switch from angular, sveltekit and astro following the use case of the project.
Rich Harris gave a talk recently where he gave a bunch of spicy takes, one of them being that MPA's are dead. I had to do a double take because I feel like it was just yesterday that the headline read "SPA's are dead". The javascript community is honestly exhausting to be on top of right now. I think I am going to build my apps in Elixir's Phoenix until the javascript community settles down. It's really great and liveview gets you 90% of the client side interactivity you need. The only time I really need Javascript is when I work in three.js and pure SPA's are best suited for that work anyway.
@@evols7028 That's exactly what I'm going to do. What I mean in regards to the is they always claim to solve an issue that currently exists with the older javascript framework. Then, once they are out for a bit, an issue with the new approach arises and a new javascript framework pops up to address that issue, and the cycle continues. Knowing what's best for the application you want to create is an impossible task and the reason we adopt/learn the new frameworks is precisely because we want to create the best apps possible.
@@jeremybuckets It's always been a hot community but these past 2-3 years have been bordering on ridiculousness. I think we are going to settle on a sustainable solution but I don't think it's worth learning the "intermediary paradigms" while we figure it out. I feel like I've learned Next.js 4 separate times at this point haha
@@alexnahas2907 LiveView is essentially a «server rendered SPA» (i.e. for *every* (sub) render, not just the initial one) taking advantage of the relatively cheap server side state managed by the Erlang VM. However the web has a fluid spectrum of navigation and rendering options. I recommend having a look over “Patterns for Building JavaScript Websites in 2022” to get some details about this. That spectrum can give rise to any number of overlapping framework implementations. The problem is that people keep looking for «the one» when in fact it is impossible any one implementation to cover the entire spectrum and therefore serve all possible use cases. Astro itself is firmly rooted in a server-first world but inherently supports a broad range of client side interactivity by virtue of being able to host a number of client-side solutions. At the same time it has no intention of being the base for immersive applications with deep sessions like Figma.
What about using HTMX in Astro? My overall impression is that it just needs some equivalent of Rails turbolinks or Laravel livewire to be able to reload part of a page instead of the entire page as a progressive enhancement, which is not the same thing as abandoning MPA. It's just catching up to what PHP or Rails can do One step past that would be to have a liveview like Phoenix, but I don't know if Javascript is the right platform for that
@@awesome-coding You can read the entire docs in an hour and adding it to the project is just a script tag. If you specifically want to be able to reload part of a page as HTML from the server, it is the easiest way to achieve that specific task. It's especially nice if you have a project that has to be handed over to a team that doesn't have permanent frontend devs, since it does not have anything in the JS ecosystem as a prerequisite and it works well with backends written in any language.
@@IainSimmons The whole point is that it was never that complicated to be in the backend-space. JavaScript feels like everyday something changes and you have to learn a completely another way of doing things. It's honestly driven lot of people to fatigue and burnout. Or they just dont learn the new technologies. Which dont take me wrong. Every single step in frontend mileway has been a big one. But not big enough to break the battle of framework and libraries. There's no such thing in any other space except the JavaScript community. And it's just getting ... to the point of boring. I honestly got myself out when I started things going downhill at 2019 and just became full Go dev in my professional career. The worst dilemma or wonders I have are just "why the fuck did they implement generics that way" or "why no enums". Not which new framework to choose this month for my new golang application. Now I'm using SvelteKit for my sideproject + go. And I keep seeing no final solution. I still feel like SvelteKit is just a matter of 1-2 years before it is being replaced/hyped over by some other project. JavaScript proves that it has been a mistake every step along the way. And I love that I stopped giving a fuck about it professionally long ago. edit: bonus: npm .... no need to say a lot about that. Security issues and vulnurabilities, one registry to rule them all, 1 line packages being used by big projects (isEven), literally useless packages like CommonJS or their creators trolling the packages, maintainers constantly abandoning their projects or going to jail even though their project is being used by 1 million other projects. JS is just a big kids' playground.
@@exapsy 🤣🤣😂 If you put it that way you are completely right but this client side router is just for preserving page state across page navigations like the sidebar scroll position for example. It improves the UX a lot
I wonder if your videos have any real purpose. Every time I click, it's just some aim less, random talk
No purpose - I’m just practicing my english 👍🏻
@@awesome-coding Haha, just like my comment
Checkout the "astro" branch in the solid-start repo. Solid-start will be using Astro as base to build off instead of writing their own. Tan-stack start will do the same for react.
The client side router is about preserving page state across navigation. It still renders everything on the server and Islands are still Islands. Everything works the way it did the only change is that the page will not refresh on navigation so things like tabs and scroll positions are preserved without workarounds like using local storage. It makes the UX much better and adds support for features like the View transactions API which is super cool.
No Astro is not turning into another meta framework. There are still no data loading patterns or mutation primitives. Astro components still render only on the server. The router just swaps the changed head and body elements that's it
What is dead is the MPA/SPA dichotomy.
Now there can be a variable mix of server and client routing as required by any specific use case.
Back in 2015 there was a Perficient blog post: “Mixing MPA and SPA: worst of both worlds”.
But now the Gen 3 mantra is “what *can* be done of the server will be done on the server; what *needs* to be done on the client will be done on the client”.
With Rails & Alpine you are grafting the Alpine application on top of the Rails application; “one web application for the price of two”.
Gen 3 frameworks approach server and client as part of the same application.
This is a very good explanation. Thank you!
Okay, hear me out: server side routing, client side navigation
What does that mean?
@@aidantilgner that's how most of the SSR framework work, the inicial routing is on the server after that the client take the navigation.
Next, Remix, SolidStart do that
@Freddx L. im sure im missing something, but isn't that how all javascript frameworks work? Even if you're using react with express, the client is handing the navigation (as an spa) and the server is handling the routing. I thought the only difference with an SSR framework is that it renders the page server side per navigation request and then sends it back to the client's browser.
@@neociber24 That's not how they work :) isomorphic frameworks have two copies of the same router, and run it twice, once on server and once on the client
At this rate, we are all going back to PHP and come full circle.
😂 And we'll call it a "breakthrough"
1:36 I'd like to add that Solid-Start's file based routing is optional.
I much prefer an "app like" experience than loading each page over and over
I get that from the end user's perspective.
But don't most of the SSR framework in JS work that way?
The initial page is using file system routing and after that the client takes control.
NextJS, RemixJS, SolidStart, SvelteKit work like that, helps to achieve smooth transitions.
Right! I know that the majority of frameworks were doing it like this.
However, there was a lot of talk about not needing the client to take control of the navigation.
If astro manage to include an option to give the ability to activate the client routing, or even better, partial client routing between couple of page, well, astro will cover all the use case and in my opinion, it make no sence to choose another framework. It is a verry good idea for them, and i truly hope they will eneable this feature. I'm tired to switch from angular, sveltekit and astro following the use case of the project.
Rich Harris gave a talk recently where he gave a bunch of spicy takes, one of them being that MPA's are dead. I had to do a double take because I feel like it was just yesterday that the headline read "SPA's are dead". The javascript community is honestly exhausting to be on top of right now.
I think I am going to build my apps in Elixir's Phoenix until the javascript community settles down. It's really great and liveview gets you 90% of the client side interactivity you need. The only time I really need Javascript is when I work in three.js and pure SPA's are best suited for that work anyway.
"until the javascript community settles down"
bro it's been 15 years, you think the JS community is going to settle down?
Why do you feel the need to do what « the community » wants you to do ? Just do what is best for the application you want to create
@@evols7028 That's exactly what I'm going to do. What I mean in regards to the is they always claim to solve an issue that currently exists with the older javascript framework. Then, once they are out for a bit, an issue with the new approach arises and a new javascript framework pops up to address that issue, and the cycle continues. Knowing what's best for the application you want to create is an impossible task and the reason we adopt/learn the new frameworks is precisely because we want to create the best apps possible.
@@jeremybuckets It's always been a hot community but these past 2-3 years have been bordering on ridiculousness. I think we are going to settle on a sustainable solution but I don't think it's worth learning the "intermediary paradigms" while we figure it out. I feel like I've learned Next.js 4 separate times at this point haha
@@alexnahas2907 LiveView is essentially a «server rendered SPA» (i.e. for *every* (sub) render, not just the initial one) taking advantage of the relatively cheap server side state managed by the Erlang VM.
However the web has a fluid spectrum of navigation and rendering options. I recommend having a look over “Patterns for Building JavaScript Websites in 2022” to get some details about this.
That spectrum can give rise to any number of overlapping framework implementations.
The problem is that people keep looking for «the one» when in fact it is impossible any one implementation to cover the entire spectrum and therefore serve all possible use cases.
Astro itself is firmly rooted in a server-first world but inherently supports a broad range of client side interactivity by virtue of being able to host a number of client-side solutions. At the same time it has no intention of being the base for immersive applications with deep sessions like Figma.
ever wonder large companies are slow to adopt to new tech stacks? this
They should maybe take some inspiration from StimulusReflex and how they handle the client-side state on the server.
lol @ the intro & outro
YES! at least one person liked it! :))
You suggest Ruby on Rails with Alpine JS and not with Turbo and Hotwire?
It was just an example, especially knowing the popularity of RoR.
What about using HTMX in Astro? My overall impression is that it just needs some equivalent of Rails turbolinks or Laravel livewire to be able to reload part of a page instead of the entire page as a progressive enhancement, which is not the same thing as abandoning MPA. It's just catching up to what PHP or Rails can do
One step past that would be to have a liveview like Phoenix, but I don't know if Javascript is the right platform for that
I never got the chance to properly look into HTMX. Is it really worth it?
@@awesome-coding You can read the entire docs in an hour and adding it to the project is just a script tag. If you specifically want to be able to reload part of a page as HTML from the server, it is the easiest way to achieve that specific task.
It's especially nice if you have a project that has to be handed over to a team that doesn't have permanent frontend devs, since it does not have anything in the JS ecosystem as a prerequisite and it works well with backends written in any language.
@@BosonCollider Nice! Thank you for the explanation!
Any body used solid-router with Astro ???
Only ever used 'location.replace("/someRoute")'
So we still need ssr
Yep 😅
Yeah.. So they want to be Sveltekit...
@@IainSimmons The whole point is that it was never that complicated to be in the backend-space.
JavaScript feels like everyday something changes and you have to learn a completely another way of doing things. It's honestly driven lot of people to fatigue and burnout. Or they just dont learn the new technologies.
Which dont take me wrong. Every single step in frontend mileway has been a big one. But not big enough to break the battle of framework and libraries.
There's no such thing in any other space except the JavaScript community. And it's just getting ... to the point of boring. I honestly got myself out when I started things going downhill at 2019 and just became full Go dev in my professional career. The worst dilemma or wonders I have are just "why the fuck did they implement generics that way" or "why no enums". Not which new framework to choose this month for my new golang application.
Now I'm using SvelteKit for my sideproject + go. And I keep seeing no final solution. I still feel like SvelteKit is just a matter of 1-2 years before it is being replaced/hyped over by some other project.
JavaScript proves that it has been a mistake every step along the way. And I love that I stopped giving a fuck about it professionally long ago.
edit:
bonus: npm .... no need to say a lot about that. Security issues and vulnurabilities, one registry to rule them all, 1 line packages being used by big projects (isEven), literally useless packages like CommonJS or their creators trolling the packages, maintainers constantly abandoning their projects or going to jail even though their project is being used by 1 million other projects. JS is just a big kids' playground.
@@exapsy 🤣🤣😂 If you put it that way you are completely right but this client side router is just for preserving page state across page navigations like the sidebar scroll position for example. It improves the UX a lot
Astro is short of only sending 10kb of JavaScript, which Svelte does already
@@greendsnow sveltekit must be used with svelte but astro can be used with everything, that is the difference.
javascript is becoming php before php frameworks.
is this a good or a bad thing? 😅
Alpine not the best approach becuase it is not safe
care to elaborate?