9 ms·

Introducing Brick: Minimal-markup Web Components for Faster App Development

207 points by rnyman 13y ago

616c 13y ago
I am sure I have seen this before on HN, but I thought there was a good amount of criticism regarding Angular.js and making customized HTML tags. I am sure it is not a new invention in Brick, but is this so different? (I do not know what I am talking about; please feel free to correct if I am wrong). Negativity aside, thanks to Mozilla for more cool code. You guys support stuff all over the place web-wise, and whether or not I use it, I appreciate the hell out of your efforts.
workbench 13y ago
"<x-slider>" FFS… can't you just implement it properly like everyone else has done. Instead of investing time in stopgaps
deleted 13y ago
[deleted]
annnnd 13y ago
I don't want to sound negative, but how is that any better than using jQuery UI and similar tools? In other words, what are the advantages of web components over traditional JS+HTML+CSS?
- CmonDev 13y ago
  1) Declarative 2) Someone could _finally_ implement something like <grid> to be used instead of hacky <div>s or old-school <table>s to get a proper grid layout _quickly_ as it should be. Something that you get in WPF/Silverlight for free.
- michaelsbradley 13y ago
  Encapsulation: the HTML, JS and CSS that comprise a web component are encapsulated as and within said component. See also Google Polymer and its <polymer-element> "sugar" for building web components: http://www.polymer-project.org/polymer.html http://www.polymer-project.org/polymer.html
- csuwldcat 13y ago
  We for starters, this entire component package is lighter than some single jQuery UI plugins. It is declarative, something jQuery UI simply cannot do as it is designed. Web Components APIs are landing in browsers, so these code paths will be highly optimized as time goes on - jQuery's plugin code path will not be.
boothead 13y ago
I'm not sure I get it.. There are already several two way DOM <-> data binding frameworks, e.g. Angular, knockout, ember. What does this do differently? It reads more as a presentation layer thing, but presumably you could do this with one of the above frameworks right now... Perhaps a walk though of how to build a complete brick would be useful in demonstrating to differences and uses. Does anyone know of one - I couldn't find such a thing in the docs?
- potch 13y ago
  Hey there! Brick developer here. You can use Brick along side another framework. Because the interface for Brick components is the DOM, they work out-of-the-box with template systems in existing frameworks. We're not trying to replace or re-invent DOM-data binding, in fact, explicitly not doing that.
jh3 13y ago
Why are there always so many negative comments? Does everyone open a new tab, quickly find something to complain about, and then comment here? Just because you begin a comment with "I don't want to sound negative" does not make your comment any less negative. If HN is passionate about anything lately, it's been negativity. Rant aside, Brick is now an option for rapid HTML5 development. Why is this a bad thing? Oh right, it's not.
- CmonDev 13y ago
  Maybe because we'll have to switch to new GUI model n-th time without any significant pay-rise?
- dubcanada 13y ago
  I guess the problem most people see is, why are we making brand new HTML elements for things that are part of HTML5 and or can be done with a simple javascript file. <x-slider></x-slider> can be replaced by <input type="range"> <x-layout> can be replaced with CSS <x-datepicker> can be replaced with <input type="date"> etc etc... I just don't see any reason why we need to create a whole new set of HTML elements that are not part of any HTML spec just so you don't need to add a few more characters. And 90% of these are just polyfills which already exist. If you want a rapid HTML5 development look up Emmet and add bootstrap or some other giant framework. Don't start making brand new HTML elements that have absolutely no meaning unless there is 150kb's of JS to read them. Me thinks that is what people don't like.
  - ramy_d 13y ago
    Actually custom html elements are part of a spec: http://www.w3.org/TR/2013/WD-custom-elements-20130514/ http://www.w3.org/TR/2013/WD-custom-elements-20130514/ This method is a much cleaner approach, separating the declaration of functionality from the declaration of style. Your <input> example is convenient but does not apply to divs or other elements that could be used.
  - highwind 13y ago
    What if I wanted to just display a calendar and not a date picker?
CmonDev 13y ago
I want this now: <fluid-grid>...</fluid-grid>.
- jhull 13y ago
  how about: <bootstrap-website linkedin-id=XXXX twitter-id=XXXX facebook-id=XXXX github-id=XXXX> </bootstrap-website>
