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

111–120 of 122 posts

Re: Mozilla Brick

#111

Post by sp332 »

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…

Good points, just thought I'd mention that Mozilla Labs shut down a while ago.

Re: Mozilla Brick

#112

Post by Lerc »

sp332 wrote: post #111
wpietri wrote: post #89

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

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?

Re: Mozilla Brick

#113

Post by sp332 »

Lerc wrote: post #112
sp332 wrote: post #111

Earlier quoted context omitted.

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

Re: Mozilla Brick

#114

Post by ble »

cdnsteve wrote: post #93

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.

Re: Mozilla Brick

#115

Post by pekk »

anonbanker wrote: post #97
anonbanker wrote: post #69

Earlier quoted context omitted.

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.

Re: Mozilla Brick

#116

Post by porker »

bshimmin wrote: post #35

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.

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

Re: Mozilla Brick

#117

Post by csuwldcat »

spankalee wrote: post #101
BinaryIdiot wrote: post #94

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

Re: Mozilla Brick

#118

Post by csuwldcat »

ngokevin wrote: post #19
spankalee wrote: post #17

Earlier quoted context omitted.

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

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.

Re: Mozilla Brick

#119

Post by csuwldcat »

BinaryIdiot wrote: post #94

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

Re: Mozilla Brick

#120

Post by fuzzywalrus »

neves wrote: post #108
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.

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

Post reply on HN