Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla Brick

brick.mozilla.io

Post reply on HN
Print view View original

91–100 of 122 posts

Re: Mozilla Brick

#91

Post by tonyplee »

nanoscopic wrote: post #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 an…

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.

Re: Mozilla Brick

#92

Post by Kaihuang724 »

nanoscopic wrote: post #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 an…

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.

Re: Mozilla Brick

#94

Post by BinaryIdiot »

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?

Re: Mozilla Brick

#95

Post by jo_ »

cdnsteve wrote: post #93

So web components. Haven't used them yet. What's the selling point on this vs Google's Polymer?

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.

Re: Mozilla Brick

#96

Post by libria »

hmsimha wrote: post #28
qewrffewqwfqew wrote: post #18

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

It looks like their following the Google model, except without needlessly pulling projects that don't gain enough traction yet serve a niche market.

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

Re: Mozilla Brick

#97

Post by anonbanker »

anonbanker wrote: post #69
morgante wrote: post #32

Earlier quoted context omitted.

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.

Interesting. Perhaps the downvoter can explain why a comment they disagreed with was considered against the HN posting guidelines?

Re: Mozilla Brick

#98

Post by jessaustin »

vertex-four wrote: post #90
jessaustin wrote: post #88

Earlier quoted context omitted.

This is what I meant by "scripting hooks". I have something like the following in package.json for various projects: "devDependencies": { "bower": ">=1.3" }, "scripts": { "postinstall": "bower install" } 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 googl…

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.

Re: Mozilla Brick

#99

Post by arenaninja »

wpietri wrote: post #89
potch wrote: post #80

Earlier quoted context omitted.

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

Honestly, I thought it was obvious that the entire thing is probably alpha or thereabout

Re: Mozilla Brick

#100

Post by spankalee »

cdnsteve wrote: post #93

So web components. Haven't used them yet. What's the selling point on this vs Google's Polymer?

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.

Post reply on HN