Podcasts about html imports

A bit of follow up from the last episode, getting your team on to the same tooling - and cool things in VS Code, import ordering, the new Chrome API eye dropper, and some YouTube thoughts and ideas.

John Lindquist asks Evan You when exactly did he become a developer? Evan talks about how the whole thing was a gradual process with no definite "I'm a developer now!" moment. Evan had a degree in art and art history, but he was finding it hard to find work. So Evan went back to school and enrolled in a design and technology program where everyone was forced to learn to code, this is where he first learned Javascript and found great enjoyment in using it.Google's Chrome experiments are what drove Evan to learn Javascript on a deeper level. Evan landed a job at Google Creative Labs after he created and put a portfolio of his prototypes out there once he thought himself to be good at programming. Google Creative Labs were looking for someone who could bring in design and build cool things quickly, they contacted Evan, and things sort of just fell together.Google Creative Labs was where Evan first started his work on Vue. As the project grew, the team started to use Angular 1. it had too many features that they didn't need. Evan also didn't like some of the design decisions that Angular 1 had. So, Evan started to work on a templating library just for his personal use. After six months, in February 2014, he officially released it as Vue.js, putting it out there for others for others to use. Initially, it was just a templating library but as the community grew and more features got requested Vue got built into the framework that it is today, being compared on the same level as React and Angular.Finally, Evan and John discuss Vue's future regarding single file components and proxies. Currently, there are still a lot of problems going with the compile on the fly approach. However, there is a spec being discussed called HTML Modules. Html Imports are getting dropped from the spec. There has been discussion around the HTML Modules spec that looks very similar to what single file components look like on the platform level.Evan plans to refactor Vue to leverage proxies. Currently, when Vue receives data, it will walk through all of its properties and convert them to getter/setters, this has caveats such as not tracking newly added properties when it finishes. Proxies allows them to get rid of these caveats. Proxy traps can track these changes!Transcript"Evan You, creator of Vue.js" TranscriptResourcesVue.js WebsiteHTML Import SpecAll About Reactivity in VueGoogle Chrome ExperimentsGoogle Creative Labs Five ProgramEvan YouGithubWebsiteBlogLinkedInTwitterPatreonJohn LindquistTwitteregghead.ioGithubWebsite

mizchiさん、雨宮氏とキーボード、React、Redux、Firebase、WebAssembly、Flutter、Web Componentsなどについて話しました。 ErgoDox users meet up (2016) キーボード二刀流のススメ | Nekoya Press Kinesis Dvorak配列 - Wikipedia なぜ仮想DOMという概念が俺達の魂を震えさせるのか (2014) Redux Refactoring Reducers Example You Might Not Need Redux dailymotion/vast-client-js rails/sprockets airbnb/hypernova reactjs/react-rails 今、SPA/ReactNativeにとっての必要な PaaS を考える Node/SPAエンジニアにとっての富豪的Firebase Hosting Firebase Authentication Authenticate with Firebase Anonymously Using JavaScript Cloud Firestore Amazon Cognito ユーザープールのトークンの使用 AWS AppSync Firebase Functions 上に GraphQL サーバーを実装する Facebook Query Language (FQL) grpc Pattern: API Gateway / Backend for Front-End WebAssembly Optimistic UIs in under 1000 words serde-rs/serde RustをEmscriptenなしでwasmにコンパイルしてNode.jsから呼び出す A Tour of the Flutter Widget Framework Flutter感想 Google Fuchsia Buttons: Floating Action Button HTML Imports skatejs/skatejs Tracking unhandled rejected Promises フロントエンドの負債と向き合う

