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?
Mozilla Brick
101–110 of 122 posts
Re: Mozilla Brick
#102Re: Mozilla Brick
#103Earlier quoted context omitted.
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 i…
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.
Re: Mozilla Brick
#104I 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!
Re: Mozilla Brick
#105I 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?
Re: Mozilla Brick
#106Earlier quoted context omitted.
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 y…
Honestly, I thought it was obvious that the entire thing is probably alpha or thereabout
Re: Mozilla Brick
#107Earlier quoted context omitted.
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??
Re: Mozilla Brick
#108I 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 an…
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 also didn't understand why we need a new collection of UI widgets. What you bring to the table
Re: Mozilla Brick
#109Earlier quoted context omitted.
It looks like their following the Google model, except without needlessly pulling projects that don't gain enough traction yet serve a niche market.
For an example of a pulled Mozilla project, see Skywriter/Bespin: https://mozillalabs.com/en-US/skywriter/