- michaelsbradley 13y ago
  Take a look at <polymer-grid> and <polymer-flex-layout> https://github.com/Polymer/polymer-elements/tree/stable/polymer-grid-layout https://github.com/Polymer/polymer-elements/tree/stable/poly... https://github.com/Polymer/polymer-elements/tree/stable/polymer-flex-layout https://github.com/Polymer/polymer-elements/tree/stable/poly...
- fwenzel 13y ago
  seems doable :)
k3n 13y ago
One of the more recent discussions on Brick here: https://news.ycombinator.com/item?id=6223313 https://news.ycombinator.com/item?id=6223313
moron4hire 13y ago
It's like ASP.NET's template processor is coming to the rest of the world.
cpursley 13y ago
Interesting. How does one begin to integrate this type of markup with something like Ember or Angular?
- rexreed 13y ago
  That was the first thing I thought about (and came to the HN comments for). I like this conceptually, just want to know how I can meld it with my Angular Directives. They would seem to overlap no?
  - ebidel 13y ago
    See my post [1] on SO on "Polymer elements (e.g. web components) vs. Angular directives". Essentially, Angular directives allow you to create new elements in HTML. That's done through JavaScript because the proper API primitives haven't existed in the web platform to create components. Now they're getting built in via Custom Elements, Shadow DOM, etc. Frameworks also win because they can leverage these new APIs. [1]: http://stackoverflow.com/questions/18089075/what-is-the-difference-between-polymer-elements-and-angularjs-directives http://stackoverflow.com/questions/18089075/what-is-the-diff...
Pxtl 13y ago
My XML kung-fu is weak... is there a reason that nobody uses a second namespace/schema for this kind of thing (well, other than ASP.Net web forms and we all loved those)? I mean, XML has a painful list of features created to allow for extensibility, seems funny that we don't use them.
- randomfool 13y ago
  Because everyone else's kung-fu is weaker and they don't grok xmlns's. The HTML5 WG is anti xml namespaces- too confusing.
  - Pxtl 13y ago
    Really? I picked up xmlns when trying to figure out Microsoft's .NET1.1 XML serializer. In addition to your object's schema, it imports a few extra namespaces for the schema definition language (xsd) and schema instance (xsi) features... in particular you need a schema instance attribute "xsi:type" to resolve type names for polymorphic things. Used like that, it feels just like importing a library in a programming language - I have a reference up top on the root element saying "this schema has this namespace and this prefix" and then I have attributes and tags with that prefix peppered through my document in addition to my own object schema tags and attributes. I can see how a lot of xmlns features could be really opaque (I don't understand any of them) but in this use case it was pretty straightforward.
- zurn 13y ago
  Yeah, isn't this what "the future" was going to look like back when xhtml was a thing? I guess there were some missing building blocks on the dom/scripting side, but what's the syntax story. edit: found a clue here, about abandonment of xhtml2 etc: http://tantek.com/2010/302/b1/xhtml-dead-long-live-xml-valid-html5 http://tantek.com/2010/302/b1/xhtml-dead-long-live-xml-valid...
- chc 13y ago
  "We" don't use these XML features because "we" (in the general sense) aren't using XML.
- 13y ago
desireco42 13y ago
This is exactly what I believed web/html should have. I know how to simulate this (re: other comments), this is better imho. Thank you Mozilla. BTW, this time next year you will all be use this in Chrome and bitch how IE is not following trends or something :)
- the1 13y ago
  no, what web/html should be is xml and xslt
- munificent 13y ago
  > Thank you Mozilla. Don't forget Google either. The Web Components spec [1] was created by Googlers (along with contributions from lots of other people, of course). [1]: http://www.w3.org/TR/2013/WD-components-intro-20130606/ http://www.w3.org/TR/2013/WD-components-intro-20130606/
theboywho 13y ago
What about the "Don't re-invent the wheel" thingy ?
- sanderjd 13y ago
  The funny thing about that analogy to me has always been that throughout history we have constantly improved the wheel through reinvention. Software wheel-reinvention is similarly reasonable.
