David Mulder's temporary corner on the intertubes...

Just a quick pointer I often notice people don’t know about on the Polymer slack group (or know about it but don’t understand it): It’s possible to share information between all elements of a certain type. This can be both great for performance (retrieving information only once instead of once for every element) and usability (once any <auth-api> element in my application finishes authentication all the other elements on the page can use the same token). Note: This post is going to be a bit more verbose and NOT to the point, just to cover some extra ground which might seem irrelevant to most of you O:) . What are HTML imports Let’s start with HTML imports, Eric Bidelman introduces them in one of his blogposts as the magic solution that’s supposed to make embedding HTML easy. The reason I am bringing them up is that understanding what they are and aren’t for and what they exactly do will make everything a whole lot easier to comprehend (and I just want to acknowledge it’

Already touched upon this topic in my HTTP/2 write-up (don’t do this without setting up HTTP/2 first), but although I did initial testing back then only got back to it seriously yesterday. So, let met give some very quick instructions on how to get it working in PSK, though likely it will be similar in any other Polymer application. <page-*> elements Start of with making every page an element. In my case these elements are called <page-*> elements, so your index.html looks something like: <iron-pages attr-for-selected="data-route" selected="{{route}}"> <page-welcome data-route="home"></page-welcome> [...] </iron-pages> It’s possible to set this up in different ways as well, but this is the best way I have found so far to organize my application in Polymer. Lazy loading them My approach is to trigger the loading of the elements from the router. This might be somewhat debatable from a logical poi

I still owe you guys two more posts about Letsencrypt and Service Workers, but let me just share a short article about my struggle getting Recaptcha working in the Shadow DOM… and a crazy solution how to get such components working none the less. You can’t use the standard <div class="g-recaptcha"></div> , because Googles script simply won’t see it. You can’t use the standard Javascript API rendering mechanism, because first of all most of the documentation uses it with an id reference (which isn’t going to be found inside the Shadow DOM), but even if you use a direct element reference there (which will actually show the Recaptcha box) we reach the most painful issue: Recaptcha stays stuck on the spinner after clicking the checkbox . And yes, I checked, it’s really the Shadow DOM causing the issue, likely due to some crazy callback to some global or something. So how do we get it to work? By putting it in to the light DOM… which is far easier said than done

Getting HTTP/2 up and running is such a pain that I decided to that I would try sparing the rest of the world some of the pain by sharing the story. Let’s get the basics out of the way first: The biggest advantage of HTTP/2 is that files get interleaved over a single connection, which means in normal language that you can send one thousand one kilobyte sized files for virtually the same cost as one huge concatenated one megabyte file. Practically this thus means you don’t need to have huge complex build steps where you attempt to inline all your dependencies and concatenate the entire thing into one huge file. Want to read up on other advantages then this is the best resource I found. So, in this article we’re going to assume that our intention is to deploy just the Polymer Starter Kit and a simple node backend API. Additionally the goal of implementing HTTP/2 is not about getting marginal speed benefits, but about easing development by making production more like development and si