ShadowDOM isn't that much needed and I have concern as to how good this is going to be. ShadowDOM IS a div soup. It's just hidden from you.
From a developer standpoint, the DOM still need to be handled. Moreover, I haven't seen any discussion with regards to strings in shadowDOM that needs to be pluralized/genderized.
Also, ShadowDOM is outside the scope of the article. This is probably why you got downvoted.
I gave you an argument why I think it's (components) - you just say your opinion - it' not an argument
2. "I have concern as to how good this is going to be"
It IS WORKING already in Chrome. You can try it out [1].
"ShadowDOM IS a div soup." - no it's not. Web component tags are tags like any other HTML tag. You don't get the idea. Div's are like thinking about computer program in terms of electrical signals whereas web components is thinking in terms of program logic. See example video [2] with Google maps component. It just hides unnecessary complexity.
" I haven't seen any discussion with regards to strings in shadowDOM that needs to be pluralized/genderized."
Sorry. Don't get what do you mean. Could you please evaluate ?
"Also, ShadowDOM is outside the scope of the article"
well I just express my opinion that there are bigger unsolved issues in webdev than those solved by Constraint CSS
> I gave you an argument why I think it's (components)
No you did not. "it sucks less" is not an argument (and it's pretty faint praises), it's just your opinion.
> "ShadowDOM IS a div soup." - no it's not. Web component tags are tags like any other HTML tag.
And what do you think lives inside the tags, pray tell?
> It just hides unnecessary complexity.
That's the point, the complexity is still there, just hidden.
> "Also, ShadowDOM is outside the scope of the article" well I just express my opinion that there are bigger unsolved issues in webdev than those solved by Constraint CSS
That's not a very on-topic opinion to express in a thread dedicated specifically to discussing layout in CSS.
It's also wrong, web components make it somewhat easier to reason about the existing mess, they don't actually fix issues. Actually having layouting tools in CSS fixes issues, namely the issue that layouting in CSS is currently intractably brittle.
Yes it's not an argument.
It's conventional wisdom that it's easier and faster to create app in native toolkit than in HTML/CSS.
I refereed to my components argument not to "suck less".
>>tags are tags like any other HTML tag.
>And what do you think lives inside the tags, pray tell?
You don't have to think about it (you just import the component) as you don't have to think what's current CPU pin state. You just use attributes to communicate with the component.
>"That's the point, the complexity is still there, just hidden."
And there is a value in this. Higher level langs hide complexity as well (eg. C# vs C) and that makes them usable.
>It's also wrong, web components make it somewhat easier to reason about the existing mess, they don't actually fix issues
I don't agree. In my entire web dev career single biggest pain in the ass was more or less like "what CSS rule is breaking my div style".
Since ShadowDOM brings CSS fence between components as you probably know (do you?), ShadowDOM makes it way easier to create HTML/CSS ui simply because it's hard to make CSS rules breaking whole app view.
I do agree layouting is an issue - it's just not that important at least for me - joe average web dev
> It's conventional wisdom that it's easier and faster to create app in native toolkit than in HTML/CSS.
Because native toolkit provide tools which let you actually lay out your screens.
> I refereed to my components argument
I found no such thing, hence my response.
> And there is a value in this.
I didn't claim there was no value to it.
> In my entire web dev career single biggest pain in the ass was more or less like "what CSS rule is breaking my div style".
Well we apparently have very different experiences of web development.
> Since ShadowDOM brings CSS fence between components as you probably know (do you?), ShadowDOM makes it way easier to create HTML/CSS ui simply because it's hard to make CSS rules breaking whole app view.
Again, I didn't claim there was no value to shadow dom, you're strawmanning here.
You must have never done any kind of development outside the web if you think for one second that native toolkit development is faster/easier than HTML/CSS.
You have absolutely no idea what you are talking about. Please stop talking.
>You must have never done any kind of development outside the web
Well actually I started as a Windows.Forms Silverlight/WPF .NET dev
>if you think for one second that native toolkit development is faster/easier than HTML/CSS.
With MS tooling and/or paid e.g Devexpress controls average .NET dev is way faster building
LOB apps than average web dev and you don't have to test on multiple browsers.
Additionally if you have to support older browsers you will get extra penalty
Do I have to add how much JS sucks compared to C# ?
There is a trade-off - you can't skin your app as much as you can with CSS.
>You have absolutely no idea what you are talking about. Please stop talking.
Native toolkits are usually easier to dev once you know them.
It's a conventional wisdom - at least one other person in this thread seems to agree with me on this.
From a developer standpoint, the DOM still need to be handled. Moreover, I haven't seen any discussion with regards to strings in shadowDOM that needs to be pluralized/genderized.
Also, ShadowDOM is outside the scope of the article. This is probably why you got downvoted.