- protomyth 13y ago
  The old wagon wheels don't work so well with the new cars.
  - theboywho 13y ago
    I think you are referring to "re-make". Re-invent is not re-make. You can re-make, but you shouldn't re-invent.
moonlighter 13y ago
What's so new and great about it? I built something pretty much exactly like that way back in 2002 (when jQuery et al. weren't invented yet). Heck, I even got a patent for that (my bad; I now firmly believe that software patents are evil). 2004: http://www.patentgenius.com/patent/7458019.html http://www.patentgenius.com/patent/7458019.html ... 2013: http://mozilla.github.io/brick/ http://mozilla.github.io/brick/ Is that progress?
- sanderjd 13y ago
  It's interesting that you link to your patent but not to the "something pretty much exactly like that". If I am correct in assuming that what you built is a) obsolete now and/or b) proprietary, then the answer to your (rhetorical?) question is: yes, a highly respected open-source organization working on a modern and freely available project (even if it is nearly identical to one of yours from a decade ago) is progress.
  - moonlighter 13y ago
    The concrete implementation of it is contained as open source (not free, but as in "you can look at the source and change it") in a commercial offering, which was the 'normal' back in these days. Yes, it is great that it is made freely available and is backed by an open source organization, no doubt. However, given the amount of time in-between, on a fundamental technical level though it seems slow progress at best.
    - sanderjd 13y ago
      I guess my rebuttal is very schoolyard...so what? I don't really understand the goal of meta-discussions about the speed of progress or lack thereof. This project seems potentially useful in the here and now, which is where we are living. I didn't mean to imply judgment of the licensing of your software - I think everyone should license whatever they make however they wish - a fully free version of anything is simply more useful to me personally, as someone who isn't a deep-pocketed business, and who enjoys reading code.
rDr4g0n 13y ago
For those who are wondering why this even exists, it is part of what is being called Web Components. Currently we use libraries and semi-hacky techniques to handle templating and creating private scopes for javascript. Some of the many things web components will let us do is have a true private scope for a component, have built in browser-supported templating, and allow us to separate presentation details from data. Separation of concerns ftw! The value, to me, is that I can create true modules with html, css, and js that are scoped to ONLY inside the <x-whatever> tag I design (finally my css won't step on other css and I won't have to use unnecessary selectors to ensure that), and it will all be handled by the browser; no libraries needed (if web components becomes standardized of course). For now, google and mozilla are creating polyfills to add this functionality because they want people to get onboard with the web component thing so that it will drive adoption and a consensus on how it should work in the final spec. I definitely recommend doing some research on the pieces and how they fit together because they are, at the least, intriguing and possibly the somewhat distant future of web application development. http://www.polymer-project.org/faq.html http://www.polymer-project.org/faq.html http://www.w3.org/TR/2013/WD-components-intro-20130606/ http://www.w3.org/TR/2013/WD-components-intro-20130606/ http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/ http://www.html5rocks.com/en/tutorials/webcomponents/shadowd... http://www.html5rocks.com/en/tutorials/webcomponents/template/ http://www.html5rocks.com/en/tutorials/webcomponents/templat...
- deleted 13y ago
  [deleted]
- jplur 13y ago
  Great explanation of why this is exciting. Separation of js/css/html is great for the top down structure of a project, but a major pain from the bottom up. I can see myself making heavy use of web components to fix that. Also it will be interesting to see how this shakes up the templating/data binding framework ecosystem.
