DEV Community: Valery Zinchenko

AI Guidance - How to use AI as a Senior Developer

Valery Zinchenko — Sun, 05 Apr 2026 11:43:54 +0000

I've been giving LLMs a chance every year now, and now I think the Agents are finally capable of something, so here's I make some use of AI as a Senior Developer.

I'm experimenting a lot so having a technology that might give me a quick implementation of what's in my mind is a game changer.

But usually LLMs generates a ton of shit if you don't tell them very specifically what to do, but if you already know what to do exactly, you can implement it yourself 10x faster than any CjAI that goes in circles.

It's not a secret here I'm going to expose here that has never been discussed. No, it's very common pattern of AI Guidance, but I was able to reproduce it and actually move forward with actual implementations.

Put your reasons high

In contrast to you (a senior developer), the LLMs need more ~~water~~ specific instructions. You can simply go and implement whatever you need, but so that LLM can do its job, it needs hints and direction.

To make a good use of LLM direction, you basically need to put maximum reasoning level, otherwise it will deviate ridiculously often.

What works for me is xHigh setting in Copilot, it takes a very long time to "think" but its output is very on point. And it doesn't consume monthly limit!

Prompting Strategy

It's very simple, write what you want in the beginning, add whatever resources you can think of to support your implementation idea.

It's very crucial since if you don't give all the resources you keep in mind yourself, AI might miss something. It's pretty obvious, but always slips out of mind when prompting, probably because we all think about LLMs as universal program that can read your mind.

Multistep Implementation

Preparation

As we're a senior engineer, we won't ask for a full implementation of a website/app.

Instead we first do our human work:

Think about our app as modules/libraries, the manual labor that no one wants to pay for.
Do the git init and you might want to add some initial files.

Plan

Do the obvious things you usually do to have better results for yourself and then ask the Agent in the Agent Mode to make a comprehensive plan for the future implementation concentrated in one/few files.

Then look at the LENGTH of the plan file(s), you don't need to get into them deeply, treat them as PRs from your team mates - read only what's on the surface!

Keep asking it to iterate the plan once again until you're satisfied with a length of the plans (imagine how much text it would take if you wrote those yourself).

If you remembered something you forgot to add initially, it's time to add any forgotten/further details.

And ofc ask to iterate again.

Sketch

Once it's done, commit the files, ask it to iterate again.

It's like apt update you see every before installing a new package.

Then ask it to outline the program using only Interfaces and Abstract Classes. This is where it starts being interesting.

It will output some code, you must go through a bit deeper than the plan files since this is what the Agent will be using a foundation, it will follow these interfaces and classes very carefully if it doesn't make sense.

You may want to edit the files to introduces the corrections, but the Agent is very likely to ignore them, so instead copy the changes in chunks and introduce them at once.

I personally edit the code myself and then copy-paste chunks to the Agent, sometimes explain how/what/why and then prompt it.

Commit the files.

Exclusion

Look at the sketch files once again, think what else could be split or minimized since you want the Agent to be in full focus on the core implementation, you should guide it to skip anything it can waste time on instead of caring about the core.

e.g. Particle System is a part of a bigger system, but it also consists of sub-systems, you should choose wisely what the Agent should focus on.

Implement

When you're satisfied with the sketch, which is a very exciting moment because usually it means you're on the very right track and have a very good understanding of the potential implementation (which you should do before moving on).

It means the Agent will likely have a similar understanding and you can proceed with asking the Agent to implement it using the whole knowledge base, the plans and the sketch.

When it's done, quickly peek if it actually follows the sketch and looks like something that would work.

Commit.

Demo

To actually see if it's good or shit, ask it to create a very minimal, one html file demo, using this module/library.

Review the demo file, look for the module/library usage, it will tell if the interfaces were good enough:

If there is a very minimal and simple setup of your module, it's a success.
If the usage is more complex that you wanted, you should proceed with refining it.

Commit anyway.

Refine

Refining might be the most toughest since the Agent would need to follow and update the Plan/Sketch/Implementation/Demo files - that's why we actually stick to a modular approach rather than a whole application - no LLM is capable of doing such at this moment.

There are no advice of how to do it better, sure make sure you do commits and review code changes important to you.

It will likely to change the implementation and the demo separately and lazily - that's good, ask things like "is it possible to do ... in the demo with current implementation?".

Keep iterating until the usage in the demo file looks clean enough and test the performance (performance tab of the devtools in browsers).

