Web Frameworks: The Future

Recently, a livestream host sparked an interesting thought: "In a decade, React might not be my go-to framework." This got me pondering the evolution of web frameworks. Let's explore some potential directions.

Syntax: A Blend of HTML and JSX

For those familiar with HTML, whether through server-side rendering, CodePen experiments, or even Tumblr customization, a familiar syntax is key. Consider this:

<h1>Counter</h1>
<p>Count is 0</p>
<button onclick="increment()">Increment</button>

<style>
  h1 {
    color: red;
    font-family: 'Comic Sans MS', cursive;
  }
</style>

<script>
  const p = document.querySelector('p');
  let count = 0;
  function increment() {
    count++;
    p.textContent = `Count is ${count}`;
  }
</script>

This resembles Svelte's approach, enhancing HTML's inherent structure. A more modern iteration might look like:

<script>
  let count = 0;
  function increment() {
    count++;
  }
</script>

<h1>Counter</h1>
<p>Count is {count}</p>
<button on:click={increment}>Increment</button>

<style>
  h1 {
    color: red;
    font-family: 'Comic Sans MS', cursive;
  }
</style>

Markup remains in HTML, CSS in <style>, and JavaScript in <script>. It feels like component-based, modern HTML. However, building a website requires server-side interaction.

Server-Side Rendering with JSX

Web servers handle database connections, authentication, and data processing before sending assets to the browser. A typical server-side route might look like:

app.get('/', async (req, res) => {
  const user = await db.getUser(req.body);
  if (!user.isAuthenticated) return res.status(401);
  return res.html`
    <title>My Website</title>
    <h1>Hello ${user.name}</h1>
  `;
});

Using JSX for server-rendered pages makes intuitive sense:

export async function ProfilePage() {
  const user = await getSession();
  if (!user) throw redirect('/login');
  return (
    <div>
      <img alt={user.name} src={user.profileUrl} />
      <h1>Hi {user.name}</h1>
      <style>
        h1 {
          font-family: 'Comic Sans MS', cursive;
        }
      </style>
    </div>
  );
}

This resembles a React component but resides entirely on the server. Client-side JavaScript remains crucial for interactivity.

The Best of Both Worlds

Let's combine server-side JSX with client-side interactivity using a system similar to Remix's loaders and actions, or React Server Components (RSC), but without explicit directives.

export async function CounterPage() {
  let initialValue = await db.getCount();

  async function updateCount(formData) {
    let count = +formData.get('count');
    await db.updateCount(count);
  }

  return (
    <div>
      <script>
        let count = {initialValue};
        function update(e) {
          count = e.target.value;
        }
      </script>
      <p>Count is {count}</p>
      <input type="number" value={count} onchange={update} />
      <button onclick={() => updateCount({count})}>Save</button>
      <style>
        p {
          font-family: 'Comic Sans MS', cursive;
        }
      </style>
    </div>
  );
}

The framework would intelligently identify updateCount as an RPC call based on its context.

Reactivity: Signals for Speed

A lightweight, fast reactivity system is essential. Svelte's Signals are a strong candidate:

export function Counter() {
  let count = 0;
  $effect(() => console.log(count));
  function increment() {
    count++;
  }
  return (
    <div>
      <h1>Count is {count}</h1>
      <button onclick={increment}>Increment</button>
    </div>
  );
}

Data Fetching: Implicit Server Actions

Instead of explicit directives like 'use server', we could leverage language features. Imagine a keyword like action to designate functions for server-side processing:

export async component Counter() {
  let initialValue = await db.getCount();
  async action updateCount(formData) {
    await db.updateCount(+formData.get('count'));
  }
  // ... rest of the component
}

This simplifies the code while maintaining clear separation of client and server logic.

Conclusion: A Vision, Not a Proposal

This exploration isn't a concrete framework proposal, but a thought experiment. The goal is to envision a framework that blends the best aspects of existing technologies, offering a simpler, more intuitive development experience for the next decade. What are your thoughts on the future of web frameworks?

The above is the detailed content of Web Frameworks: The Future. For more information, please follow other related articles on the PHP Chinese website!