DEV Community: denshya

End Of The Year For Denshya Libraries

Valery Zinchenko — Tue, 16 Dec 2025 11:36:30 +0000

Hello everyone,
By now, there were some accomplishments.
https://github.com/pinely-international/tama/discussions/145
(Though I'm not entirely satisfied with the quality of the code, AI is the evil)

Some planned issues were not completed because there was 3 weeks pause on this project due to other projects I'm engaged in.

Despite of this delay, I was constantly thinking and considering evolution options for Denshya and Tama, now I see clearly that mere renaming (to Tama) and documentation polishing is not enough.

I was questioning signals approach generally (which I like) and by watching React Dev Conference 2025, I understood that React gives (at least) familiar and nice data-modelling approach, which I like too.
I can't just ignore the fact that React nails it, whereas Tama focuses on different aspects.

With this, I made a decision to support both approaches, both signals and plain JS scoped updates.
For you, this just means React hooks will work in Tama (potentially any React components will work too). Though for me it means more work 🥲

I adopted Tama in different projects to see how well it solves problems where React fails and how it feels to use Tama. My conclusion: Tama itself is great, it feels much better than React in terms of "Freedom", but all-around reactivity is tedious at complex data structures, though the state-management overall is nice too.

That's why now I will be focusing on providing more appealing and familiar way for data-modeling and state-management through React hooks and maybe something else. Only then I will switch back to "cosmetics", "ergonomics" and polishing. I will do that in this Reactivity library.

I also implemented a documentation website with SSR and benchmarks for it, so take a look:
https://github.com/pinely-international/tama/tree/main/docs/ssr
https://github.com/pinely-international/tama/tree/main/benchmarks/ssr

For now, I'm suspending new releases until I figure a new data-modeling strategy and util I'm generally satisfied with the quality of the library. The new releases will definitely be resumed in the new year 2026! 😁

What's Changed

feat: add disableJSXCache flag
Fix typos in README
Remove unnecessary logic
Refactor code
Migrate Symbol.subscribe to subscribe
Add Multiple on Events Binding - issue #33
Add Mount for conditional mounting per attribute
Integrate TransitionAPI state handling with tests
feat(lifecycle): Add life.scoped and hook enter into component constructor
Renaming to "Tama"
Add Tama.Ref
feat(lifecycle): Support cleanup functions in Life.scoped
Update CONTRIBUTING.md with AI usage guidelines
Add ref attribute
Add SSR Benchmarks
Implement Documentation Website with Tama itself

New Contributors

bittere made their first contribution in https://github.com/pinely-international/tama/pull/97
1amKhush made their first contribution in https://github.com/pinely-international/tama/pull/100
meetdhorajiya made their first contribution in https://github.com/pinely-international/tama/pull/107
Divayang-2006 made their first contribution in https://github.com/pinely-international/tama/pull/126

New Framework Ripple? What about Others?

Valery Zinchenko — Sat, 13 Sep 2025 11:10:48 +0000

That's funny how people who already has media traction can sell basically anything - unfinished, unpolished project that repeats Vuejs with React style.

It's not something bad actually, but the way it's done is just killing me slow. Ripple is not unique, on my way of creating actually new framework - Proton, I've seen so many frameworks like Ripple, so I don't really understand how people are attracted to THIS, while not attracted to anything else that really changing it.

Yeah, I guess that's just marketing, now you have to sell a open source project. Imagine how many projects die that could've changed the industry because they didn't have enough of media resource? - Probably a lot.

Why Ripple even got attention? It uses JSX, while actually not, because it uses its own .ripple files, which simply means entirely new syntax parser. It parasitize on what's loved by community and includes by what's hated, but still sold.

Maybe it's giving something better than reactive $ that Vuejs has already been doing forever?

A new syntax of mapping an array? Wait! Angular has already doing that.

You can declare components with component keyword - OMG, WTF, so you're saying I'm so idiot that I need a special keyword to declare a component?

JavaScript directly in the html? Mmm, is this some kind of punishment? I think there is a reason why developer community is up to {{foo}} syntax...

Maybe a nice tree-shaking? SSR speed? Small bundle size? Customization? Anything actually new? Well It's basically a mix of several frameworks without any change, and I'm afraid it inherits the worst qualities of all of them rather than vice versa.

So what, people are dumb? - No, people are trustful, they trust in people they are already subscribed to, so they eat what they give, even if it's undercooked meat.

Why youtubers advertise this? - Because they are dumb... well I mean they just ride on a hype wave :(

What then?

Can we just appreciate some open source projects that really require attention?

Back the builders, not the buzz, spotlight open source that actually make a move.
Stop applauding noise, promote projects that solve real problems.
Discover, star and support under-the-radar projects.


Support Proton with a ⭐	rimmel	kitajs

TamaJs Core - No Root Components

Valery Zinchenko — Sun, 06 Jul 2025 09:52:37 +0000

Building a rootless framework is difficult, but still TamaJs was built with a very intentional design choice: its components are allowed to return anything - from DOM Nodes, to primitives, and null/undefined. This flexibility is not a bug, but a feature. However, this freedom comes with sharp edges: when null is returned, no anchor is created, and the view replacement logic has nothing to latch onto.

One of core goals of Tama is to eliminate the concept of "Root Components" entirely and embrace fully "Atomic Components" - meaning self-contained, relocatable, and behaviorally independent.

For example:

function Component() {
  setTimeout(() => this.view.set(<div>Another layout</div>), 1_000)
  return <div>Some layout</div>
}

const componentView1 = inflator.inflate(<Component />)
const componentView2 = inflator.inflate(<Component />)

// These should be two independent component nodes with identical reactive behavior.
document.body.append(componentView1, componentView2)

setTimeout(() => {
  // And they should be moveable across the DOM freely.
  anotherElement.append(componentView2, componentView1)
}, 2_000)

This is where complications begin to surface. Without an anchor or predictable rendering footprint, null becomes a dead-end.

These problems (dynamic mounts, node independence, movable view layers) are elegantly solved by node-group library.

Introducing `Group` node

The design of Group is a practical implementation of the DocumentPersistentFragment proposal, aiming to cover its core aspects in current browsers. The proposal envisions a fragment that can persist beyond a single parent and avoid surrogate wrapper elements. node-group approximates these goals today by leveraging custom elements and live synchronization.

Alignment with the Proposal

Persistent Fragment Semantics
The proposal defines a DocumentPersistentFragment that its children remains even when its was attached to a parent. In node-group, it follows this precisely.

A Group instance can be reparented at any time. When appended to a new parent, its associated nodes removed from the previous one.

Zero-Wrapper Behavior
The proposal discussion emphasizes avoiding synthetic wrapper elements. node-group uses a non-rendering custom element that emits no visual footprint. To engines, the Group nodes appear as true direct children, preserving CSS, Box Model and Layout consistency.

Live Mutation Tracking
While the spec would rely on low-level fragment mutation observers, node-group hooks into the Custom Elements API (connectedCallback/disconnectedCallback) to detect when a relay enters or leaves the DOM. It then streams append, remove, and move operations to the targeted parent.

Group Usage Example

import { Group } from "node-group"

const group = new Group
group.append(
  document.createElement("header"),
  document.createElement("main"),
  document.createElement("footer")
)

const content = document.getElementById("root")
content.append(group)

setTimeout(() => {
  const note = document.createElement("aside")
  note.textContent = "Persistent Fragment in action"
  group.append(note)
}, 500)

Group not only solves TamaJs dynamic mounting challenges, but also opens up door for future enhancements.


Support Tama with a ⭐	Denshya Movemenet	Pinely International

A React Alternative That Turned out Better than I Thought

Valery Zinchenko — Tue, 01 Jul 2025 13:35:01 +0000

Introduction

I was always striving for something better, first I was making my own little tools working with JQuery, then I started learning more about VanilaJS, after all I found React. It was a Heaven that day, but learning deeply was really something incredible difficult and felt like hell.

Now I'm very used to React, I don't even think about how things work anymore, I'm just building - which is great! Unless you want to strive for more.

While learning React I was trying out how I could build application with different architectures. The thing I figured out is that everything is possible, but you need hooks :)

This means you can't use your tools you've been developing and polishing for years in another frameworks or just in VanilaJS.

Limits are Reached

While figuring out architecture patterns and how I can organize things with React, I realize I can't go even further just because React itself doesn't allow me to do so, I can't really customize it. It might seem like too much, but that's maybe just for you as a user-developer, but for as Developer-Tools developer, that's something I'm missing very much.

The complexity of React is not going anywhere, they can't fix it, it wouldn't be React anymore. It's easily proven by React Team themself since they Pre-Released React Compiler, which should help avoid that fundamental complexity - even they understand that it can't be fixed.

That's why some developers choose other frameworks over React like Angular, Vue, Svelte, SolidJS, ...

Tired 😩

I'm honestly tired from React, that's true that it's my Money-Making machine and that's a tool I can use to quickly build something - even faster than AI as for now. However, I'm striving for even better reality and I'm really tired of using this one tool for too long with not so many improvements.

Like why I need that useOptimistic if I could build that hook on my own, just let me do that - they don't.

Maybe let me introduce at least ONE SINGLE new attribute so I don't suffer with importing a function over and over again, why I can't just do that?

Is that really so difficult?
<div classBEM={["base", { active: true }]} />

Sketching into Reality

When I had enough of it, I just started sketching the better React and was a chaos to be honest. I was imagining a beast, but eventually I took the practical approach and simplified many things, it took almost a whole year to just sketch what I wanted - It took another year to reach several severe goals I wanted.

Now I'm ready to give something I'm proud of
https://denshya.github.io/proton/learn/

This is something between React, SolidJS and VanilaJS - you can create components almost like in React with Observables like in SolidJS, while attaching Components like regular VanilaJS elements!

Quick Example

function RangeApp() {
  const progress = new State(0)

  return (
    <div>
      <input type="range" min="0" max="100" step="1" value={progress} />
      <progress value={progress} max="100">{progress} %</progress>
      <button>Reset</button>
    </div>
  )
}

const inflator = new WebInflator
const AppView = inflator.inflate(<App />)

document.getElementById("root").append(AppView) // And you can move it arround.

Why it's better

If you're too lazy to the whole docs, I will give a quick list of why I would prefer Proton over React for the next project:

No hooks - Do things and reuse them anywhere (even in React).
Observables - no need to rely on Component lifecycle, I can design and develop state flows and then use/reuse them in components or directly in elements as globals.
Customization - I can add my own attributes to elements and even render DOM Nodes directly to JSX.
No root hijacking - I'm just building components and then put them as see it fits - all the components can be Root Components right now.
Super lightweight - I'm an extreme footprint optimizer, so for me saving 200kb of code means a lot! Proton is just ~5kb!

Seemingly Successful Road

In the beginning I tried it on my own personal projects - it was not so good, I was really questioning if it's even worth continuing building.

But now I'm building a website for the company I'm working at (Pinely) and we're planning to spread it to another projects we had if clients do not mind.

So I think it's somewhat a success for me, I've been inspired by many people and library I've seen outer no one is looking at - so I want to say thanks to these libraries as well:


Support Proton with a ⭐	Denshya Movemenet	Pinely International

SSR with Full DOM Support

Valery Zinchenko — Mon, 14 Apr 2025 06:13:00 +0000

Background

I have never worked with SSR, but recently I was tasked with that and it was somewhat challenging. I found out that usually you can't use much DOM things in your SSR components - sheesh, that's frustrating. As someone who loves the flexibility of the full browser environment, I felt defeated. I thought, “There has to be a better way.”

So I decided that my SSR will support all the DOM and it actually turned out better than I expected...

DOM Limitations

Traditional SSR setups usually come with a set of constraints that simplify the rendering process, but at the cost of the natural browser experience. In many systems, SSR components are stripped of access to a rich DOM API, meaning you can't use many of the things that DOM naturally provides in a client-rendered app. This not only makes development cumbersome but also forces to adopt workarounds. 😠

It was clear that the conventional way wasn't meeting my needs as a developer.

Dedication

What if SSR could support the full browser environment, including unrestricted DOM access? That's when I set out to create a solution that didn't require a dedicated SSR build.

Full DOM Support in SSR

First I take a look at how other libraries/frameworks implement SSR and found out that they either simply don't implement DOM at all or implement the least of it (like Lit).

I tried to copy-paste the Lit implementation and tried using it, but was disappointing as it was merely a boilerplate without actual DOM rendering and without working features like HTML elements at least.

I tried using JSDOM for that purpose - it magically worked, but when I setup my first performance benchmark - it was disappointing. I realize I either should abandon this idea or implement my own JSDOM.

I looked into the JSDOM code and saw a gigantic codebase - phew...

Ok, I don't need ALL the features to actually work but just some.

Nah, I took a third path - looking for alternatives to JSDOM... And I found it - happy-dom.

It stated that it's ... Mmm... It's better at everything at least 10x. So I decided to use it.

The simple function I came with that just works was like this

import { Window } from "happy-dom"

export function injectDOMPolyfill(context: typeof globalThis) {
  const window = new Window

  for (const key of Object.getOwnPropertyNames(window)) {
    if (key in context) continue

    try {
      // @ts-expect-error ok.
      context[key] = window[key]
      // eslint-disable-next-line @typescript-eslint/no-unused-vars
    } catch (error) {
      // skip
    }
  }

  context.requestAnimationFrame = (callback: (a: number) => void) => { callback(1); return 2 }
}

JSX Optimization

This time, before benchmarking anything, since it was clear that I need to optimize how JSX elements are stringified (turned into a string) myself (I was purely relying on document.documentElement.outerHTML).

I developed JSXSerializer class, which is standalone but able to inherit WebInflator configs. And it does serialization as you can tell.

It worked ~8x faster than React, so I thought it's cool and it's just 1kb of code.

Now I was prepared to do benchmarking - it was AMAZING, it scored way more than Next or React and even 5% better than Solidjs, but frameworks like Vuejs and Svelte were 25% ahead in performance than TamaJs.

Which makes sense since they are string based from the beginning comparing to JSX, which is first creates objects and only then being converted into strings.

Assets Problem

When setting up basic server to test my solution and ended up with a lot unnecessary code, but it was somehow working (after 50 hours of suffering). Working, but not displaying any images nor loading CSS correctly, I was disappointed. However this time it was clearly fixable as the incorrectness came from incorrect paths.

Briefly saying: My imports of images were resolved to absolute path of the system like import MyImagePNG from "./my-image.png" to /home/user/project/src/component/my-image.png, which is clearly not where my image is located in the WEB.

This time it really made my brain flexing, the question was

How do I customize import resolution?

It first seemed like impossible until I googled. I found that Bun supports runtime plugins via Bun.plugin API, which to my surprise and fortune supported changing import resolution behavior.

That's where I came up with my first plugin in Bun
Here's the code

Ok, now I can modify where my assets imports are resolved to.

How do I specify where exactly they should be resolved to?

Was my next question, which basically broke my brain... I came up with several ideas, all of them wasn't that great.

So Vite places assets into ./assets folder - cool, it adds hash suffix to each file - sheesh. Ok I just need to figure what the hashing method is and the reuse it. Nope, I simply couldn't find anything useful, even though I kinda found the script for Vite hashing, but it turned out to be arbitrary, which means developer can override it in the config or even disable the hashing entirely.

So I decided to use additional build step - yeah now this contradicts with the article banner... Nonetheless, I continue and implemented the second plugin for Vite
Here's the code

Entry points

As for basically all the frameworks and for SSR generally, it's a standard to have two entry points and thus two builds. I thought I can go with one, so what I did instead was simply exporting the WebInflator instance and using in the index.ts (or main.tsx), which was used in the index.html, which is the client entry point. And that's it.

So it means, you don't need to modify your code or care about client/server sides in your Frontend App, you don't have to touch if want SSR, just use it or don't - that's up to your use case.

Want SSR? - Put the plugins and that's it!

Server Setup

Now it was the time to clean up the mess after my experiments with SSR, DOM and Import Resolution. Additionally, my use-case required Initial Data loading, but with this setup it was just a breeze to implement.

The server.ts code looks like this

import compression from "compression"
import express from "express"
import sirv from "sirv"

import { injectDOMPolyfill } from "./dom"

import getInitialData from "../src/initial-data"



const PORT = process.env.PORT || 45678
const BASE = process.env.BASE || "/"


// Load HTML template.

let templateHTML = await Bun.file("./build/index.html").text()
templateHTML = templateHTML.replaceAll(/^\s*|\n/gm, "") // Minimize.

// Serve.

const server = express()

server.use(compression())
server.use(BASE, sirv("./build", { extensions: [] }))

// SSR happens here.

server.use("*", async (req, res) => {
  try {
    await injectInitialData()
    const initialDataJSON = JSON.stringify(__INITIAL_DATA__)

    const html = templateHTML
      .replace(`<!--element-->`, jsxSerializer.componentToString(AppRoot))
      .replace(`<!--initial-data-->`, `<script>window.__INITIAL_DATA__=${initialDataJSON}</script>`)

    res.status(200).set({ "Content-Type": "text/html" }).send(html)
  } catch (error) {
    console.error(error)
    res.status(500).send("Server error")
  }
})

server.listen(PORT, () => {
  console.log(`Server started at http://localhost:${PORT}`)
})

// Polyfill DOM.

injectDOMPolyfill(globalThis)
console.log("[SSR] DOM polyfilled")

Bun.plugin(assetsImportResolution({
  cwd: path.resolve("./"),
  assets: sourceAssetsMap.assets,
}))

console.log("[SSR] Resolving imports to Vite Build Assets")

// Inject initial data for app modules import
// as they may use the initial data immediately.

await injectInitialData()

// Load app modules.

const { WebJSXSerializer } = await import("@denshya/proton")
const { default: appInflator } = await import("@/app/inflator")
const { default: AppRoot } = await import("@/app/AppRoot")

// Setup serializer.

const jsxSerializer = new WebJSXSerializer
jsxSerializer.inherit(appInflator)

console.log("[SSR] Ready to render app")

async function injectInitialData() {
  try {
    globalThis.__INITIAL_DATA__ = await getInitialData()
  } catch (error) {
    console.log(error)
    return // Gracefully.
  }
}

Conclusion

I implemented 2 little plugins in Vite and Bun, so that SSR can resolve assets imports of the client app directly to the static build.

I used Express, Bun and Vite. I didn't introduced any new build for Vite, so it was building only once - just the client bundle with the bundle assets map. There were no modifications to the codebase since the DOM is fully supported (for real) and you don't have to care about server-side/client-side things.

At this point I realized - it's Plug & Play SSR, it doesn't require dedicated SSR build (but a bundle map generated by plugin) and fully support browser environment.

Cloud

Unfortunately, this doesn't fit to cloud computing architecture, it works only with static assets, build and source code all placed in the same server, so it needs a further evolution that it can be implemented in Cloud (like AWS and Google Cloud).

I'm working on it, so follow me for further news.

I invite you to experiment with this approach, test out the plugins, and share feedback. There's always room for improvement, and I'm excited to see how this idea can evolve further with community input.

Have you encountered similar challenges with SSR, or do you know of other innovative approaches?

The Prove of No-Framework principal - TamaJs

Valery Zinchenko — Thu, 10 Apr 2025 06:23:00 +0000

In my previous blog post I introduced the No Framework principle and argued that enforcing a rigid framework can sometimes stifle creativity and control. Today I'm excited to take that conversation a step further by introducing a new twist in this journey — the Framework-less Framework.

The Philosophy Behind

Traditional frameworks, while immensely popular, often come with a set of built-in "primitives" and hidden implementations that dictate how you build your applications. They're designed to abstract away the complexities of DOM manipulation and state management, but this also means you sometimes lose direct control over the inner workings of your UI.

The Framework-less Framework concept embraces the idea of no framework in the sense that it strips away these superstructures, exposing open internals and giving you the flexibility to shape your UI as you see fit. It's about having a lean, minimalistic foundation that handles the essentials while letting you extend, experiment, and even replace parts as your project grows.

Introducing TamaJs: A (No)Framework Library

Or just read README.

It is a fast, lightweight (around 5kb gzip) and component-based UI builder that embodies the no-framework philosophy. You can check it out on GitHub: denshya/tama. Tama isn't meant to become the next giant framework that monopolizes your codebase; instead, it's a tool that gives you the potential to build app and manage your UI the way you see it.

Key Pillars of Tama

Tama's design is built on four foundational pillars:

No Framework: It liberates you from the heavy abstractions of typical frameworks, giving you direct control over the rendered output.
Open Internals: Every part of Tama is exposed and customizable, ensuring that you're never stuck with hidden magic.
Fault Tolerance: Robust enough to handle errors gracefully while giving you tools like error boundaries and context APIs.
Customization: From JSX mapping straight to DOM elements to flexible event handling and custom attribute management, Tama is designed with extension in mind.

These pillars reflect the beliefs I shared in my previous post, where I argued for simplicity and transparency over abstraction and obfuscation.

Exploring Tama Through Code

Let's look at some of the basic examples and usage patterns that Tama makes available:

Quick Start

bun i @denshya/tama

For TypeScript and JSX support, add the following snippet to your tsconfig.json or jsconfig.json:

{
  "compilerOptions": {
    "jsx": "react-jsx",
    "jsxImportSource": "@denshya/tama"
  }
}

Once configured, you can get started by creating a simple component:

function App() {
  return <div>Hello World!</div>
}

const inflator = new WebInflator
const appView = inflator.inflate(<App />)

document.getElementById("root").replaceChildren(appView)

You can see how this is rather standalone and unbound comparing to things you've seen before.

See a playground.

Observables and State

Instead of relying on a built-in state management, Tama treats any object with a Symbol.subscribe method as an observable. This opens up declarative and fine-grained UI updates just like SolidJs.

function ProductCard() {
  const title = new State("Title")
  const image = new State("Image source")

  return (
    <>
      <div className="product-card__title">{title}</div>
      <img className="product-card__image" src={image} alt="Preview" />

      <input value={title} />
      <input value={image} />
    </>
  )
}

See implementation of State class.

Custom JSX Attributes and Rendering

Tama supports React-like JSX but maps it directly to the DOM. This means you're free to pass any value—primitive or object—into your JSX attributes. Moreover, Tama allows you to define custom JSX attributes. For instance, if you want to override the default className with a dynamic set of CSS modifiers, you can do so like this:

  const inflator = new WebInflator
  inflator.jsxAttributes.set("classMods", context => {
    if (context.value == null) return
    context.bind("className", bem(context.props.className, ...castArray(context.value)))
  })

Moreover, you can define how you treat values put into JSX as children:

const inflator = new WebInflator
inflator.adapters.add(class {
  constructor(inflator) { this.inflator = inflator }
  inflate(value) {
    if (value instanceof MyObject === false) return

    return document.createElement("div") // Do something cool.
  }
})

This level of customization means you're not fighting against a rigid API—you're co-authoring it.

The beauty of Tama is the freedom it provides. It does not lock you into a preordained structure or magic; instead, it exposes its internals and invites you to innovate. If you've ever felt that a framework was limiting your creative control, Tama offers a counterpoint: a toolkit that empowers you to build the UI exactly the way you want. In a sense, it is as much a challenge that encourages developers to rethink how they view UI libraries.

Component API

In Tama, components are constructed using functions that serve as both constructors and evaluators for Tama.Component. This design allows developers to have direct control over the component's behavior and lifecycle.

When a component function is invoked, an instance of Tama.Component is automatically created and passed as the this context to the function. This approach provides access to various APIs that manage the component's behavior.

View API

The View API manages the element displayed by a component. Developers can set or update the component's view using the this.view.set method. For example:

function MyView(this: Tama.Component) {
  this.view.set(<div>Hello World!</div>)

  setTimeout(() => {
    this.view.set(<div>I'm Replaced!</div>)
  }, 1000)
}

In this example, the component initially displays "Hello World!" and then updates to "I'm Replaced!" after one second. The View API facilitates dynamic content updates within components.

Async/Await Support

Tama components can be asynchronous functions, enabling the use of async/await for handling asynchronous operations. The View API is particularly useful in these scenarios:

async function MyView(this: Tama.Component) {
  this.view.set(<Loader />)

  await new Promise(resolve => setTimeout(resolve, 1000))

  return <div>I'm loaded!</div>
}

In this example, a loader is displayed while waiting for the asynchronous operation to complete, after which the main content is rendered.

Error Boundaries

Similar to React, Tama provides an interface to catch errors thrown in child components, including those occurring in event handlers:

function Child() { throw new Error("Test") }

function Parent(this: Tama.Component) {
  this.catch(thrown => { /* Handle error */ })

  return <div><Child /></div>
}

Context API

Tama's Context API allows for the creation and consumption of context using classes:

class MyContext {
  constructor(readonly value: string) { }
}

function Child(this: Tama.Component) {
  const context = this.context.require(MyContext)

  return <span>{context.value}</span>
}

function Parent(this: Tama.Component) {
  this.context.provide(new MyContext("value"))

  return <div><Child /></div>
}

By defining contexts as classes, it gives a developer complete freedom in how they define contexts since they can be anything, while also giving general structure and predictability.

Proof of Concept

The Framework-less Framework philosophy isn't about discarding all structure. It's about providing a flexible, transparent, and ultra-lightweight set of tools that let you decide what really matters in your application. Tama encapsulates this idea by giving you a robust set of primitives—state management, JSX transformation, observable handling, and more—without the bloat of an all-encompassing framework.

I invite you to dive into the Tama library and experiment with building your next project with this no-framework approach.

Remember this is a way to understand new possibilities and play around with alternative technologies. I'm trying to see what it can turn into.

For contributors and enthusiasts

Idea behind Tama

Beside what I mentioned above about Tama, it was created with a thought in mind that it can be very useful in Web Game Development as well, as its nature is atomic inflation.

Movement

Ideally, I want to make this much more than one single library, but create a whole new movement.

I have plenty to do - pretty big roadmap, it includes various IDE plugins, remastering existing libraries, patterns/practices and forming a new way of thinking as a Web Developer.

Generally, I'm trying to make Web Dev much easier and "entertaining" rather than vIbECoDiNg, LLMs are cool, but as a developer I want real vibe during development not Commercially Advertised. If you share my ideas, connect.

Eventually

I encourage you to explore the Tama repository on GitHub. Fork it, extend it, share your projects, and contribute ideas. It's through this kind of community engagement that we redefine what it means to build UI efficiently and with minimal overhead maybe.


Support Tama with a ⭐	Denshya Movemenet	Pinely International

No-Framework Principle in Frontend

Valery Zinchenko — Fri, 04 Oct 2024 11:02:17 +0000

Statement

No-Framework Principle in Frontend Development states that Developer should not rely on framework utils/tools/methods to build dataflow or data structures.

Instead, Developer should rely on a language and well-known libraries to build and maintain them.

Developer should go for a codebase that splits into two branches: Framework-Based and Framework-Free and provide another integration between. Shortly: good and isolated APIs.

The framework should take care of initiating, storing and reacting to updates of external data. On other hand, a Developer should choose right tools to better support the integration of the external data.

Though there are cases when a part of the flow could only be implemented in a way that is well-supported by framework. Or local object environments where data is not going beyond itself and has no side-effects.

Problem

Writing components often involves establishing data flow/structures locally or between other components. This usually done by abusing framework (e.g. using React Hooks), which to accomplish correctly requires learning the framework deeply that leads to a learning curve just to support a data flow/structure.

Moreover, this tightly couples a data flow/structure to a framework, which kills reusability across other frameworks and puts additional burden to always stick to latest updates of the particular framework for maintenance.

Afterward

There is a noticeable movement to a similar paradigm, like this one: https://pureweb.dev/.

And people are tend to ask for alternative approaches for handling reusability like bit.dev and such, which stores components in a specific way allowing better reusability across FrameWorks.

The web itself is striving to provide much better support for native Web Components
Related comment to the topic of Components Composition

Though I don't think we should just quit the FrameWorks, but rather they should be better optimized and adapted to handling, reusing and declaring the data-flow independently of their own code.

The original "zero framework manifesto"
Framework-Free at Last