Push notifications explained using astrology. But don’t worry, there’s also some code, just in case you prefer your explanations to also include models that actually work.
It is very disheartening to read misinformation like this:
A progressive web app is an enhanced version of a Single Page App (SPA) with a native app feel.
To quote from The Last Jedi, “Impressive. Everything you just said in that sentence is wrong.”
But once you get over that bit of misinformation at the start, the rest of this article is a good run-down of planning and building a progressive web app using one possible architectural choice—the app shell model. Other choices are available.
Brendan shows how he uses IFTTT and a webhook to post to his own site from Instagram. I think I might set up something similar to post from Untappd to my own site.
This post goes into specifics on Django, but the broader points apply no matter what your tech stack. I’m relieved to find out that The Session is using the tripartite identity pattern (although Huffduffer, alas, isn’t):
What we really want in terms of identifying users is some combination of:
- System-level identifier, suitable for use as a target of foreign keys in our database
- Login identifier, suitable for use in performing a credential check
- Public identity, suitable for displaying to other users
Many systems ask the username to fulfill all three of these roles, which is probably wrong.
Chris has set up a whole site dedicated to someone-else’s-server sites with links to resources and services (APIs), along with ideas of what you could build in this way.
A great bucketload of common sense from Jake:
Rather than copying bad examples from the history of native apps, where everything is delivered in one big lump, we should be doing a little with a little, then getting a little more and doing a little more, repeating until complete. Think about the things users are going to do when they first arrive, and deliver that. Especially consider those most-likely to arrive with empty caches.
And here’s a good way of thinking about that:
I’m a fan of progressive enhancement as it puts you in this mindset. Continually do as much as you can with what you’ve got.
All too often, saying “use the right tool for the job” is interpreted as “don’t use that tool!” but as Jake reminds us, the sign of a really good tool is its ability to adapt instead of demanding rigid usage:
Netflix uses React on the client and server, but they identified that the client-side portion wasn’t needed for the first interaction, so they leaned on what the browser can already do, and deferred client-side React. The story isn’t that they’re abandoning React, it’s that they’re able to defer it on the client until it’s was needed. React folks should be championing this as a feature.
Ooh, this is a tricky scenario. If you decide to redirect all URLs (from, say, a
www subdomain to no subdomain) and you have a service worker running, you’re going to have a bad time. But there’s a solution here to get the service worker to remove itself.
The server-side specifics are for NGINX but this is also doable with Apache.
In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.
This blog post saved my ass—the Huffduffer server was b0rked and after much Duck-Duck-Going I found the answer here.
I’m filing this away for my future self because, as per Murphy’s Law, I’m pretty sure I’ll be needing this again at some point
Speaking as an ancient web developer myself, this account by Gina of her journey into Node.js is really insightful. But I can’t help but get exhausted just contemplating the yak-shaving involved in the tooling set-up:
The sheer number of tools and plugins and packages and dependencies and editor setup and build configurations required to do it “the right way” is enough to stall you before you even get started.
An open beta of Smashing Magazine’s redesign, which looks like it could be a real poster child for progressive enhancement:
Remy wants to be able to apply progressive enhancement to React: server-side and client-side rendering, sharing the same codebase. He succeeded, but…
In my opinion, an individual or a team starting out, or without the will, aren’t going to use progressive enhancement in their approach to applying server side rendering to a React app. I don’t believe this is by choice, I think it’s simply because React lends itself so strongly to client-side, that I can see how it’s easy to oversee how you could start on the server and progressive enhance upwards to a rich client side experience.
I’m hopeful that future iterations of React will make this a smoother option.
Bookmark this page! Who knew that so much knowledge could be condensed into one document? In this case, it’s life-saving
git commands, explained in a user-centred way.
So here are some bad situations I’ve gotten myself into, and how I eventually got myself out of them in plain english.
This looks like it could be a very nifty tool to have at your disposal while coding. I like that it’s editor-agnostic.
I’m so happy that Ember is moving to a server-side rendering model. Not only that, but as Tom points out here, it’s crucial that the server-side rendering is the default and the client-side functionality than becomes an enhancement.
The videos from EnhanceConf are started to go up already. Stefan’s talk really struck me—all the talks were great but this one had the most unexpected insight for me. It really clarifies a lot of ideas that I’ve been trying to articulate, but which Stefan crystalises by taking the long-zoom view.
I don’t agree with the conclusion of this post:
But I think the author definitely taps into a real issue:
The real problem is the perception that any code running in the browser is front-end code.
This is something we’re running into at Clearleft: we’ve never done backend programming (by choice), but it gets confusing if a client wants us to create something in Angular or Ember, “because that’s front end code, right?”
The difference between back-enders and front-enders is that the first work in only one environment, while the second have to work with myriad of environments that may hold unpleasant surprises.