RSC is indeed very cool. It also serves as a superior serialization format compared to JSON. For example, it can roundtrip basic types such as `Date` and `Map` with no extra effort.

One thing I would like to see more focus on in React is returning components from server functions. Right now, using server functions for data fetching is discouraged, but I think it has some compelling use cases. It is especially useful when you have components that need to fetch data dynamically, but you don't want the fetch / data tied to the URL, as it would be with a typical server component. For example, when fetching suggestions for a typeahead text input.

(Self-promotion) I prototyped an API for consuming such components in an idiomatic way: https://github.com/jonathanhefner/next-remote-components. You can see a demo: https://next-remote-components.vercel.app/.

To prove the idea is viable beyond Next.js, I also ported it to the Waku framework (https://github.com/jonathanhefner/twofold-remote-components) and the Twofold framework (https://github.com/jonathanhefner/twofold-remote-components).

I would love to see something like it integrated into React proper.

I have also found that Next.js is shockingly slow.

I recently added some benchmarks to the TechEmpower Web Framework Benchmarks suite, and Next.js ranked near dead last, even for simple JSON API endpoint (i.e. no React SSR involved): https://www.techempower.com/benchmarks/#section=data-r23&hw=...

I discussed it with a couple of Next.js maintainers (https://github.com/vercel/next.js/discussions/75930), and they indicated that it's only a problem for "standalone" deployments (i.e. not on Vercel). However, I'm not entirely convinced that is true. I wonder if there are major optimizations that could be made to, for example, the routing system.

I have no particular views on performance but the thing i keep hearing about next of 'this is solved by using one particular hosting provider' really surprises me as something people are ok with.

kind of like the AWS tools only really work if you use them with Amazon Web Services...

I think people reasonably expect, say, an aws lambda to be aws specific.

That's a very different story to React, which is supposed to be a library for general application ui development, and the official react documentation recommending Next as the way to use it.

https://react.dev/learn/creating-a-react-app

I've been using React on and off since 2017 or so. Back in the day it was typical to bundle your React code and integrate it with the backend framework of your choice. It was stable and cheap. In the 2020s frontend tech took a bizarre turn...

Going through the GitHub discussion is eye-opening given that CEO of Vercel just publicly stated that Next.js is an API framework: https://x.com/rauchg/status/1895599156724711665

Is he wrong though? Next.js reason of existence is essentially that .json file navigation. The addition of server side compute (ie: middlewares, router, etc...) is mostly a business decision that the framework has nothing to do with as it breaks your back-end/front-end separation (unless your application is very simple to fit in a nextjs function).

> and they indicated that it's only a problem for "standalone" deployments (i.e. not on Vercel)

The fix is clearly to take out your wallet /not.

NextJs is slow. It doesn't have to be. For their swc, turborepo and everything else going on they could have made the actual production usage fast just as well.

Agreed! There is a proposal for something like that in the WHATWG repo: https://github.com/whatwg/html/issues/8538

I would bet at least one person at Meta wanted to call it Llamapalooza.

In any case, I'm excited!

JavaScript is dead. Long live YavaScript.

JS, ECMAScript.

Upcoming in Rails 7.1, you can specify a custom compressor for your cache, out of the box. See the `:compressor` option of `ActiveSupport::Cache::Store.new`:

https://api.rubyonrails.org/v7.1/classes/ActiveSupport/Cache...

Thanks for this. Will likely defer until this lands, but looking forward to trying out Brotli and Zstd for this use case!

Thanks, I wasn't sure when it will be live. I'll update the post to reflect it.

Very cool bot! I was looking for that kind of bot a few months ago, but I couldn't find one that was still maintained, so I created my own[1]. But if you're going to continue maintaining yours (despite the FB debacle), I may just use yours instead.

[1] https://github.com/jonathanhefner/verba-sequentur

I created a gem which wraps all this up in a nice API: https://github.com/jonathanhefner/talent_scout

So the final code from the article would look like:

  class ProductSearch < TalentScout::ModelSearch
    criteria(:search) { |search| where("title ILIKE '%?%'", search) }

    criteria(:from_price) { |from_price| where("price > ?", from_price) }

    criteria(:to_price) { |to_price| where("price < ?", to_price) }

    criteria(:properties) { |properties| joins(:product_properties).where(property_id: properties) }

    criteria(:category_id) { |category_id| where(category_id: category_id) }

    order :price, default: :desc
  end

Brevity is an obvious benefit, but reliability even more so. For example, the code in the article has at least two major mistakes:

1) `from_price` will silently never be applied

2) `sort_type` and `sort_direction` defaults are mixed up and always nil, either of which will raise an exception, but only when the corresponding request params are omitted

Another benefit of using the gem: instances of the `ProductSearch` class from above can be used with the stock Rails form builder (i.e. `form_for` and `form_with model:`).

I agree with most of the points regarding user experience. But I loathe infinite scrolling, and so strongly disagree that Facebook "got it right." I think "geared pagination" with a sprinkle of Ajax works well though, in lieu of infinite scrolling.

Here's an example, assuming there are 200 rows in total:

- User visits page; first 10 rows are listed.

- User clicks "More" link; next 20 rows are fetched via Ajax and appended to the list (30 total).

- User clicks "More" link again; next 30 rows are fetched via Ajax and appended to the list (60 total).

- User clicks "More" link again; browser navigates to the next 60 rows (rows #61-120).

- User clicks "More" link again; browser navigates to the next 60 rows (rows #121-180).

- User clicks "More" link again; browser navigates to the final 20 rows (rows #181-200).

The basic idea is that there are two typical use cases: 1) The user expects their desired row to appear in the first few dozen rows, and will change their query if it doesn't (as mentioned in the article). 2) Or, the user really does want to sift through all the rows, in which case it's preferable to do it in large steps.

Of course, the Ajax fetch increments can be tuned to best support these cases, as well as the number of Ajax fetches before triggering a full page transition.

I actually wrote a Rails gem that encapsulates this behavior, including robust handling of back-and-forth navigation: https://github.com/jonathanhefner/moar

Disappointing... still no support for HTML5 date and time input types. Safari seems to be the last major hold out[0] keeping JavaScript-powered date pickers a (prudent) necessity.

[0]: https://caniuse.com/#feat=input-datetime

Those native interfaces look so dull and out of place when having other input 'helpers' such as better 'select' with bootstrap themes, that I don't even consider them as existent and other third party date pickers are going to be around for quite a while.

Input type 'number' also gives you weird step helper which most of the time is unnecessary and there isn't even a simple way to disable it.

Somehow HTML stopped innovating for so long, the latest revision (HTML5) is just mostly fixing what sucked with HTML4 and adding stuff other third parties already did better.

Those JS pickers are going to be needed for a long time still, because native widgets are a nightmare to style consistently. Apparently nothing has been learned from the <select> styling minefield of the past.

I don't think that everyone should be able to edit the style of native elements. I prefer a consistent behavior, and the select itself works fine everywhere for example.

But i sadly agree, JS stuff is going to be needed for a long time.

There are good arguments for styling native elements and against them. I don't think this is specific to the web, cross-platform GUI toolkits have had this challenge forever.

The current datepickers on the desktop are "consistent in the same browser across many sites". There is no native solution for "consistent in the same site across browsers", which makes a lot of designers and PHBs upset, doesn't always fit the overall look of the site, and makes it harder for developers because each browser brings its own quirks with formatting, localization, validation, etc.