I like Ionic's, which is the most fully fleshed out set of UI components I've seen. Though it's not as modular as Brick, I'd rather have a complete monolithic set of components rather than sparse modular ones: http://ionicframework.com/docs/components/
The site does throw some errors, which leads me to believe this wasn't meant to be shared yet. Although, Brick has done the "HN launch" already in the past.
Brick components are encapsulated, both with shadow DOM and scoped CSS, and usable in any web page and with any or no framework. You can freely mix Brick, Polymer, Bosonic, or "raw" custom elements in a single page.
edit: It looks like Mozilla is dropping X-Tag in favor of "vanilla" (what I called "raw") standard web components APIs. This would make Brick a collection of components, rather than a web component helper library like Polymer, and more akin the to Polymer project's Paper Elements.
As others here have stated, I also couldn't tell if some of the examples are even working or not; they are that bad.
If you are looking for a fine set of interworking components that provide a refined look and feel along with nice examples of the options provided; then you'll probably want to look at one of the other 30 or so UI widget sets.
I also strongly recommend working with a small, carefully selected audience to begin with. Typically only a small percentage of your eventual audience will put up with the rough edges of a work in progress. Getting the average audience member involved early on is frustrating for both sides. You get a lot of feedback on things you a) already know about, and b) are intentionally avoiding for now. And they waste a bunch of time on stuff that wasn't intended for them.
I also didn't understand why we need a new collection of UI widgets. What you bring to the table
http://www.ianbicking.org/blog/2014/09/professional-transiti...
I'd love to see that effort concentrated on solving actual problems in a focused way, or maybe even making Firefox not sucky.
For a good example of a business that divested its underperforming businesses to the great benefit of its shareholders, look at General Dynamics beginning around 1994.
I thought they did exactly this with Persona. It seems like they barely gave it a shot before pulling the plug, and a trusted, neutral federated login is still not a solved problem.
Does anyone know what framework is used to 'generate' such doc websites? http://brick.mozilla.io/v2.0/docs
<meta name="description" content="Mozilla Brick was created using readme.io">
edit: damn, "Normally $99/month | $79/mo" for documentation
There's also a free tier that does the three column layout, which is targeted at projects and single developers (rather than actual startups or companies).
looks like the link should be v2.0 instead of v1.0
Also, Stylus seems a curious choice (not because it's bad, just that it's not exactly the frontrunner in the CSS preprocessor race). I'm not even sure why a CSS preprocessor is even necessary, to be honest.
- 'Fork me on Github' points to https://github.com/gkoberger/test instead of https://github.com/mozbrick/brick
- The Github link at the 'Keep Up To Date' section points to http://twitter.com/mozbrick
Update: Nice to see that the links are fixed.
I hope they will get there fast - this will put pressure on dinosaurs like IE or Safari
Brick uses vanilla syntax for the creation of custom elements, where "vanilla" means "as defined in the relevant standards." Brick uses the platform.js polyfill from the polymer project.
From http://brick.readme.io/v2.0/blog/welcome-to-mozilla-brick
We have very specific goals for Brick- to make building
webapp interfaces easier. There are other projects that
use the same technologies (like Google's excellent
Polymer) that provide a more complete web application
development solution. The motto on the Brick project is
"strong opinions, tightly scoped"- meaning we don't
intend to solve the problems of code stucture, module
loading, data binding, or really any other problem other
than webapp interfaces.
... the rising popularity of Google's Polymer and its
syntax for describing Custom Elements grew, and when
users came to contribute to Brick and x-tag, they found
themselves facing an unfamiliar syntax and an underlying
library that was frequently not well documented. The
decision was made that if users encounter Custom Element
registration syntax, it should be the standards-based
syntax. Brick components are now written in a 'vanilla'
style, using the standards-based APIs directly.Polymer is a library that helps you write web components with some sugar around data-binding, templating, attribute handling, mutation observers and such.
Brick is a set of concrete components written against the raw web component APIs.
Compare it for yourself:
Brick Flipbox: https://github.com/mozbrick/brick-flipbox/blob/master/src/br....
vs
X-Tag Flipbox: https://github.com/x-tag/flipbox/blob/master/src/flipbox.js
-----
Brick Deck: https://github.com/mozbrick/brick-deck/blob/master/src/deck..... AND https://github.com/mozbrick/brick-deck/blob/master/src/card.....
vs
X-Tag Deck: https://github.com/x-tag/deck/blob/master/src/deck.js
A big part of their switch seems to be a result of interpersonal issues with the X-Tag creators. After I left on less-than-good-terms with a handful of folks at Mozilla, they decided to ditch a library that makes components small, modular, and DRY, for what appears to be spite. The new Brick code base is over 2x heavier (despite being billed as a "lightening" move), each component is 40-60% larger (with a ton of repetition and use of X-Tag code), and the browser compat range has been reduced greatly.
They never reached out to the X-Tag team before posting this - it contains glaring inaccuracies and negative sentiment toward X-Tag.
I'm deeply disappointed by their poor open source behavior, and general lack of courtesy.
http://designmodo.com/the-bricks/
Seems a bit close for comfort
Plus most of the demos do not wort (tried in chromium).
I don't believe in this thing.
On another note, as someone else mentioned, there's too many package managers, a package manager that detects when you try to use a package manager you don't have installed, and installs it for you would be a neat project to have, although talk about dependency hell.
$ gem install dummystuff
The program 'gem' can be found in the following packages:
* rubygems1.8
* rubygems1.9.1
Ask your administrator to install one of them
The doc generator used for this, readme.io, generates this three column layout automatically, so no fancy coding required.
The three column layout is nice for being able to scan back and forth between code and instruction. I like how it blends the purpose of the docs with the implementation.
There is so many already, its hard to keep track what names come from what repositories of what package managers.
It used to be so simple, yourDistroPackageManager install whatever, now there is x2000 versions of packageManager.
The path to a standard package manager starts with a standardized protocol for package management.
A service protocol that is able to serve a repository of packages over http and ftp. A client protocol that can keep track of installed packages and can index, search and look for updates on installed packages.
Split package management into layers and only try to standardize bit by bit. People will never agree on deb vs rpm. People will never agree on using json vs python vs Makefile vs ruby vs shell vs whatever else - they'll always want their most familiar language for their package manager, which in domain-specific packaging means the domain-specific language.
So don't try to standardize those. Standardize the rest. Give us the protocol that can power all of this and increase interoperability. Separate the repository layer, the package format (deb, rpm), the packagefile format (setup.py, Makefile, PKGBUILD) and the package manager (interface: yum, apt-get, aptitude, pip, npm) from the rest of the protocol.
Make this potentially usable for things such as browser extension repositories, android package management, vim bundles and what not.
Someone please work on this. I'd do it but it just occured to me I have to clean my oven.
The idea is to have a common UI and REST API for building packages and managing repositories across packaging toolchains. Right now it supports rpm+yum and deb+apt. Packages are built in isolated Linux containers using Heroku's buildpack interface. (Would love feedback from anyone who's interested in beta testing.)
Also, have you seen the Omaha protocol?
https://code.google.com/p/omaha/wiki/ServerProtocol
It's used by a lot software, including Chrome and ChromeOS. Recently, CoreOS has built infrastructure with it and they offer a SaaS product for rolling updates. I think they're planning on using it to update Docker containers, too:
The only result will inevitably be that we'll have yet another package manager.
In the days when space and bandwidth was expensive, a lot of compromises had to be made, but with many current language ecosystems, the cost of maintaining separate infrastructure is trivial, so we shouldn't be continuing to make our lives more difficult by deferring to the system package manager.
The sibling comment brings up Nix, but the only reason that looks like a good solution is that it happens to make all libraries application-specific libraries (if I understand correctly), which fuses the two problem domains. Nix excepted, however, I think it's a mistake to conflate them.
So long as you define the problem space as "package management for POSIX systems," and in the case of Guix you can scratch OS X and I think the BSDs off the list, too. If your package manager doesn't run on all of Windows, Linux and OS X at a bare minimum then your package manager is not solving the problems of Node.js, Python, PHP, Perl, Ruby or any other cross-platform runtime.