Tags: client

24

sparkline

Netflix functions without client-side React, and it’s a good thing - JakeArchibald.com

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.

Why it’s tricky to measure Server-side Rendering performance

A good analysis, but my takeaway was that the article could equally be called Why it’s tricky to measure Client-side Rendering performance. In a nutshell, just looking at metrics can be misleading.

Pre-classified metrics are a good signal for measuring performance. At the end of the day though, they may not properly reflect your site’s performance story. Profile each possibility and give it the eye test.

And it’s always worth bearing this in mind:

The best way to prioritize content by building a static site. Ask yourself if the content needs JavaScript.

Progressively Worse Apps

This article makes a good point about client-rendered pages:

Asynchronously loaded page elements shift click targets, resulting in a usability nightmare.

…but this has nothing, absolutely nothing to do with progressive web apps.

More fuel for the fire of evidence that far too many people think that progressive web apps and single page apps are one and the same.

Is it really safe to start using CSS Grid Layout?

Rachel uncovers a great phrase for dealing with older browsers:

It isn’t your fault, but it is your problem.

She points to multiple ways of using CSS Grid today while still providing a decent experience for older browsers.

Crucially, there’s one message that hasn’t changed in fifteen years:

Websites do not need to look the same in every browser.

It’s crazy that there are still designers and developers who haven’t internalised this. And before anyone starts claiming that the problem is with the clients and the bosses, Rachel has plenty of advice for talking with them too.

Your job is to learn about new things, and advise your client or your boss in the best way to achieve their business goals through your use of the available technology. You can only do that if you have learned about the new things. You can then advise them which compromises are worth making.

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!

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.

Introduction to Ember FastBoot by Tom Dale on Vimeo

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.

Introduction to Ember FastBoot by Tom Dale

JavaScript web apps considered valuable · molily

A response to a rant I linked to recently.

The solution for bad JavaScript web apps is not to abandon them altogether, but to make better ones.

I couldn’t agree more. The tools have evolved and we now have frameworks and practices that allow us to render from the server and use the same code to render on the client, progressively enhancing from a solid robust base.

JavaScript is the best technology to build excellent interactivity in the browser. Still, the most important skill of a client-side JavaScript developer is to know when not to solve a problem with client-side JavaScript. It’s always more robust to solve a problem further down in the stack.

The problem is that I don’t see a willingness from developers to embrace this way of thinking. Instead I see it dismissed as being unrealistic or more expensive.

Still, it always takes time for behaviour to change so maybe things will only get better. I certainly hope so.

How the Web Works: A Primer for Newcomers to Web Development (or anyone, really) by Preethi Kasireddy

This is a great reminder of the fundamental nuts’n’bolts of the internet and the World Wide Web: clients, servers, URLs, DNS, HTTP, TCP/IP, packet switching, and all the other building blocks we sometimes take for granted.

This is part one of a four-part series:

  1. A Primer for Newcomers to Web Development (or anyone, really)
  2. Client-Server Model & the Structure of a Web Application
  3. HTTP & REST
  4. Stay tuned…

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.)

being a client (tecznotes)

Mike writes about what it was like being a client for a change. After working with him on the Code for America project, I can personally vouch for him as a dream client:

Clearleft’s pattern deliverables are the special-special that made the final work so strong. Jon Aizlewood’s introduction to the concept convinced me to contact Clearleft. Jeremy Keith’s interest in design systems kicked off the process, and Anna Debenham’s fucking rock star delivery brought it all home.

Quietweet - A Simpler Twitter Reader

A cute little read-only Twitter client from James that only displays fully-formed tweets: no hashtags, no @-replies.

For discussion: viewport and font-size data in client hints

The “client hints” proposal looks really interesting: a way for user-agents to send data to the server without requiring the server to have a library of user-agent strings. But Scott has a few concerns about some of the details.

“The Post-PSD Era: A problem of expectations,” an article by Dan Mall

I really like Dan’s take on using Photoshop (or Fireworks) as part of today’s web design process. The problem is not with the tool; the problem is with the expectations set by showing comps to clients.

By default, presenting a full comp says to your client, “This is how everyone will see your site.” In our multi-device world, we’re quickly moving towards, “This is how some people will see your site,” but we’re not doing a great job of communicating that.

Client/Agency Engagement is F*cked, Waterfall UX Design is a Symptom | disambiguity

Leisa nails it. The real stumbling block with trying to change the waterfall-esque nature of agency work (of which Clearleft has certainly been guilty) can be summed up in two words: sign off.

And from a client’s perspective, this emphasis on sign-off is completely understandable.

It takes a special kind of client to take the risk and develop the level of trust and integration required to work the way that Mr Popoff-Walker any many, many other inhabitants of agency world would like to work.

Good Kickoff Meetings

The companion website to Kevin Hoffman's IA Summit talk, this is a hugely valuable resource for an often-overlooked part of the design process: the kick-off meeting.

How a Web Design Goes Straight to Hell - The Oatmeal

I don't know whether to laugh or cry.

"It's like twitter. Except we charge people to use it."

This is just wonderful. "Please design a logo for me. With pie charts. For free."