Mozilla Brick
brick.mozilla.io
brick.mozilla.io
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.
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
-----
The above examples call into question the claim that the move was to increase modularity and decrease weight - clearly that isn't the case when you actually look at the code.
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.
No-one to turn out the lights?
I also didn't understand why we need a new collection of UI widgets. What you bring to the table
Example: https://github.com/mozbrick/brick-menu/blob/master/index.htm...
It looks like the library is pre-pended with a bunch of brick elements, based off its Minimal-markup Web Components.
They really do a bad job of explaining this on their brick page as right now, looking at it you'd assume its just yet-another-front-end-framework. Its not compelling (yet), but still of interesting.
https://hacks.mozilla.org/2013/08/introducing-brick-minimal-...
http://www.ianbicking.org/blog/2014/09/professional-transiti...
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.
I'd love to see that effort concentrated on solving actual problems in a focused way, or maybe even making Firefox not sucky.
I was under the impression that Servo would end up being the web browser engine powering newer versions of Firefox (or any other flagship Mozilla browsers to be) and from my more extensive reading after reading your comment, I appear to be mistaken.
The underlying point I was making though (if it still stands) is that the good folks at Mozilla are not exactly sitting on their collective ass, they are in fact trying really hard (and the bleeding edge way) to make the web better.
I never claimed that they're sitting on their collective ass. They're certainly trying to make the web better, but by running in a million directions at once (due to the lack of direction) they end up going nowhere.
Does anyone know what framework is used to 'generate' such doc websites? http://brick.mozilla.io/v2.0/docs
looks like the link should be v2.0 instead of v1.0
<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).
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.
What would you say the frontrunner is?
- '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
As a technologist I hope that de-facto monopolic legacy poorly-designed technologies (JS and HTML) will give way to new better technologies.
I am very happy that at least mobile still gives developers many options - mostly without lame transpilation.
Talk is cheap - would love to see some of yours "not lame" piece of work.
Web lets me use: only JavaScript (that is written manually or transpiled).
Yes I will have to pay extra for some solutions, but I don't mind doing this as opposed to using language that I hate.
And Web Components are bringing innovation (component based app building) to rusty world of web dev which is not restricted to rich western society (Apple).
I stopped ranting on JS - just use lang with good enough IDE like Dartlang (DartEditor or IntelliJ)
PS: previous comment was not "ad persona" - but if you think transpilation is "lame" - you don't know how hard it's to make performant transpiler and how wonderful piece of tech are some of those transpilers
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.
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.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.
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
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.
"devDependencies": {
"bower": ">=1.3"
},
"scripts": {
"postinstall": "bower install"
}
I get that having a standard format (let's say "dependencies", "devDependencies", and "peerDependencies" as properties of a json file) would make somebody's life easier, but it's not clear that is the same set of somebodies who develop and use all these package managers.
Because dependency management is a separate problem from building. I need to be able to see what, exactly, every package depends on, and to be able to operate on that, to be able to deploy my system, and in order to know what exactly it is that I'm running.
Figuring out what my dependencies are at the same time as building my system leads to near-constant breakage, and I couldn't even figure out "am I using this package somewhere or not?" because there's no central package database when using npm/pypi/whatever else. How am I supposed to figure out whether my system is secure if I can't figure out what's installed on it to match against the CVE databases?
Today, I solve this with an extremely hackish set of scripts (npm2nix, pypi2nix, etc) and a lot of manual overrides to specify dependencies between bits of code written in different languages, and wrap that into one package database. Operating system distributors are forced to do the same.
> I get that having a standard format (let's say "dependencies", "devDependencies", and "peerDependencies" as properties of a json file) would make somebody's life easier, but it's not clear that is the same set of somebodies who develop and use all these package managers.
As a user of package managers, it would make my life easier if everybody would actually define all their dependencies in such a way that I can run an automated tool against a list of packages and discover every single package, so that I can wrap them into a DVD for offline installation, or figure out whether I'm vulnerable to something, or convert them for use with my own package manager, or whatever else I want to do.
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.
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.
Hell, space and bandwidth are cheap: Let's just distribute all of our applications as 2 GB binary VM images.