A nice straightforward introduction to web development for anyone starting from scratch.
The transcript of a really great—and entertaining—talk on performance by Wilto. I may have laughed out loud at points.
The texture here is shockingly realistic.
Really good advice for anyone thinking of releasing a polyfill into the world.
Phil describes the process of implementing the holy grail of web architecture (which perhaps isn’t as difficult as everyone seems to think it is):
I have been experimenting with something that seemed obvious to me for a while. A web development model which gives a pre-rendered, ready-to-consume, straight-into-the-eyeballs web page at every URL of a site. One which, once loaded, then behaves like a client-side, single page app.
Now that’s resilient web design!
promises address?” but that is then addressed further down:
Fair enough. In any case, what you’ll find here is mainly good advice for writing modular code.
The text detection API is still in its experimental stage, but it opens up a lot of really interesting possibilities for the web: assistive technology to read out text, archiving tools for digitising text …it’s all part of the nascent shape detection API.
A great little script from Una that’s perfect for blogs and news sites—allowing users to explicitly save a page for offline reading.
A nice and clear description of how browsers parse and render web pages.
Ever been on one of those websites that doesn’t allow you to paste into the password field? Frustrating, isn’t it? (Especially if you use a password manager.)
It turns out that nobody knows how this ever started. It’s like a cargo cult without any cargo.
So if AMP is useful it’s because it raises the stakes. If we (news developers) don’t figure out faster ways to load our pages for readers, then we’re going to lose a lot of magic.
A number of developers answered questions on the potential effects of Google’s AMP project. This answer resonates a lot with my own feelings:
AMP is basically web performance best practices dressed up as a file format. That’s a very clever solution to what is, at heart, a cultural problem: when management (in one form or another) comes to the CMS team at a news organization and asks to add more junk to the site, saying “we can’t do that because AMP” is a much more powerful argument than trying to explain why a pop-over “Like us on Facebook!” modal is driving our readers to drink.
But the danger is that AMP turns into a long-term “solution” instead of a stop-gap:
So in a sense, the best possible outcome is that AMP is disruptive enough to shake the boardroom into understanding the importance of performance in platform decisions (and making the hard business decisions this demands), but that developers are allowed to implement those decisions in standard HTML instead of adding yet another delivery format to their export pipeline.
The ideal situation looks a lot more like Tim’s proposal:
Behind the amusing banter there’s some really solid performance advice in here. Good stuff.
Client Side Rendering (CSR), or as I call it “setting money on fire and throwing it in a river” has its uses, but for this site would have been madness.
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.
This philosophy doesn’t apply to every website out there, but it sure as hell applies to a lot of them.