natural219 13y ago
One main benefit I can see from Web Components is that it allows you to front-load the implementation code for common components to the browser, which can hypothetically be far better for performance than including custom, non-standard javascript libraries on every website you visit. Since browsers are either bundled with mobile OSs (or they are a big, one-time download), users don't have to deal with the performance cost of rendering Your Custom Component Script for every website they visit. Conceivably we can move towards a mobile web that is highly interactive with very little payload cost in terms of loaded javascript and CSS. That said, the obvious downside is how customizable and cross-browser these components will eventually be. As your components get more complicated, adding more html attributes to customize your element becomes prohibitively harder. I'm interested to see how they tackle this problem.
programminggeek 13y ago
This feels like JSF Tags all over again.
jplur 13y ago
A pleasant scenario for web components would be replacing the social media button's script/html injection with a link to the component and a <x-tweet-this>.
toblender 13y ago
Very nice. This works on my iphone4s. My question is how heavy this is compared to Bootstrap. It looks a little larger: Brick 134K vs. 88K for Bootstrap 2.3.2
mistercow 13y ago
I remember early in my HTML writing experience searching high and low for a way to define new elements with behavior defined by CSS and JS, and coming up dry. I could never articulate why I wanted it so badly, but it just felt like the way things should be done. It's incredible to see that it's finally becoming a reality, and other people are starting to flesh out the justification I never managed.
gizmogwai 13y ago
Web Component is at the same time a bless and a curse for the web. On the blessing way, it will finally allow to build some concise tags without waiting proper standardisation and implementation by the browsers (with various level of success). On the curse side, it's the false promise that those components will be reusable. They are not. Nothing prevent clashes in the names, so you cannot blindly import two different component libraries and use them. There is neither extension points to extend or augment existing component. Again we are re-inventing the wheel (xml) with some quirks. It looks like people never tried to fix the root cause of the VHS vs BetaMax battle .
- drivebyacct2 13y ago
  > There is neither extension points to extend or augment existing component. What are you talking about? It's like feature #2 from Polymer and it's very easily supported in Brick. Polymer has multiple examples and demos of this on their site and in their videos.
WayneDB 13y ago
Microsoft had this back in IE 5.5. They were called "behaviors" and you could basically bundle HTML, CSS and JS into one file with a .htc file extension and then use it as a new tag in your document. http://msdn.microsoft.com/en-us/library/ff626304(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/ff626304(v=vs.85).as... http://msdn.microsoft.com/en-us/magazine/cc301531.aspx http://msdn.microsoft.com/en-us/magazine/cc301531.aspx
- est 13y ago
  Microsoft even ported DirectX to dHTML in IE4~IE6
gambler 13y ago
I think I get the overall idea, but why are we encouraged to write <x-slider> instead of <input type="range">? I know that most of JS ninjas go bezerk at the mere mention of progressive enhancement these days, but in this case it seems the most sensible thing to do, regardless of ideological affiliation. We already have a standard element that is supposed to render a slider, why not just use it and add things to it?

207 points by rnyman 13y ago

616c 13y ago

I am sure I have seen this before on HN, but I thought there was a good amount of criticism regarding Angular.js and making customized HTML tags. I am sure it is not a new invention in Brick, but is this so different? (I do not know what I am talking about; please feel free to correct if I am wrong). Negativity aside, thanks to Mozilla for more cool code. You guys support stuff all over the place web-wise, and whether or not I use it, I appreciate the hell out of your efforts.

workbench 13y ago

"<x-slider>" FFS… can't you just implement it properly like everyone else has done. Instead of investing time in stopgaps

deleted 13y ago

[deleted]

annnnd 13y ago

I don't want to sound negative, but how is that any better than using jQuery UI and similar tools? In other words, what are the advantages of web components over traditional JS+HTML+CSS?

CmonDev 13y ago
1) Declarative 2) Someone could _finally_ implement something like <grid> to be used instead of hacky <div>s or old-school <table>s to get a proper grid layout _quickly_ as it should be. Something that you get in WPF/Silverlight for free.
michaelsbradley 13y ago
Encapsulation: the HTML, JS and CSS that comprise a web component are encapsulated as and within said component. See also Google Polymer and its <polymer-element> "sugar" for building web components: http://www.polymer-project.org/polymer.html http://www.polymer-project.org/polymer.html
csuwldcat 13y ago
We for starters, this entire component package is lighter than some single jQuery UI plugins. It is declarative, something jQuery UI simply cannot do as it is designed. Web Components APIs are landing in browsers, so these code paths will be highly optimized as time goes on - jQuery's plugin code path will not be.

boothead 13y ago

I'm not sure I get it.. There are already several two way DOM <-> data binding frameworks, e.g. Angular, knockout, ember. What does this do differently? It reads more as a presentation layer thing, but presumably you could do this with one of the above frameworks right now... Perhaps a walk though of how to build a complete brick would be useful in demonstrating to differences and uses. Does anyone know of one - I couldn't find such a thing in the docs?