My Angular Story 015 Danny Blue On today’s episode we have a My Angular Story with Danny Blue. Danny is a Google Developer Expert for web technologies. In this episode we hear the story about how Danny first started coding, a method suggestion for picking a frameworks, and how vocabulary is vital for a new programmer to learn. It’s a good one, stay tuned. How did you get into programming? Didn’t get started until college. In school he was under the impression that you had to be a math genius to be a programmer. Didn’t even try until college. He wish he would have taken more in College. His first dive into code was ActionScript 2. He was offered a class that taught how to make Flash games and he took the class and made a few games, which he mentions were most likely awful. His game was an infinite runner with a robot. It taught him the basics like loops and storing variables.In his class he realized that as long as he understood some of the key concepts, he would be able to handle it.Soon he went out and just bought a book and after experiencing the code in action he got hooked. Managing memory in C Danny’s friend tried to teach him how to build a checkers game in C. He remembers the pains of manually managing memory. His feedback on malloc is that it’s one of his favorite words because it rolls off the tongue. Charles talks about how in college he had to design systems in VSDL with transistors and silicon. How do you get from that to JavaScript Development First job was at a swimming pool manufacturing company’s marketing department in West Virginia. He worked a lot in Dreamweaver until a man that started after him decided they were going to write all the markup and CSS by hand. From that Danny learned how websites were put together. He talks about a contact form that they wanted to animate. He knew that he could figure it out. He would use code snippets to figure out and build the animation. He started to do more and more JavaScript and teaching himself as much as he could. He did the CodeSchool JavaScript Road Trip. The first few episodes ease you into JavaScript and helps you learn where things lives. From that point he became obsessed with building things with JavaScript. Charles talks about how CodeSchool wasn’t around when he started. Modern code seem to be more complicated but it can be learned best by breaking it down into smaller bites. CodeSchool is good for that. Getting your start or foothold is the hardest part. It’s easy to skip over fundamentals. Charles talks about how that things like CLI came second nature for him and sometimes instructors dismiss that new students may get hung up on those sort of fundamental concepts and tools. Danny adds that there had been times where he would read articles on sites like StackOverflow that would be explaining something but even the baseline instructions has information in it that can something someone has skipped. Little pieces of information can really help pull things together. He talks about the dissociation that can happen for someone who only learned JavaScript and doesn’t know what CLI is and how hard it would be to explain the difference between JavaScript running in the browser and Node, or explaining what a package manager is, then a package , etc. Many people come into it not understanding any of it. He can remember copying commands into a terminal but not understanding what was going on. For learning JavaScript from a basic level, what do you suggest? Finding the beginner tutorials for stuff. CodeSchool is good, Code Academy as well. Do those first. Don’t skip it assuming you know too much to do them. After that just make something. From there you will figure out stuff that works and stuff that doesn’t. Twitter is a great resource for finding helpful people. Being in the environment helps to get exposed to the information. Mainly just write code. Charles mentions that people have grown to understand the concepts and lingo of web development by just listening. Danny also advises that if you learn the vocabulary before learning the concepts, you’ll be able to do things like Google your issues affectively as well as reading articles or talking with others. Complicated concepts end up be boiled down to single words. Ultimately you will need to be able to communicate with everyone on projects anyway. How did you get into Angular? While working at DualLink Digital, they started looking at a few different things, he started looking at Ember and found that he really enjoyed the concepts. One of his friends started messing around with angular and they started workshopping with it to make it work. Afterwards he started to like it, really the plain JavaScript objects. The more he worked with he, the more he started enjoying it compared to Ember. It’s interesting to see how people have moved from Backbone or React or Ember to things like Angular. One of Embers pluses is how large their community is. Charles talks about how the history of Ember is great and the people behind Ember are great. Also, the JavaScript community used to seem to have animosity against the different communities but now it’s more collaborative. Picking the right framework. Danny suggests that when trying to figure out what framework to go with, be able to describe in your own words why the framework you’ve picked is better. Making sure that you do understand the decisions that you are making is important. He uses the example of within the React community and the use of virtual DOM. There was a common misconception that the virtual DOM was faster than the regular DOM, which is just not true. Later the details had to be expressed to clear the misunderstanding. If you don’t talk about the specifics, you may believe something without knowing the facts behind it. Charles adds that its sort of like politics in that way. Tell us the work you’ve done with Web Standards. Danny talks about getting interested in web components through his friend Eric and actually interviewed at the company Eric worked at. He didn’t get the job but they stayed in touch and Eric introduced him into Polymer. He started to learn about Polymer, specifically custom elements. He remembers very early on wanting to make a custom HTML tag. He suggests that being able to do things without the framework has been a piece that has been missing. Having lower level building blocks to build off of is really exciting to Danny. He talks about using custom elements to build a familiar API surface to interact with. He talks about an example where he wrapped a bunch of HTML APIs, like the notification API and the fullscreen API, wrapping another element within it. He was trying to build things that the younger version of himself could use. He things that could be something we are heading towards more often. Danny adds that Web Components come with 4 major parts: Custom elements, HTML Imports (kind of), ShadowDOM, and templates. Custom elements allow you to create a unique piece of HTML and is the most widely accepted and supported. What are you working on now? Danny talks about how the Angular’s component model is very similar to Custom Element component model. Where you pass information in through properties and you listen for changes through events. You can use Custom Elements with very little setup. There is a specific Custom Elements Scheme that will let you use custom elements without any properties being thrown. You use the custom event in the exact same way and syntax as for any other component. The one issue with the source code where it parses the metadata, losing the friendly compiler messages out of the box. He is playing around with trying to find a way to whitelist different element names and properties. He wants to learn how the Framework is parsing potential data and make it easy to whitelist a set of custom elements. Picks Dannys Daemon by Daniel Suarez Bob’s Burgers CodeSchool Charles VR & Augmented Reality IoT Artificial Intelligence Veritone.com Coursera on Artificial Intelligence Artificial Intelligence with Python Machine Learning for Absolute Beginners Links Twitter Blog on Medium

