
Introducing Brick: Minimal-markup Web Components for Faster App Development - rnyman
https://hacks.mozilla.org/2013/08/introducing-brick-minimal-markup-web-components-for-faster-app-development/
======
jh3
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.

~~~
dubcanada
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.

~~~
highwind
What if I wanted to just display a calendar and not a date picker?

~~~
dubcanada
I see the reason why we would need such things, and I am a massive fan of web
components and frameworks like Montage. But I also see the other side, where
realistically we are just trying to reinvent a more low level language on the
web browser.

------
rDr4g0n
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/shadowd...](http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/)

[http://www.html5rocks.com/en/tutorials/webcomponents/templat...](http://www.html5rocks.com/en/tutorials/webcomponents/template/)

~~~
jplur
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
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.

------
desireco42
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 :)

~~~
munificent
> 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/)

------
Pxtl
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
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
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.

------
k3n
One of the more recent discussions on Brick here:

[https://news.ycombinator.com/item?id=6223313](https://news.ycombinator.com/item?id=6223313)

------
616c
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.

------
gambler
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?

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

------
gizmogwai
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 .

------
annnnd
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
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.

------
moonlighter
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
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
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
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.

~~~
moonlighter
I'm in full agreement with you and yes, it's a silly discussion. I guess I
just wanted to point out that the idea behind it isn't all that original and
actually pretty old, it's just that it's now made widely accessible, which IS
great. Maybe I should've just kept the whole thing to myself ;)

------
jplur
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>.

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

~~~
michaelsbradley
Take a look at <polymer-grid> and <polymer-flex-layout>

[https://github.com/Polymer/polymer-
elements/tree/stable/poly...](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)

------
boothead
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
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.

------
mistercow
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.

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

~~~
rexreed
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
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-
diff...](http://stackoverflow.com/questions/18089075/what-is-the-difference-
between-polymer-elements-and-angularjs-directives)

------
toblender
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

------
programminggeek
This feels like JSF Tags all over again.

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

~~~
protomyth
The old wagon wheels don't work so well with the new cars.

~~~
theboywho
I think you are referring to "re-make". Re-invent is not re-make. You can re-
make, but you shouldn't re-invent.

------
WayneDB
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).as...](http://msdn.microsoft.com/en-
us/library/ff626304\(v=vs.85\).aspx)

[http://msdn.microsoft.com/en-
us/magazine/cc301531.aspx](http://msdn.microsoft.com/en-
us/magazine/cc301531.aspx)

~~~
est
Microsoft even ported DirectX to dHTML in IE4~IE6