potch 13y ago
Hey there! Brick developer here. You can use Brick along side another framework. Because the interface for Brick components is the DOM, they work out-of-the-box with template systems in existing frameworks. We're not trying to replace or re-invent DOM-data binding, in fact, explicitly not doing that.

jh3 13y ago

Why are there always so many negative comments? Does everyone open a new tab, quickly find something to complain about, and then comment here? Just because you begin a comment with "I don't want to sound negative" does not make your comment any less negative. If HN is passionate about anything lately, it's been negativity. Rant aside, Brick is now an option for rapid HTML5 development. Why is this a bad thing? Oh right, it's not.

CmonDev 13y ago
Maybe because we'll have to switch to new GUI model n-th time without any significant pay-rise?
dubcanada 13y ago
I guess the problem most people see is, why are we making brand new HTML elements for things that are part of HTML5 and or can be done with a simple javascript file. <x-slider></x-slider> can be replaced by <input type="range"> <x-layout> can be replaced with CSS <x-datepicker> can be replaced with <input type="date"> etc etc... I just don't see any reason why we need to create a whole new set of HTML elements that are not part of any HTML spec just so you don't need to add a few more characters. And 90% of these are just polyfills which already exist. If you want a rapid HTML5 development look up Emmet and add bootstrap or some other giant framework. Don't start making brand new HTML elements that have absolutely no meaning unless there is 150kb's of JS to read them. Me thinks that is what people don't like.
- ramy_d 13y ago
  Actually custom html elements are part of a spec: http://www.w3.org/TR/2013/WD-custom-elements-20130514/ http://www.w3.org/TR/2013/WD-custom-elements-20130514/ This method is a much cleaner approach, separating the declaration of functionality from the declaration of style. Your <input> example is convenient but does not apply to divs or other elements that could be used.
- highwind 13y ago
  What if I wanted to just display a calendar and not a date picker?

CmonDev 13y ago

I want this now: <fluid-grid>...</fluid-grid>.

jhull 13y ago
how about: <bootstrap-website linkedin-id=XXXX twitter-id=XXXX facebook-id=XXXX github-id=XXXX> </bootstrap-website>
michaelsbradley 13y ago
Take a look at <polymer-grid> and <polymer-flex-layout> https://github.com/Polymer/polymer-elements/tree/stable/polymer-grid-layout https://github.com/Polymer/polymer-elements/tree/stable/poly... https://github.com/Polymer/polymer-elements/tree/stable/polymer-flex-layout https://github.com/Polymer/polymer-elements/tree/stable/poly...
fwenzel 13y ago
seems doable :)

k3n 13y ago

One of the more recent discussions on Brick here: https://news.ycombinator.com/item?id=6223313 https://news.ycombinator.com/item?id=6223313

moron4hire 13y ago

It's like ASP.NET's template processor is coming to the rest of the world.

cpursley 13y ago

Interesting. How does one begin to integrate this type of markup with something like Ember or Angular?

rexreed 13y ago
That was the first thing I thought about (and came to the HN comments for). I like this conceptually, just want to know how I can meld it with my Angular Directives. They would seem to overlap no?
- ebidel 13y ago
  See my post [1] on SO on "Polymer elements (e.g. web components) vs. Angular directives". Essentially, Angular directives allow you to create new elements in HTML. That's done through JavaScript because the proper API primitives haven't existed in the web platform to create components. Now they're getting built in via Custom Elements, Shadow DOM, etc. Frameworks also win because they can leverage these new APIs. [1]: http://stackoverflow.com/questions/18089075/what-is-the-difference-between-polymer-elements-and-angularjs-directives http://stackoverflow.com/questions/18089075/what-is-the-diff...

Pxtl 13y ago

My XML kung-fu is weak... is there a reason that nobody uses a second namespace/schema for this kind of thing (well, other than ASP.Net web forms and we all loved those)? I mean, XML has a painful list of features created to allow for extensibility, seems funny that we don't use them.

