🚀 Lively Components in Duck Framework — Frozen vs Dynamic Components

Show & Tell
1

Hi everyone :waving_hand:

I’ve been working on a Python web framework called Duck Framework, and recently designed a UI architecture called Lively Components.

The goal is to make it easier to build interactive server-driven UIs while keeping development mostly in Python and HTML.

I’d love to share the design and get feedback from the community.

:puzzle_piece: Core Idea

The system is based on two types of components:

:snowflake: Frozen Components

Frozen components are rendered once and reused across requests.

Typical examples include:

  • Layouts
  • Headers
  • Navigation bars
  • Footers

Once rendered, their output is cached and reused, avoiding unnecessary rendering work.

:high_voltage: Dynamic Components

Dynamic components are instantiated and rendered per request.

They are used for parts of the UI that depend on:

  • request data
  • user state
  • frequently changing information

Examples include:

  • dashboards
  • user widgets
  • data-driven sections

:building_construction: Rendering Pipeline

Here’s a simplified explanation of how the system works:

  1. A browser sends an HTTP request.
  2. The framework builds a component tree.
  3. Frozen components reuse cached render output.
  4. Dynamic components are instantiated and rendered for the request.
  5. The results are combined into the final HTML response.

file_00000000a190720cb2e384967d6477b7
file_00000000a190720cb2e384967d6477b71536×1024 119 KB

:bullseye: Goals of the Architecture

The design aims to provide:

  • :snake: Python-first UI development
  • :high_voltage: high rendering performance through frozen components
  • :puzzle_piece: clean component-based page architecture
  • :rocket: server-driven UI without heavy frontend frameworks

:page_facing_up: Documentation

More details here:

:speech_balloon: Feedback

I’d really appreciate feedback on things like:

  • the frozen vs dynamic component model
  • potential edge cases in component caching
  • comparisons with similar server-driven UI systems

Thanks!

2

Hi, sorry that I don’t really have any substantial thoughts/opinions about your framework itself right now but wanted to give a heads up that that the docs say:

Duck is not a small or mini web framework, it is a full-fledged framework which makes you do almost everything!

My guess is that is not what you meant. I think the phrasing you want instead is this:

Duck is not a small or mini web framework, it is a full-fledged framework which allows you to do almost everything!

In the first, you are describing a situation where Duck is forcing its user to do almost everything (implying that it’s not really helpful). In the second version, you would be describing a situation where Duck is giving the user the tools to accomplish almost anything they want (implying that it’s really helpful).

I’m sure most people who’ve read the first version understood what you meant anyway (no one would make a whole framework to be unhelpful :joy:) but just mentioning that you might still want a rephrase of that sentence.

3

Kkk, ok I will change that thanks.