Tags: rendering



Progressive Progressive Web Apps - Tales of a Developer Advocate by Paul Kinlan

Paul goes into detail describing how he built a progressive web app that’s actually progressive (in the sense of “enhancement”). Most of the stuff about sharing code between server and client goes over my head, but I understood enough to get these points:

  • the “app shell” model is not the only—or even the best—way of building a progressive web app, and
  • always, always, always render from the server first.

The Critical Request | CSS-Tricks

Ben takes us on a journey inside the mind of a browser (Chrome in this case). It’s all about priorities when it comes to the critical path.

Jekyll Includes are Cool - daverupert.com

Dave explains how Jekyll Includes are starting to convert him to web components. The encapsulation is nice and neat. And he answers the inevitable “but why not use React?” question:

Writing HTML that contains JavaScript, not JavaScript that contains HTML, feels good to me.

The key feature for me is that this approach doesn’t have to depend on JavaScript in the browser:

I like that Web Components are an entirely client-side technology but can be rendered server-side in existing tech stacks whether it’s Jekyll, Rails, or even some Enterprise Java system.

HN PWA - Hacker News readers as Progressive Web Apps

Of all the sites to pick to demo progressive web apps, we get the cesspit that is Hacker News …I guess it is possible to polish a turd.

Anyway, here are some examples of using frameworks to create alternative Hacker News readers. So the challenge here is to display some text to read..

Four of them render absolutely no content without JavaScript.

In the Hall of Shame we have React, Preact, Angular, and Polymer.

In the Hall of Fame, we have the ones doing it right: React, Vue, and Viper.

That’s right: React appears in both. See, it’s not about the tools; it’s about how you use ‘em.

Need to Catch Up on the AMP Debate? | CSS-Tricks

Funnily enough, I led a brown bag lunch discussion about AMP at work just the other day. A lot of it mirrored Chris’s thoughts here. It’s a complicated situation that has lots of people worried.

Base64 Encoding & Performance, Part 1: What’s Up with Base64?

Harry clearly outlines the performance problems of Base64 encoding images in stylesheets. He’s got a follow-up post with sample data.

Isomorphic rendering on the JAM Stack

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!

Understanding the Critical Rendering Path

A nice and clear description of how browsers parse and render web pages.

Does Google execute JavaScript? | Stephan Boyer

Google may or may not decide to run your JavaScript, and you don’t want your business to depend on its particular inclination of the day. Do server-side/universal/isomorphic rendering just to be safe.

10 things I learned making the fastest site in the world

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.

Server Side React

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.

Progressive Enhancement for JavaScript App Developers | De Voorhoede

Build JS apps responsibly - cover your basics, render strategically and enhance into true apps.

React Isomorphic Demo

It is possible to use React without relying completely on client-side JavaScript to render all your content—though it’s certainly not the default way most tutorials teach React. This ongoing tutorial aims to redress that imbalance.

Besides the main benefit of server rendering giving faster page loads, it also enables large amounts of the site to run without JavaScript. There are many reasons why you would want this, but my personal reasons are that it allows you to completely drop support JavaScript in older browsers, but still have the site function.

Surma.link – New ways to make your web app jank with Houdini – An introduction

This is a really good primer on all the pieces that make up the Houdini approach to CSS—giving authors access to low-level APIs for rendering.

As is often repeated here, it’s still early days and caution is advised, but it’s still a good idea to wrap your head around what’s coming down the standards pipe.

There’s even more specs in Houdini’s list of drafts, but the future of those is rather uncertain and they are not much more than a placeholder for an idea at this point. Examples include custom overflow behaviors, CSS syntax extension API, extension of native scroll behavior and similar ambitious things that allow you to screw up your web app even worse than ever before. Rejoice!

Troubleshooting rendering performance issues - YouTube

Harry packs a lot of great tips and tricks into one short video about performance troubleshooting. It’s also a great lesson in unlocking some handy features in Chrome’s developer tools.

Great stuff!

A look at detecting, pinpointing, measuring, and fixing rendering performance issues.

Supercharging page load (100 Days of Google Dev) - YouTube

A straight-faced Jake talks us through the step-by-step iterations for turning a JavaScript-required web thang into a progressively enhanced zippy experience, supercharged with Service Worker.

Making the case for Progressive Javascript — The Millstone — Medium

I think we can all agree that “isomorphic JavaScript” is a terrible name for a good idea. I quite like calling it “portable JavaScript”, but here’s a good case for calling it “progressive JavaScript.”

(Right up until the end when the author says “But mainly, it’s pretty safe to assume JavaScript will just work. Everywhere.” …which is precisely the kind of unfounded assumption that leads to the very problems that isomorphic/portable/progressive JavaScript can help fix.)

Client-side MVC’s major bug - TimKadlec.com

I’ve said it before: if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples performance.

Stop Breaking the Web

Angry, but true.

Don’t lock yourself into a comprehensive technology that may just die within the next few months and leave you stranded. With progressive enhancement you’ll never go wrong. Progressive enhancement means your code will always work, because you’ll always focus on providing a minimal experience first, and then adding features, functionality, and behavior on top of the content.

Type Rendering Mix

I got excited when Tim Brown announced this at An Event Apart today: a small JavaScript tool for detecting what kind of rasterising and anti-aliasing a browser is using, and adding the appropriate classes to the root element (in much the same way that Web Font Loader does).

Alas, it turns out that it’s reliant on user-agent string sniffing. I guess that’s to be expected: this isn’t something that can be detected directly. Still, it feels a little fragile: whenever you use any user-agent sniffing tool you are entering an arms race that requires you to keep your code constantly updated.