Live data from Hacker News

Mozilla Brick

brick.mozilla.io

61–70 of 122 posts

Re: Mozilla Brick

#61

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…

I'll send you an email.

Re: Mozilla Brick

#62
post #5

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 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.…

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.

Re: Mozilla Brick

#63
post #57

Earlier 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.

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.

Re: Mozilla Brick

#64
post #59

Earlier 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.

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.

Re: Mozilla Brick

#65
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.

Re: Mozilla Brick

#67
post #21

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.

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.

Re: Mozilla Brick

#68

Earlier 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.

I would assume "evergreen IE" means IE9+.

Re: Mozilla Brick

#69

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.

That's what happens when you oust Brendan Eich. He seemed to be the one with vision and drive.

Re: Mozilla Brick

#70

Earlier 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.

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.
Post reply on HN