How to pwn your frontend with thousands of extraneous network calls in one line of code I would definitely use Alpine for something like a counter that is heavily interacted with over HTMX (to be clear, I’m about mixing HTMX and Alpine and using each when appropriate to do so)
@@owenwexler7214 You could technically have the cdn go through an edge and have it strip out the hx-trigger="load" requests and have the edge do these calls and stream this to the client. It'd be as complex as PPR though.
I´m genuinely confused... How´s that different from what we used to do 15 years ago by hosting static html and using js to fetch api and replacing some part of the view? Am I missing something? I´m starting to believe that people just forgot the way we used to do sites before SPA´s....
It’s the same concept (and also similar to HTMX), they’re just supporting it out of the box for their framework, which also supports other techniques eg client islands (parts of the page which are handed over to client side rendering for some frontend framework eg react or vue). So things are just returning to normal I guess 😅
@lucasmarin4040 I don't think so... we used to host static sites even before javascript. That technique regarding host static content and replace it with some dynamic content was popularized by ajax technology in the early 00's.
lmao.. yeah! SPA frameworks simplified this part so we don't need to do this 🤣🤣🤣 now they saying like this is the big issue.. Dang, we already have code splits and lazy load in react to minimize initial load times.. we don't need to do this 🤣🤣🤣🤣
This was a great demo to explain these concepts. Kudos! I am loving Astro more and more. However, if this is all you need, I'd still go HTMX route and use whatever you want to build the static files to host on a CDN.
I think most people commenting here that this is just like htmx are only partially right. Server Islands are like a shortcut to hx-get a dynamic route (params = props) with a partial HTML response and with hx-trigger="load" to start the request once the initial page and JS has loaded. You definitely can do it with htmx, along with so much more, and even use both together on an Astro site. This just saves a ton of time and gives a nice DX for hybrid static/SSR apps.
This reminds me of how we used React when it first came out. We had static web apps where we built a React app and mounted it in a specific div on the page (for adding a comments functionality, for instance, you should typically insert a div with a data attribute and a specific class name, and then mount React into that div and supply the data attributes to the main component being mounted.
14:19 this seems unnecessary, if you are building for the CDN, you can also build an optimized version which doesn't have the content which the CDN already delivered ????
Did this 10+ y ago with server-cached (varnish) magento frontend (it's so slow). We only fetched the dynamic parts (cart, user-login) via ajax. Worked great for simple stuff, but get's pretty convoluted when it gets more complicated.
Reminds me of Java portals :) For example Liferay basically works like that; you create a portlet, add that to a layout, it takes care of its own UI, backend and connections. Granted, nothing about that is fast or optimized for loading speed, it's all about isolation
The server endpoints for server island components needs to be dynamic URLs, since a user hitting site when you've deployed version A1 will hit server component at /MyComponent, then when you deployed site version B2 that same user will still be hitting /MyComponent endpoint expecting content from site version A1. Unless somehow you're forcing all users viewing site to reload when you deploy a new version, which isnt feasible at all since many people have inactive tabs viewing older versions of your website.
This is is the go-to progressive enhancement vanilla JS approach for years - I did this well over 12 years ago. It’s a great approach, it always has been. It’s just baffling that it’s this new/foreign to the JavaScript/React/web app community. Anyway, great feature, great explainer, and glad you’re putting this out.
This is like SPA with the shell being pre-rendered and served from the CDN. The benifit here over SPA would be less JS that we ship to the client. However there is one area where NextJS approach might prove better is SEO. This the same reason why people started SSR their SPA page and then hydrate on client. Relying on JS to load content negatively impacts SEO which is a deal breaker for blogs/news articles/e-commerce etc. Or am I missing something?
Hey YT comments: I'm confused by the PPR example. What's the benefit/purpose of having the "server" run the exact same first response as the "CDN" just to kill it on the "edge" section? I don't have the correct words for it I think, but it seems a bit needlessly complex? I understand it's a hard problem, but the confusion is still there.
Would it actually be possible to have an Astro Server Islands approach in NextJS? What if I want a fully client-less page but with dynamic chunks, and without the complex edge-server ordeal? Is that achievable?
Export the route statically, and load components with `ssr: false` using next/dynamic and you can have very similar behaviors (this is how Ping, UploadThing and my new picture service's homepages all work)
@@t3dotgg I understand how next/dynamic with ssr:false can help improve FCP, but does it mean you do data fetching client-side on the lazy-loaded components? (Otherwise I don't see the parallel with Server Islands).
Genuine question, why is this news? I thought this concept/feature was already something Astro supported and was the whole idea of what Astro was based off? I already had the assumption that you were able to render sections of a site dynamically with a separate JS framework while having the rest of the site loaded via SSR or something else SEO friendly?
Coding in public has a great video explaining what was going on before and whats actually new. TLDR though basically before it would still be hard to cache pages with ssr with a CDN, since you had to run the generation function. Now you can hit a cdn and your page can still stream in stuff from an ssr provider.
In Svelte you can just fetch dynamic content in the client. I do prefer how data is handled in Svelte: - Static is pre-rendered - Dynamic data can be fetched in your server load functions - If it’s better suited, you can also fetch dynamic data directly from the component
Sometimes I think like Apple trying to make the iPhones thinest possible instead of making them better. We as developers are fixating on trying to make the site load faster. Below 200 ms is still fast enough to anyone to notice the difference. We don't really need solutions to get from 50 ms to 10 ms.
what about comparing astro islands with nextjs standalone? I actually find it to be a lot faster than non-standalone outputs. Even with 1 server on a different continent than my user, it's still extremely fast. no cold starts, cdn responses are not noticeably slower.
I did not understand what you mean What is faster? Astro Island? NextJs standalone? Normally serveless is always slower than a hosted app except when the hosted app is doing garbage collector or have a memory leak
32:33 I remember a time when the hitcouter was just an image tag on a HTML file which points to a URL which dynamically put some images with numbers together and record the count.
it's worth watching the whole video before writing comments no one states it's a breakthrough, but it's an easy way to do it just add a prop to an existing component, and it works no additional libs, services, weird config files for ESI living somewhere on the servers and being hard to update when shipping new app version
It's the classic difference between an inventor and an entrepreneur. The inventor invents something, while the entrepreneur is the one who figure out how to make things useful for many people.
Then the salesman gives it a catchy name, adds some vendor buy-in ("you're gonna have a hard time if you try to set it up in your own infra, just use our service!") and you end up paying for something that was already practiced 20 years ago and for free, before the terms "CDN" and "Edge" were coined.
It seems that most devs here are not understanding what are the benefits of using Server Components streamed. The only "real" benefit comparated to use something simple like HTMX load is that it reuses the same network connection and probably the database connection saving lot of computation power and costs for high demand apps For any common app the old simple way is probably way better and simpler to maintain
Currently, 22 Minutes after your comment - there are just 13 Commentarys visible to me and none are bots. I believe your comment that they're was bot comments, but they appear to be deleted/not visible anymore. Someone is cooking.
cool stuff.. what about form actions that next offers or... cache invalidations right from the server actions? so in a way this is just good old critical-css stuff?
How is Astro Server Islands different from fetching data with something like React Query? I guess the benefit is that Astro prepares the server APIs seamlessly for you, rather than us having to create a server API separately.
Oh I guess "less javascript" is a big one, astro's approach of fetching the data from its own server is probably more lightweight (and wouldn't even necessarily require client-side React code to work).
Can someone with an actual understanding of RSCs explain to me the difference between Having a RSC in next that calls a client component inside of it Having a react component in astro with no client directive that calls a component with a client directive inside of it Does astro basically achieve the same end goals of the RSC paradigm without actual RSCs? is the only difference that a server component (no client directive) in astro will "let" you call browser APIS like useState, but they wont work, whereas next will give a legit error? is that really it?
The difference on a technical level is not that different as you’re realizing here The difference in functionality, integration etc is much larger but in the sense that it’s a TON of “small differences”. In RSCs, you can mount a client component and pass it a server component all within React. In Astro, the “boundaries” have to be described with Astro’s syntax outside of React Fwiw, Dan Abramov has used Astro as the “server side react” example and tRPC as the “server actions” example to explain in the past
Can someone help me understand "why" you would want a cart component to be server side? Since it's different for each user, what's the benefit to having this on the server? Why don't we just do this client side and let the browser handle it?
@@DiogoSilva-xx8nz not really tho? Fetching the cart needs to happen each time (no caching). So in this use case I don't know the benefit of doing it on the server vs the client side. You'll show a loading state regardless
@@thomasv1999you should keep track of what your user is trying to buy on the server so you have info to show recommended products maybe display a you have already ordered badge on some product cards etc
Picture this: because the astro server has to serve small bits of html, it can be a cheap server, running all the time. Boom! You don't have cold startup
sounds also somewhat scary. How secure is this? I mean, normally, developers don't need to care that much what the user puts inside the component as it's on the client, but when it's run on the server it seems to open new attack possibilities
You would typically have the static parts of the site rendered on the server, like the general layout and blocks that anyone can see, and anything that requires authentication would not use server islands because it's dynamic content (e.g. displays the name of the logged-in user)
@@andreilucasgoncalves1416 its about that i can now easily change the javascript and send stuff to the server which could be exploited. You can do it also on the client with the difference that it can't do anything as everything happens on the client , but its different when the page gets rendered on the server and than gets to a server. a quick way would be something if a component takes a path in or something like "./assets/" or whatever (just an example) and now i give in "../../../home" and i can view stuff on the server.
I disagree with some key points. No, it isn't about the speed of showing the person something. It is about showing them something meaningful which they can interact with. If I see the framework of a site load, yet not the thing I need to interact with, and I have to wait for it to load, that is worse than if the page itself just took longer to load. And it is even more annoying if some elements are there, but I can't interact with them until the page fully loads, and if I do I then need to refresh the page. And likewise it is very annoying if it loads, so I can interact, but then something else loads which pushes it around making me click the wrong thing. Also, if I understand this correctly, this then makes individual requests for each dynamic component.
And related to that, showing me a useless message that you are loading is no better than just leaving the default browser page. If that means you site takes longer to actually load, then it is a worse experience. The only time such loading information is useful is if it is showing progress, which is only useful if it is something that takes a long time and the progress indicator is meaningful and usable.
Islands is not something new. They have been here for several years already and astro was ignored for around two or three years. I'm glad that now devs starts to experimenting with it.
@@t3dotgg my understanding of your explanation is that static parts or the page can come quickly from cache while dynamic parts come from a streamed response. My question is why not just send down discrete webcomponents down with the cached page that will fetch dynamic data? I dont see the benefits of this complexity.
I think of Theo as both an extremely useless and extremely skillful developer. It’s like two unstoppable forces colliding, ultimately leaving behind a sense of nothingness and a broken time machine.
I would argue that React has pretty much won them already, but astro can integrate all the other frameworks, so it is basically a meta framework. I used astro before and really like it.
I don't use Astro, neither Next or Sveltekit because of too complex build steps Most devs I know prefer just use Vite with SPA because it is simple, easy and fast enough
a workaround in nextjs would be to have a static side and just fetch the data needed through client fetching (react query). obviously more work, and not as elegant but probably kind of similar in speed.
You don’t have to use a JavaScript framework for enterprise stuff - all the enterprise web stuff I’ve ever touched has been written in C# and Razor with a bit of jQuery lol
hx-trigger="load" hx-get="/count" hx-swap="innerHTML"
red pill gang
How to pwn your frontend with thousands of extraneous network calls in one line of code
I would definitely use Alpine for something like a counter that is heavily interacted with over HTMX (to be clear, I’m about mixing HTMX and Alpine and using each when appropriate to do so)
@@owenwexler7214 You could technically have the cdn go through an edge and have it strip out the hx-trigger="load" requests and have the edge do these calls and stream this to the client. It'd be as complex as PPR though.
Alpine AJAX is better than HTMX especially if you're already using Alpine. It's a very good plugin.
imagine putting application code in the markup. unmaintainable mess in the making
I´m genuinely confused... How´s that different from what we used to do 15 years ago by hosting static html and using js to fetch api and replacing some part of the view?
Am I missing something?
I´m starting to believe that people just forgot the way we used to do sites before SPA´s....
It’s the same concept (and also similar to HTMX), they’re just supporting it out of the box for their framework, which also supports other techniques eg client islands (parts of the page which are handed over to client side rendering for some frontend framework eg react or vue).
So things are just returning to normal I guess 😅
Was it really like that? I don't remember hosting the static content in a cdn, I think thats the main difference.
@lucasmarin4040 I don't think so... we used to host static sites even before javascript. That technique regarding host static content and replace it with some dynamic content was popularized by ajax technology in the early 00's.
@@O_Eduardo it's harder!
Yeah. The novel concept of... Not having your entire page be one huge component.
I used to do this with JQuery and partial templates rendered by my MVC backend. 😂
Everybody used to do that... I believe that Theo just started front-end after SPA era...
Oh yeah. AspNet MVC + Partial Views + JQuery was indeed very hot back when I first started learning web.
Circles do have a tendency to close ;)
Thought the same exact thing immediately. Not that they've given it a name, they make it sounds they've invented something new.
lmao.. yeah! SPA frameworks simplified this part so we don't need to do this 🤣🤣🤣
now they saying like this is the big issue..
Dang, we already have code splits and lazy load in react to minimize initial load times.. we don't need to do this 🤣🤣🤣🤣
Islands architecture, when your app does not need to be a spa, but you still want the headaches
re-learning the same front-end lessons over and over--but with a new name and more dependencies and complexity.
yes, but this time we are re-learning the lessons much faster and more efficiently!
This was a great demo to explain these concepts. Kudos! I am loving Astro more and more. However, if this is all you need, I'd still go HTMX route and use whatever you want to build the static files to host on a CDN.
All this complexity just for Vercel to make more money from hosting. Nice! I miss good old Gatsby SSG. Astro is great though
I think most people commenting here that this is just like htmx are only partially right. Server Islands are like a shortcut to hx-get a dynamic route (params = props) with a partial HTML response and with hx-trigger="load" to start the request once the initial page and JS has loaded.
You definitely can do it with htmx, along with so much more, and even use both together on an Astro site. This just saves a ton of time and gives a nice DX for hybrid static/SSR apps.
wake up honey, a new framework that takes months to learn to be replaced by another dropped.
when does this ever actually happen? or are you just memeing like most youtube commenters
@@PraiseYeezusha?
Welcome to Microsofts GUI frameworks.... Wait, this is the web
skill issue
@@jurassicthunder Astro has been around for years. When last has a new framework been released?
I sat through 18 minutes thinking you were describing Server Islands just to be revealed that Server Islands is just HTMX rebranded.
Really? HTML serves a static layer and then client request for the dynamic content?
This reminds me of how we used React when it first came out. We had static web apps where we built a React app and mounted it in a specific div on the page (for adding a comments functionality, for instance, you should typically insert a div with a data attribute and a specific class name, and then mount React into that div and supply the data attributes to the main component being mounted.
First time I understand Edge. Thanks
14:19 this seems unnecessary, if you are building for the CDN, you can also build an optimized version which doesn't have the content which the CDN already delivered ????
Great video, I really enjoyed watching your explanation of Astro's new feature. 🤙
Awesome video Theo! Love the sketches. Greetings from Croatia! Yes, we don't have just football players, we have developers as well in Croatia :)
As someone who knows nothing about frontend, I'm shocked that all of this functionality hadn't been there for at least 5 years.
Oh, it has. For about 25 years.
No way! Is this HTMX? 😮
Did this 10+ y ago with server-cached (varnish) magento frontend (it's so slow). We only fetched the dynamic parts (cart, user-login) via ajax. Worked great for simple stuff, but get's pretty convoluted when it gets more complicated.
Didn't deno/fresh do this like three years ago?
was looking for this 👍
Reminds me of Java portals :)
For example Liferay basically works like that; you create a portlet, add that to a layout, it takes care of its own UI, backend and connections. Granted, nothing about that is fast or optimized for loading speed, it's all about isolation
The server endpoints for server island components needs to be dynamic URLs, since a user hitting site when you've deployed version A1 will hit server component at /MyComponent, then when you deployed site version B2 that same user will still be hitting /MyComponent endpoint expecting content from site version A1. Unless somehow you're forcing all users viewing site to reload when you deploy a new version, which isnt feasible at all since many people have inactive tabs viewing older versions of your website.
Ok, maybe I'm getting something wrong. But this feels like we are going back to where we started. I like that.
This is is the go-to progressive enhancement vanilla JS approach for years - I did this well over 12 years ago. It’s a great approach, it always has been. It’s just baffling that it’s this new/foreign to the JavaScript/React/web app community. Anyway, great feature, great explainer, and glad you’re putting this out.
This is like SPA with the shell being pre-rendered and served from the CDN. The benifit here over SPA would be less JS that we ship to the client.
However there is one area where NextJS approach might prove better is SEO. This the same reason why people started SSR their SPA page and then hydrate on client. Relying on JS to load content negatively impacts SEO which is a deal breaker for blogs/news articles/e-commerce etc.
Or am I missing something?
You’re wrong since the SEO will be the same for both. Both ship the unchanged content first and that’s the content that will be used for SEO
I love astro, it's actually my favourite javascript framework, reason being it's really simple, not as crazy as NextJS
As a backend dev who felt at loss of sanity coding fromt end, this feels exponentionally easier and intuitive to code and maintain.
Feels like HTMX in terms of requesting snippets of HTML. 🤷♂️
Yay - ANOTHER framework!
I now feel like an idiot I wrote all my previous stuff in all the frameworks I've used to date!
This is very tempting to use
Hey YT comments: I'm confused by the PPR example. What's the benefit/purpose of having the "server" run the exact same first response as the "CDN" just to kill it on the "edge" section? I don't have the correct words for it I think, but it seems a bit needlessly complex?
I understand it's a hard problem, but the confusion is still there.
ooh perfect timing, I just got into using Astro and have loved it! SSG boiiii!
Why not PHP?
So basically htmx
exactly ... lol
Regarding the island architecture, revisit Deno Fresh?
Would it actually be possible to have an Astro Server Islands approach in NextJS? What if I want a fully client-less page but with dynamic chunks, and without the complex edge-server ordeal? Is that achievable?
Export the route statically, and load components with `ssr: false` using next/dynamic and you can have very similar behaviors (this is how Ping, UploadThing and my new picture service's homepages all work)
@@t3dotgg I understand how next/dynamic with ssr:false can help improve FCP, but does it mean you do data fetching client-side on the lazy-loaded components? (Otherwise I don't see the parallel with Server Islands).
This pattern has been around since 2001 with ESI tags and Varnish Cache has been able to process them since 2010 😅
Genuine question, why is this news? I thought this concept/feature was already something Astro supported and was the whole idea of what Astro was based off? I already had the assumption that you were able to render sections of a site dynamically with a separate JS framework while having the rest of the site loaded via SSR or something else SEO friendly?
Coding in public has a great video explaining what was going on before and whats actually new. TLDR though basically before it would still be hard to cache pages with ssr with a CDN, since you had to run the generation function. Now you can hit a cdn and your page can still stream in stuff from an ssr provider.
Nice video Theo! Would it be an option to share your excalidraw diagram with us? I would love to use this to explain this to colleague devs.
ISR and DSG, also Gatsby left the conversation.
Thx for cool video, are there something similar for Svelte?
Not at the moment no
In Svelte you can just fetch dynamic content in the client.
I do prefer how data is handled in Svelte:
- Static is pre-rendered
- Dynamic data can be fetched in your server load functions
- If it’s better suited, you can also fetch dynamic data directly from the component
so now i have another thing to debug when a script doesn't work :)
so basically like Laravel Livewiere and push js from that component to the main stack when the component is loaded
"What happens after, is Afterwards" -- teo
All this work to meet the functionality of the simple Go+Echo+Templ+HTMX stack
my favorite stack rn
Is this similar to parallel routes?
Sometimes I think like Apple trying to make the iPhones thinest possible instead of making them better. We as developers are fixating on trying to make the site load faster. Below 200 ms is still fast enough to anyone to notice the difference. We don't really need solutions to get from 50 ms to 10 ms.
This is a real question but isn’t this the same thing that qwik does? Basically serializing data as html (json) instead of the cdn?
what about comparing astro islands with nextjs standalone? I actually find it to be a lot faster than non-standalone outputs. Even with 1 server on a different continent than my user, it's still extremely fast. no cold starts, cdn responses are not noticeably slower.
I did not understand what you mean
What is faster? Astro Island? NextJs standalone?
Normally serveless is always slower than a hosted app except when the hosted app is doing garbage collector or have a memory leak
What about deduplication? If I have three React components, will the runtime only be sent once or thrice?
Strangely, I can image Theo as a cop similar to Reno 911 or a cop from super troopers cause of the stashe, anyone agree with me here?
Also possible with Edge Side Includes (and Varnish)
32:33 I remember a time when the hitcouter was just an image tag on a HTML file which points to a URL which dynamically put some images with numbers together and record the count.
Clearly
I'm amazed how javascript dev are trying to reinvent the wheel everyday
@@nicejungle I'm not against it, but I wish people who are doing it didn't have the disconnect with the past.
it's worth watching the whole video before writing comments
no one states it's a breakthrough, but it's an easy way to do it
just add a prop to an existing component, and it works
no additional libs, services, weird config files for ESI living somewhere on the servers and being hard to update when shipping new app version
Didn't Deno Fresh coin the term islands a year+ ago?
It's the classic difference between an inventor and an entrepreneur. The inventor invents something, while the entrepreneur is the one who figure out how to make things useful for many people.
Then the salesman gives it a catchy name, adds some vendor buy-in ("you're gonna have a hard time if you try to set it up in your own infra, just use our service!") and you end up paying for something that was already practiced 20 years ago and for free, before the terms "CDN" and "Edge" were coined.
you should bring back small talk since it was the true first oop language. glad you show how you code.
Please follow up with an Astro + Qwik dive.
Is it okay for me to say at this stage I am not interested in this and have zero consideration I might use it?
well, you can just cache the response with any server you want and that's it
It seems that most devs here are not understanding what are the benefits of using Server Components streamed. The only "real" benefit comparated to use something simple like HTMX load is that it reuses the same network connection and probably the database connection saving lot of computation power and costs for high demand apps
For any common app the old simple way is probably way better and simpler to maintain
The bots love your content
Currently, 22 Minutes after your comment - there are just 13 Commentarys visible to me and none are bots. I believe your comment that they're was bot comments, but they appear to be deleted/not visible anymore. Someone is cooking.
Idk some of these comments lol... 👀👀
Is this different then how remix handles it?
cool stuff.. what about form actions that next offers or... cache invalidations right from the server actions?
so in a way this is just good old critical-css stuff?
Stupid tangent question, but does anyone know what the vscode color scheme he's using is called?
Poimandres
Finally! Astro video
How is Astro Server Islands different from fetching data with something like React Query? I guess the benefit is that Astro prepares the server APIs seamlessly for you, rather than us having to create a server API separately.
Oh I guess "less javascript" is a big one, astro's approach of fetching the data from its own server is probably more lightweight (and wouldn't even necessarily require client-side React code to work).
Can someone with an actual understanding of RSCs explain to me the difference between
Having a RSC in next that calls a client component inside of it
Having a react component in astro with no client directive that calls a component with a client directive inside of it
Does astro basically achieve the same end goals of the RSC paradigm without actual RSCs?
is the only difference that a server component (no client directive) in astro will "let" you call browser APIS like useState, but they wont work, whereas next will give a legit error? is that really it?
The difference on a technical level is not that different as you’re realizing here
The difference in functionality, integration etc is much larger but in the sense that it’s a TON of “small differences”. In RSCs, you can mount a client component and pass it a server component all within React. In Astro, the “boundaries” have to be described with Astro’s syntax outside of React
Fwiw, Dan Abramov has used Astro as the “server side react” example and tRPC as the “server actions” example to explain in the past
@@t3dotggThat's super cool you reply to yt comments. Thank you!! It does make sense!
The story about how a User become an Edge, which sounds like obvious thing🎉
I wouldn’t even surprise if HTMX is evaluating that “needSomething”
So essentially we're coming back to the xmlhttp requests started back in the days of Ajax making "island" calls to fetch dynamic data 😂😂
Can someone help me understand "why" you would want a cart component to be server side? Since it's different for each user, what's the benefit to having this on the server? Why don't we just do this client side and let the browser handle it?
having it rendered by the server gives the user a faster ui presentation
@@DiogoSilva-xx8nz not really tho? Fetching the cart needs to happen each time (no caching). So in this use case I don't know the benefit of doing it on the server vs the client side. You'll show a loading state regardless
@@thomasv1999you should keep track of what your user is trying to buy on the server so you have info to show recommended products maybe display a you have already ordered badge on some product cards etc
@@thomasv1999 Only the first hit is rendered by the server
What about seo?
isn't this the same as adding a counter component to nextjs with a use client?
Picture this: because the astro server has to serve small bits of html, it can be a cheap server, running all the time. Boom! You don't have cold startup
no. svelte already got it right.
Svelte is the way
The only way
ho0w
Please elaborate
@@hl356 reactivity in svelte is the best in most cases
People seems to have missed how great of a presentation this video was. Theo, your a legend.
sounds also somewhat scary.
How secure is this? I mean, normally, developers don't need to care that much what the user puts inside the component as it's on the client, but when it's run on the server it seems to open new attack possibilities
You would typically have the static parts of the site rendered on the server, like the general layout and blocks that anyone can see, and anything that requires authentication would not use server islands because it's dynamic content (e.g. displays the name of the logged-in user)
It normally reuses the same network connection for streaming components which means it is usually "more secure"
@@andreilucasgoncalves1416 its about that i can now easily change the javascript and send stuff to the server which could be exploited.
You can do it also on the client with the difference that it can't do anything as everything happens on the client , but its different when the page gets rendered on the server and than gets to a server.
a quick way would be something if a component takes a path in or something like
"./assets/" or whatever (just an example) and now i give in "../../../home" and i can view stuff on the server.
This was very interesting
Nuxt?😢
It's crazy how many of these features leptos (Rust client side and SSR framework) already has.
ty mate
The wheel is turning and we start to see new developers re-inventing basics, thinking they are inventing the wheel… 🎉 life is life…
this is what happens when you take a bunch of smart people and don't give them a concrete problem to solve.
I disagree with some key points.
No, it isn't about the speed of showing the person something. It is about showing them something meaningful which they can interact with.
If I see the framework of a site load, yet not the thing I need to interact with, and I have to wait for it to load, that is worse than if the page itself just took longer to load.
And it is even more annoying if some elements are there, but I can't interact with them until the page fully loads, and if I do I then need to refresh the page.
And likewise it is very annoying if it loads, so I can interact, but then something else loads which pushes it around making me click the wrong thing.
Also, if I understand this correctly, this then makes individual requests for each dynamic component.
And related to that, showing me a useless message that you are loading is no better than just leaving the default browser page. If that means you site takes longer to actually load, then it is a worse experience.
The only time such loading information is useful is if it is showing progress, which is only useful if it is something that takes a long time and the progress indicator is meaningful and usable.
This video is a masterpiece, thank you Theo!
You explain in such a comprehensible way, pure talent.
I thought this video would be about physical islands, with server facilities lmao
So what I’m seeing here, is that Astro Server Islands is similar to AJAX? Interesting…
would this work with routers?
Oh yeah, and thats how the history repeats itself. Uset to be its called XHR / AJAX :)
Islands is not something new. They have been here for several years already and astro was ignored for around two or three years. I'm glad that now devs starts to experimenting with it.
marketing language used so very often to hide what actually its 'magic. its more than a decade tech. ssi or ajax or jquery😊
that's how htmx works ?
except the cdn stuff i guess
so cdn is the talk nvm
at this point, I think we should have just improved jquery and add virtualization to speed up animations... lmao
Qwik moment
Thank you for the video
why not web components? This seems unnecessarily complex. Write a webcomponent to do something interactive, embed it in the page.
This has nothing to do with interactivity lol
@@t3dotgg my understanding of your explanation is that static parts or the page can come quickly from cache while dynamic parts come from a streamed response. My question is why not just send down discrete webcomponents down with the cached page that will fetch dynamic data? I dont see the benefits of this complexity.
I see why htmx is banned on r/webdevs 😂
the reason is because some tools are used by non web devs to create endless dooms day discussions, like when web assembly came out
I think of Theo as both an extremely useless and extremely skillful developer. It’s like two unstoppable forces colliding, ultimately leaving behind a sense of nothingness and a broken time machine.
Is Astro going to win the framework wars? I have never even tried it. FOMO 😔
I would argue that React has pretty much won them already, but astro can integrate all the other frameworks, so it is basically a meta framework. I used astro before and really like it.
Astro doesn’t have shared state or client-side routing. so not really, unless you building a blog or ecomm site
@@pooyatolideh9527 yeah I agree. Astro seems targeted at blogs. Not real apps
I don't use Astro, neither Next or Sveltekit because of too complex build steps
Most devs I know prefer just use Vite with SPA because it is simple, easy and fast enough
a workaround in nextjs would be to have a static side and just fetch the data needed through client fetching (react query).
obviously more work, and not as elegant but probably kind of similar in speed.
Wooooooow! Streeeeeeeaaaaams
I just want to use Go, Pocketbase and HTMX
Some Alpine too
Neh . You saying this bc you have not worked on enterprise level product. For side projects, your mentioned stack would work
@@habong17359 lmao
@@habong17359 Nope. Go with HTMX (and some Alpine) is a good choice for enterprise projects, and JS mess for side projects.
You don’t have to use a JavaScript framework for enterprise stuff - all the enterprise web stuff I’ve ever touched has been written in C# and Razor with a bit of jQuery lol
Sounds like PHP LOL, wait! SOUNDS LIKE PHP!
Not really, it's direct html and js with no server for the initial request.
Looks like PHP & Varnish infra 10 years ago
What a discovery
[insert comment whining about "muh more Javascript frameworks" here]