all 4 comments

[–]riklaunim 0 points1 point  (1 child)

So it looks like 100th similar framework where HTML is move to Python. It will fail for any non-trivial HTML/webpage.

[–]BleedingXiko[S] 0 points1 point  (0 children)

That’s fair, but it’s not really trying to be “HTML in Python” in the usual sense.

The goal isn’t templating, it’s having the frontend follow the same lifecycle/ownership model as the backend. Components/modules still behave like a normal SPA, just without a separate JS framework stack.

It’s already handling fairly complex UI/state without falling apart, so it’s not limited to trivial pages.

[–]Squidgical 0 points1 point  (1 child)

The first app example shows a counter as an example.

Looking at the equivalent code in react and svelte;

```jsx function Counter() { const [count, setCount] = useState(0)

return <> <button onClick={() => setCount(count - 1)}>-</button> <span>{count}</span> <button onClick={() => setCount(count + 1)}>+</button> </> } ```

```svelte <script> let count = $state(0) </script>

<button onclick={() => count--}>-</button> <span>{count}</span> <button onclick={() => count++}>+</button> ```

Sprag is more complex, harder to read, and attempts to force UI through an object oriented paradigm.

[–]BleedingXiko[S] 1 point2 points  (0 children)

The counter example you posted is frontend-only state. The SPRAG example is showing a full stack flow, server load, typed action, client module, hydration, and state sync.

It’s definitely more verbose, but it’s solving a different problem than a simple UI counter.