Mozilla Brick
brick.mozilla.ioThe 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:
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.
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.
Good points, just thought I'd mention that Mozilla Labs shut down a while ago.
Did they? Seems like something they should mention on https://mozillalabs.com
No-one to turn out the lights?
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."
Honestly, I thought it was obvious that the entire thing is probably alpha or thereabout
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.
You just have one chance to make a first impression.
I also didn't understand why we need a new collection of UI widgets. What you bring to the table
Outside of using Gulp JS and Stylus, I don't really see much of a point myself either, but where it gets interesting is the structure.
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-...
Good. Its not just me. I almost wonder if this was a draft site never intended for release and someone mistakenly or prematurely posted it.
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.
http://www.ianbicking.org/blog/2014/09/professional-transiti...
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.
Servo has nothing to do with Firefox.
You're right, I stand corrected.
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.
And Phoenix had nothing to do with SeaMonkey. Funny how things work out.
That's what happens when you oust Brendan Eich. He seemed to be the one with vision and drive.
Interesting. Perhaps the downvoter can explain why a comment they disagreed with was considered against the HN posting guidelines?
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.
It looks like their following the Google model, except without needlessly pulling projects that don't gain enough traction yet serve a niche market.
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.
For an example of a pulled Mozilla project, see Skywriter/Bespin: https://mozillalabs.com/en-US/skywriter/
Which lives on as part of Cloud 9. https://github.com/ajaxorg/cloud9
haha - thanks for the laugh
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.
The demos seems very unpolished but I hope they keep working on it.
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
It's currently only $39/mo.
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).
This page is throwing an exception for me... http://brick.readme.io/v1.0/blog/welcome-to-mozilla-brick
looks like the link should be v2.0 instead of v1.0
Link fixed!
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.
Doesn't seem to be working on mobile safari either.
> Stylus seems a curious choice (not because it's bad, just that it's not exactly the frontrunner in the CSS preprocessor race)
What would you say the frontrunner is?
"Brick" has a negative connotation in the tech world.
My first impression from the title was some kind of Firefox phone debacle.
And "Pad" has a negative connotation in the rest of the world... Didn't stop Apple though.
I got the same impression of Mozilla locks up base on the title. :-)
except for LEGO
Yes LEGO can be used with technology it's not a thing typically associated with "tech".
most tech people I know are aware of or have used LEGO bricks, and 'brick' as a negative tech term is recent afaik.
There are some invalid links on the page:
- '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.
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.
Firefox still does not seem to support fully web components (html templates, custom elements, shadowdom see http://caniuse.com/#search=shadowdom )
I hope they will get there fast - this will put pressure on dinosaurs like IE or Safari
I hope the apps market keeps recovering. This will put pressure on dinosaurs like browsers pretending to be an OS.
yea because it's much better to have closed, restricted app markets (like Apple, Google, Microsoft ones) than web standards.
It's a choice between restricted standards that hinder technology innovation and restricted markets that hinder business.
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.
Restricted App Store rules eg. disallowing external web browsers or interpreters hinder technology much more than web standards.
Talk is cheap - would love to see some of yours "not lame" piece of work.
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.
> iOS lets me use [...]
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
Society has lot of mobile OSes to chose from, not only from Apple.
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.
So web components. Haven't used them yet. What's the selling point on this vs Google's Polymer?
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.
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.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!)
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
It looks like Mozilla is moving away from X-Tags in favor of directly using the web component APIs.
X-Tag author here.
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.
Designmodo has their own UI framework, The Bricks:
http://designmodo.com/the-bricks/
Seems a bit close for comfort
You're right.
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).
I don't believe in this thing.
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 will interpret this as a bug report. What browser are you testing in?
Oh, you reckon it might work on some iPad browsers but not others??
Each iOS version is a different browser, so to reproduce the bug they need to know which rev you're using (presumably ios 7 or ios 8?)
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.
Ubuntu has done this for many years:
It's occasionally useful.$ 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 themYeah, I was looking for browser support in the documentation, but couldn't find any.
if you include the platform.js file, everything should be supported in the last versions of every browser
Hmm. Something more specific? I assume evergreen browser support means - Chrome, Firefox, Safari, Opera, IE, but which versions. What about mobile OS ?
The whole point of "evergreen browsers" is that the version number doesn't matter.
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.
I would assume "evergreen IE" means IE9+.
It does not support IE9.
It seems a little incomplete, or am I just missing the point?
I like how the documentation and example area laid out side by side, anyone cares to describe how they accomplished that? Thanks aot.
Yeah, looks like it's modeled after the Stripe API reference docs:
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.
They are using https://readme.io/
Another stripe inspired documentation made easy @ http://ricostacruz.com/flatdoc/
It's so bare, I love it. Just add more components and we might have something usable for front end developers.
Can we get a package manager for package managers?
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.
Reposting an old comment of mine on the subject::
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.
Well, since it's an old comment your oven should be clean by now :)
I'm working on something along these lines:
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:
I'll send you an email.
> Someone please work on this.
The only result will inevitably be that we'll have yet another package manager.
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 is what I meant by "scripting hooks". I have something like the following in package.json for various projects:
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."devDependencies": { "bower": ">=1.3" }, "scripts": { "postinstall": "bower install" }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.
Since Pete Hunt said Web Components might be bad idea, I become less enthusiastic about those things. But they look really powerful.
Some dude said they are bad?