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.
<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">
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.
Under your logic, any compilation of functionality can be reduced to vanilla, long-hand, zero-abstraction, blocks of HTML, CSS, and JS functions --> Ok everyone, dubcanada has figured out that all the packages on NPM, Bower, and Component, and all the frameworks for UI and CSS, etc, along with many of the other APIs in the DOM, are not reeeeally necessary technically speaking - why did we all waste our time on all that?!?...ugg, what a ridiculous argument.
"If you want a rapid HTML5 development look up Emmet and add bootstrap or some other giant framework" - <x-massive-sarcasm> Oh yeah, duh, why didn't I think of that - wait, there are already giant frameworks that try to provide similar functionality, with less ergonomic interfaces, that are more of a management hassle, all for the low low price of 10x the wire size! Gosh, I love things that provide less utility and weight exponentially more, sign me up! </x-massive-sarcasm>
"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" - yeah, you're right, because lord knows we have this fantastic solution right now: <div><div><div><span></span><span></span></div></div></div> - who in their right mind would ever see value in lightweight, tightly encapsulated, auto-instantiating, semantically inferred, components like this: <x-switch role="input"></x-switch>, le sigh.
"Me thinks that is what people don't like." - me thinks you're going to be eating those words by the beginning of 2015.
A. I am all for web components, if you read the parent I was replying too. I answered his question.
B. They aren't "technically speaking"... you don't need a calendar. You can create 3 dropdowns with every date. You don't need a slider you can create a dropdown with 1 to 100. I could go on and on. The reason we do this is so it is easier to use. But "technically speaking" it is not a requirement.
Any ways you seem to be a little angry at the moment, I was never attacking the product lol. I actually like the idea, and I'm a contributor/have used extensively to Montage and Broadway. I was just answering the question that the parent asked.
The problem is that you run out of built-in components really quick. Not sure why Mozilla chose to start with existing controls, but the point here is that it's an easy way to introduce new controls.
'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.'
The problem is that every framework has a different way of writing controls. This is a standardization of the control model with built-in support in the browsers (FF and Chrome at least). Doesn't take 150kb's of JS at all, or even a framework.
Custom elements also allow you to create your own shadow DOM, you can have your own "native" functions, and there is also some scoping for CSS.
So since their browser happens to be one that doesn't do those things, why don't they fix their browser?
Did you miss the post specifically calling them
> cross-browser polyfill implementations of existing native not-yet-globally-supported elements
And thus it is a polyfill indeed, since IE9 does not support HTML5 input types (and more generally HTML5 form extensions).
Luckily, Brick is open source, so you can file an Issue about it, and if you're interested, even submit a pull request yourself.
But comments complaining about negativity are not helping anyone. Stop complaining, just use the upvote buttons to help determine what comments you like to see rise to the top.
I also prefer to leave it up the voters to reward/discourage behavior, rather than content campaigning.
So yes, the astute observations of which the negative ones are usually the easiest to come up with (humans are choice rankers first, creators a distant n-th) get us points, and those points give us dopamine.
Remember when EVERYONE could see the points? The problem was even worse. Really, the points should go away or be delayed.
Here's what happens to me, and I'll bet it happens to other commenters too: I read a post, and when I come to a point that seems problematic, I scan the rest of the post to see if it is addressed, then come to the comments to see if it's addressed, and if it's not, I post a comment about it.
Since no post is going to be perfect, this algorithm leads to a lot of negative comments. But they do tend to be constructive.
(1) I was on a bus in Manhattan a few years ago, commenting to a friend that at least 10% of software engineers must show significant symptoms of OCD. Some random woman said "It's much higher. I'm a psychologist. 10% of the general population shows OCD symptoms. The incidence much is higher in software engineers." Terrible citation, but...
(2) All engineering fields are largely about quickly finding and identifying the biggest flaw in some work. If you're positively rewarded for this behavior 50+ hours per week, it's tough to unlearn this behavior outside of the office.
Edit: changed to describe engineers rather than engineering.
Not to mention you still have to deal with the css and js files that the control needs. Personally I would have liked to see a better way to manage assets that these plugins (and now controls) depend on. Like some kind of way to bundle everything. Then again this whole custom html tags thing wreaks of Asp.NET WebForms.
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.
Also it will be interesting to see how this shakes up the templating/data binding framework ecosystem.
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.
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 :)
Don't forget Google either. The Web Components spec  was created by Googlers (along with contributions from lots of other people, of course).
edit: found a clue here, about abandonment of xhtml2 etc: http://tantek.com/2010/302/b1/xhtml-dead-long-live-xml-valid...
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.
The event model, no, but the templating and compositing absolutely.
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.
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 .
See also Google Polymer and its <polymer-element> "sugar" for building web components:
Is that progress?
How is that not progress?
So you are just disagreeing on the definition.
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.
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?
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.