The interfaces are very important as they are those you will be working with and they are a natural constrain for the Agent.

Merge

Keep going until you implemented satisfied versions of all the modules you see your app consists of.

Once you're done "building" the modules, you can finally engage yourself fully into the process without AI and maybe start getting your croissant-only salary.

Using AI/LLMs/Agents at this stage is very dangerous since it can mess up all the libraries and the code itself, since the reason to [split the work for the Agent into multiple chunks] is for that it doesn't "forget" details much and do a concentrated work, instead of constantly having its context overflowed and compacted.

That's your stage to shine!

Later you may refactor the AI-built modules completely.

Conclusion

Yeah, it looks exactly like you would do the project with a $200,000 salary, which is not what we usually practice, so we always forget that normality exists.

I tested this approach on my big project, it works nicely, it ofc takes time, but at least now I can suffer less from motivation loss since LLM can at least build something in 1 day that looks like a working solution, comparing to me, that takes 2 months to build non-working one - Hurray!

I overpowered AI by inventing "Brilliant" code by AI opinion itself

Valery Zinchenko — Sat, 07 Mar 2026 21:35:20 +0000

As it always happens to me, I started from describing a simple API client, then I started playing around Mixins, and at this point I really wanted to make my own Mixins library that is just faster than ts-mixer.

I set up benchmarks and started testing what works fast, I honestly got tired of hours of benchmarking and did what usually developers do right now when there are in a dead-end - asking LLM, I asked my agent to make it fast as possible, usually I don't do this, but this time and decided to establish proper tests and benchmarks, so AI can comfortably deprive me of my job. I let it iterate for some time, while going out for bread. Long story short - it did improve the performance, but it also told me that to push limits even further, it would need to sacrifice some specification and "correctness", which I thought is insane since I felt like it can be much faster.

I tried some times again and again until I noticed that it's cycling 2-3 the same implementations and ignoring my notes, doesn't matter how much I told it to go further and "don't make mistakes", it still made mistakes, breaking the code, then fixing it and telling me that "no, that's it".

I decided to forget AI and do it myself, it spent even more hours, without buying any single loaf of bread, I've gone over the options. When I felt like I was almost there partially fitting the spec and having better performance - I did a mistake, I waste my time asking AI to finish it again. It just gave the same code as before and that's it actually.

Next day, with fresh state of mind - I did it - I came with my own CompositeMap that is just 40 lines and insanely fast. It seems it's also interesting from the point of keys ordering, usually in CompositeMap [A, B] does not equal [B, A]. There are libraries for CompositeMap indeed, moreover there is a TC39 proposal for Composite keys, but these libraries and polyfills are not fast enough for me.

That's where I pushed the limits to the top and even asked AI what it thinks about it.

This is what it said:

That code is brilliant. This is a "Performance Masterclass". This is a very clean implementation of a "Discrete Identity Map." ...

Though it wasn't able to come up with this code that I need itself, even when I have done everything LLM needs.

This simply highlights that no matter how good AI is and will be, it will never be better than what you do yourself since LLM are trained with what people were able to do in the past and post about it. It is simply unaware and can't reproduced things no one has thought or talked about - that's on you.

Can you be better than AI? Yes! In fact, you are better because you are human. Anyone saying "this is a prompting skill issue" or "use another model" are just gasping for what is not there - coding skill. You're not going to be replaced if you do code yourself, but you are replaceable if you can't do code without LLM, it's simple math.

Was I able to save any time using LLM? - hmm, actually no. Whenever I put long running process, it requires careful and exhausting prompting and I just go for a break and out for a bread, but I could've coded myself all this time getting the results much faster or understanding I failed earlier.

Thanks to the company I'm working on by letting me to work on this kind of side work.

It's always that people are ignoring "serious" posts about real world things, so I decided to combine memes and make this topic a bit more involving.

Here's the code: https://github.com/pinely-international/mixin/blob/main/src/CompositeMap.ts

Shortly how it works: for every object it assigns ID incrementally and hashes all keys with bitmask, this way it's super fast and order-insensitive - it is bit-wise. The bitmask is usually used for things like Flags and usually seen in Game Development. There is a limitation though, bitmask can take very limited about of variants, usually up to 32 (depends how many bits your integer is). In my CompositeMap, if it runs out of 32 bits, it escalates to BigInt, which is still faster than other libraries. However, for Mixins, it's not often to have 32 variations of mixins, so it should be fine anyway.

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

We're Joining Hacktoberfest 2025 🎉 with TamaJs

