As President Kennedy implored:
“My fellow developers, ask not what your Framework can do for you. Ask what you can do for your framework!”.
Yeah, I know, not quite the exact quote. But sometimes it feels that you have to do more to help your framework work than your framework does to help you.
Maybe it’s time to ask yourself, what is your Framework really doing for you … and do you still need it?
First of all, let me make clear that I have no inside knowledge and am not privy to any secrets - my views are based purely on using the platform, hanging out in Slack and watching the presentations.
It’s also maybe useful to describe where I “am” as a web developer. I used to use Angular 1 and then 2, never really cared much for React but was aware of it (and like Redux) but was totally sold on WebComponents and the benefits of any framework being built on the platform. When Angular 2 turned out to be a huge letdown and Polymer had turned 1.x it was time to change and I’ve been happy with the choice. I find it quicker to develop apps and I’m spending more time on app-development and much less on endless framework upgrades plus the end results start and run faster.
The Polymer CLI and Polymer Starter Kit are really fantastic tools for quickly bootstrapping your Progressive Web App development - you get a slick PRPL pattern Single Page App complete with Service Worker and lazy-loading views, all with pretty much zero effort. So simple, so easy.
The simplicity of course makes sense for a starter kit but it can mean that exactly how to implement more advanced features may not be obvious and leave you lost. Once your app starts to grow and you decide you need some views to have their own custom toolbar in the app-header or menu options in the app-drawer for instance, or you just want to use a paper-dialog in some part of the UI - how should you do it?
Does the app-shell (
my-app.html) element become cluttered with functionality to pass on toolbar options and state? Is your paper-dialog showing behind the overlay instead of on top of your app and you don’t know why?
As it always seems with web-development, it’s easy to “cobble something together” that seems to work … but isn’t really clean and tidy. Here’s some approaches that I’ve been using.
This works great for discreet isolated pieces of state but as you work with larger and more complex apps there are definite benefits to be had by using something like Redux to centralize things.
To demonstrate how simple a framework is to use and how productive you can be with it, the examples provided are often deliberately simple to fit the easy-use cases. It makes sense to keep things simple for people learning but it can sometimes leave a gap when you need to step beyond the trivial and start building more complex, real-world apps.
One place where this seems to be especially apparent is when it comes to state-management and Polymer is of course no exception. The typical examples you’ll see most often involve a single parent and one or more child elements and some binding between them. But what if things are not so simple? How do you pass state between things? Do you need to start adding Redux to do it?
Here’s a question that comes up a lot in Slack: you have multiple views in your Polymer app and notice that anytime the URL changes, they all respond and try to update, even the ones that are not visible. What’s going on? How do you make a view truly inactive?
If you’ve started your app based on the Polymer Starter Kit then you know it provides a great out-the-box setup complete with PRPL pattern and views as separate elements for lazy-loading.
Everything works great at this early stage because the only routing involved is the top-level switching between views (or fragments), there is no routing within views. Only when you start adding some per-view routing do you run into the issue. Here’s what’s going on and how to fix it.
We’ve all seen and used them, we may even have written some ourselves. They seem such a great idea at the time and using them seems to make life easier. I’m talking about Framework Specific Components.
I want to talk about why WebComponents are much better and they should be the first think we look to use and create whenever possible.
Whether you put ads on a blog to earn a full time income as a blogger or use them to help offset the hosting costs of a community forum, it makes sense to maximize whatever revenue you can from the space you give up to ads.
Many people’s first (and only) experience of generating passive website income with ads is via Adsense and it’s a great system - you add some code snippets to your pages, ads show up to visitors and, if you have sufficient traffic to generate enough views and clicks on them, Google pays you some money each month. If you work hard at SEO to promote your site then it can contribute to the hosting costs or even generate a decent income.
So what if you could generate additional income on top of what Adsense was paying and at the same time, increase what Adsense was paying each month? It almost sounds too good to be true but it isn’t. Here’s how …
If you’re still paying $$$’s for SSL certificates it may be time to look at Let’s Encrypt which describe themselves as “a free, automated and open certificate authority”.
SSL certificates are now effectively free.
Sounds too good to be true? Unless you need some fancy green-bar EV certificate there’s really no need to be paying for SSL certificates anymore. Especially now there is a Go package to support automatic certificate generation.
It turned out to be easier to setup the auto-certificate system than it was to renew a paid-for SSL certificate, here’s how …
Hang out in any front-end web development chatroom for even a short period and you’ll come across the same set of “help me” or “how do it?” questions over and over again. They are not difficult issues once you have learnt about them but until you do and while you are learning frontend development they are often a source of confusion and frustration.
So I thought I’d try and cover a few of the common issues that seem to come up repeatedly …