randomfool 13y ago
Because everyone else's kung-fu is weaker and they don't grok xmlns's. The HTML5 WG is anti xml namespaces- too confusing.
- Pxtl 13y ago
  Really? I picked up xmlns when trying to figure out Microsoft's .NET1.1 XML serializer. In addition to your object's schema, it imports a few extra namespaces for the schema definition language (xsd) and schema instance (xsi) features... in particular you need a schema instance attribute "xsi:type" to resolve type names for polymorphic things. Used like that, it feels just like importing a library in a programming language - I have a reference up top on the root element saying "this schema has this namespace and this prefix" and then I have attributes and tags with that prefix peppered through my document in addition to my own object schema tags and attributes. I can see how a lot of xmlns features could be really opaque (I don't understand any of them) but in this use case it was pretty straightforward.
zurn 13y ago
Yeah, isn't this what "the future" was going to look like back when xhtml was a thing? I guess there were some missing building blocks on the dom/scripting side, but what's the syntax story. edit: found a clue here, about abandonment of xhtml2 etc: http://tantek.com/2010/302/b1/xhtml-dead-long-live-xml-valid-html5 http://tantek.com/2010/302/b1/xhtml-dead-long-live-xml-valid...
chc 13y ago
"We" don't use these XML features because "we" (in the general sense) aren't using XML.
13y ago

desireco42 13y ago

This is exactly what I believed web/html should have. I know how to simulate this (re: other comments), this is better imho. Thank you Mozilla. BTW, this time next year you will all be use this in Chrome and bitch how IE is not following trends or something :)

the1 13y ago
no, what web/html should be is xml and xslt
munificent 13y ago
> Thank you Mozilla. Don't forget Google either. The Web Components spec [1] was created by Googlers (along with contributions from lots of other people, of course). [1]: http://www.w3.org/TR/2013/WD-components-intro-20130606/ http://www.w3.org/TR/2013/WD-components-intro-20130606/

theboywho 13y ago

What about the "Don't re-invent the wheel" thingy ?

sanderjd 13y ago
The funny thing about that analogy to me has always been that throughout history we have constantly improved the wheel through reinvention. Software wheel-reinvention is similarly reasonable.
protomyth 13y ago
The old wagon wheels don't work so well with the new cars.
- theboywho 13y ago
  I think you are referring to "re-make". Re-invent is not re-make. You can re-make, but you shouldn't re-invent.

moonlighter 13y ago

What's so new and great about it? I built something pretty much exactly like that way back in 2002 (when jQuery et al. weren't invented yet). Heck, I even got a patent for that (my bad; I now firmly believe that software patents are evil). 2004: http://www.patentgenius.com/patent/7458019.html http://www.patentgenius.com/patent/7458019.html ... 2013: http://mozilla.github.io/brick/ http://mozilla.github.io/brick/ Is that progress?

sanderjd 13y ago
It's interesting that you link to your patent but not to the "something pretty much exactly like that". If I am correct in assuming that what you built is a) obsolete now and/or b) proprietary, then the answer to your (rhetorical?) question is: yes, a highly respected open-source organization working on a modern and freely available project (even if it is nearly identical to one of yours from a decade ago) is progress.
- moonlighter 13y ago
  The concrete implementation of it is contained as open source (not free, but as in "you can look at the source and change it") in a commercial offering, which was the 'normal' back in these days. Yes, it is great that it is made freely available and is backed by an open source organization, no doubt. However, given the amount of time in-between, on a fundamental technical level though it seems slow progress at best.
  - sanderjd 13y ago
    I guess my rebuttal is very schoolyard...so what? I don't really understand the goal of meta-discussions about the speed of progress or lack thereof. This project seems potentially useful in the here and now, which is where we are living. I didn't mean to imply judgment of the licensing of your software - I think everyone should license whatever they make however they wish - a fully free version of anything is simply more useful to me personally, as someone who isn't a deep-pocketed business, and who enjoys reading code.

rDr4g0n 13y ago