My Angular Story 015 Danny Blue On today’s episode we have a My Angular Story with Danny Blue. Danny is a Google Developer Expert for web technologies. In this episode we hear the story about how Danny first started coding, a method suggestion for picking a frameworks, and how vocabulary is vital for a new programmer to learn. It’s a good one, stay tuned. How did you get into programming? Didn’t get started until college. In school he was under the impression that you had to be a math genius to be a programmer. Didn’t even try until college. He wish he would have taken more in College. His first dive into code was ActionScript 2. He was offered a class that taught how to make Flash games and he took the class and made a few games, which he mentions were most likely awful. His game was an infinite runner with a robot. It taught him the basics like loops and storing variables.In his class he realized that as long as he understood some of the key concepts, he would be able to handle it.Soon he went out and just bought a book and after experiencing the code in action he got hooked. Managing memory in C Danny’s friend tried to teach him how to build a checkers game in C. He remembers the pains of manually managing memory. His feedback on malloc is that it’s one of his favorite words because it rolls off the tongue. Charles talks about how in college he had to design systems in VSDL with transistors and silicon. How do you get from that to JavaScript Development First job was at a swimming pool manufacturing company’s marketing department in West Virginia. He worked a lot in Dreamweaver until a man that started after him decided they were going to write all the markup and CSS by hand. From that Danny learned how websites were put together. He talks about a contact form that they wanted to animate. He knew that he could figure it out. He would use code snippets to figure out and build the animation. He started to do more and more JavaScript and teaching himself as much as he could. He did the CodeSchool JavaScript Road Trip. The first few episodes ease you into JavaScript and helps you learn where things lives. From that point he became obsessed with building things with JavaScript. Charles talks about how CodeSchool wasn’t around when he started. Modern code seem to be more complicated but it can be learned best by breaking it down into smaller bites. CodeSchool is good for that. Getting your start or foothold is the hardest part. It’s easy to skip over fundamentals. Charles talks about how that things like CLI came second nature for him and sometimes instructors dismiss that new students may get hung up on those sort of fundamental concepts and tools. Danny adds that there had been times where he would read articles on sites like StackOverflow that would be explaining something but even the baseline instructions has information in it that can something someone has skipped. Little pieces of information can really help pull things together. He talks about the dissociation that can happen for someone who only learned JavaScript and doesn’t know what CLI is and how hard it would be to explain the difference between JavaScript running in the browser and Node, or explaining what a package manager is, then a package , etc. Many people come into it not understanding any of it. He can remember copying commands into a terminal but not understanding what was going on. For learning JavaScript from a basic level, what do you suggest? Finding the beginner tutorials for stuff. CodeSchool is good, Code Academy as well. Do those first. Don’t skip it assuming you know too much to do them. After that just make something. From there you will figure out stuff that works and stuff that doesn’t. Twitter is a great resource for finding helpful people. Being in the environment helps to get exposed to the information. Mainly just write code. Charles mentions that people have grown to understand the concepts and lingo of web development by just listening. Danny also advises that if you learn the vocabulary before learning the concepts, you’ll be able to do things like Google your issues affectively as well as reading articles or talking with others. Complicated concepts end up be boiled down to single words. Ultimately you will need to be able to communicate with everyone on projects anyway. How did you get into Angular? While working at DualLink Digital, they started looking at a few different things, he started looking at Ember and found that he really enjoyed the concepts. One of his friends started messing around with angular and they started workshopping with it to make it work. Afterwards he started to like it, really the plain JavaScript objects. The more he worked with he, the more he started enjoying it compared to Ember. It’s interesting to see how people have moved from Backbone or React or Ember to things like Angular. One of Embers pluses is how large their community is. Charles talks about how the history of Ember is great and the people behind Ember are great. Also, the JavaScript community used to seem to have animosity against the different communities but now it’s more collaborative. Picking the right framework. Danny suggests that when trying to figure out what framework to go with, be able to describe in your own words why the framework you’ve picked is better. Making sure that you do understand the decisions that you are making is important. He uses the example of within the React community and the use of virtual DOM. There was a common misconception that the virtual DOM was faster than the regular DOM, which is just not true. Later the details had to be expressed to clear the misunderstanding. If you don’t talk about the specifics, you may believe something without knowing the facts behind it. Charles adds that its sort of like politics in that way. Tell us the work you’ve done with Web Standards. Danny talks about getting interested in web components through his friend Eric and actually interviewed at the company Eric worked at. He didn’t get the job but they stayed in touch and Eric introduced him into Polymer. He started to learn about Polymer, specifically custom elements. He remembers very early on wanting to make a custom HTML tag. He suggests that being able to do things without the framework has been a piece that has been missing. Having lower level building blocks to build off of is really exciting to Danny. He talks about using custom elements to build a familiar API surface to interact with. He talks about an example where he wrapped a bunch of HTML APIs, like the notification API and the fullscreen API, wrapping another element within it. He was trying to build things that the younger version of himself could use. He things that could be something we are heading towards more often. Danny adds that Web Components come with 4 major parts: Custom elements, HTML Imports (kind of), ShadowDOM, and templates. Custom elements allow you to create a unique piece of HTML and is the most widely accepted and supported. What are you working on now? Danny talks about how the Angular’s component model is very similar to Custom Element component model. Where you pass information in through properties and you listen for changes through events. You can use Custom Elements with very little setup. There is a specific Custom Elements Scheme that will let you use custom elements without any properties being thrown. You use the custom event in the exact same way and syntax as for any other component. The one issue with the source code where it parses the metadata, losing the friendly compiler messages out of the box. He is playing around with trying to find a way to whitelist different element names and properties. He wants to learn how the Framework is parsing potential data and make it easy to whitelist a set of custom elements. Picks Dannys Daemon by Daniel Suarez Bob’s Burgers CodeSchool Charles VR & Augmented Reality IoT Artificial Intelligence Veritone.com Coursera on Artificial Intelligence Artificial Intelligence with Python Machine Learning for Absolute Beginners Links Twitter Blog on Medium

