Node.js 23 was released on Wednesday, and Node.js 22 will be promoted to long-term support the week of Oct. 29. That means it will enter long-term maintenance to ensure stable and secure updates, the Node team wrote in an OpenJS community blog post about Node.js 23.
The highlights of this release include:
- Support for loading native ES modules using require(). Previously, this was enabled through —experimental-require-module;
- Stabilized –run Command, which has been stabilized for more efficient script execution; and
- Test Runner Enhancements, specifically test runner, now supports glob patterns for coverage files, improving test configuration.
This release also drops support for 32-bit Windows. The team wants to focus on more modern environments, according to the blog post.
For those who need a refresher on the Node release number strategy, the team wrote that odd-numbered versions like Node.js 23 “are great for early feature testing for your own specific environment.” They are not, however, promoted to long-term support (LTS).
“Even-numbered releases like the current Node.js 22, once LTS, are focused on creating stability and security and are supported for 30 months,” the blog post added.
Rust 1.82.0 Released Thursday
Rust 1.82.0 is available as of Thursday. It includes a slew of API updates, all listed on the blog. It also offers as stable some new features, including:
- The Cargo info subcommand, which displays information about a package in the registry;
- Apple target promotions, which means macOS on 64-bit ARM is now Tier 1 and Mac Catalyst targets are now Tier 2. Mac Catalyst allows running iOS applications natively on the Mac;
- Precise capturing use<..> syntax. “Rust now supports use<..> syntax within certain impl Trait bounds to control which generic lifetime parameters are captured,” the blog post explained;
- Native syntax for creating a raw pointer. “A pointer is more than just an address, so Rust is moving away from terms like ‘address-of’ that reaffirm a false equivalence of pointers and addresses”;
- Safe items with unsafe extern. “We’ve decided that it’s the responsibility of the person writing the extern block to ensure that all signatures contained within it are correct, and so we now allow writing unsafe extern,” the team explained.
- Unsafe attributes. “Some Rust attributes, such as no_mangle, can be used to cause undefined behavior without any unsafe block,” the team wrote. “If this were regular code we would require them to be placed in an unsafe {} block, but so far attributes have not had comparable syntax. To reflect the fact that these attributes can undermine Rust’s safety guarantees, they are now considered ‘unsafe’…”;
- Omitting empty types in pattern matching;
- Floating-point NaN semantics and const. “With this release, Rust standardizes on a set of rules for how NaN values behave,” the team noted. The blog post also linked to the NaN bit patterns documentation;
- Constants as assembly immediates. “The const assembly operand now provides a way to use integers as immediate, without firs storing them in a registry.”
How States Rank on Voter Site Accessibility
Frontend developers are often responsible for ensuring websites meet accessibility standards. But alas, there are still sites that don’t comply.
A recent survey by software testing platform QAwerk found that 83% of U.S. websites offer the option for online voter registration — but of those, only 35% have a high web accessibility index. Forty-two percent rated a medium web accessibility index and 23% rated a low web accessibility index.
North Carolina’s DMV website offered the highest level of web accessibility and scored 14 points out of 15 used in the survey. The only point deducted was for errors in the HTML code, the study noted.
You can see how your site ranked by going to the survey link above. The study explains its methodology, but for those interested in improving your own site accessibility, it ranked the sites measured using criteria based on WCAG 2.2 guidelines and the company’s own experience with accessibility testing for e-government solutions. Those criteria were:
- Adaptive Design. Determines whether the content/functionality is accessible on different devices and screen sizes.
- Screen Reader Compatibility. Evaluates whether the site can be presented through a screen reader without losing any information or structure.
- Autocomplete for Forms. For text input elements, the autocomplete attribute should be in place to let the user know what kind of data is expected to be entered.
- Clear Error Messages: Input errors are clearly marked and described to the user.
- Labeled Input Fields: Items requiring user input are clearly labeled or have clear instructions.
- Predictable UI Changes: Changing the settings of a checkbox, radio button, or other UI component does not trigger unexpected changes in context, such as causing significant changes to the page content or opening a new window.
- Use of Color: Color is not used as the only visual means of conveying info.
- High-Contrast Text: Text has enough contrast with the background (the contrast ratio should be 4:5:1 for small text and 3:1 for large text).
- Zoomable Content: The website can be zoomed in without losing any information or structure.
- Keyboard Navigation: All functionality is available from a keyboard, except for tasks such as drawing.
- Focus and Action Control: When a UI component receives focus, this does not trigger unexpected actions such as automatically submitting a form, opening a new window, or switching focus to another element.
- Descriptive Page Title: The page has a title describing its topic or purpose.
- Link Purpose: The purpose of each link can be determined from the link text or context.
- Defined Page Language: The language of the web page (e.g., English) is specified in the code.
- Valid HTML Code: There are no errors in the HTML and no duplicate element IDs.