For those who are wondering why this even exists, it is part of what is being called Web Components. Currently we use libraries and semi-hacky techniques to handle templating and creating private scopes for javascript. Some of the many things web components will let us do is have a true private scope for a component, have built in browser-supported templating, and allow us to separate presentation details from data. Separation of concerns ftw! The value, to me, is that I can create true modules with html, css, and js that are scoped to ONLY inside the <x-whatever> tag I design (finally my css won't step on other css and I won't have to use unnecessary selectors to ensure that), and it will all be handled by the browser; no libraries needed (if web components becomes standardized of course). For now, google and mozilla are creating polyfills to add this functionality because they want people to get onboard with the web component thing so that it will drive adoption and a consensus on how it should work in the final spec. I definitely recommend doing some research on the pieces and how they fit together because they are, at the least, intriguing and possibly the somewhat distant future of web application development. http://www.polymer-project.org/faq.html http://www.polymer-project.org/faq.html http://www.w3.org/TR/2013/WD-components-intro-20130606/ http://www.w3.org/TR/2013/WD-components-intro-20130606/ http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/ http://www.html5rocks.com/en/tutorials/webcomponents/shadowd... http://www.html5rocks.com/en/tutorials/webcomponents/template/ http://www.html5rocks.com/en/tutorials/webcomponents/templat...

deleted 13y ago
[deleted]
jplur 13y ago
Great explanation of why this is exciting. Separation of js/css/html is great for the top down structure of a project, but a major pain from the bottom up. I can see myself making heavy use of web components to fix that. Also it will be interesting to see how this shakes up the templating/data binding framework ecosystem.

natural219 13y ago

One main benefit I can see from Web Components is that it allows you to front-load the implementation code for common components to the browser, which can hypothetically be far better for performance than including custom, non-standard javascript libraries on every website you visit. Since browsers are either bundled with mobile OSs (or they are a big, one-time download), users don't have to deal with the performance cost of rendering Your Custom Component Script for every website they visit. Conceivably we can move towards a mobile web that is highly interactive with very little payload cost in terms of loaded javascript and CSS. That said, the obvious downside is how customizable and cross-browser these components will eventually be. As your components get more complicated, adding more html attributes to customize your element becomes prohibitively harder. I'm interested to see how they tackle this problem.

programminggeek 13y ago

This feels like JSF Tags all over again.

jplur 13y ago

A pleasant scenario for web components would be replacing the social media button's script/html injection with a link to the component and a <x-tweet-this>.

toblender 13y ago

Very nice. This works on my iphone4s. My question is how heavy this is compared to Bootstrap. It looks a little larger: Brick 134K vs. 88K for Bootstrap 2.3.2

mistercow 13y ago

I remember early in my HTML writing experience searching high and low for a way to define new elements with behavior defined by CSS and JS, and coming up dry. I could never articulate why I wanted it so badly, but it just felt like the way things should be done. It's incredible to see that it's finally becoming a reality, and other people are starting to flesh out the justification I never managed.

gizmogwai 13y ago

Web Component is at the same time a bless and a curse for the web. On the blessing way, it will finally allow to build some concise tags without waiting proper standardisation and implementation by the browsers (with various level of success). On the curse side, it's the false promise that those components will be reusable. They are not. Nothing prevent clashes in the names, so you cannot blindly import two different component libraries and use them. There is neither extension points to extend or augment existing component. Again we are re-inventing the wheel (xml) with some quirks. It looks like people never tried to fix the root cause of the VHS vs BetaMax battle .

drivebyacct2 13y ago
> There is neither extension points to extend or augment existing component. What are you talking about? It's like feature #2 from Polymer and it's very easily supported in Brick. Polymer has multiple examples and demos of this on their site and in their videos.

WayneDB 13y ago

Microsoft had this back in IE 5.5. They were called "behaviors" and you could basically bundle HTML, CSS and JS into one file with a .htc file extension and then use it as a new tag in your document. http://msdn.microsoft.com/en-us/library/ff626304(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/ff626304(v=vs.85).as... http://msdn.microsoft.com/en-us/magazine/cc301531.aspx http://msdn.microsoft.com/en-us/magazine/cc301531.aspx

est 13y ago
Microsoft even ported DirectX to dHTML in IE4~IE6

gambler 13y ago

I think I get the overall idea, but why are we encouraged to write <x-slider> instead of <input type="range">? I know that most of JS ninjas go bezerk at the mere mention of progressive enhancement these days, but in this case it seems the most sensible thing to do, regardless of ideological affiliation. We already have a standard element that is supposed to render a slider, why not just use it and add things to it?