Tag: Once

Servers: Cool Once Again

There were jokes coming back from the holiday break that JavaScript decided to go all server-side. I think it was rooted in:

  • The Basecamp gang releasing Hotwire, which looks like marketing panache around a combination of technologies. “HTML over the wire,” they say, meaning it makes the server generate and serve HTML, and leaves client-side JavaScript to things only client-side JavaScript can do.
  • The React gang Introducing Zero-Bundle-Size React Server Components, which I believe is the first step of the core project toward server-side anything.

I’m all about some marketing hype, but it’s worth noting that these are just fresh takes on already solid (dare I say old) ideas.

Turbo (“The heart of Hotwire”) is an evolution of Turbolinks, which is a terrifically simple base idea: intercept clicks on internal links. Rather than the browser doing a full page refresh, fetch the contents of the new page, plop it in place, and History.pushState() the URL. Now you’ve got a Single Page App feel, but you didn’t have to build a SPA. That’s mighty convenient if you’ve already built your app in Rails with ERB templates.

But is that actually efficient? Well, it hasn’t been particularly popular so far. The thinking has been that the network is the bottleneck, so let’s send as little as possible over the network. “As little as possible” typically translates into JSON, typically. If you get JSON on the client, now you need a templating system on the client to turn that into usable DOM. With that technique, you’re paying two costs: 1) loading a client-side library 2) data-to-DOM processing. If you sent “HTML over the wire,” you pay neither of those costs (faster), but theoretically are sending beefier payloads across the network (slower), which assumes that HTML is heavier than JSON, which is… questionable.

So… it depends. It depends on how big the payloads are and what is expected to be done with them.

You’d expect the React opinion would be: definitely use the client. But that’s not true with the new preview of server side components. The video is abundantly clear: “rendering” the components on the server is faster, particularly in nested component situations where many of the components are responsible for fetching their own data. So what comes across the network then? Is it DOM-ready HTML? Not here. From a peek at the video, it looks like the network response is some proprietary format that describes a React component. That seems important because it means the client-side JavaScript bundle doesn’t contain that component at all, and state can be passed back and forth. Lauren Tan is also clear in the video: this is kinda SSR but distinct from how something, like Next.js, does SSR today. And the point is to make the Next.js of tomorrow far better.

So: servers. They are just good at doing certain things (says the guy typing into his WordPress blog). There does seem to be some momentum toward doing less on the client, which I think most of us would agree has been taking on a bit much lately, which asset sizes doing nothing but growing and growing.

Let’s push those servers to the edge while we’re at it.

The post Servers: Cool Once Again appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , ,

Click Once, Select All; Click Again, Select Normally

A bonafide CSS trick from Will Boyd!

  1. Force all the content of an element to be selected when clicked with user-select: all;
  2. If you click a second time, let the user select just parts of the text as normal.
  3. Second click? Well, it’s a trick. You’re really using a time-delayed forwards-ending @keyframes animation when the element is in :focus to change it to user-select: text;

Will’s article has a bunch of more useful information and use-cases for user-select.

Direct Link to ArticlePermalink

The post Click Once, Select All; Click Again, Select Normally appeared first on CSS-Tricks.


, , , ,

JavaScript Libraries Are Almost Never Updated Once Installed

Some commentary from Zack Bloom on the Cloudflare Blog, looking at requests to CDNJS for versions of jQuery.

What we don’t see is a decline in our old versions which come close to the volume of growth of new versions when they’re released. In fact the release of 3.4.1, as popular as it quickly becomes, doesn’t change the trend of old version deprecation at all.

Sorta makes sense. We make CDNJS easy to use at CodePen, where people can quickly search for, find, and add libraries like jQuery to Pens. I very much doubt most users are rushing back to their old Pens to update versions when a new jQuery comes out.

And upgrading versions is hard and scary on large sites. I saw an Instagram from someone at Etsy (the photo is private) commemorating their upcoming upgrade off of jQuery 1.8.2, which is eight years old!

Direct Link to ArticlePermalink

The post JavaScript Libraries Are Almost Never Updated Once Installed appeared first on CSS-Tricks.


, , , , , ,

Run useEffect Only Once

React has a built-in hook called useEffect. Hooks are used in function components. The Class component comparison to useEffect are the methods componentDidMount, componentDidUpdate, and componentWillUnmount.

useEffect will run when the component renders, which might be more times than you think. I feel like I’ve had this come up a dozen times in the past few weeks, so it seems worthy of a quick blog post.

import React, { useEffect } from 'react';  function App() {   useEffect(() => {     // Run! Like go get some data from an API.   });    return (     <div>       {/* Do something with data. */}     </div>   ); }

In a totally isolated example like that, it’s likely the useEffect will run only once. But in a more complex app with props flying around and such, it’s certainly not guaranteed. The problem with that is that if you’re doing something like fetching data from an API, you might end up double-fetching which is inefficient and unnecessary.

The trick is that useEffect takes a second parameter.

The second param is an array of variables that the component will check to make sure changed before re-rendering. You could put whatever bits of props and state you want in here to check against.

Or, put nothing:

import React, { useEffect } from 'react';  function App() {   useEffect(() => {     // Run! Like go get some data from an API.   }, []);    return (     <div>       {/* Do something with data. */}     </div>   ); }

That will ensure the useEffect only runs once.

Note from the docs:

If you use this optimization, make sure the array includes all values from the component scope (such as props and state) that change over time and that are used by the effect. Otherwise, your code will reference stale values from previous renders.

The post Run useEffect Only Once appeared first on CSS-Tricks.


, ,