I'm a bit miffed that, when they talk about "server-side" they specifically talk about NodeJS-exclusive solutions and static site generators instead of things that can integrate with backend frameworks (Rails, Flask, Django, etc).
With you on this. I run mostly PHP on the server side, but implement web components + Svelte on the client side. What’s more is that there are other JS runtimes and environment types (e.g. Cloudflare workers or WinterJS/WinterCG). Interestingly, runtimes _like_ those which are WinterCG compatible offer opportunities for SSR of JS-bound things (like web components) without necessarily having to have JS as your “back-end”. In this case, there are 3 total layers now (a traditional back-end, traditional front-end and a middleware layer of some sort to perform component SSR). It’s something I’m working on myself in my free time (sorta rare, but still an ongoing thing). 😅
Web components, while not quite as elegant in some ways as modern frameworks, they have one *huge* thing going for them: They’re a standard. That means that they’re here to stay. They work great to sorta bridge the gap as well, in many different ways, including between heterogeneous back-ends (like Ruby, PHP, Python, etc) and even between JS frameworks which support rendering custom elements.
What I'd really like is: Button will not work as scripting is not working. 1 The traits attribute could have multiple values space delimited. This way I don't have to junk up all my HTML with tags. Just add an attribute. Nice and simple. I know there is the `is` attribute. But it only allows for one trait and Safari says they refuse to implement it. But normally I only use one trait so, I suppose I could just polyfill it for now... But I think a lot of library creators don't use it since Safari refuses to implement it.
I'm no expert, just a foggy from the 90s. How is it "server rendered"? The server doesn't layout the page, the server doesn't calculate the DOM. All the server is doing is caching and pushing data. Rendering of everything else is on the client, yes?
To add to that: With the “server rendered” declarative shadow DOM, the component will take on the appearance defined in that HTML/CSS even if JavaScript isn’t even enabled. This is in contrast with the traditionally “client rendered” version where JS would still be required to execute and set the contents of the shadow DOM.
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
I'm a bit miffed that, when they talk about "server-side" they specifically talk about NodeJS-exclusive solutions and static site generators instead of things that can integrate with backend frameworks (Rails, Flask, Django, etc).
With you on this. I run mostly PHP on the server side, but implement web components + Svelte on the client side. What’s more is that there are other JS runtimes and environment types (e.g. Cloudflare workers or WinterJS/WinterCG).
Interestingly, runtimes _like_ those which are WinterCG compatible offer opportunities for SSR of JS-bound things (like web components) without necessarily having to have JS as your “back-end”. In this case, there are 3 total layers now (a traditional back-end, traditional front-end and a middleware layer of some sort to perform component SSR). It’s something I’m working on myself in my free time (sorta rare, but still an ongoing thing). 😅
Great talk, a pleasure to watch, thank you!
I am moving away from a lot of these frameworks to web components. I got sick of the constant bullshit with vue/angular/react specific crap.
Web components, while not quite as elegant in some ways as modern frameworks, they have one *huge* thing going for them: They’re a standard.
That means that they’re here to stay. They work great to sorta bridge the gap as well, in many different ways, including between heterogeneous back-ends (like Ruby, PHP, Python, etc) and even between JS frameworks which support rendering custom elements.
this guy is hilarious, so much that i didn't learn anything i was just laughing the whole time. gonna have to watch again.
i find the endless sarcasm so annoying, different strokes. 😊
What I'd really like is:
Button will not work as scripting is not working.
1
The traits attribute could have multiple values space delimited. This way I don't have to junk up all my HTML with tags. Just add an attribute. Nice and simple. I know there is the `is` attribute. But it only allows for one trait and Safari says they refuse to implement it. But normally I only use one trait so, I suppose I could just polyfill it for now... But I think a lot of library creators don't use it since Safari refuses to implement it.
I couldn't stop noticing how much Zach sounds similarly to Nick Swardson...
:host-context() selector is depreciated I believe, there is a github issue for that.
Do you have a link?
I'm no expert, just a foggy from the 90s. How is it "server rendered"? The server doesn't layout the page, the server doesn't calculate the DOM. All the server is doing is caching and pushing data. Rendering of everything else is on the client, yes?
The term/phrase has come to mean declaring/generating markup dynamically on the web server vs the client.
You can think of it like "rendering" a template. You're right that none of the layouting-related decisions are done on the server's side.
To add to that: With the “server rendered” declarative shadow DOM, the component will take on the appearance defined in that HTML/CSS even if JavaScript isn’t even enabled. This is in contrast with the traditionally “client rendered” version where JS would still be required to execute and set the contents of the shadow DOM.
It's rendering the *html code* in the server, instead of using javascript locally. It's not about the visual rendering that the browser does.
I agree. Kids use wrong terminology to describe things. It's like software development wokeness.
common yellow tint
Why does this guy sound so terrified and nervous? It is really distracting
I was thinking the same thing. Lol
😂😂
get to the point holy hell