My Angular Story 015 Danny Blue On today’s episode we have a My Angular Story with Danny Blue. Danny is a Google Developer Expert for web technologies. In this episode we hear the story about how Danny first started coding, a method suggestion for picking a frameworks, and how vocabulary is vital for a new programmer to learn. It’s a good one, stay tuned. How did you get into programming? Didn’t get started until college. In school he was under the impression that you had to be a math genius to be a programmer. Didn’t even try until college. He wish he would have taken more in College. His first dive into code was ActionScript 2. He was offered a class that taught how to make Flash games and he took the class and made a few games, which he mentions were most likely awful. His game was an infinite runner with a robot. It taught him the basics like loops and storing variables.In his class he realized that as long as he understood some of the key concepts, he would be able to handle it.Soon he went out and just bought a book and after experiencing the code in action he got hooked. Managing memory in C Danny’s friend tried to teach him how to build a checkers game in C. He remembers the pains of manually managing memory. His feedback on malloc is that it’s one of his favorite words because it rolls off the tongue. Charles talks about how in college he had to design systems in VSDL with transistors and silicon. How do you get from that to JavaScript Development First job was at a swimming pool manufacturing company’s marketing department in West Virginia. He worked a lot in Dreamweaver until a man that started after him decided they were going to write all the markup and CSS by hand. From that Danny learned how websites were put together. He talks about a contact form that they wanted to animate. He knew that he could figure it out. He would use code snippets to figure out and build the animation. He started to do more and more JavaScript and teaching himself as much as he could. He did the CodeSchool JavaScript Road Trip. The first few episodes ease you into JavaScript and helps you learn where things lives. From that point he became obsessed with building things with JavaScript. Charles talks about how CodeSchool wasn’t around when he started. Modern code seem to be more complicated but it can be learned best by breaking it down into smaller bites. CodeSchool is good for that. Getting your start or foothold is the hardest part. It’s easy to skip over fundamentals. Charles talks about how that things like CLI came second nature for him and sometimes instructors dismiss that new students may get hung up on those sort of fundamental concepts and tools. Danny adds that there had been times where he would read articles on sites like StackOverflow that would be explaining something but even the baseline instructions has information in it that can something someone has skipped. Little pieces of information can really help pull things together. He talks about the dissociation that can happen for someone who only learned JavaScript and doesn’t know what CLI is and how hard it would be to explain the difference between JavaScript running in the browser and Node, or explaining what a package manager is, then a package , etc. Many people come into it not understanding any of it. He can remember copying commands into a terminal but not understanding what was going on. For learning JavaScript from a basic level, what do you suggest? Finding the beginner tutorials for stuff. CodeSchool is good, Code Academy as well. Do those first. Don’t skip it assuming you know too much to do them. After that just make something. From there you will figure out stuff that works and stuff that doesn’t. Twitter is a great resource for finding helpful people. Being in the environment helps to get exposed to the information. Mainly just write code. Charles mentions that people have grown to understand the concepts and lingo of web development by just listening. Danny also advises that if you learn the vocabulary before learning the concepts, you’ll be able to do things like Google your issues affectively as well as reading articles or talking with others. Complicated concepts end up be boiled down to single words. Ultimately you will need to be able to communicate with everyone on projects anyway. How did you get into Angular? While working at DualLink Digital, they started looking at a few different things, he started looking at Ember and found that he really enjoyed the concepts. One of his friends started messing around with angular and they started workshopping with it to make it work. Afterwards he started to like it, really the plain JavaScript objects. The more he worked with he, the more he started enjoying it compared to Ember. It’s interesting to see how people have moved from Backbone or React or Ember to things like Angular. One of Embers pluses is how large their community is. Charles talks about how the history of Ember is great and the people behind Ember are great. Also, the JavaScript community used to seem to have animosity against the different communities but now it’s more collaborative. Picking the right framework. Danny suggests that when trying to figure out what framework to go with, be able to describe in your own words why the framework you’ve picked is better. Making sure that you do understand the decisions that you are making is important. He uses the example of within the React community and the use of virtual DOM. There was a common misconception that the virtual DOM was faster than the regular DOM, which is just not true. Later the details had to be expressed to clear the misunderstanding. If you don’t talk about the specifics, you may believe something without knowing the facts behind it. Charles adds that its sort of like politics in that way. Tell us the work you’ve done with Web Standards. Danny talks about getting interested in web components through his friend Eric and actually interviewed at the company Eric worked at. He didn’t get the job but they stayed in touch and Eric introduced him into Polymer. He started to learn about Polymer, specifically custom elements. He remembers very early on wanting to make a custom HTML tag. He suggests that being able to do things without the framework has been a piece that has been missing. Having lower level building blocks to build off of is really exciting to Danny. He talks about using custom elements to build a familiar API surface to interact with. He talks about an example where he wrapped a bunch of HTML APIs, like the notification API and the fullscreen API, wrapping another element within it. He was trying to build things that the younger version of himself could use. He things that could be something we are heading towards more often. Danny adds that Web Components come with 4 major parts: Custom elements, HTML Imports (kind of), ShadowDOM, and templates. Custom elements allow you to create a unique piece of HTML and is the most widely accepted and supported. What are you working on now? Danny talks about how the Angular’s component model is very similar to Custom Element component model. Where you pass information in through properties and you listen for changes through events. You can use Custom Elements with very little setup. There is a specific Custom Elements Scheme that will let you use custom elements without any properties being thrown. You use the custom event in the exact same way and syntax as for any other component. The one issue with the source code where it parses the metadata, losing the friendly compiler messages out of the box. He is playing around with trying to find a way to whitelist different element names and properties. He wants to learn how the Framework is parsing potential data and make it easy to whitelist a set of custom elements. Picks Dannys Daemon by Daniel Suarez Bob’s Burgers CodeSchool Charles VR & Augmented Reality IoT Artificial Intelligence Veritone.com Coursera on Artificial Intelligence Artificial Intelligence with Python Machine Learning for Absolute Beginners Links Twitter Blog on Medium