Valery Zinchenko — Mon, 22 Sep 2025 13:18:13 +0000

We're excited to announce that Denshya TamaJs is officially participating in Hacktoberfest 2025 🍂

Whether you're a seasoned open-source contributor or just starting your journey, Hacktoberfest is the perfect opportunity to get involved, sharpen your skills, and make an impact.

With Tama.js, you'll get hands-on experience contributing to a growing ecosystem while being part of a global celebration of open source.

✨ Why contribute to Tama.js?

Learn by contributing in a friendly community
Explore new possibilities and enhance existing tools
Boost your GitHub portfolio with meaningful contributions
Earn exclusive Hacktoberfest swag along the way
Land a job if your contributions are valuable and meaningful
Having a fun of course!

👉 Start contributing today: https://github.com/pinely-international/tama
🐱 Join discord hacktoberfest server and find more details about the project in the hacktoberfest-projects channel.

Let's build future together this Hacktoberfest 🚀

It is a part of a bigger set of libraries - Denshya - a movement of signal-based, DOM-first, Open Source Frontend Libraries.

https://github.com/denshya

Currently it's being developed in http://github.com/pinely-international, which is the company you could be hired in.

It also challenges DOM standards with Group proposal with this library that is being used as the only dependency for TamaJs.

All this means there are lots of work, so you can take in work anything you want.

useEffect With AbortSignal

Valery Zinchenko — Mon, 15 Sep 2025 17:32:54 +0000

If this is the way you subscribe to events, then you must keep reading.

function Component() {
  const ref = useRef()

  useEffect(() => {
    if (ref.current == null) return

    function onDrag(event: DragEvent) { ... }
    function onDrop(event: DragEvent) { ... }

    ref.current.addEventListener("drag", onDrag)
    ref.current.addEventListener("drop", onDrop)

    return () => {
      ref.current.removeEventListener("drag", onDrag)
      ref.current.removeEventListener("drop", onDrop)
    }
  }, [])  

  return <div ref={ref} />
}

Of course, there are other ways to subscribe to these ones such as:

<div onDrag={onDrag} onDrop={onDrop} />
Using libraries with utility hooks like useEvent

However, the problem is that - it's not always accessible.

If you want to properly listen to resize updates, you should use ResizeObserver or to track viewport enter, the IntersectionObserver.
There are cases when you need to integrate third-party libraries that are not React into React 😱, and subscribe to the elements like shown in the example above.

The shows example is already ok, but we can raise the bar a little bit. And this is good to know several ways how to implement something rather than single one.

`AbortSignal`

AbortSignal is simply an object that can be passed when you subscribe to an event source, either addEventListener or when(...).subscribe.

So instead of calling a separate function to unsubscribe, you can just pass a signal and that's it. The subscription or subscriptions can terminated when signal.abort is called.

Improved `useEffect`

To make an improvement, we simply introduce a AbortController to have access to abort and the signal that we can pass around.

function Component() {
  const ref = useRef()

  useEffect(() => {
    if (ref.current == null) return

    const abortController = new AbortController
    const signal = abortController.signal

    ref.current.addEventListener("drag", event => { ... }, { signal })
    ref.current.addEventListener("drop", event => { ... }, { signal })

    return () => abortController.abort()
  }, [])

  return <div ref={ref} />
}

And you can go further and create a very simple custom hook

function useEffectScoped(callback: (signal: AbortSignal) => void) {
  useEffect(() => {
    const abortController = new AbortController
    callback(abortController.signal)
    return () => abortController.abort()
  }, [])
}

To transform the final implementation into this

function Component() {
  const ref = useRef()

  useEffectScoped(signal => {
    if (ref.current == null) return

    ref.current.addEventListener("drag", event => { ... }, { signal })
    ref.current.addEventListener("drop", event => { ... }, { signal })
  })

  return <div ref={ref} />
}

Which eliminates extra unsubscribe call (removeEventListener) for each subscription (addEventListener), shorts AbortController and return declaration.

In total we're abstracting away from almost half of the code!


New Framework Ripple? What about Others?
Support Proton with a ⭐

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

Embeddable Open Source Unity-like Editor for ThreeJS

Valery Zinchenko — Mon, 18 Aug 2025 07:19:00 +0000

I'm a open-source developer, so yes I do staff for free even if you don't pay me.

This is a short introduction a concept of embeddable editor for easier development of 3D apps in ThreeJS (for Vite bundler).

Description

