4 ms·
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 st
by pothibo 12y ago
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.
- tkubacki 12y ago1. "shadowDOM isn't that much needed" 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 [1] http://www.polymer-project.org/ http://www.polymer-project.org/ [2] http://youtu.be/8OJ7ih8EE7s?t=28m26s http://youtu.be/8OJ7ih8EE7s?t=28m26s
- masklinn 12y ago> 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.
- tkubacki 12y ago>"it sucks less" is not an argument 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!]
- masklinn 12y ago> 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. > it's just not that important at least for me I'd kinda understood that at this point. > joe average web dev Yeah… no.
- pothibo 12y agoYou 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.