Is ActiveRecord reinventing Sequel? If it is, does it matter? Derek and Sean discuss that and whether maybe we could all stand to tone down the JavaScript. ActiveRecord is Reinventing Sequel Ryan Bigg gives up his open source projects Maybe We Could Tone Down the JavaScript by Evee Stronger Parameters Mother F*cking Website Discourse Ember CLI Fastboot Introduction to HTML Imports TC39 Modernizr Can I Use: Date and Time Input Types

Hajime Morita さんをゲストに迎えて、Bitcode, microservices, Rust, Go, Web Assembly, Polymer, Web Components などについて話しました。 Show Notes Apple’s Bitcode Telegraphs Future CPU Plans LLVM Bitcode File Format Monolith First Don’t start with a monolith RailsConf 2015 - Opening Keynote by DHH The Recipe for the World's Largest Rails Monolith cookpad/chanko The Rust Programming Language Mozilla 2 - MozillaWiki Servo Generics | Rust by Example Rust Ownership Rust Means Never Having to Close a Socket Stability as a Deliverable PSA: Important info about rustc's new feature staging Cargo Using Rust from Perl and Julia Mozilla: land rust mp4parse v0.0.8 From ASM.JS to WebAssembly asm.js PNaCl - The Chromium Projects WebAssembly/polyfill-prototype-1 emscripten JavaScriptCore should natively support WebAssembly Future Features - WebAssembly/design Introducing Polymer 1.0 Polymer と Web Components Introduction - Material design What is a Polyfill? The state of Web Components HTML Imports Local DOM Basics and API - Polymer import - JavaScript

Daniel Buchner (@csuwildcat), Product Manager at Target & former Mozillian, talks with The Web Platform Podcast on x-tag, the Custom Elements library competitor to Polymer that he created alongside former Mozillian & Kraken Developer, Arron Schaar (@pennyfx). X-tag is a interesting way to work with web components that takes a totally imperative approach to creating Web Components as opposed to the declarative way of building with Polymer. Some features include legacy browser support, optional mixins to share across components, & functional pseudos to assist in delegation.   Daniel has worked on the W3C specs for Web Components and is now updating x-tag to meet the demands of developers to have more flexibility with Shadow DOM, Templates, and HTML Imports. Daniel is very active on github and would love to have more contributors help build the future of the x-tag projects as well as all projects that help make the web better. Resources   x-tag - http://www.x-tags.org x-tag documentation -http://x-tag.readme.io/v1.0/docs x-tag input - https://github.com/x-tag/input/blob/master/src/input.js x-tag on Github - https://github.com/x-tag web search - https://github.com/web-services/web-search A Quantum Leap into Web Development - http://slides.com/danielbuchner/wc-qconf#/ Daniel at SFHTML Meetup - https://www.youtube.com/watch?v=iPmN4CvLGJc What's next for x-tag - http://webcomponents.org/articles/interview-with-daniel-buchner/ Daniel's Github - https://github.com/csuwildcat Target - http://www.target.com

