I am currently changing all my libraries to components but were the video I saw about components as clear and didactic as this one, I would never have code otherwise
You guys REALLY need to fix that layout. In this case the slides take up only 40% of the viewable area (and I'm definitely being generous here). Small actual pixel count, add some compression to the mix and you get something of worse quality then tutorials made in the early 90s
Great video, I really liked it. I think the biggest problem with Web Components is the people think it's hard, because you have to think in a different way. It's easier to wrap your head around the abstractions we see in JSX and template-based frameworks. However, I think the problem with a lot of frameworks, is that they let you do dumb thing, because you don't have to really think about things like data structure. For instance, we often see prop mining or too many contexts in React, not to mention that 9/10 bugs are because of some hidden dependency you forgot to add to your hooks. And where in the chain of components did the error occur? The thing that was holding me back with Web Components, was the ability to handle a complex data-structure - Where I would definitely not dare to rely on custom events and element attributes to update the DOM.But it can be done, if you bind the Web Components to an observable service(s) that handles when it updates. But it still have its caveats, and requires a bit of overhead. But the data will be isolated to that service, and not floating around in components as we see in React. Still, Web Components are really hard to sell because frameworks are easier to use.
I came to web from windows forms c# and I'm familiar with abstractions. I learned about components couple days ago while working on my pet-project. And this is greatest thing I learned about web developement
@@viteralex Yeah, I'm happy to hear from others who have seen the light :D. Also, you can isolate every component with shadowDOM, and you don't need a ton of tools to mimic that. Also, your styling becomes a lot more simple, so you don't need tools like Sass to handle inheritance etc. Just put it in a style tag in the template. Best thing about WCs is that they are completely agnostic. So you can use them in any client-side framework. I used them with great success in a nasty React/Pug/jQuery combo - and it worked great across the all technologies.
Год назад
I had a bad time trying to bind the "onchange" property with my component dispatching an "onchange" event (Programming can make you feel quite powerful but NS (Natural Stupidity) always level things up)
I think what most people are missing is that these are _low level_ apis. They are shockingly powerful, but we should & will have frameworks that take care of the boilerplate, add type checking etc. What is great to me is that we can finally use regular attributes, regular events, etc. This means that the html markup actually starts to reflect what our application is doing AND makes testing so much easier since we just rendering a custom component, using regular dom APIs to fire & listen to events. Our frameworks aren't all ready yet, but getting our application logic closer & closer to the real native web apis is always a good thing.
This is NOT something you would do, writing them as bare stings. And even IF, this is not a problem at all. This gives me Jinja vibes. And in the end your HTML is just a bare string. It just get's interpreted by the browser or your ide. I don't see a reason why syntax highlighting would not be possible to support. I think there are many things one could critique, but this string thing is a "problem" which was solved more than 20 years ago.
@@addcoding8150 Writing them as string screws me over big time since my accessibility tools treats it as what they are, strings. Writing code inside of strings is such an ugly hack. I guess that makes it fit right in with html, css and js though, because they're already filled to the brim with hacks and workarounds.
@@WorstDeveloper In the beginning, he also showed the more declarative way of doing this - using a template element in the HTML, which is then accessed by the JavaScript. I think that is a better way of doing this.
Far the biggest enemy to web component popularity is React. React has better TypeScript integration for props. In web components there is no way to declare the “props” interface, in React you can. A hell lot of developers are in love with hooks, web components paradigm is completely class based, I love it, but hard core hook fanatics will never give up on hooks.
As a big fan of hooks for years I think most the comments here are missing the big picture. What we're looking at here is a low level api which we should have frameworks target. Though I think modelling new frameworks against web APIs (like using events & regular attributes) would be better than what we currently have with react & most current web frameworks. When the framework is in place, hooks, typescript, all of that is possible & maybe more.
I am currently changing all my libraries to components but were the video I saw about components as clear and didactic as this one, I would never have code otherwise
You guys REALLY need to fix that layout. In this case the slides take up only 40% of the viewable area (and I'm definitely being generous here).
Small actual pixel count, add some compression to the mix and you get something of worse quality then tutorials made in the early 90s
The web is always backwards compatible.
Great video, I really liked it.
I think the biggest problem with Web Components is the people think it's hard, because you have to think in a different way. It's easier to wrap your head around the abstractions we see in JSX and template-based frameworks. However, I think the problem with a lot of frameworks, is that they let you do dumb thing, because you don't have to really think about things like data structure. For instance, we often see prop mining or too many contexts in React, not to mention that 9/10 bugs are because of some hidden dependency you forgot to add to your hooks. And where in the chain of components did the error occur?
The thing that was holding me back with Web Components, was the ability to handle a complex data-structure - Where I would definitely not dare to rely on custom events and element attributes to update the DOM.But it can be done, if you bind the Web Components to an observable service(s) that handles when it updates. But it still have its caveats, and requires a bit of overhead. But the data will be isolated to that service, and not floating around in components as we see in React.
Still, Web Components are really hard to sell because frameworks are easier to use.
I came to web from windows forms c# and I'm familiar with abstractions. I learned about components couple days ago while working on my pet-project. And this is greatest thing I learned about web developement
@@viteralex Yeah, I'm happy to hear from others who have seen the light :D.
Also, you can isolate every component with shadowDOM, and you don't need a ton of tools to mimic that. Also, your styling becomes a lot more simple, so you don't need tools like Sass to handle inheritance etc. Just put it in a style tag in the template.
Best thing about WCs is that they are completely agnostic. So you can use them in any client-side framework. I used them with great success in a nasty React/Pug/jQuery combo - and it worked great across the all technologies.
I had a bad time trying to bind the "onchange" property with my component dispatching an "onchange" event (Programming can make you feel quite powerful but NS (Natural Stupidity) always level things up)
Great job on explaining such a complicated topic in just 40 minutes! I finally understand how web components work.
I think what most people are missing is that these are _low level_ apis.
They are shockingly powerful, but we should & will have frameworks that take care of the boilerplate, add type checking etc.
What is great to me is that we can finally use regular attributes, regular events, etc. This means that the html markup actually starts to reflect what our application is doing AND makes testing so much easier since we just rendering a custom component, using regular dom APIs to fire & listen to events.
Our frameworks aren't all ready yet, but getting our application logic closer & closer to the real native web apis is always a good thing.
Very good presentation!
Who on earth thought it would be a good idea to type html and css as strings?
Were they high when they created web components?
This is NOT something you would do, writing them as bare stings. And even IF, this is not a problem at all. This gives me Jinja vibes. And in the end your HTML is just a bare string. It just get's interpreted by the browser or your ide. I don't see a reason why syntax highlighting would not be possible to support. I think there are many things one could critique, but this string thing is a "problem" which was solved more than 20 years ago.
@@addcoding8150 Writing them as string screws me over big time since my accessibility tools treats it as what they are, strings. Writing code inside of strings is such an ugly hack. I guess that makes it fit right in with html, css and js though, because they're already filled to the brim with hacks and workarounds.
@@WorstDeveloper In the beginning, he also showed the more declarative way of doing this - using a template element in the HTML, which is then accessed by the JavaScript. I think that is a better way of doing this.
Ikr.
If you're on vscode 'Inline HTML' can help
Guys you definitely have no clue what is lit-html, that is revolutionary standard JS syntax vs JSX. And VS code extensions supports syntax highlight.
Far the biggest enemy to web component popularity is React. React has better TypeScript integration for props. In web components there is no way to declare the “props” interface, in React you can. A hell lot of developers are in love with hooks, web components paradigm is completely class based, I love it, but hard core hook fanatics will never give up on hooks.
As a big fan of hooks for years I think most the comments here are missing the big picture.
What we're looking at here is a low level api which we should have frameworks target. Though I think modelling new frameworks against web APIs (like using events & regular attributes) would be better than what we currently have with react & most current web frameworks.
When the framework is in place, hooks, typescript, all of that is possible & maybe more.
I don't understand why they are trying to sell us Web Components. Web Components more like 💩 components.