Earlier quoted context omitted.
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 standar…
I'm working on something along these lines: https://www.packagelab.com/ 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 p…
Mozilla Brick
61–70 of 122 posts
Re: Mozilla Brick
#62The 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 bea…
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.…
Re: Mozilla Brick
#63Earlier quoted context omitted.
> 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.
Re: Mozilla Brick
#64Earlier quoted context omitted.
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.
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.
Re: Mozilla Brick
#65As 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.
Re: Mozilla Brick
#66I like how the documentation and example area laid out side by side, anyone cares to describe how they accomplished that? Thanks aot.
Re: Mozilla Brick
#67Can 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.
Re: Mozilla Brick
#68Earlier quoted context omitted.
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.
Re: Mozilla Brick
#69wth 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.
Re: Mozilla Brick
#70Earlier quoted context omitted.
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.