Embeddable ThreeJS Editor in browser that you can add to any of your existing projects, expand (Picture-in-Picture) to a second display and add/move/remove/update scene objects in real time while you're is running - no need for annoying restarts.

This is helpful if you're designing a scene and you want to move/update objects freely to proactively see how they look, which is 100x faster than editing, reloading and only then looking.

It enables Visual Programming, so that you can compose a scene even with object behavior using only interactive editor.

It resembles Unity and Godot editor, so if you're already familiar with these, it should be easy to learn.

You don't need subscriptions, registration or anything, all happens on your computer and only - it's self-hosted, it's just a library.

Why me

I have a big experience in UI Design and Frontend Development as well as Patience about game development (and I worked with Unity). So I think I'm a good person to work on this and actually ship a product that you will be using.

I have a little roadmap for this project
https://www.patreon.com/posts/136404913

Why it's possible

Thanks to new Web APIs that recently got available in browsers and ThreeJS that took care implementing it.
Thanks to my another project - Denshya Proton ⭐ that allowed me to build such UI.

Your feedback

I don't ask to donate me as I might not be able to finish this project, but I'm asking for your feedback to understand if this even matters to keep building.

Transparent NodeParent Without Wapprer: a new DOM Node

Valery Zinchenko — Tue, 05 Aug 2025 08:09:00 +0000

After struggling several months spent brainstorming how I could implement this without DOM patching, something which seemed to be impossible turned out to be pretty easy.

Not everything, but essential parts like "remote attaching" of nodes and "PersistentFragment" was achieved purely in conventional Vanilla JS.

Here's the tests & playground:
https://stackblitz.com/edit/node-group

The One Big Reveal

Traditional DocumentFragment is a one‑shot batch—append it once, its children move into the host, and the fragment empties itself. If you need the same nodes elsewhere, you must clone or rebuild them.

Group changes that. It holds onto its children as single instances, and lets you attach the very same nodes to multiple hosts - not by duplicating or sequentially reappending, but by moving the live nodes between parents while they remain discoverable via childNodes.

const group = new Group
group.append(span, img, div)

// mount the same nodes in hostA
hostA.append(group)
console.log(group.childNodes) // [span, img, div]

// later, move them to hostB, without losing discovery:
hostB.append(group)
console.log(group.childNodes); // still [span, img, div]

Unlike DocumentFragment, Group does not clear its childNodes on append. It simply reassigns their parentage - so your live nodes persist as a coherent set across hosts.

Why It Actually Matters

Shared Ownership: Borrowing React compositional mindset - sharing a single node tree instead of duplicating or rebuilding it. Now multiple containers can host the exact same elements, without side-effects.

Wrapper-free Transparency: No extra <div> or invisible wrapper. Under the hood, Group is a Custom Element shim that preserves CSS selector behavior, event targeting, and box‑model semantics.

Live, Incremental Updates: Every append, remove, or move inside a Group fires connectedCallback/disconnectedCallback, streaming exactly the DOM mutations you expect - no innerHTML rewrites, no virtual DOM.

Alignment with WHATWG `PersistentFragment` Proposal

Group mirrors WHATWG Issue #736: "A DocumentFragment whose nodes do not get removed once inserted."

Persistent fragment semantics: children survive mounts.
No artificial wrappers: CSS and DOM behave as if the fragment never existed.
Mutation tracking via Custom Elements: no heavy diffing, just native callbacks.

Perfect Fit With Proton Rootless Architecture

Proton struggled to express null or an array of nodes from components without fake containers. Group solves this by exposing a mountable footprint that:

Represents null but retains identity.
Integrates with inflators to plug into the DOM later.
Moves dynamically without re-rendering.

Use Cases That Spark Imagination

Shared UI fragments: One tree, live across multiple panes.
Drag‑and‑drop reparenting: Move a node group seamlessly between containers.
Nullable Proton components: Maintain identity even when nothing renders.
Plugin UIs without hacks: Inject UI anywhere without hijacking a root.

But Let's Be Skeptical: What Doesn't Work (Yet)

parentNode illusions: Children report their real parent, not the Group - maybe contrary to some expectations.
Serialization gaps: No native markup for named fragments - will be implemented if enough attraction is gained.
Callback latency: Custom‑element lifecycle timing can introduce microtask delays - but in reality I haven't noticed even once.
Browser support: Custom Elements V1 only; legacy browsers need polyfills.

How to Try It Now

npm install node-group

