These new APIs have gotten developers excited about the Web in a whole new way, and people have begun building and sharing their own Custom Elements. Brick, Polymer, and many other third-party Custom Elements are being distributed and indexed as part of an awesome burgeoning Custom Elements ecosystem.
People have asked how their component can become part of Brick. We love contributions, but not every component may match the coding and API style of Brick, or meet its goals. Just as many programming languages have a standard library as well as a rich ecosystem of third-party modules, Brick aims to be a 'standard library' of webapp-specific Custom Elements, but will support and interoperate with the larger community of components.
In the early(er) days of Web Components, the Custom Elements standard was very much so in flux. It was hard to build to the standard or even a polyfill because the APIs kept changing. Daniel Buchner and Arron Schaar concieved of x-tag, which provided useful helper functions around events and the component definition process. The library was a godsend, and using it Brick was able to get off the ground. Over time, however, the APIs have settled, and the project found itself in need of the other features of the Web Components standards. These features are all part of the platform.js polyfill that is part of Polymer and available externally as well. Additionally, 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.
+In the early(er) days of Web Components, the Custom Elements standard was very much so in flux. It was hard to build to the standard or even a polyfill because the APIs kept changing. Daniel Buchner and Arron Schaar concieved of x-tag, which provided useful helper functions around events and the component definition process. The library was a godsend, and using it Brick was able to get off the ground. Over time, however, the APIs have settled, and the project found itself in need of the other features of the Web Components standards. These features are all part of the webcomponents.js polyfill that is part of Polymer and available externally as well. Additionally, 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.
Here's a diagram of how things looked with Brick 1.0:
Going forward, Brick will ship using the same platform.js polyfill used by Polymer. This gives us access to the full range of Web Components features, as well as ensures interoperability with Polymer and other standards-based Custom Elements:
+Going forward, Brick will ship using the same webcomponents.js polyfill used by Polymer. This gives us access to the full range of Web Components features, as well as ensures interoperability with Polymer and other standards-based Custom Elements:
After deciding to use the platform.js polyfills and remove the x-tag library, Brick is being built from the ground-up to be lighter, more modular, and easier to contribute to. It's a big undertaking, so we're moving from 1.0 to 2.0 to reflect the scale of the work. It's a more-or-less reboot of the entire project, and I as well as the rest of the team are very excited about it. We haven't been vocal enough about updates, but I'm committing to posting regularly here as well as on Twitter at @mozbrick. Stay tuned!
+After deciding to use the webcomponents.js polyfills and remove the x-tag library, Brick is being built from the ground-up to be lighter, more modular, and easier to contribute to. It's a big undertaking, so we're moving from 1.0 to 2.0 to reflect the scale of the work. It's a more-or-less reboot of the entire project, and I as well as the rest of the team are very excited about it. We haven't been vocal enough about updates, but I'm committing to posting regularly here as well as on Twitter at @mozbrick. Stay tuned!
~potch
written 15 July 2014 · permalink
diff --git a/blog/2014-07-11-Brick-2-point-0.md b/blog/2014-07-11-Brick-2-point-0.md index 81829c6..62572d9 100644 --- a/blog/2014-07-11-Brick-2-point-0.md +++ b/blog/2014-07-11-Brick-2-point-0.md @@ -31,7 +31,7 @@ People have asked how their component can become part of Brick. We love contribu ## On X-Tag -In the early(er) days of Web Components, the Custom Elements standard was very much so in flux. It was hard to build to the standard or even a polyfill because the APIs kept changing. [Daniel Buchner](https://github.com/csuwildcat/) and [Arron Schaar](https://github.com/pennyfx/) concieved of [x-tag](http://x-tags.org/), which provided useful helper functions around events and the component definition process. The library was a godsend, and using it Brick was able to get off the ground. Over time, however, the APIs have settled, and the project found itself in need of the other features of the Web Components standards. These features are all part of the [platform.js](https://github.com/Polymer/platform/) polyfill that is part of Polymer and available externally as well. Additionally, 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. +In the early(er) days of Web Components, the Custom Elements standard was very much so in flux. It was hard to build to the standard or even a polyfill because the APIs kept changing. [Daniel Buchner](https://github.com/csuwildcat/) and [Arron Schaar](https://github.com/pennyfx/) concieved of [x-tag](http://x-tags.org/), which provided useful helper functions around events and the component definition process. The library was a godsend, and using it Brick was able to get off the ground. Over time, however, the APIs have settled, and the project found itself in need of the other features of the Web Components standards. These features are all part of the [webcomponents.js](https://github.com/Polymer/webcomponentsjs/) polyfill that is part of Polymer and available externally as well. Additionally, 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. Here's a diagram of how things looked with Brick 1.0: @@ -40,7 +40,7 @@ Here's a diagram of how things looked with Brick 1.0:These new APIs have gotten developers excited about the Web in a whole new way, and people have begun building and sharing their own Custom Elements. Brick, Polymer, and many other third-party Custom Elements are being distributed and indexed as part of an awesome burgeoning Custom Elements ecosystem.
People have asked how their component can become part of Brick. We love contributions, but not every component may match the coding and API style of Brick, or meet its goals. Just as many programming languages have a standard library as well as a rich ecosystem of third-party modules, Brick aims to be a 'standard library' of webapp-specific Custom Elements, but will support and interoperate with the larger community of components.
In the early(er) days of Web Components, the Custom Elements standard was very much so in flux. It was hard to build to the standard or even a polyfill because the APIs kept changing. Daniel Buchner and Arron Schaar concieved of x-tag, which provided useful helper functions around events and the component definition process. The library was a godsend, and using it Brick was able to get off the ground. Over time, however, the APIs have settled, and the project found itself in need of the other features of the Web Components standards. These features are all part of the platform.js polyfill that is part of Polymer and available externally as well. Additionally, 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.
+In the early(er) days of Web Components, the Custom Elements standard was very much so in flux. It was hard to build to the standard or even a polyfill because the APIs kept changing. Daniel Buchner and Arron Schaar concieved of x-tag, which provided useful helper functions around events and the component definition process. The library was a godsend, and using it Brick was able to get off the ground. Over time, however, the APIs have settled, and the project found itself in need of the other features of the Web Components standards. These features are all part of the webcomponents.js polyfill that is part of Polymer and available externally as well. Additionally, 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.
Here's a diagram of how things looked with Brick 1.0:
Going forward, Brick will ship using the same platform.js polyfill used by Polymer. This gives us access to the full range of Web Components features, as well as ensures interoperability with Polymer and other standards-based Custom Elements:
+Going forward, Brick will ship using the same webcomponents.js polyfill used by Polymer. This gives us access to the full range of Web Components features, as well as ensures interoperability with Polymer and other standards-based Custom Elements:
After deciding to use the platform.js polyfills and remove the x-tag library, Brick is being built from the ground-up to be lighter, more modular, and easier to contribute to. It's a big undertaking, so we're moving from 1.0 to 2.0 to reflect the scale of the work. It's a more-or-less reboot of the entire project, and I as well as the rest of the team are very excited about it. We haven't been vocal enough about updates, but I'm committing to posting regularly here as well as on Twitter at @mozbrick. Stay tuned!
+After deciding to use the webcomponents.js polyfills and remove the x-tag library, Brick is being built from the ground-up to be lighter, more modular, and easier to contribute to. It's a big undertaking, so we're moving from 1.0 to 2.0 to reflect the scale of the work. It's a more-or-less reboot of the entire project, and I as well as the rest of the team are very excited about it. We haven't been vocal enough about updates, but I'm committing to posting regularly here as well as on Twitter at @mozbrick. Stay tuned!
~potch
written 15 July 2014 · permalink
diff --git a/bower.json b/bower.json index 0f31cb7..4263907 100644 --- a/bower.json +++ b/bower.json @@ -15,7 +15,7 @@ "tests" ], "dependencies": { - "platform": "Polymer/platform#~0.3.3", + "webcomponentsjs": "Polymer/webcomponentsjs#~0.5.1", "brick": "mozbrick/brick#master" } } diff --git a/bower_components/brick-action/.bower.json b/bower_components/brick-action/.bower.json index 2c251a5..d0ecbd4 100644 --- a/bower_components/brick-action/.bower.json +++ b/bower_components/brick-action/.bower.json @@ -20,7 +20,7 @@ ], "dependencies": { "brick-common": "*", - "platform": "Polymer/platform" + "webcomponentsjs": "Polymer/webcomponentsjs" }, "devDependencies": { "brick-flipbox": "mozbrick/brick-flipbox" diff --git a/bower_components/brick-action/bower.json b/bower_components/brick-action/bower.json index d380780..6f98044 100644 --- a/bower_components/brick-action/bower.json +++ b/bower_components/brick-action/bower.json @@ -21,7 +21,7 @@ ], "dependencies": { "brick-common": "*", - "platform": "Polymer/platform" + "webcomponentsjs": "Polymer/webcomponentsjs" }, "devDependencies": { "brick-flipbox": "mozbrick/brick-flipbox" diff --git a/bower_components/brick-action/gulpfile.js b/bower_components/brick-action/gulpfile.js index 55d4c6b..3a9e204 100644 --- a/bower_components/brick-action/gulpfile.js +++ b/bower_components/brick-action/gulpfile.js @@ -15,7 +15,7 @@ var paths = { 'src': 'src/*', 'index': 'index.html', 'bowerComponents': 'bower_components/**/*', - 'testfiles': ['test/*', 'bower_components/platform/platform.js'] + 'testfiles': ['test/*', 'bower_components/webcomponentsjs/webcomponents.js'] }; gulp.task('lint', function() { diff --git a/bower_components/brick-action/index.html b/bower_components/brick-action/index.html index 5d1e169..13cc134 100644 --- a/bower_components/brick-action/index.html +++ b/bower_components/brick-action/index.html @@ -6,7 +6,7 @@