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.
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
[edit added what gives us Shadow DOM CSS boundry]
[edit2 - hell yea! no arguments? just downvote!]