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.
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 🤣🤣🤣🤣
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.
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.
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 ????
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 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.
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
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.
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.
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.
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.
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
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.
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).
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?
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
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
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.
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
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).
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
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.
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.
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
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
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.
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
@@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 love how the kids just reinvent things and give them new names to rebrand the idea because the previous implementations have such a bad reputation. See Also: Portlets
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 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 🤣🤣🤣🤣
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.
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
Islands architecture, when your app does not need to be a spa, but you still want the headaches
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.
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!
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?
No way! Is this HTMX? 😮
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 ????
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?
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.
Awesome video Theo! Love the sketches. Greetings from Croatia! Yes, we don't have just football players, we have developers as well in Croatia :)
Great video, I really enjoyed watching your explanation of Astro's new feature. 🤙
Didn't deno/fresh do this like three years ago?
was looking for this 👍
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
I love astro, it's actually my favourite javascript framework, reason being it's really simple, not as crazy as NextJS
Ok, maybe I'm getting something wrong. But this feels like we are going back to where we started. I like that.
Yay - ANOTHER framework!
I now feel like an idiot I wrote all my previous stuff in all the frameworks I've used to date!
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
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
Regarding the island architecture, revisit Deno Fresh?
Feels like HTMX in terms of requesting snippets of HTML. 🤷♂️
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.
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.
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.
As a backend dev who felt at loss of sanity coding fromt end, this feels exponentionally easier and intuitive to code and maintain.
This is very tempting to use
Why not PHP?
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.
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.
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.
All this work to meet the functionality of the simple Go+Echo+Templ+HTMX stack
my favorite stack rn
Is it okay for me to say at this stage I am not interested in this and have zero consideration I might use it?
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?
ISR and DSG, also Gatsby left the conversation.
Didn't Deno Fresh coin the term islands a year+ ago?
Just started the video but sounds like what
Deno's Fresh has been doing for a while?
It's similar but not the same. As I understand it Fresh's Island executes on the client as opposed to Astros.
@@everywan 👍
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
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... 👀👀
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).
Is this similar to parallel routes?
you should bring back small talk since it was the true first oop language. glad you show how you code.
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?
ooh perfect timing, I just got into using Astro and have loved it! SSG boiiii!
so now i have another thing to debug when a script doesn't work :)
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.
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?
Is this different then how remix handles it?
so basically like Laravel Livewiere and push js from that component to the main stack when the component is loaded
What about deduplication? If I have three React components, will the runtime only be sent once or thrice?
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
So essentially we're coming back to the xmlhttp requests started back in the days of Ajax making "island" calls to fetch dynamic data 😂😂
What about seo?
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!
This pattern has been around since 2001 with ESI tags and Varnish Cache has been able to process them since 2010 😅
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.
isn't this the same as adding a counter component to nextjs with a use client?
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
"What happens after, is Afterwards" -- teo
So basically htmx
exactly ... lol
Nuxt?😢
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).
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”
Oh yeah, and thats how the history repeats itself. Uset to be its called XHR / AJAX :)
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
This was very interesting
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.
Finally! Astro video
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.
It's crazy how many of these features leptos (Rust client side and SSR framework) already has.
Stupid tangent question, but does anyone know what the vscode color scheme he's using is called?
Poimandres
I thought this video would be about physical islands, with server facilities lmao
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.
Wooooooow! Streeeeeeeaaaaams
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
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
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.
well, you can just cache the response with any server you want and that's it
People seems to have missed how great of a presentation this video was. Theo, your a legend.
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
So what I’m seeing here, is that Astro Server Islands is similar to AJAX? Interesting…
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
would this work with routers?
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
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.
Qwik moment
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
Please follow up with an Astro + Qwik dive.
marketing language used so very often to hide what actually its 'magic. its more than a decade tech. ssi or ajax or jquery😊
at this point, I think we should have just improved jquery and add virtualization to speed up animations... lmao
[insert comment whining about "muh more Javascript frameworks" here]
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.
Thank you for the video
that's how htmx works ?
except the cdn stuff i guess
so cdn is the talk nvm
I love how the kids just reinvent things and give them new names to rebrand the idea because the previous implementations have such a bad reputation. See Also: Portlets
houston we have a solution
👍