poly-on-fire: Polymer, on Firebase


poly-on-fire is my collection of commonly required functionality pieces, in isolation.


The big gripe about Polymer – whenever I talk to front end devs here in Austin TX, is that it’s “… too low level, too hard to get things done, you have to know javascript.” I didn’t find that to be the case, maybe it’s because breaking the functionality I needed for my apps into these isolated, easy to learn pieces made it all work easily, for me.

Leaving them behind in github, as really dumb, easy, projects, makes it fast for me to re-learn them again when I forget. Or when I need some perspective. Especially compared to real apps, where everything gets all mixed up, and a little more time consuming to distinguish which component is doing what.

You’ll also find there, something more than only the most isolated pieces. Some projects then integrate more isolated pieces, in layers. One project for just CRUD, one for social logins, one for redux, but then an integration project that combines the CRUD with redux and social logins into a visibility controller, but without the complexity of a finished app.

Last but not least, it’s all combined into a more finished (never truly finished) app called pullmodel, which brings it all together and tests whether these pieces are ready for prime time, in a consumer oriented PWA for both mobile and desktop.

Find it all on github/poly-on-fire

The on-fire part:

There is no pretending, with poly-on-fire, in the sense that you don’t have to wonder how it would actually deploy in real life, with real hosting, on a real phone or desktop with real integration with a db and server side functions.

Because everything deploys immediately onto firebase, and firebase is free for modest usage, you can experiment to your heart’s content with the real deal. The only thing that changes for me when I go into production is that the increased volume will eventually start dinging my credit card.

I won’t even go into how cool this is compared to everything I’ve been through previously, at least not in this blog. Another blog, however, does make the comparison.


The good news: Polymer isn’t a framework in the swiss-army-knife sense that most frameworks mean it.

The bad news: Polymer requires you to build your app piece at a time, with web components.

poly-on-fire is a collection of code repositories that explore how certain pieces might be combined or used together, for assembly into a larger app.

Use Cases:

Business requires more common features than is provided for by the Polymer Starter Kit.

If the feature is common enough to be needed in most any typical business app that I would have to build, but is not provided by the Polymer Starter Kit, this is a typical use case for a poly-on-fire project.

This lets me work out the basic kinks in a sample project, and easily migrate it to a real project when the time comes.

Such as:

  • How to bring in and consume query params?
  • Using Polymer and Redux for state management
  • Using Redux for visibility control (client side form of workflow and/or security)
  • NodeJS for server admin
  • SpringBoot for Firebase DB Admin
  • others

Polymer on Firebase

Polymer is a very small framework for building web components, presumably even into entire applications.

Firebase is an aggregation of hosting and 20 or so other products for deploying and supporting web applications.

Both are fully supported by Google and not necessarily intended to be used together, nor does it appear to be the common use case. But it can be a very keen strategy, for many reasons not clarified here.

Polymer Version 1,2, or 3?

All projects are currently written at Polymer 2 level.

There is an intent to migrate everything to Polymer 3 when it is released, but both schedule and my current lack of Polymer 3 skills mean this probably won’t happen anytime soon.

The Advantage of Entry Level Javascript Skills:

There are three very difficult aspects to learning Polymer, all of which are addressed by poly-on-fire projects.

  1. Polymer requires much more ‘low level’ JS skills than other platforms. Intentionally.
  2. Polymer enthusiasts tend towards advanced, and often don’t even remember what beginning JS coders have to learn.
  3. Poly-on-fire are isolated, fully deployable projects – including hosting code.

I started writing Polymer with no understanding of how javascript, the DOM, or the web component standard even worked. That’s pretty dumb to do, especially for a lifetime coder, but it did give me the chance to learn everything from scratch.

As a consequence, you may find that these projects are a bit easier to learn from, if you’re a coder coming from a non-javascript background.

You can deploy them for free on Firebase, and to a great degree, they should just work.

The Dis-Advantage of Entry Level Javascript Skills:

The veteran JS coder might find some of these projects too fundamental or uninteresting.

I have made an honest effort to learn everything I need to learn before publishing each example project. But that’s a fancy way of saying there may be subtle tricks that a 10 year JavaScript veteran could probably show me, and these projects might wish some of them to be included.

Please feel free to submit pull requests or even just a note to pete@datafundamentals.com, if you see anything missing.

Firebase Assumed:

For decades, we have avoided vertical stacks because lock in can be expensive and technologically limiting.

Firebase is free for low usage, and has excellent enough tech stacks to default to this platform first. It’s weird to hardwire to one vertical stack, but for the specific use-cases of these projects, it’s actually pretty appropriate.

Specifically, these firebase products are used in poly-on-fire, to date.

  • Hosting
  • Realtime Database
  • Cloud Functions
  • Authentication


A more fully featured app with most of the other projects incorporated within is featured in pullModel.

This is a kind of seedbed for learning Polymer, for me. In it, you may discover that Polymer is a pretty powerful app.

With the exception of the workflow model – which took me foreeeeeeever to design and implement, even though it really isn’t very hard or even very much code – pullmodel proved to me that Polymer and Firebase make a pretty dang easy way to build a real PWA.

There are many aspects to PullModel, most noticeably service worker and testing, which are completely ignored to date.

Pullmodel is currently, and will probably always be, an incomplete, work-in-progress.

Autopm is the server side of pullModel, and does event based admin, responding to Realtime Database events.