Today, Web Components have emerged from cutting edge technologies to technologies we can implement in our small scale production. It won't be long before we are building large scale applications with Custom Elements, HTML Imports, Template Tags, and the infamous Shadow DOM. In embracing this type of developer environment, with it's flexibility and compositional nature, consider interoperabilty as a core concept.   If you need a custom element for a card layout, as an example, you should be able to use any Web Component out there in the ecosystem regardless of which library or toolchain it comes from. If the component provides the desired functionality and styling you would require it should work seamlessly in your application. Furthermore, toolsets should not limit the the extending and composition of these custom elements. In practice, this may or may not always be the case and library & toolchain creators will need to be aware of these concerns.   Rob Dodson (@rob_dodson), Developer Advocate on the Google Chrome team, talks about his thoughts on the subject. Rob is helping to educate developers, not just about Google's Polymer Library built on top of Web Components, but across the entire Web Components community.   Rob goes through many of the changes made to Polymer 0.4.2, including accessibility and performance that help in making applications more integrated and how Google is working to share what the Blink Team has learned from implementing Web Components in Chrome with other browser vendors and developers.   Working closely with Mozilla developers on his SFHTML 5 Meetup talk on Web Components Mashups, Rob was able to collaborate and share ideas so that Web Components could alleviate many of the concerns we had when migrating from one JavaScript library to another. It is painful for developers to have to remake components every time they switch libraries or frameworks. Web Components aims to make that a thing of the past and Rob has done much more on this topic since that talk. Have a listen and hear what he has to say. Resources Rob's Blog - http://robdodson.me/ I/O Presentation - http://webcomponents.org/presentations/unlock-the-next-era-of-ui-development-with-polymer-at-io/ Accessible Web Components Part 1 -https://www.polymer-project.org/articles/accessible-web-components.html SFHTML Mashup Video -https://www.youtube.com/watch?v=75EuHl6CSTo The Web Platform Status for IE - https://status.modern.ie/ IE Beta Channel - http://www.microsoft.com/en-us/download/details.aspx?id=43360 Polytechnic Events - http://itshackademic.com/ Polycast Playlist - https://www.youtube.com/playlist?list=PLOU2XLYxmsII5c3Mgw6fNYCzaWrsM3sMN Custom Elements on GitHub - https://twitter.com/polymer/status/464103568392200193 IE Platform Voting -https://wpdev.uservoice.com/forums/257854-internet-explorer-platform customelements.io - http://customelements.io/ Webcomponents.org -http://webcomponents.org/ Bosonic Shadow DOM Issue (#4) - https://github.com/bosonic/bosonic/issues/4 The Bower Package Manager - http://bower.io/ Divshot - http://divshot.io Divshot Blog - https://divshot.com/blog/ BuiltWithPolymer - http://builtwithpolymer.org/ Divshot's Web Component Playground - https://ele.io/ Angular 2 Web Components Data Binding Document - https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG0cFh0ST0ekhD_g8sxtI/edit?hl=en&forcehl=1&pli=1#heading=h.xgjl2srtytjt ReadTheSource - http://hangouts.readthesource.io/hangouts/divshot-superstatic/ RailsCasts -http://railscasts.com/ PhantomJS -https://github.com/ariya/phantomjs/wiki/PhantomJS-2 saucelabs -https://saucelabs.com/ People Alex Russel -https://twitter.com/slightlylate Alice Boxhall -https://twitter.com/sundress Raphael Rugeron - https://twitter.com/goldoraf Jonathon Sampson  -https://twitter.com/jonathansampson Arron Schaar - https://github.com/pennyfx Michael Bleigh - https://twitter.com/mbleigh Scott Corgan - https://twitter.com/scottcorgan Projects Reactive Elements -https://github.com/PixelsCommander/ReactiveElements X-Tags Imports - https://github.com/x-tag/x-tag-imports Enyo -http://enyojs.com/ React.js -http://facebook.github.io/react/ Famo.us -http://famo.us/ Chromium Blink -http://www.chromium.org/blink Polymer 0.4.2 -https://github.com/Polymer/polymer/releases/tag/0.4.2 Brick 2.0 -http://brick.mozilla.io/ X-Tags -http://www.x-tags.org/ Polymer -https://www.polymer-project.org/ Bosonic -https://bosonic.github.io/ Vulcanize - https://github.com/polymer/vulcanize generator-element -https://github.com/webcomponents/generator-element Firefox OS - https://www.mozilla.org/en-US/firefox/os/ web-component-tester -https://github.com/Polymer/web-component-tester Topeka -https://github.com/polymer/topeka Jquery UI -http://jqueryui.com/ Components core-a11ykeys -https://github.com/Polymer/core-a11y-keys core-list -https://github.com/Polymer/core-list core-animated-pages -https://github.com/Polymer/core-animated-pages Brick Components -http://brick.mozilla.io/v2.0/docs WinJS Polymer Samples -https://github.com/banguero/winjs-polymer-samples core-ajax - https://github.com/polymer/core-ajax google-map - https://github.com/GoogleWebComponents/google-map core-shared-lib - https://github.com/Polymer/core-shared-lib google-apis - https://github.com/GoogleWebComponents/google-apis core-selector - https://github.com/polymer/core-selector paper-menu-button - https://github.com/Polymer/paper-menu-button paper-tabs - https://github.com/Polymer/paper-tabs paper-elements - https://www.polymer-project.org/docs/elements/paper-elements.html core-signals -https://github.com/Polymer/core-signals

