Don't get fooled, web components are not what they seem. Whenever someone brings up web components they conveniently always talk about markup and javascript and never speak of how css interacts with the outer world. There is no way for a web component to share css with other web components or even the parent page, because they live in a shadow dom. In short, you can't build a package of web component elements using, say for example bootstrap, without including almost the whole bootstrap library in each and every single web component. Also, afaik, data between web components and outside world is serialized both ways, am I wrong about that, I feel like remembering that to be the case, am I wrong? There is no way I'm going to ship that to an enduser. You are way better off using something like island architecture with Astro or similar platforms. And before you mention how web components is a new technology and needs time to mature, I remind you that they are older than react, web components were introduced in 2011, react in 2013, that's plenty of time to "mature". At least mention the drawbacks at some point in the video if you're gonna clickbait, no hard feelings hopefully.
You can share CSS across shadow trees using constructable stylesheets. No, you do not have to ship the whole bootstrap library with every component. You dont need to serialize Data, you can always use property binding which does not rely on serialisation. You can build an "island architecture" type application wit lit because astro has first class integration with lit. Are you running some sort of anti lit agenda? lol
Hey! Thanks for the feedback - no hard feelings :) You raised some good points, but also some aspects which were already addressed by @klaus_1083. I'm pinning your comment to the top of this video, since I believe you are right - I did a bad job explaining the cons of WebComponents.
"No way for a web component to share css", luckily they added "shadowroot adoptedStyleSheets", which focuses on shareability. Might do the trick for your needs
In my experience with Shadow DOM isolation, most authors promote a sharing design through CSS variables and parts. The variables to define the design tokens so that you can adjust the theme globally and parts to do any necessary overrides you may need for your use case. Big CSS frameworks like Bootstrap are not very popular with WC because the mindset is different; with each component, you have a very focused and minimal stylesheet because of the small scope you need to worry about. That is not to say you cannot share particular standard rules; quite often, those are encapsulated with layout components instead of doing it all with CSS modules you would need to bundle for your route or island.
Complex data is usually passed through properties and not attribute serialization; however, when your data is complex, it is very common that you don't actually use properties. When there is a lot of complex data to worry about there are usually two main approaches: 1) Component Composition, where you break down your layout into smaller components expected to be passed into slots. 2) Global state management, where you create a "Context," usually with a "smart" component, and everyone else just queries the data they need.
My favorite thing about the Lit project is that they don't force you to use Lit Element if you don't want it. I've been using the lit-html package (templating and rendering) with native Web Components since 2017.
same here, using lit-html baked into custom elements together with my own state management solution (based on js proxies) ... i always try to keep the dependencies low and rely on browser standards as much as possible... well i don't like the scoped css thing but hey i don't have to use it :)
Yup. It's been my stack for a long time. Hey, which transpiler/builder did you use to work with polymer components? Recently, I couldn't use them in my project since Gulp, webpack, Babel were complaining about @property syntax
Per usual appreciate the agnostic approach (unless flaming the state of Front End development). Love to see finally after a decade, we’re optimizing php and jquery.
One of my next videos will be on creating a website with PHP and jQuery. I'm sure it'll get almost 0 clicks / views, but at least I'll have fun with it :D
I was forced to use Lit Elements by my education, now using React. My main gripe with lit elements, the shadow dom. I love that my components keep their tag in the HTML, I hate that about React, it all turns into default HTML and forces me to need React devtools to more easily see what's what.
The only thing that is really tricky still with Lit is HMR where you kinda need to generate a random element name to use and register. Otherwise I love using it ever since Polymer 1.5 or so.
I've been using lit for a bigger project.. I like how it doing thing in a component perspective. But once you want to do thing like i18n, global state management (which very weird that they recommend using Redux...), and their context api which only be readonly for child...it is totally painful at the time. Not to mention the authentication part and ssr is still on experimental stage...truly reveal the lit lack of community support. For that said, building a component library using lit maybe a good choice, but not suggest to use for a fullstack project..
I find the Redux suggestion weird as well. I think it would pair much better with a solution like NanoStores. i18n has little to no support in HTML in general, so I would expect it to be a mess in Lit (WebComponents) as well :(
I use Lit when working with home-assistant custom UI elements because its recommended borderline required (requires web components at least). I'm not sold on it, Seems fine but not notably better or worse than anything else I've used. Lit definitely makes dealing with the web component api a little more friendly though.
We started using Lit for all our projects. We were all in with Lit and using Shoelace, but found it to have issues when compiling, would get random compile and runtime errors.The file size was 2-3x the size of other project and the dev experience wasn't all that great. We were creating wrappers to wrappers. IMO it is better to use components that were designed for the framework / library you are building your apps for.
One of the main reason to use webcomponents is building websites using only html/css/js and having component reusability. No npm/script bs and all. Adding something like lit defeats this purpose
I agree with you. On the other hand, the standard way of building web components is fairly tedious / boilerplatey for today's DX standards. A thin layer on top of the WebComponents standard is something I can live with if I get access to decorators, the css and html helpers.
I worked on polymer JS ( daddy of lit ) for almost a year. All I can say it really helps us creating reusable component creation. I remember creating a reusable gradient icon ( applies gradient colors to svg icons by dynamically injecting linear-gradient tag ), tabs, table, pagination components. but Problem arises when we try to bundle those definition files. importing all the definitions increases initial load and we have to do all sort of splitting to efficiently import those definitions right before their use.
Right. But, in all fairness, Vue will be late to the game. Frameworks like Svelte and Solid are already working directly with the DOM, and they can compile to WebComponents as well.
Hi, lit 3 is not full released, it is in pre-released like release candidate (RC), as it is mention in the Docs. Lit is a bit small then svelte and solid. Lit with ts is 5kb big in size in prod compare with js version of lit. So lit pretty cool and fast since behind you are using a native browser feature in the end with small fingerprint.
I like Web Components and already using them, however I don't like one of their aspect: you can build them differently. I tried 3 different approach when building them and with that I don't actually know which one is better. Each time I create something new I have a train of thought "how I will write Web Component today?" And I can't really measure if one of the approach is better, than the other.
I hope I'm getting this right - you are talking about the component implementation code, right? In that case, yes, that code has to be sent over the wire to the browser. The browser has access to the JS engine and the Web APIs needed to execute that code and run the components.
yeah , I'd use this if I wasnt so comfortable with JSX and its large community eco system of existing reusable GUI components . However I'd straight jump on lit rather them working on html5 files directly again. TBH I'd even rather use Jquery then going back to working directly on html files again. I love the advantage of native web components being able to easily be used for reusable server side components .
I've been using lit-html for number of years. I've tried polymer components not so long ago. I couldn't make it to work. Gulp/Babel, webpack/Babel couldn't build/understand "@property" syntax. I had to switch to React.
As some one who came back to web dev after a 16 year hiatus as a game dev, my immediate thoughts were "Wtf is React? Angular? The most Angular thing about this is the learning curve"
@@jediampm I think you might be right. I looked into this still open issue right here - github.com/lit/lit.dev/issues/448 which points out some known XSS risks which might not have been addressed yet. It looks like the whole security aspect is stil an open issue in the GitHub project, but I might be mistaken, in which case I apologise.
Lit is experimenting with SSR (lit.dev/docs/v3/ssr/overview/) but their support is far from the performance you might be used to from other frameworks.
The point of every new library or framework is exploring new ways of doing things and not an opportunity to bash other tools. Eventually, Lit will become a full blown framework like React or Angular, just give it some time to evolve. Finally, we don’t use frameworks because we want to, but because they save us time and effort.
@@awesome-coding Do they really? Last time I tried, it was not really a thing. And to my knowledge Svelte is the only compiler, the rest are libraries/frameworks. Maybe you could do a video with some comparison of native web components in Lit/Svelte/React, that would be awesome :D
@@arjix8738 Yep! React can also do this. Some info is available in their documentation - react.dev/reference/react-dom/components#custom-html-elements And you can use things like these - github.com/bitovi/react-to-web-component
I’m using IntelliJ IDEA. No Discord server yet :( I tried it a couple of months back, and there was little interest in this community to join there. I’ll try it again in a few months once there are more core members in here. I’m very active in the YT comments though
Ye a library like shoelace switched from stincill (a framework to build web components) to lit.. Idk why they did maybe its better for them? Their library is bassically ui elements that you can import into any of your projects by simply adding the es script into your html if you know daisy ui its the same thing but web components
I feel like you should find a better balance between memes / clips and code showed in the video, the fireship kinda style works but u should balance it a little more ;)
I wouldn't call Lit a framework. At most it is a library which simplifies the work of building components using Web Standards. A framework has its own opinionated way of building components, routing, state management, reactivity and more.
Bro can you turn down the bass in your EQ settings please? I want to watch the video cuz it seems valuable but it makes my ears bleed. I suggest buying a pair of quality headphones so that you can hear the overly large volume of bass that your voice with those settings has.
Hey! Thanks for the suggestion! Sound is something I'm still struggling with. I'm usually using the Compressor, Limiter and Normalize settings in Audacity, but I never messed around with the bass. I'll try to figure out how this can be decreased. Thanks again!
Hey! You are right about Angular, they use an Incremental DOM. However, Vue uses a VirtualDOM (vuejs.org/guide/extras/rendering-mechanism.html) but they have plans to offer an alternative with Vapor mode.
Oh, I see Web Components hype about decade and its steel "kinda work". As I remember this conception make simple work simple and unsolved challenge for hard parts. And it's made no sense in real word how you build your components, it's just minor of developer task at all.
from the start of the video when your start writing the word class and this and all that oop things i stop whatching the video sorry but javascript code is much cleaner specially with react
@@awesome-coding bro functional components in react are so simple it is a function that get the data and return html so simple fn(data)=dynamicHTMLComponent and if you respect the good practises and clean code pattern and specially working with atomic design and theming with provider no more css problems and thank you for the video by the way i was lynig i completed watching all the video it was a joke hhh
@@gldzzpro5793 I fully agree that the DX of React (or even better, Solid) is way more convenient than the one WebComponents or Lit is offering. At the end of the day, I believe this is what it all boils down to these days - what's the DX you prefer? You love functional and elegant - try React, you love clean and easy - try Vue, you love a good old fashion s**t show - go with Angular!
Thank you for your feedback! Honestly, this is a tough one for me. I actually like doing more code / text /diagrams (mostly because it's actually easier and faster to produce the video). However, it seems that the more memes I add, the higher the interest and retention in the videos. I'm still trying to calibrate things, and figure out the best mix of useful information and entertainment.
@@awesome-coding awesome, I really like your content and think it is valuable, but we can't satisfy everyone obviously, either we want to entertain first, or teach first ;) keep on the good content.
Lit is a small library that reduces some of the boilerplate of vanilla JS features, and eventually it won't be needed. React has you writing proprietary code that has to be transpiled using a string of third party technologies. One marries you to an entire ecosystem and the other does not. React is a framework that calls itself a library and Lit is an actual library
Don't get fooled, web components are not what they seem.
Whenever someone brings up web components they conveniently always talk about markup and javascript and never speak of how css interacts with the outer world.
There is no way for a web component to share css with other web components or even the parent page, because they live in a shadow dom.
In short, you can't build a package of web component elements using, say for example bootstrap, without including almost the whole bootstrap library in each and every single web component.
Also, afaik, data between web components and outside world is serialized both ways, am I wrong about that, I feel like remembering that to be the case, am I wrong?
There is no way I'm going to ship that to an enduser.
You are way better off using something like island architecture with Astro or similar platforms.
And before you mention how web components is a new technology and needs time to mature, I remind you that they are older than react, web components were introduced in 2011, react in 2013, that's plenty of time to "mature".
At least mention the drawbacks at some point in the video if you're gonna clickbait, no hard feelings hopefully.
You can share CSS across shadow trees using constructable stylesheets.
No, you do not have to ship the whole bootstrap library with every component.
You dont need to serialize Data, you can always use property binding which does not rely on serialisation.
You can build an "island architecture" type application wit lit because astro has first class integration with lit.
Are you running some sort of anti lit agenda? lol
Hey! Thanks for the feedback - no hard feelings :)
You raised some good points, but also some aspects which were already addressed by @klaus_1083.
I'm pinning your comment to the top of this video, since I believe you are right - I did a bad job explaining the cons of WebComponents.
"No way for a web component to share css", luckily they added "shadowroot adoptedStyleSheets", which focuses on shareability. Might do the trick for your needs
In my experience with Shadow DOM isolation, most authors promote a sharing design through CSS variables and parts. The variables to define the design tokens so that you can adjust the theme globally and parts to do any necessary overrides you may need for your use case.
Big CSS frameworks like Bootstrap are not very popular with WC because the mindset is different; with each component, you have a very focused and minimal stylesheet because of the small scope you need to worry about.
That is not to say you cannot share particular standard rules; quite often, those are encapsulated with layout components instead of doing it all with CSS modules you would need to bundle for your route or island.
Complex data is usually passed through properties and not attribute serialization; however, when your data is complex, it is very common that you don't actually use properties.
When there is a lot of complex data to worry about there are usually two main approaches:
1) Component Composition, where you break down your layout into smaller components expected to be passed into slots.
2) Global state management, where you create a "Context," usually with a "smart" component, and everyone else just queries the data they need.
My favorite thing about the Lit project is that they don't force you to use Lit Element if you don't want it. I've been using the lit-html package (templating and rendering) with native Web Components since 2017.
same here, using lit-html baked into custom elements together with my own state management solution (based on js proxies) ... i always try to keep the dependencies low and rely on browser standards as much as possible... well i don't like the scoped css thing but hey i don't have to use it :)
@@fopsdev3676 sounds interesting, would love to connect and talk about it!
Yup. It's been my stack for a long time. Hey, which transpiler/builder did you use to work with polymer components? Recently, I couldn't use them in my project since Gulp, webpack, Babel were complaining about @property syntax
Per usual appreciate the agnostic approach (unless flaming the state of Front End development). Love to see finally after a decade, we’re optimizing php and jquery.
One of my next videos will be on creating a website with PHP and jQuery. I'm sure it'll get almost 0 clicks / views, but at least I'll have fun with it :D
I was forced to use Lit Elements by my education, now using React.
My main gripe with lit elements, the shadow dom.
I love that my components keep their tag in the HTML, I hate that about React, it all turns into default HTML and forces me to need React devtools to more easily see what's what.
You can use arbitrary named custom elements, though react doesn't like them much.
Those are valid in html.
@@thekwoka4707 yeah but I'm talking about runtime. I'd love it if React would just put my in the HTML as is.
Wow! The moment I saw the thumbnail of this video, I was so excited! Thank you. And, as always, the content is of high quality.
Glad you enjoyed it! Thank you for the kind words!
The only thing that is really tricky still with Lit is HMR where you kinda need to generate a random element name to use and register. Otherwise I love using it ever since Polymer 1.5 or so.
I've been using lit for a bigger project.. I like how it doing thing in a component perspective. But once you want to do thing like i18n, global state management (which very weird that they recommend using Redux...), and their context api which only be readonly for child...it is totally painful at the time. Not to mention the authentication part and ssr is still on experimental stage...truly reveal the lit lack of community support. For that said, building a component library using lit maybe a good choice, but not suggest to use for a fullstack project..
I find the Redux suggestion weird as well. I think it would pair much better with a solution like NanoStores.
i18n has little to no support in HTML in general, so I would expect it to be a mess in Lit (WebComponents) as well :(
I use Lit when working with home-assistant custom UI elements because its recommended borderline required (requires web components at least). I'm not sold on it, Seems fine but not notably better or worse than anything else I've used. Lit definitely makes dealing with the web component api a little more friendly though.
Excellent. More, please.
Thank you!
We started using Lit for all our projects. We were all in with Lit and using Shoelace, but found it to have issues when compiling, would get random compile and runtime errors.The file size was 2-3x the size of other project and the dev experience wasn't all that great. We were creating wrappers to wrappers. IMO it is better to use components that were designed for the framework / library you are building your apps for.
Interesting. Thanks for sharing the experience!
One of the main reason to use webcomponents is building websites using only html/css/js and having component reusability. No npm/script bs and all. Adding something like lit defeats this purpose
exactly my first thoughts
I agree with you. On the other hand, the standard way of building web components is fairly tedious / boilerplatey for today's DX standards.
A thin layer on top of the WebComponents standard is something I can live with if I get access to decorators, the css and html helpers.
You can add lit via a CDN.
I remember using polymer web components back in 2014.
That might be exactly what I needed. Thank you!
Glad to hear!
I worked on polymer JS ( daddy of lit ) for almost a year. All I can say it really helps us creating reusable component creation. I remember creating a reusable gradient icon ( applies gradient colors to svg icons by dynamically injecting linear-gradient tag ), tabs, table, pagination components. but Problem arises when we try to bundle those definition files. importing all the definitions increases initial load and we have to do all sort of splitting to efficiently import those definitions right before their use.
When vue ships their new "Vapor" engine (which removes the need for a virtual dom), it becomes a direct competitor to lit, but with a much better api?
Right. But, in all fairness, Vue will be late to the game. Frameworks like Svelte and Solid are already working directly with the DOM, and they can compile to WebComponents as well.
@@awesome-coding well, it is an upgrade to already existing sites that use vue
@@awesome-coding Vue has been able to compile to WC since many years already. Way before the vite days.
Hi, lit 3 is not full released, it is in pre-released like release candidate (RC), as it is mention in the Docs.
Lit is a bit small then svelte and solid. Lit with ts is 5kb big in size in prod compare with js version of lit.
So lit pretty cool and fast since behind you are using a native browser feature in the end with small fingerprint.
Great points!
I like Web Components and already using them, however I don't like one of their aspect: you can build them differently. I tried 3 different approach when building them and with that I don't actually know which one is better. Each time I create something new I have a train of thought "how I will write Web Component today?"
And I can't really measure if one of the approach is better, than the other.
@1.20 Web Component are defined using javascript which has to be sent over the wire, in order to get them defined in browsers right ?
I hope I'm getting this right - you are talking about the component implementation code, right?
In that case, yes, that code has to be sent over the wire to the browser. The browser has access to the JS engine and the Web APIs needed to execute that code and run the components.
@@awesome-coding yes yes yes
yeah , I'd use this if I wasnt so comfortable with JSX and its large community eco system of existing reusable GUI components .
However I'd straight jump on lit rather them working on html5 files directly again. TBH I'd even rather use Jquery then going back to working directly on html files again. I love the advantage of native web components being able to easily be used for reusable server side components .
I've been using lit-html for number of years. I've tried polymer components not so long ago. I couldn't make it to work. Gulp/Babel, webpack/Babel couldn't build/understand "@property" syntax. I had to switch to React.
Interesting point. Thanks!
2:50 this information is wrong - Angular doesn't use a Virtual DOM
As some one who came back to web dev after a 16 year hiatus as a game dev, my immediate thoughts were "Wtf is React? Angular? The most Angular thing about this is the learning curve"
Since it uses plain template literals for rendering, how does it do with xss? Do we need to sanitize the content ourself?
yep - we have to handle xss on our own
@@awesome-coding did you even tried on lit playground if lit avoid xss ? before answer, try it. Because you just gave wrong info. ;)
@@jediampm I think you might be right.
I looked into this still open issue right here - github.com/lit/lit.dev/issues/448 which points out some known XSS risks which might not have been addressed yet.
It looks like the whole security aspect is stil an open issue in the GitHub project, but I might be mistaken, in which case I apologise.
I think that all of the major frameworks can be compiled to Web Components!
Angular has default support for web components. So you can compile to modules to
Web components so you get the best of both worlds
How does it play with tailwindcss?
Why not svelte? It compiles to web components to if that is your thing, or don't if you prefer not to.
The whole benefit of web components is that you don’t have to compile them
It has many limitations, everyone should use lit but people are just ignorant and dumb.
@@danko95bgd some guy said that building a large project is a pain scroll for a lil bit and u will find it.
I would like to rely more on web components. But are they easily server rendered ? It was a major drawback at the time. What about now?
Lit is experimenting with SSR (lit.dev/docs/v3/ssr/overview/) but their support is far from the performance you might be used to from other frameworks.
The point of every new library or framework is exploring new ways of doing things and not an opportunity to bash other tools. Eventually, Lit will become a full blown framework like React or Angular, just give it some time to evolve. Finally, we don’t use frameworks because we want to, but because they save us time and effort.
This sounds exciting 😃
Great Info!
Glad you think so!
This is extremely interesting
Wow... we have so many well-stabilized frameworks.. what are we gonna do?
Lit team: Let's create another one and say we fix many frameworks problems!!
😂✌️
Dude come to an comparison for the frontend frameworks
Svelte vs solid and other frameworks
I got you - th-cam.com/video/wUrY86BTGtg/w-d-xo.html ✌️
Lit docs are pretty raw still. Is there SASS support setup working out of the box?
No out of the box support for SASS I'm afraid 🥲
Svelte can compile into a web component :) No need for all the Lit boilerplate
Most libraries can compile to WebComponents these days 👍🏻
@@awesome-coding can react do it?
Cause having every component be plain html is a pain
@@awesome-coding Do they really? Last time I tried, it was not really a thing. And to my knowledge Svelte is the only compiler, the rest are libraries/frameworks. Maybe you could do a video with some comparison of native web components in Lit/Svelte/React, that would be awesome :D
@@arjix8738 Yep! React can also do this.
Some info is available in their documentation - react.dev/reference/react-dom/components#custom-html-elements
And you can use things like these - github.com/bitovi/react-to-web-component
@@am01013 Will do, thank you for the suggestion!
Are you using WebStorm? Also do you have a community Discord server?
I’m using IntelliJ IDEA.
No Discord server yet :( I tried it a couple of months back, and there was little interest in this community to join there. I’ll try it again in a few months once there are more core members in here. I’m very active in the YT comments though
Are you tired of learning new tools? Just learn this new tool!
It is what it is 😅
I’ve done Web Components like 3 years ago and lookin at Lit right now looks simpler hahaha
Ye a library like shoelace switched from stincill (a framework to build web components) to lit.. Idk why they did maybe its better for them? Their library is bassically ui elements that you can import into any of your projects by simply adding the es script into your html
if you know daisy ui its the same thing but web components
0:21 "If you are sick of all this libraries, web components and especially Lit..."
XD
There is no way around them... sorry 😅
I feel like you should find a better balance between memes / clips and code showed in the video, the fireship kinda style works but u should balance it a little more ;)
Thank you for the feedback! I agree the format can be way better 😅
Hopefully I'll figure it out in time.
Sadly no SSR without a framework. It does the frontend stuff for you, but what framework is limited to this nowadays?
SSR is experimental in Lit 3 - lit.dev/docs/v3/ssr/overview/
Angular does not use virtual DOM
"tired of libraries? There's a library for that!"
😅
First you talk about benefits of not using the framework to later proceed with the framework. I don't get it.
I wouldn't call Lit a framework. At most it is a library which simplifies the work of building components using Web Standards.
A framework has its own opinionated way of building components, routing, state management, reactivity and more.
MOAR
I'm trying but the day only has so many hours in it 😑
I'll have to quit my job soon 🥲😅
lit element and tailwind will be awesome
Yeah, you can't do that...
th-cam.com/video/HwkXCYiRgtE/w-d-xo.html
I don't see the benefit using this instead of Svelte
Svelte has to be compiled and seems to have more proprietary dependencies and syntax
Why Web componentes? Lit. Excelent Solution
vs htmx + hyperscript?
Man... everybody talks about htmx these days - I need to jump on this bandwagon and make a video on it 😅
@@awesome-coding yeappp
@@awesome-coding waiting...
They are so late to the party tho. I was so excited for web components 5 years ago, but Polymer at the time never really took off
YAJFK (Yet another javascript frameworks killer)
But using classes, no from me
This is a very common stance. Funny how class support was such a big deal in ES6, and now everybody is pretty much running away from classes.
@@awesome-coding personally I have no problem with classes, but using objects with methods within them is cleaner and just the same.
Bro can you turn down the bass in your EQ settings please? I want to watch the video cuz it seems valuable but it makes my ears bleed. I suggest buying a pair of quality headphones so that you can hear the overly large volume of bass that your voice with those settings has.
Hey! Thanks for the suggestion!
Sound is something I'm still struggling with. I'm usually using the Compressor, Limiter and Normalize settings in Audacity, but I never messed around with the bass. I'll try to figure out how this can be decreased.
Thanks again!
@@awesome-coding you're welcome 👍 I believe you can use an EQ for such cases
It's frameworks all the way down
😅
Why did you delete my comment?
Hey! Which one? I’m never deleting comments, so it might be some other issue?
Angular and Vue Don't use Virtual DOM btw
Hey!
You are right about Angular, they use an Incremental DOM.
However, Vue uses a VirtualDOM (vuejs.org/guide/extras/rendering-mechanism.html) but they have plans to offer an alternative with Vapor mode.
Oh, I see Web Components hype about decade and its steel "kinda work". As I remember this conception make simple work simple and unsolved challenge for hard parts. And it's made no sense in real word how you build your components, it's just minor of developer task at all.
Writing css in js is the worst
OMg he writes html in js too
hahaha the html comment cracked me up
no it provides no added value
from the start of the video when your start writing the word class and this and all that oop things i stop whatching the video sorry but javascript code is much cleaner specially with react
😂 fair enough!
@@awesome-coding bro functional components in react are so simple it is a function that get the data and return html so simple fn(data)=dynamicHTMLComponent and if you respect the good practises and clean code pattern and specially working with atomic design and theming with provider no more css problems and thank you for the video by the way i was lynig i completed watching all the video it was a joke hhh
@@gldzzpro5793 I fully agree that the DX of React (or even better, Solid) is way more convenient than the one WebComponents or Lit is offering.
At the end of the day, I believe this is what it all boils down to these days - what's the DX you prefer? You love functional and elegant - try React, you love clean and easy - try Vue, you love a good old fashion s**t show - go with Angular!
> I see word class
> immediately loses interest
not going back to cavemen days
😂 I can understand that
Oh lmao another js framework
✌️
OOP again? no thanks. I prefer functional components 😀
Fair enough!
please a little bit less memes videos and a bit more text or diagrams, it feels like watching a video gag show, can't concentrate on content. 😢
Thank you for your feedback!
Honestly, this is a tough one for me. I actually like doing more code / text /diagrams (mostly because it's actually easier and faster to produce the video). However, it seems that the more memes I add, the higher the interest and retention in the videos.
I'm still trying to calibrate things, and figure out the best mix of useful information and entertainment.
@@awesome-coding awesome, I really like your content and think it is valuable, but we can't satisfy everyone obviously, either we want to entertain first, or teach first ;) keep on the good content.
So the solution to a web framework is a web framework 😂😂😂😂
Lit is a small library that reduces some of the boilerplate of vanilla JS features, and eventually it won't be needed. React has you writing proprietary code that has to be transpiled using a string of third party technologies. One marries you to an entire ecosystem and the other does not. React is a framework that calls itself a library and Lit is an actual library
This looks like it came out of a time machine and married the worst parts of java and react
One of my favorite things about having a YT channel is reading the inventive ways you guys come up with to bash a topic 😂
web components is dead
they were dead since their birth
This is what I've been telling people about Java for the past 15 years 🤦♂️