Dev News: Deno Decorates, Pre-Rendering Added to Nuxt, Astro

The Deno team released Deno v. 1.40 this week, calling it a “significant step forward in the evolution” of the JavaScript and TypeScript runtime.

“This new version is packed with features that enhance the Deno experience, introducing the powerful Temporal API for advanced date and time operations, and embracing the latest decorator syntax for more expressive code,” the team wrote. “Alongside these advancements, we’ve implemented a series of deprecations, stabilizations, and removals aimed at streamlining Deno’s capabilities and preparing for Deno 2.”

The temporal proposal calls for a new API aimed at standardizing date and time handling in JavaScript.

Deno also now supports decorators, which are called for in a proposal for TC39. They are also being implemented in all browsers, the team wrote.

Decorators allow developers to add functionality without modifying the existing code, via what’s basically a wrapper that changes the function of whatever it “decorates.” You can use decorators to add functionality, modify behavior, validate data or support lazy loading. Babel and TypeScript already support decorators.

“Decorators are a proposal for extending JavaScript classes which is widely adopted among developers in transpiler environments, with broad interest in standardization,” they explained. “TC39 has been iterating on decorators’ proposals for over five years. This document describes a new proposal for decorators based on elements from all past proposals.”

Astro 4.2 and 4.3 Releases

JavaScript framework Astro 4.3 was released Thursday, with more control over the HTML file output. It does this by adding a new build.format option called preserve. The new format preserves how the filesystem is structured and makes sure that it is mirrored to production.

”This feature unlocks better compatibility with certain web servers [that] have strict requirements on how files are structured,” the team noted.

The update also added a new ComponentProps type export that’s similar to React.ComponentProps or Svelte’s ComponentProps.

“This type of export allows you to reference the Props accepted by another component, even if that component doesn’t export that Props type directly,” the team wrote.

Also, Astro 4.2, released earlier this month, boasts experimental features for users to play with. It marked the first release where all but one of the features were community-built.

“This is a huge milestone for us, as it means that Astro is now big enough to have a thriving community of contributors capable of spearheading releases,” the team wrote.

Astro is a relative newcomer to JavaScript frameworks, and ranked as the most popular framework, as measured by growth in satisfaction and usage, in Netlify’s The State of Web Development report.

Astro 4.2 added support for an experimental feature: Pre-rendering pages using the Chromium Speculation Rules API, which allows developers to pre-render pages on the client and run client-side JavaScript on pages the user is likely to visit next for a faster browsing experience.

The other experimental feature it added is reworked routing priority for injected routes. Interestingly, this actually came about because of a problem. Routes injected using the injectRoute()API were given priority so they were matched before other routes.

“While this seemed like a good idea at the time, it unfortunately caused a lot of hard-to-debug issues where routes wouldn’t be matched as expected,” the team wrote. “Historically, we’ve been hesitant to change this behavior due to how many unintended issues changes to the routing system can cause.”

Luiz Ferraz implemented a fix — and thus began the creation of a “new and improved” default routing system, the team stated.

“With this flag enabled, routes injected using the injectRoute() API, as well as redirects, will now follow the same priority order that routes from the filesystem do. This should provide more stable, consisting priority ordering rules for all your project routes,” the blog stated.

There were also bug fixes, detailed in the release notes.

Nuxt 3.10 Adds aSyncData When Pre-Rendering

Nuxt 3.10 was released this week and it’s “packed with features and fixes,” wrote Daniel Roe, who leads the core Nuxt team.

One update that should improve site performance is experimental share asyncData when pre-rendering, in which Nuxt automatically refetches data for developers when pre-rendering the site.

“Your useAsyncData and useFetch calls will be deduplicated and cached between renders of your site,” explained Roe. “It is particularly important to make sure that any unique key of your data is always resolvable to the same data. For example, if you are using useAsyncData to fetch data related to a particular page, you should provide a key that uniquely matches that data. (useFetch should do this automatically.)”

This update also includes SSR-safe accessible unique ID creation, which supports building more accessible interfaces in an app.

Also included in this update:

• Extended app/router options for custom scrollBehavior or added runtime augmenting of routes;
• Client-side Node.js support, which ”should make life easier for users who are working with libraries without proper browser support,” Roe noted. That said, he added that because of the risk in increasing a bundle unnecessarily, Nuxt “would strongly urge users to choose other alternatives if at all possible.”
• Better cookie reactivity;
• Better detection of antipatterns, which translates into a better ability to identify potential bugs and performance problems;
• Build-time route metadata; and
• Bundler module resolution.

The blog post covers these highlights but the full release notes are on GitHub.