Raphael Rougeron joins us from Toulouse, France to talk about The Bosonic Project.  Raphael and his team of developers mostly focus their development efforts working in the Financial Industry, building out secure and robust applications as well as intricate cross browser UI Components. The UI components part of his work is especially interesting in that it led him to create The Bosonic Project.   Raphael was frustrated, like most of us, with having to constantly rewrite all of his components every time his team shifted technologies so he created The Bosonic Project. Bosonic, deriving its name from the word Boson, which is a subatomic particle that has zero or integral spin, is a philosophy and supporting tool chain to assist in building better UI components as the standardized Web Component specs (Custom Elements, HTML Imports, Shadow DOM, Templates, and CSS Decorators) describe them. This approach shields components against potential spec changes and provides support for “not-so-modern” browsers like Internet Explorer 9 (IE9).   Resources https://bosonic.github.io/ https://github.com/bosonic/grunt-bosonic https://github.com/bosonic/bosonic https://bosonic.github.io/getting-started.html https://raw.githubusercontent.com/bosonic/bosonic/master/dist/bosonic-polyfills.js https://github.com/bosonic/transpiler http://blog.raphael-rougeron.com/ https://twitter.com/goldoraf

A little over a year ago at JSConf EU, Angelina tried to inspire developers to take an interest in Web Components, which includes Shadow Dom, HTML Templates, HTML Imports, and Custom Elements. In this talk we'll take a look at how far we've come in a year: what has been implemented, what hasn't, the current state of the relevant specifications, and discuss various frameworks and libraries that have emerged either with patterns similar to web components or embracing the technology completely. We will take a look at these changes, and also dive into some code for a comprehensive overview of 'the state of things' - spoiler: it's still always changing. More info at: https://fronteers.nl/congres/2013/sessions/web-components

A little over a year ago at JSConf EU, Angelina tried to inspire developers to take an interest in Web Components, which includes Shadow Dom, HTML Templates, HTML Imports, and Custom Elements. In this talk we'll take a look at how far we've come in a year: what has been implemented, what hasn't, the current state of the relevant specifications, and discuss various frameworks and libraries that have emerged either with patterns similar to web components or embracing the technology completely. We will take a look at these changes, and also dive into some code for a comprehensive overview of 'the state of things' - spoiler: it's still always changing. More info at: https://fronteers.nl/congres/2013/sessions/web-components