As the about page suggests, I'm going to write as I learn web components on this little blog here. As of today, I don't really know much, but I'm definitely excited.
I see web components as a major opportunity for the web platform as a whole. Yes, there's JavaScript frameworks, which themselves are doing a fantastic job of progressing the platform, but baked in capability to build rich applications seems like a winner to me.
My initial feelings
I've been thinking about web components for a while now. I appreciate how Dave Rupert keeps them in conversation in Shop Talk Show episodes and really felt for him when the HTML imports dream disappeared. With that, my interest also fell off because I thought "what's the point" when Vue seemed to be doing a good job with single file components.
This has all changed though. At Google I/O, Monica Dinculescu gave a really interesting talk, which I think you should watch because it's certainly really inspired me.
I constantly try to reduce weight in what I produce on the web, so this approach really appeals to me. The only thing I'm really not feeling right now is template literals for templating. I'm willing to give it a fair crack though.
I'll kick off my learning with those repositories. Maybe I'll make something really simple to just get a feel of things. I'll write about it here for sure.
I thought the best thing to do to get started is to get a feel for Polymer. Polymer and web components have a strong association and people seem to say good things about it. Also, the talk and repositories that I mentioned in 001 are all based on Polymer.
I found this great little tool that lets you play with Polymer and web components right on the page. This is great because there's no mucking around setting up configs. You're just straight into the code.
Although the examples are pretty basic, I feel like I know what's going on a bit more now, which feels good!
Hey, you look a bit like Vue!
I've gotta say it: this all feels very familiar. I work with Vue every day, so it didn't take long for Polymer to feel very similar in places. This is a good thing because familiarity should carry me through learning more than if I hadn't been working with Vue. I think it'll also help me search for the right sort of things when I get stuck.
I wouldn't say that Vue experience is a pre-requisite though. I'm just feeling like I might find some of the concepts easier to grasp. I've also worked plenty with React and again, this feels similar to some of that stuff too.
Next stop: Shadow DOM
I have a very weak understanding of the shadow DOM. Polymer and web components seem to use it heavily, so I'm going to dive into it to gain some understanding before I continue with Polymer stuff.
I'll write what I find / learn in the next article.
Yeh yeh, I know I said I wanted to look at Shadow DOM in the last post, but I’ve been reading and the “vanilla” web components API looks it could possibly be quite straightforward, so I thought I’d jot down some thoughts.
Keeping things light
I yearn to deliver the lightest possible payload to a browser and going “frameworkless” with JavaScript while using portable, reusable components feels like a dream.
There has to be a trade-off though, right? Efficient re-rendering and that almost magic feeing when a state-driven app just updates itself are very useful things that frameworks give us. Maybe writing and reusing some tiny boilerplate code and base classes is the answer to almost recreating that. Maybe there’s functionality there that I’m yet to learn. It’s exciting not knowing, for sure.
All this again seems relevant to the Shadow DOM, so I’ll stay on course now (I promise). I’m just going to consider wether Polymer as a whole is worth looking at before I get too deep. Maybe I just take parts like the awesome router that I keep going on about instead.
The shadow DOM has always sounded like some sort of superhero to me. I've totally discounted it (wrongly) as a poorly supported bleeding-edge thing, but that's certainly not the case.
While looking around for resources, I found this handy post by Eric Bidelman on the Google Developers site/blog. Instead of regurgitating what I've read, you should go ahead and read it.
The way I see it, the shadow DOM is like an iframe* , but allows a bit more access in either direction. I know that's a pretty crude summary, but I think it's actually a reasonably accurate analogy.
A quick example of what I've learned
I've made a real quick prototype that by default, will render a heading and a paragraph. If everything is supported, I change the colour of the paragraph and also render a button that's clickable.
I can't help but think how useful this will be for rendering components on Astrum, which I help maintain at my day job. I think that the shadow DOM and scoping can help with not just CSS, but also an Astrum component's state which we are aiming to implement after a core application rebuild.
For now, I feel pretty good about this portion of learning. I think the next steps are that I need to make something meatier with web components because I learn best by doing, rather than reading.
Arguably a prerequisite for performant, front-end development, the humble service worker is quite incredible.
With only a few lines of JavaScript, you can create a system that will cache assets and provide your users with a blazing fast site as they browse. As a special bonus, you can provide cached assets by default which allows an "offline first" approach. This means that if a page is in the cache and a user visits while offline, they will get content. Add a fallback "offline.html" (or similar) page and you're granting your users a nice, branded offline experience.
Required reading
I strongly recommend that you read Going Offline by Jeremy Keith. Before his book, I found the concept of service workers quite daunting and convinced myself that it's one of those things that I'll have to set aside a big chunk of time to learn. I got through Jeremy's book in a few hours and felt confident and inspired. This is because he's very good at explaining concepts in a friendly, concise manner.
I can only hope that one day, I'm a tenth as good as he is at teaching.
A crude example
I run an open source project called Boilerform and its website is an ideal candidate to be a guinea pig for my service worker learning. If you go along now, you'll be able to see the service worker in action. It's really basic, but writing it has helped cement the core concepts in my head. You can check out the code here if you want to learn for yourself.
The thought of rolling out an offline-first progressive web app with nothing but native, vanilla browser technologies is exciting, to say the least. I'm geared up to hopefully make that a reality in the near future with my continued learning of web components and the tools that compliment them, such as service workers.
Update 05/05/2017:This recipe resource from Mozilla looks handy for helping to learn various service worker scenarios.
First up, what's a PWA? A PWA is a Progressive Web App. A PWA is essentially a website that behaves like a native app, in essence. I feel that definition will change when the aim of a PWA is no longer to imitate native iOS and Android apps though.
The main benefit of a PWA is that it's delivered on the open web, so we get to use technologies that exist already and that we're comfortable with. We also get the benefit of not having to deploy our app through App Stores, which is great for inclusivity. Lastly, on that point, we get to use URLs for routing, which is where the web has always trumped other options.
For me, web components and PWAs are almost synonymous with each other. In my mind, if I'm going to build any sort of app with web components, it'll be following some the standards of a PWA, even if that's just creating a cached and/or offline experience with service workers.
But, there are rules
To qualify as a proper PWA, rules and standards still need to be followed. I imagine that this is mainly to maintain a level of quality in the ecosystem, which I'm personally all for. There's a handy checklist by Google that outlines the standard that your app needs to meet. In return, your app is installable on a user's device and on some platforms, will appear in app stores.
It's worth mentioning that there's a really useful tool for testing this stuff called Lighthouse (Google), which is already baked into Chrome.
A useful podcast
The main reason I'm jotting this all down is that I listened to a very handy episode of Syntax by Wes Bos and Scott Tolinski, where they go through that checklist and give more detail with their considerable joint expertise.
You should definitely check it out if like me, you're learning this sort of thing.
One of the first things that was a concern for me with web components was state management, or rather, a lack-of it. Managing state in a trivial manner is something I've become almost reliant on with the React and Vue work that I do and the thought of going back to DOM based state management was not even an option.
I'd been mulling around with some ideas, but I noted down that Redux works in a vanilla stack well, so I'd just go with that.
After some more thought though, I tweeted this:
I’ve been thinking about super lightweight JS things recently and I think a < 100(ish) line state system is doable.
Obviously no where near as powerful as Redux, MobX or Vuex, but handy for smaller projects.
I’m going to have a play and maybe write some stuff about it.
I took that thinking further and created a prototype, which I sent to Chris Coyier from CSS-Tricks to see if he would publish a new tutorial about how to write a state management system from scratch. That got published and went down really well with folks. This, along with this system's successful use on mybrowser.fyi, which was my first proper project with web components (I'll make some notes on that in another article), made me think that others could benefit from a more "plug and play" version, so I made Beedle.
Making an open source library
I'm not overly strong with open source stuff, so I was nervous. The approach I took was to put together some really quick prototypes that would need state management and then refactor the existing system from mybrowser.fyi until it became self sufficient and useful for those prototypes.
I then documented the library up, wrote some tests and put it all out there. Hopefully it'll help some folks out — not just vanilla JavaScript fans, but also folks using React and Vue et. al.
Long-term concerns
I've enjoyed working with ES6 Modules, so creating and subsequently relying on an npm package is a concern now. There might well be a way to get the best of both worlds that I'm not aware of yet. It's something to add to the very long list of things to learn about. I'm also not averse to working with a lightweight bundler, like I made for Beedle.
I am happy that I can managed state with a dependecy that's less than 1kb when compressed 🙂
