In JS, sending the "wrong" number of arguments is frequently a feature. There's no concept of language-level function overloading, and it allows for the authorship of functions that take a variable or unbounded number of arguments (useful when coding in a functional paradigm).
Although Firebug has "fire" in the name, it is not an official Mozilla project. It's an independent group of developers (though naturally, many are Mozilla contributors). That independence is important, as competition always is! I can't speak for the developers who are working on it, Firebug will likely evolve to be a complementary set of tools to the built-in ones. Today provides valuable continuity for people who are used to using Firebug to build websites, and has a number of addons for Firebug itself that exists nowhere else on the web. Shutting it down would be a shame.
Bootstrap trades initial learning curve for huge expressibility. The column 'hieroglyphics' allow responsive behavior and column size to be declared in a single token. Semantic UI looks great, but the mud flinging tastes sour.
That's fair, but other than that, I'm curious what there is. CSS is still bad at grids without pretending they're tables, but Flexbox has solved most of the other limitations.
There is, but only if you can place a manifest file[1] on the domain where the app resides. Any website can trigger installation of an app via an API[2].
<x-slider> and <x-datepicker> are sorta unique amongst the components in that they are polyfill components- they do things that some browsers already do, but many don't do yet. They're also some of the most popular UI widgets from jQuery UI. We decided to do them because we thought we could make using them much easier than most existing widgets libraries. Most components are novel functionality not found in HTML5 specifications.
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.
We were torn whether to call the current state of things alpha or beta, but yes, these are not ready for prime time. Where we and some other orgs disagree is that things should be kept secret until they're 'ready', when outside contributions could help you get them ready!
We're actually not using the Polymer Web Components shim- it attempts to simulate Shadow DOM by overriding DOM Methods(!), which didn't seem necessary.
Hi! I work on Brick. Yes, there are still rough edges on these components, and we're putting them out there in the hopes of getting feedback and bug reports- a traditional beta.
Given that the standard is well-locked down on those bits of CSS3, why not support the un-prefixed version? I'm not saying you have to stop supporting the prefixed version - I know that would cause all manner of compat issues.
Legitimately excited to see Blink-based Chrome released. However, Chrome 28 still does not support un-prefixed CSS transitions, transforms, and animations. What gives?? http://www.chromium.org/blink#vendor-prefixes
The "non-technical" user is real, in my experience. I worked tech support at a school where the teachers at the school would accidentally delete icons on their desktop and change every setting in the browser one day trying to print something. I've also volunteered as in-person support at Firefox events. Watching people bring in their computers full of crapware and with things modified all to hell before they finally asked for help. These people aren't dumb, they just lack the technical literacy sometimes. But they are most certainly not hypothetical.
Ensuring your app loads quickly over the network is definitely an optimization, but to call it a micro-optimization is wrong. Size on the wire for html5 apps (frequently loaded over mobile connections) is completely relevant.