The things that deters me about Brick are that there aren't very many components yet, they aren't very styled or pretty, and the site doesn't show me what the components look like on one page (I have to click through to a demo for each component). It's only been around for a year, though honestly with the support it has gotten, I'd need to see more before I'm able to imagine developers using it. Obviously, it's a beautiful concept.
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.
Ionic's widgets aren't web components and aren't usable outside of Ionic/AngularJS. This means they're not recognized as custom elements by the browser (no future dev tools support). They leak DOM and CSS internals into the page. Worse, they require the host application to be Angular based.
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.
Definitely, though when it comes to UI frameworks, many developers want a complete (and styled) solution, and usually stick to a cohesive framework. Brick is obviously more modular, but that's not enough yet. It still needs more components and perhaps themes in order to be looked up, but I recognize it's a new project. Hopefully, the exposure today gets it some contributors.
Not sure Brick is now "more modular" and "lighter", without X-Tag - in fact, it's quite the opposite. They've dramatically increased the weight of each component, and constantly repeat the same code over and over, much of which is derived from X-Tag's internal methods:
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.
We (Ionic) don't use web components because they aren't widely supported on mobile (yet) and the polyfills have pretty hefty perf impacts. When that changes we definitely will.
I clicked through all of the examples, and I would never use any of these components. They are very plain, they don't provide much functionality, and the functionality they provide is lackluster ( unappealing ).
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.
Hey, Brick project member here. Completely agreed, the styling for these components is not where it needs to be. We're a small team that works in the open, and like to ship.
I'm a big fan of "ship early, ship often", but you have to set expectations properly. If something is not ready for prime time, you should signal that. Call it v 0.7, say it's a beta, label it as a "labs" product. Say up front where the known weaknesses are, and say what audience you want.
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.
Yeah. http://www.ianbicking.org/blog/2014/09/professional-transiti... "It’s a little hard to tell – I guess we didn’t actually shutter anything, and though it was announced internally it is entirely unclear externally. But Mozilla Labs is definitely shut down."
The "Brick 2.0" version number says otherwise. I agree with the parent post. Version numbers say a lot about waht a user can expect. They should change this to 0.2.
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.
I agree, there needs to be more work done with this before release. At this stage, I have no use for any of these components and would rather build my own or use an alternative UI library.
Agree, personally, I still prefer JQuery. Most of the components in here are implemented in JQ already. JQ has a lot more other components and is cross platforms on all the browsers.
wth is going on at mozilla? There seems to be a lot of excitement to create stuff, without much attention to whether it's needed .. or where the lifecycle goes beyond creation.
Seriously. It seems like Mozilla is completely directionless, working on multiple competing projects which go nowhere either due to lack of resources or not addressing any real community need.
I'd love to see that effort concentrated on solving actual problems in a focused way, or maybe even making Firefox not sucky.
Making Firefox non-sucky? Isn't https://github.com/servo/servo good enough for you? Creating a new programming language and using it to build a modern browser rendering engine? I understand that Mozilla is going lots of different directions with its projects but come on, they can't be accused of not putting the effort to make the web better.
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.
> 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.
I am not the downvoter. Mozilla was running in a hundred directions back before the Eich fiasco. This has nothing to do with gay or anti-gay politics and that really isn't leading the conversation in a productive direction.
That's just good business. Google is a company that's run for profit and is ultimately answerable to its shareholders. Google's job isn't to perform a social good, it's to continue making money. If it has areas of its business that are net losers (with no hope of eventually performing) then it has an obligation to do something about this.
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.
> without needlessly pulling projects that don't gain enough traction yet serve a niche market
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.
This is a project under active development, and was created to address of the need of mobile app developers who expect some form of UI toolkit for building mobile webapps.
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).
I looked at this in Chrome and honestly couldn't figure out if the examples were actually working.
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.
For me personally, the challenge UI frameworks like Bootstrap solve is the pure UI. That is, which borders, shadows and spacings to use and such stuff. A thin layer on top of the actual APIs like Mozilla Brick does not seem too useful to me - why bother adding a third party component if it merely wraps the functionality of HTML/CSS? (Although I must admit I haven't used Brick yet.)
Hm... am I correct that the brick-action component is actually their way of setting up a listener, like Backbone's obj.listenTo(anotherObj, 'event', callback)?
Well, in that case it's one hell of an overhead, imagine creating an actual DOM element for every single event listener.
E.g. iOS lets me use: Objective C, Swift, C#, F#, Java, Scala. All compiling to lower-level code that is either native to platform or native to the language.
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
You means the standards where each browser version has its own view of the world, or the standards where the applications get executed behind a HTTP(S) key hole?
This is missing the point of Firefox OS. It's not meant to go head-to-head with other mobile OSes, it's a development platform for new phone-oriented HTML APIs. When Firefox OS started, there was no way for a web page to use a phone's webcam, or to act as the phone's dialer. The existence of Firefox OS means that other mobile OSes can use their standardized and tested APIs to make HTML more powerful.
Brick is for reusable UI elements; unlike Polymer, it doesn't use custom elements to solve non-UI problems.
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.
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.
They're not directly comparable. One is a collection of components, the other is a helper library.
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.
I've shuffled through all of them and, near as I can tell, there really isn't one. They're very early in development, not aesthetically pleasing, and offer limited functionality.
The first two demos aren't styled, and don't work in Safari 8, and the third one says "coming soon." C'mon, guys...I understand I'm in the minority for using Safari, but you really need to think about the demo'ability of what you build.
I don't see a reference to Mozilla's X-Tags. X-Tags already links to listings of web components so why is this so different than that listing but also similar?
It's not a lot different, in fact, they've just remade our X-Tag components into heavier, less DRY, less modular copies that range from 40-60% larger than their equivalent X-Tag originals, while at the same time managing to reduce browser compat and feature coverage (for ex: Brick Deck lacks the transition support X-Tag's provides, and it's actually larger!)
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.
Can I use this client-side? From what I read on the page this seems to be only geared towards a certain server-side-setup with node.js, brewer and stuff.
Yes you can. If you check out http://brick.mozilla.io/v2.0/docs/getting-started - Node and bower are used in order to install the library locally.
You can also download the project from Github (https://github.com/mozbrick/brick) and just copy-paste the needed files in your project. You can search for them in the 'dist' sub-directory.
Thanks. That might work. But it feels a bit unaccessible. Looking through the code also gives me a strange feeling. Too many dependencies. They should just give you a .js that enables certain functionality and thats it. Like "include brick-flipbox.js and you have flipbox functionality".
Plus most of the demos do not wort (tried in chromium).
Sure, these are custom elements, which are just HTML/JS/CSS files. What's more, they are interchangeable with other ones found at http://customelements.io/
I tried to look at the "tab bar" on my iPad, it just looked like a regular unstyled document, didn't seem to respond to any taps. Guess I just don't get it!
I wonder when we'll have projects like this targeting all browsers, and specialized functionalities for projects like Node-Webkit, maybe a fork of Bootstrap tailored towards total customization of Node-Webkit, or even a PureCSS fork as well. After using applications like Atraci, SickBeard, and others I've really come to enjoy desktop applications with web based UI's more.
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
Hmm. Something more specific? I assume evergreen browser support means - Chrome, Firefox, Safari, Opera, IE, but which versions. What about mobile OS ?
I totally agree for Chrome, Safari ..., but IE isn't one of those. At least I think it's a little bit disturbing if I can't find browser support list on any new frontend framework that pops out, even if Mozilla is behind it.
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.
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.)
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:
You completely misunderstand the point. "Another package manager" doesn't matter. People can and should use the package manager of their choice (why should I break pip?). The point is to have common ground between all package managers.
Could you talk about the advantage(s) you perceive of a "common ground between all package managers"? After using npm a bit I think scripting hooks in a package manager that can call other package managers enables many good things.
Well, for one thing, new package managers could be implemented without having to worry about the infrastructure. The server software could be shared between all linux distributions and would be applicable for any sort of "bundle server"; think game addons, firefox/chrome extensions, skins for your favourite software and what not.
One is that you can easily specify dependencies on packages not written in the language your package is written in, in a way that's machine-readable. Imagine if I could do "npm install some-framework" and it'd automatically build and install the relevant versions of node.js and MongoDB as well.
This way I never need a global install of bower, nor do I ever really need to use it directly. I don't see why something similar couldn't be set up for any other npm-able package manager or build tool. A bit of googling seems to indicate that npm can update node using e.g. the "n" module. That module or another like it can of course be a dependency in package.json.
This isn't machine-readable, for a start - I can't see what your package actually depends on without reading through your postinstall script. I also can't write a script to convert it automatically to a .deb or a NixOS package or whatever else, because I can't figure out what its dependencies are. I can't easily say "I want this package and all its dependencies on a DVD".
The dependency on bower is stated explicitly. The dependencies that bower manages itself are easily discoverable in bower.json. I don't see why a call to bower is any more of a problem than any other build step, e.g. make.
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.
> I don't see why a call to bower is any more of a problem than any other build step, e.g. make.
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.
Package management needs to be solved at the systems level. Rather than having a new package manager for every language and every extensible program, the problems that make our systems package manager (apt, yum, etc) unsuitable for the task need to be addressed. The biggest problems to me are unprivileged package management (no sudo) and support for multiple "profiles" (think virtualenv, rvm, gemsets). Projects such as GNU Guix or Nix solve the problems quite nicely, IMO. We should develop them more instead of inventing more special-purpose package managers.
Package management at the systems level is a completely different problem from package management at the application level. An externally-facing server application is ideally a self-contained system of its own which should be installable on any modern kind of system without regard to whatever is or isn't on that system already, beyond the bare minimum. Trying to resolve library dependencies between two externally-facing applications is pointless; there should be no effect of one on the other.
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.
Ugh. I think there's a lot of sense in this comment, but it still seems horrendously wasteful to install multiple, redundant versions of libraries just to maintain separation between applications.
Hell, space and bandwidth are cheap: Let's just distribute all of our applications as 2 GB binary VM images.
"Projects such as GNU Guix or Nix solve the problems quite nicely, IMO."
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.
Sigh. Well fine, if you're stuck on Windows then language-specific package managers are much better than nothing. But on POSIX systems, we can do so much better than the current mess.
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.