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.
Two years ago I was working with Angular 2 and if you managed to get your compressed javascript payload under 200Kb you thought you were doing pretty well. I remembered about it when I realized I can now have an app with far more functionality and be easily within 15Kb.
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.
In the last post I showed how to use a pure Polymer / WebComponent approach for sharing state between components when they were separated in the DOM.
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.
Redux of course comes from the React world, filled with JavaScript and ES6 imports - so how do you make it all play nicely with Polymer and Html Imports? Of course you could have your store, all the reducers, actions and so on as a set of JavaScript files and introduce a build step to generate the code to then include in your Polymer project but in my experience it’s complex and never feels quite right and you still have to figure out how to integrate the Redux parts with Polymer.
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?
One of the mistakes I saw a lot of when Agile was taking off as “the hot-new thing” was people declaring that they didn’t need to do design anymore. Of course there was no big-upfront design - the kind from the waterfall days where people first analyzed and designed a system in full before punting it to the next team to build (which rarely worked out well) but some planning and design is important, even if you’re just creating a small hobby project.
Part of the process should often involve prototyping to help decide or prove which technologies you’re going to use as these will also factor in to the design of the app. It also gives you an opportunity to kick-the-tires of some technologies if they are things you haven’t used much before prior to building too many things around them. Making late-stage switches can be costly.
This isn’t going to be an exhaustive comparison of every possible client-side framework, storage technology or hosting option. Of course I have some technology choices in my head before I even begin based on my current skillset and experience (isn’t it an amazing coincidence that the “best” technology to build any app with is always the one the developer likes to use?!) But I’ll try to go through the reasoning behind some of the choices I came up with.
This is documenting the journey of creating a “micro startup” software business from inception to realization. It will cover the initial design decisions, the technology choices, implementation challenges through to launch and operation. Along the way I’ll cover some specific technologies and how we used them (e.g. how to do authentication in a Single Page App).
First of all though, what do I mean by “micro startup”? Well, I’m under no illusion that I’ll be building the next Google or creating a whole new market genre. It’s simply a small software-based product or service that isn’t in any huge multi $billion segment but should at least be self-sustaining (i.e. self-funded bootstrapped & covering its costs) but has the potential to bring in some revenue if everything works out and it takes off. It’s really a hobby / side-project done for fun and learning but professionally so that it can be a viable business.
We’re just over a week into the project but have made good progress and already have lots of interesting things to show off and explain which I hope will make interesting reading in the weeks to come.
Firebase is great and makes serverless apps very easy to spin up but there’s always going to be times you need to access the Firebase data and / or user accounts from your server code (e.g. to sync accounts with a legacy system while we move to a Firebase auth enabled client).
There is an Official Admin SDK for Node.js, Java and Python but not all of them support user administration and poor Go doesn’t even get a mention (sad face).
But it turns out, we don’t need an official Firebase SDK for Go to be able to access the database and / or manage user accounts - all the packages to do it are already available and it’s very easy to use.
We all know that Go is extremely fast and very easy to develop with but as with any managed language, it’s easy to inadvertently generate large quantities of garbage. No, I’m not talking about poorly written code (yeah, I’m guilty of that!) but garbage as in “memory that has to be reclaimed”. This is done via Garbage Collection and the GC in Go keeps getting faster with each release but you still want to avoid it when you can.
One common culprit is creating temporary buffers for things like rendering, encoding and compression so an easy fix is to re-use these buffers instead of creating new ones each time. There’s a sync.Pool in the standard library that can be used for this but there is a subtle “gotcha” which I’ll explain.
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.