Polymer

» see polymer-project.org as it lived, on the wayback machine

~ the obit ~

polymer was google's web-components library. the pitch was that the browser already had a native custom-elements spec coming, plus shadow dom for style isolation. you should write your ui as new html tags like <my-thing>, not as react components inside javascript. polymer was the thin wrapper that made that workable across the browsers that did not ship the spec natively yet. first commits went public in november 2013 alongside the promises polyfill.

polymer 1.0 landed on 29 may 2015 as the first version the team called production-ready. load times improved up to seven times over 0.5. inside google, the youtube web rewrite picked it up, and the 2017 google earth redesign was polymer end to end. outside google the adopter list included netflix and electronic arts. it was the closest google ever came to fielding a frontend framework that could stand alongside angular without being angular.

i never wrote a polymer component. by 2015 i had a steady frontend stack i was happy with for the small tools i built around computer-vision work in ankara, and that stack was not custom-elements-first. polymer surfaced for me as a google-cdn link i saw in network panels while debugging youtube. engineer-side awareness of the library, not user-side experience with its api.

~ the rap sheet ~

~ what it actually did ~

the polymer api gave you a base class, polymer.element. you extended it and declared a template with html plus binding syntax. you got back a working custom element. two-way binding meant if you wrote {{value}} in the template, an input typed into the field updated the underlying property and vice versa. this was the part the angular crowd already understood from angularjs and the react crowd had spent years explicitly rejecting.

the second half of the pitch was the elements catalog. paper-elements were the material-design ui set. iron-elements were the structural primitives underneath. you composed an app out of these the way bootstrap users composed a page out of bootstrap classes. polymer 1.x shipped enough catalog to build the entire visible surface of an app without writing your own design system.

~ the 2 may pivot ~

on 2 may 2018 matthew mcnulty posted a roadmap update from the polymer team. polymer 3.0 was shipping at google i/o the next week, moving the project from html imports to es modules and from bower to npm. that part read like a normal version cut. the part that did not was the recommended path for new development: "litelement is our recommended base class for new development". polymer 3 would stay on full maintenance but no new feature work. lit-html and litelement, which the chrome team had been building inside the same project, were the future.

two-way binding was the explicit casualty. litelement used one-way binding plus event handlers, the same pattern react had settled on. the team's framing was that the new model was simpler and faster. the community reading was that polymer had lost the internal argument inside google about how google should write web components. polymer 3 kept getting maintenance versions all the way to 3.5.2 in october 2024 but the brand had already finished its arc on the 2 may post.

~ what survived ~

lit (the renamed litelement plus lit-html bundle) carried the web-components bet forward and is still alive in 2026. the actual web-components spec landed in every major browser, which was the whole point. you can ship a custom element today without polymer or lit because the browser does it natively. polymer was the bridge library that got the spec across the chasm, then made itself obsolete on purpose. youtube still uses descendants of the polymer 2.x components on the web client.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »