csuwldcat

Your comment is misguided for a few reasons:

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.

Each component is isolated in just the way you describe, the only requirement is the base X-Tag Web Component library.

The issue might be locality dependent, we have several people where who are running the exact same version and platform that cannot reproduce - could be an issue like this: https://github.com/eternicode/bootstrap-datepicker/issues/95...

Given that the errors and ability to reproduce are so erratic (to the extent that people with the very same browser versions on the same platform are seeing different behavior), I have a feeling the issue may be something like this: https://github.com/eternicode/bootstrap-datepicker/issues/95...

I believe you are describing the native datepicker, I am seeing the same weirdness. Be advised, the calendar polyfilled calendar is only active when a native implementation is not detected, or you force it to be used. This may be a bug in Chrome itself.

I'm also running Chrome 28 (Version 28.0.1500.95) on Windows, but everything is running fine. I'm wondering if Chrome itself is locking up, because the calendar demo is has only one demo of the polyfill picker, the rest are the native calendar that it uses when it detects it is available.

Underlying Polymer's opinionated framework, there is a set of polyfills for the emerging Web Components standards - both Mozilla's X-Tag library and Polymer use these polyfills as the basis of their offerings.

The folks working on the components are going to be incorporating all this feedback and reporting going forward. Everyone is encouraged to file bugs with the repo here: https://github.com/mozilla/brick/issues

Just an FYI - Mozilla will be employing this highly technical problem resolution strategy to ensure a high level of quality prior to official release: http://www.youtube.com/watch?v=yo3uxqwTxk0

You're overlooking that the underlying technology - Web Components - is landing as a standard as we speak in both Firefox and Chrome. The idea that creating custom elements is inherently bad is an urban legend - there is no empirical basis for such a claim. Additionally, you are mixing metaphors, Custom Elements are not meant to describe data, they are meant to create new, active UI components and other useful tags.

"How would I implement an offline navigation? (which is currently really not possible in JavaScript)" - wow, just wow. Beyond the fact that this is just plain wrong - there are packaged apps that ship all assets on install, as well as great offline JS libraries - you do realize these things (offline, telephony, etc) are _APIs_ right? No _language_ Just Does™ offline or telephony - for instance, C++ is not somehow magically self-aware of internet connectivity, it's simply a language used by developers to code against device hardware/firmware which then provides _APIs_ for these capabilities.

JavaScript is no less capable of supporting these APIs, look at Node.js for instance, it has most of the server _APIs_ you find in other server implementations that use different languages as a base (and the Firefox platform has many of them already, with many more to on the way!)

"Ignoring the housing bubble"...great talking point, but sadly, inaccurate. The most significant obstacle that blocked attempts by the Bush administration to combat the runaway housing/financial sector bubble was a Democratic House that strongly believed in the "affordable housing mission", and obstructed reform and investigation via their stranglehold on the House Financial Services Committee.

http://georgewbush-whitehouse.archives.gov/news/releases/200...

http://www.youtube.com/watch?nomobile=1&v=NQXbT5ZMYaY

The release cycle should be quite rapid, more so than any of the the existing OS platforms on the market. Additionally, if you can develop web sites/apps well on "evergreen" desktop browsers like Firefox and Chrome, the experience will be almost identical. Do you feel desktop Firefox and Chrome browsers upgrade too slowly today? If not, you're in luck, because the Gecko (JS, HTML, CSS) engine in Firefox OS can be updated just about as fast - after all, the Gecko engine that evaluates your markup, styles, and JS code in Firefox OS is the same one that's in the Firefox desktop browser ;)

There are a multitude of natively available browser functions that are immutable and cannot be CRUD'd. This guy really needs to understand more about the browser. His commentary on client storage in the browser also is myopic.

"Bind it like this: $( '.datepicker' ).datepicker()" - so the very first instruction is an incorrect reference to JavaScript 'binding' as something that extends or provides features to an element, vs what it truly does: change the scope reference of the 'this' keyword in a function. Oh jQuery, thank you for obscuring the actual JavaScript language for developers everywhere sigh

Just one little citation of the original article that demonstrated this hack would be nice. The guy references David Walsh's blog (a friend of mine), who even in the article cites and attributes the method, yet doesn't include it in here? Just a tad lame, that's all: http://www.backalleycoder.com/2012/04/25/i-want-a-damnodeins...

Hey whatdayaknow, the method I created! Here's a follow-up I published a while back that provides an generic listener method using the technique: http://www.backalleycoder.com/2012/08/06/css-selector-listen...