import { Group } from "node-group"

const group = new Group
group.append("Text1", "Text2")

document.body.append(group)
setTimeout(() => group.append("Note3"), 500);

Roadmap & Ambitions

Named fragment registry (e.g. Group.groups).
Configurable parent-reporting behavior for .parentNode.
SSR‑friendly anchors for direct serialization.
Collaboration with WHATWG on native support.

Closing Thought

I built a DOM primitive that feels like the future-persistent, transparent, live UI chunks that remain discoverable and mutable. No virtual DOM, no wrappers, no re-renders - just native behavior in plain JavaScript.

Call to Action

Let's see what it hides behind and where it can evolve to - this can't happen without you.

I would gladly appreciate if you star the repo and support me with a coffee.


Support Proton with a ⭐	Denshya Movemenet	Pinely International

Flexing Your Brain In ChatGPT Guide

Valery Zinchenko — Tue, 15 Jul 2025 05:14:00 +0000

Here are simple steps/rules how to use ChatGPT and alike without brain rot and being degraded:

Do not copy anything from what LLM replies, safely copy what you answer, of course, if your answers/prompts are entirely written by you. Treat ChatGPT like a book rather than a source you can copy from, yes it's tempting, but that's where all the brain rot comes from.

Plan what you want to discuss or create with very simple and rough points, write them down somewhere.
In a new chat without using Deep Thinking/Reasoning (so that LLM uses less memorized data from you). Browse information, look for additional knowledge and ask opinions for each point you wrote down - DO NOT include your opinions - only ask just like you would search info in Google.
Now go away from LLM, maybe drink something, just relax a bit.
Then think about what LLM told you for each point without looking at its responses.
Expand the points you wrote down in the beginning, make them more detailed, you may use wording that LLM gave (it actually really good at it), which you remember.
Consider and create a draft of the end result you want (and write down) without copying LLM replies, using only your own words.
Create new chat and start giving it parts of what you drafted one by one, read what it answers and answer next with related content of what you drafted. Try to not change your draft too much, but you can adapt it. NO OPINIONS SO FAR. Only guiding the AI in the direction of your desired result.
When you ran out of points, give your last answer as emotional and opiniated as you can in the same chat.
Congratulations! You gained 2000x times more data from simple points that you had, which you actually are aware of and already processed.

Now you have a lot to get to the end result you wanted from the beginning. Yes, this approach takes time, but it takes much less than pure Googling and laying of information yourself.

Of course, you should not forget about Googling - Check important info and if you doubt something LLM gives you - go and read the articles in the internet or at least ask LLM to give a list of sources to read.

Thanks for reading! How do you keep away from brain rot?


Support Proton with a ⭐	Denshya Movemenet	Pinely International

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

It's wrong time for Vibe coding, We don't have right tools yet

Valery Zinchenko — Fri, 13 Jun 2025 15:36:29 +0000

Vibe coding felt like a shot of adrenaline—exciting, dreamy, but totally out of sync. Right now, our tools are too shaky and our playground too messy. In game engines you have some order. On the web, it is chaos.

Too Many Moving Parts

There are dozens of frameworks. Thousands of libraries. New standards pop up every week. Web Components promised easy modules, but they still feel clunky. One month you learn React way. Next month you chase Svelte. Then you jump to Solid or Qwik. Who knows what comes next? It is a dizzying spin.

Missing Building Blocks

Core features are half‑built. Real state lifecycles? Still sketchy. Built‑in suspense? Barely there. Teams waste hours wrestling with glue code and browser quirks. How can you trust your flow when half the pipes leak?

Hype Burns Fast

Hype grabs attention. But hype also crashes hard. Vibe coding looks magical - until it crashes. Will anyone trust this idea in future after everyone burned their last drops of confidence? Doubt will linger.

AI Can't Keep up the Pace

LLMs learn patterns, but patterns shift daily - syntax changes, APIs evolve, AI spits out outdated code. It cannot "feel" the latest tricks - on unstable ground, it just slips off.

Fix the Foundation First

We need firm basics before we improvise. We need simple, solid primitives for rendering and state. We need stable standards with clear rules. We need tools that don't break every update and that LLMs can easily pick up.

Waiting for True Love

Vibe coding can wait, right now it is a false promise. Let us patch the holes. Let us nail the boards. When the stage stops shaking, we can finally be vibing truly and with pleasure.

Honestly I love this idea, I love vibing and coding. Now using AIs feel like suffer, especially if you're a developer.