Microsoft is now allowing Windows 11 testers to try out a new, larger Start menu that includes a scrollable interface, new views, and more customizability. An early version of the new Start menu first started showing up in Windows 11 builds in April, followed by Microsoft’s official announcement in May. Today’s Dev Channel release lets you try it out officially for the first time.

“We’re making it easier for you to launch your apps with our updated, scrollable Start menu,” explains the Windows Insider team. This scrollable Start menu means that all apps is now at the top level, so you don’t have to navigate to a second page to find your apps.

You’ll also be able to disable the recommended section so you can see more of your apps, and choose two new views: category and grid. The default category view groups apps by category, and the grid view is ordered alphabetically more like a traditional list view.

Microsoft has also made the Start menu larger based on the screen size of your device or monitor. “On larger devices, users can expect to see 8 columns of pinned apps, 6 recommendations, and 4 columns of categories in the Start menu,” says the Windows Insider team. “On smaller devices, you’ll see 6 columns of pinned apps, 4 recommendations, and 3 columns of categories.”

There’s also a new mobile device button on the Start menu that lets you expand or collapse the Phone Link interface that appears alongside the Start menu. Microsoft is also allowing Windows 11 users to choose what lock screen widgets appear, allowing you to add or remove widgets and rearrange them for the lock screen.

Finally, this latest Dev Channel build also includes a new Gamepad keyboard update that lets you sign into a PC with a PIN code using a controller. This is part of Microsoft’s work to improve Windows 11 on handheld gaming devices like the recently announced ROG Xbox Ally devices.

At Monday's WWDC conference, Apple announced the new macOS Tahoe, which comes with a series of updates related to Apple Intelligence, continuity features with the iPhone, and Spotlight search.

We’re excited to announce a major enhancement for SQL Server Always On Availability Groups Backups on Secondary, in SQL Server 2025.  

Until SQL Server 2022, you could only perform COPY_ONLY full backups and transaction log backups on a secondary replica of an Always On Availability Group. 

This enhancement in SQL Server 2025 allows you to offload all types of backups—full, differential, and transaction logs - to a secondary replica, significantly improving performance, resource utilization, and operational flexibility. 

What Is "Backups on Secondary"? 

Traditionally, backups in an Always On Availability Group were typically performed on the primary replica, which could lead to resource contention and performance degradation for mission-critical workloads. With this update in SQL Server 2025 to the Backups on Secondary feature, you can now configure your environment to perform all backup operations on a designated secondary replica. 

This includes: 

• Full backups 

• Differential backups 

• Transaction log backups 

Key Benefits 

🔄 Reduced Load on Primary Replica 

By offloading backup operations to a secondary replica, you free up CPU, memory, and I/O resources on the primary replica, ensuring that your production workloads run more smoothly and efficiently. 

🧩 Flexible Backup Strategies 

You can now design more flexible and resilient backup strategies by leveraging secondary replicas in different geographic locations or data centers. 

🛡️ Enhanced High Availability and Disaster Recovery 

In the event of a failover, backup operations can continue seamlessly on another secondary replica, ensuring continuous data protection. 

How It Works 

The feature is easy to configure using T-SQL or SQL Server Management Studio (SSMS). There are two steps to make backups run on secondary:

1. Configure backups to run on secondary replica via the AUTOMATED_BACKUP_PREFERENCE and BACKUP_PRIORITY parameters – refer to Configure backups on secondary replicas of an Always On availability group for prerequisites and detailed steps. 
2. Run the T-SQL BACKUP command using one of the tools such as SSMS or SQL Agent jobs or Maintenance plans. 

These are the same steps that have been currently in place for SQL Server 2022 and for prior versions. In the prior versions this configuration only allowed COPY_ONLY and transaction log backups. Now, starting with SQL Server 2025, with the same configuration in place, you can perform FULL, DIFFERENTIAL and T-LOG backups on a secondary replica and truly offload the backup overhead on to the secondary replica. 

You can also query system views like sys.dm_hadr_backup_is_preferred_replica to programmatically determine the preferred replica for backups. 

Final Thoughts 

The Backups on Secondary feature is a game-changer for organizations looking to optimize their SQL Server environments for performance, availability, and cost. Whether you're managing a large-scale enterprise deployment or a hybrid cloud setup, this feature gives you the flexibility and control you need to build a more efficient and resilient data platform. 

This feature is available in SQL Server 2025 CTP 2.0. You can download it and try it out today.  

 

---

