Some blog tweaks

packages/lit-dev-content/site/blog/2024-10-08-signals.md

@@ -11,17 +11,20 @@ author:
 # Announcing @lit-labs/signals: Integrating the TC39 Signals Proposal with Lit
 
 We’re thrilled to announce the release of our newest Lit Labs package,
-`@lit-labs/signals`, which integrates the
+[`@lit-labs/signals`](https://www.npmjs.com/package/@lit-labs/signals), which integrates the
 [polyfill](https://github.com/proposal-signals/signal-polyfill) for the
 exciting new [TC39 Signals Proposal](https://github.com/tc39/proposal-signals)
 directly with Lit. This package provides a powerful, reactive way to manage
 state in your web applications by allowing you to use shared, observable
 signals that automatically update components when their values change.
 
-Signals are quickly becoming a core feature in the JavaScript ecosystem, with
-the potential to unify how we manage state and reactivity across various
-libraries and frameworks. By adopting `@lit-labs/signals`, you can start
-experimenting with this cutting-edge technology today.
+Signals are quickly becoming a core feature in the JavaScript ecosystem, and the
+TC39 proposal has the potential to unify signals and how we manage state and
+reactivity across various libraries and frameworks.
+
+Though the proposal is in its early stages, you can start experimenting with
+signals and `@lit-labs/signals` today to see how building components and apps on
+a universal reactivity primitive might work for you.
 
 ## What Are Signals?
 
@@ -43,23 +46,34 @@ react to changes in state.
    libraries and frameworks can use signals interoperably, reducing the need for
    complex adapters and improving compatibility.
 
-## Why We're Excited About @lit-labs/signals
+## Why We're Excited About `@lit-labs/signals`
 
 Lit is already known for its lightweight, performant, and declarative approach
-to building web components. With `@lit-labs/signals`, we’re taking this to the
-next level by tightly integrating signals into Lit’s lifecycle.
+to building web components. But Lit is tightly focused on helping you build
+reusable, encapsulated _components_. Lit is not a framework and does not
+precribe how to model your _data_ or make it observable.
 
 Lit's reactivity is by default relatively _shallow_. Components automatically
-update when their reactive properties change, but not when nested properties
+update when their own reactive properties change, but not when nested properties
 change. Responding to deep property changes has either required manual update
 requests, or the integration of a state management system like Redux or MobX.
 
 Signals give us many of the same deep observability abilities as these state
 management systems, but with a smaller, simpler API, and the potential to be a
 common standard across a large ecosystem of utilies, components, and frameworks.
 
-The new `@lit-labs/signals` package makes it super easy to use signals from
-within Lit components.
+Signals aren't entirely new to Lit. We previously released the
+`@lit-labs/preact-signals` package, but we were somewhat unsatisfied with the
+need to build a Lit integration for a specific signals library, and potentially
+every signals library that Lit developers might want to use.
+
+Standardized signals in JavaScript would let us build just one integration (and
+eventually add signals support directly in Lit's core), and enable interop
+between signal-using libraries in the same spirit of the interop that web
+components enable.
+
+The new `@lit-labs/signals` package makes it super easy to use thw new
+signals proposal from within your Lit components.
 
 Let’s dive into a few examples...