1

The way I've been accustomed to User Interfaces is to see everything as a div. Where a div is essentially a box and they can be stylized in CSS.

<div class='container'>
   <div class='header'></div>
   <div class='mainbody'>
       <div class='someusercontrol'>
       </div>
   </div>
   </div class='footer'></div>
</div>

But it seems like nowadays with React and Angular Directives, and now with Web Components people are slowly shifting to:

<container>
     <header></header>
     <mainbody>
             <someusercontrol someattribute='123'>
             </someusercontrol>
     </mainbody>
     <footer></footer>
</container>

The problem that I see with the second example is that now all elements are heterogeneous as opposed to homogenous with divs. Each element can have different attributes / properties and can work in different ways. This can lead to complexity when viewing someone else's code for the very first time as each one of these "things" works differently.

But some argue that now elements will be more modular and easier to re-use. But I'm wondering if it's worth it. Are web components really the way to go? It sure seems that the future indicates they are.

closed as primarily opinion-based by Winston Ewert, Eric King, user40980, Scant Roger, GlenH7 Dec 24 '15 at 13:56

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • What about in HTML that we have lots of other tags that get used like script, input, paragraph and so forth? – JB King Dec 23 '15 at 19:35
  • personally, I use div for everything except links. – foreyez Dec 23 '15 at 20:00
  • @foreyez, I'm pretty sure you at least use script tags. – Winston Ewert Dec 23 '15 at 20:37
  • the extra 'complexity' in html5 allows us to do much more interesting things and allows browsers and search engines to become much smarter. You say you use div for everything except links - browsers already have special rules for <section> (see reader mode in FF). If you were searching for a quote in a search engine, the search engine could prioritise sites with the <blockquote> element with a matching quote, for example. Even if it is more complex it's definitely worth the complexity. – Dan Pantry Dec 24 '15 at 10:46
1

I believe what you're asking is based off of a person's personal preference or a particular level of when someone thinks something is "too complex" for them.

Now for me personally, I don't think it adds enough complexity for me not to use it. For example, jquery.validate.js in VS2015 (using NuGet Package Manager) is great and has saved me some time. For me, that's what it boils down to. Does it save me time, even if it's a little? Yes? I learn it. No? No thanks, unless if there is some other payoff somewhere else. For example: <asp:DropDownList ID="status" runat="server" CssClass="form-control" AppendDataBoundItems="true" required > -- All I have to do is add that "required" at the end and jquery-validation.js knows I want it required. It's the same for just about all the different inputs. I know I could use ASP's "required" attribute, but I'm using other things customized for me.
Here's a link for more info: http://jqueryvalidation.org/

  • 1
    so you render things on the server? I'm mainly talking about client-side here. – foreyez Dec 23 '15 at 20:21
  • Allow me to clarify, when I said, "All I have to do is add that "required" at the end and jquery-validation.js knows I want it required." That means that this validation will be rendered or executed on the client-side, I think that's what we both want, I know it's what I want from this jquery library. That "runat="server" tag just means I'm using that control in the bode behind (C#). I hope I clarified this and I didn't further confuse anyone. – Eric Milliot-Martinez Dec 31 '15 at 15:28
0

Actually, I think it will reduce complexity.

The point isn't to substitute a div tag for some other random tag. In your example, it really doesn't help anything. But that's because you've left most of the tags in your example empty. In reality they would be filled with markup, more like:

<div class='container'>
   <div class='header'>
       <div class='logo'/>
       <div class='menu'>
           <div class='menuitem'>
              ...
           </div>
        </div>
   </div>
   <div class='mainbody'>
       <div class='someusercontrol'>
            <label>All the money</label>
            <input type="checkbox">
            <input type="text"/>
            <img res="data:..."/>
       </div>
   </div>
   </div class='footer'>
       <div class="copyright">Lorem Ipsum...</div>
       <a href="terms">Terms</a>
   </div>
</div>

There are some problems with this:

  1. All that markup makes it hard to get an idea of what's going on.
  2. I can't easily reuse the same markup in multiple places/pages.

One way of solving this is to use a template language, so you could write something like:

<div class='container'>
    {{include:header.html}}
    <div class="mainbody">
         {{include:someusercontrol label="All the money"}}
    </div>
    {{include:footer.html}}
</div> 

But this has two problems:

  1. We've got a mix of syntaxes between the template and the html.
  2. Its easy to include the markup for something without including the appropriate css or js.

The components address both of these. They extend html syntax, so that the code to include a template look like an html tag, and including the template also automatically includes the approriate js and css.

Basically, unless you are willing to duplicate markup all over the place, you need to something pretty much equivalent to these components. Components happen to be a neat and clean way of doing it.

  • one could have a common js file like header.js that all pages include and it'd just spit out an html string into some div. the issue with the web component is now you need to create a new custom tag just to do that.. mb it's not a big deal, I could be speaking ahead of myself. – foreyez Dec 25 '15 at 7:43
  • @foreyez, obviously there are other ways of accomplishing the same thing. But I think components are beter. I if see a <Header/> component in react, and I know that its going to pull in a Header component I've defined somewhere else, I can go read the Header component code to see what's in there. If I see a <div class="header"/> I don't know whether or not some piece of code somewhere is going to populate that div. They end up largely the same, but I think the component style is simply more explicit about what happens. – Winston Ewert Dec 25 '15 at 16:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.