You can use arbitrary JavaScript in front matter in Eleventy project files (via the js type).

Historically Eleventy has made use of the node-retrieve-globals package to accomplish this, which was a nightmarish conglomeration of a few different Node.js approaches (each with different advantages and drawbacks).

Related research: Dynamic Script Evaluation in JavaScript

The biggest drawbacks to node-retrieve-globals include:

• CommonJS code only (even in a require(esm) world). While dynamic import() works, import and export do not. Top level await is emulated typically by wrapping your code with an async function wrapper.
• It uses Node.js only approaches not viable as Eleventy works to deliver a library that is browser-friendly.

Regardless, this abomination was a necessary evil due to the experimental status of Node.js’ vm.Module (since Node v12, ~2019), the ESM-friendly partner to CommonJS-compatible vm.Script. I’d still love to see vm.Module achieve a level of stability, but I digress.

New Best Friend is import()

Moving forward, I’ve been having success from a much lighter approach using import(), described in Evaluating JavaScript code via import() by Dr. Axel Rauschmayer. It looks something like this:

let code = `export default function() {}`;
let u = `data:text/javascript;charset=utf-8,${encodeURIComponent(code)}`;
let mod = await import(u);

Newer runtimes with Blob support might look like this (example from David Bushell):

let code = `export default function() {}`;
let blob = new Blob([code], {type: "text/javascript"});
let u = URL.createObjectURL(blob);
let mod = await import(u);
URL.revokeObjectURL(u);

Limitations

1. Importing a Blob of code does not work in Node.js (as of v24), despite Node having support for Blob in v18 and newer.

   Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. Received protocol 'blob:'

2. import.meta.url just points to the parent data: or blob:, which isn’t super helpful in script.
3. No import of relative references, even if you’ve mapped it to a full path via an Import Map.
   • e.g. import './relative.js'

     TypeError: Failed to resolve module specifier ./relative.js: Invalid relative url or base scheme isn't hierarchical.

4. No import of bare references. These can be remapped via Import Maps.
   • e.g. import 'barename'

     TypeError: Failed to resolve module specifier "barename". Relative references must start with either "/", "./", or "../".

Though interestingly, Node.js will let you import builtins e.g. import 'node:fs'.

Enter import-module-string

I’ve worked around the above limitations and packaged this code up into import-module-string, a package that could be described as a super lightweight runtime-independent (server or client) JavaScript bundler.

• import-module-string on GitHub
• import-module-string on npm

I was able to repurpose a package I created in June 2022 to help here: esm-import-transformer recursively preprocesses and transform imports to remap them to Blob URLs (falling back to data: when a feature test determines Blob doesn’t work).

import { importFromString } from "import-module-string";

await importFromString(`import num from "./relative.js";
export const c = num;`);

Where relative.js contains export default 3;, the above code becomes (example from Node.js):

await importFromString(`import num from "data:text/javascript;charset=utf-8,export%20default%203%3B";
export const c = num;`);

Which returns:

{ c: 3 }

This transformation happens recursively for all imports (even imports in imports) with very little ceremony.

When you’ve added a <script type="importmap"> Import Map to your HTML, the script will use import.meta.resolve to use the Import Map when resolving module targets.

Even more features

A few more features for this new package:

• Extremely limited dependency footprint, only 3 dependencies total: acorn, acorn-walk, and esm-import-transformer.
• Multi-runtime: tested with Node (18+), some limited testing in Deno, Chromium, Firefox, and WebKit.
  • This was my first time using Vitest and it worked pretty well! I only hit one snag trying to test import.meta.resolve.
• Supports top-level async/await (as expected in ES modules)
• If you use export, the package uses your exports to determine what it returns. If there is no export in play, it implicitly exports all globals (via var, let, const, function, Array or Object destructuring assignment, import specifiers, etc), emulating the behavior in node-retrieve-globals. You can disable implicit exports using implicitExports: false.
• Emulates import.meta.url when the filePath option is supplied
• addRequire option adds support for require() (this feature is exclusive to server runtimes)
• Supports a data object to pass in your own global variables to the script. These must be JSON.stringify friendly, though this restriction could be relaxed with more serialization options later.
• When running in-browser, each script is subject to URL content size maximums: Chrome 512MB, Safari 2048MB, Firefox 512MB, Firefox prior to v137 32MB.

As always with dynamic script execution, do not use this mechanism to run code that is untrusted (especially when running in-browser on a domain with privileged access to secure information like authentication tokens). Make sure you sandbox appropriately!