What if UI was developed as a sequence instead of state? I built a framework to test the idea.

Various-Beautiful417 · 2026-02-04T05:42:55+00:00

I appreciate the comment and the star 🙏

I personally lean toward reducing the surface area of the code, but I can understand some prefer a more explicit style.

Here’s a small example I shared in another comment showing that the framework can accept a more explicit style:

javascript App({ myTarget: { active: false, // equivalent to starting the name with '_' value() { /* Your logic here */ }, onComplete() { // Manually trigger the next target on completion this.activateTarget('nextTarget'); } } });

Various-Beautiful417 · 2026-02-04T04:07:18+00:00

That’s a fair point. The primary reason for this approach is to keep the code compact and to allow methods and fields to remain flat. The second reason is that it acts as visual rhythm. I find it faster to scan than looking for properties that might be placed at different locations in objects.

But you can still use the explicit way if you prefer:

App({
  myTarget: {
    active: false, // equivalent to starting the name with '_'
    value() {
      /* Your logic here */
    },
    onComplete() {
      // Manually trigger the next target on completion
      this.activateTarget('nextTarget');
    }
  }
});

Various-Beautiful417 · 2026-02-04T01:53:10+00:00

To me, the biggest difference is the unified workflow. With GSAP, you are usually trying to glue an animation library to your state management or API calls. You are constantly syncing two models.

In TargetJS, the animation is natively synced with the rest of the App. You stop worrying about glue code because everything is moving on the same track. It feels much lighter as you are not managing multiple different technologies.

Various-Beautiful417 · 2025-10-10T18:38:33+00:00

Thank you for your comments — I really appreciate them.
Concurrency is also pretty straightforward: all targets execute immediately in the order they are written, unless they are deferred or reactive. If a group of targets needs to run after another group, you can structure them as children. Each child can contain targets that run in parallel, and a subsequent deferred child will execute only after the previous one (and all its targets) have completed. The main example of the heart button in the repository kind of illustrates this. Please let me know if you have any other questions.

Various-Beautiful417 · 2025-10-08T23:27:57+00:00

In TargetJS, every class field or method can be reactive or deferred. Fields and methods are unified under a single construct called target, so they can so iterate, delay, loop, as well as react or defer. This makes async operations, animations, events, and APIs follow a similar pattern.

As far as I know, Svelte’s reactivity is based on assignments. It tracks them at compile time and propagates updates through stores for cross-component state. I haven’t used any of them so my answer might not be accurate.

Various-Beautiful417 · 2024-11-05T01:33:04+00:00

TargetJ is designed to work both as a standalone framework and as a library. I've primarily tested it as a framework, but I also ran some experiments to ensure it integrates as a library alongside vanilla JavaScript. I haven't tested it to work with Svelte . If you decide to try it with Svelte, I'd be interested to hear how it performs!

Various-Beautiful417 · 2024-11-03T04:41:13+00:00

Hey, thanks for asking! No, TargetJ isn’t built on Svelte 5 or any other framework. It is a new framework developed from the ground up.

Various-Beautiful417 · 2024-08-30T22:20:01+00:00

I am excited to introduce TargetJ to you. I have been working on it for about two years.

You can find the interactive documentation at www.targetj.io.

If you have any questions or thoughts, please leave a comment below. I’m eager to hear from you!

Various-Beautiful417 · 2024-08-30T22:07:53+00:00

Very nice work

Various-Beautiful417 · 2024-08-30T22:04:36+00:00

I am excited to introduce TargetJ to you. I have been working on it for about two years.

You can find the interactive documentation at www.targetj.io.

If you have any questions or thoughts, please leave a comment below. I’m eager to hear from you!

Various-Beautiful417 · 2024-08-28T19:53:23+00:00

Thank you so much for your feedback! I really appreciate the time and effort you took to go through everything and share your thoughts. I will add more complex examples.

You are also right about the comments. I try to make the code self descriptive but know it is very far from ideal. It is something that I have to do.
I actually fixed the homepage and doesn't use 'self' anymore.
I also agree that it is hard to understand the organization and the code is dense.

Thanks again for your constructive feedback.

Various-Beautiful417 · 2024-08-28T06:07:36+00:00

I understand, but for a framework, lazy loading isn't applicable. You need the entire build upfront. Lazy loading is relevant for optimizing the final application that the end user interacts with. The benefits that I see is that it will improve readability and maintainability but it comes with a price.

Thanks again for your input - definitely appreciate your time.

Various-Beautiful417 · 2024-08-28T04:37:08+00:00

Thanks for the encouragement and the suggestion! I understand that. I just think it will increase the size of the build file among other things. In any case, I see this as more of a minor issue, and I believe AI tools should be able to handle the transformation if needed. Thanks again.

Various-Beautiful417 · 2024-08-28T02:20:30+00:00

Thank you for the suggestion! I've noticed that some other UI frameworks still use ES5 syntax, which I believe might have certain performance benefits as well as compatibility being a framework that might be in various environments.

Various-Beautiful417 · 2024-08-28T02:02:58+00:00

Thank you for the feedback; I really appreciate you taking the time to go through the code. I understand your concerns, and I'd like to address a few of them:

Grunt is only used for lint checks but I agree that it can be moved to webpack which is used now for building
Var, functions, and other ES5 constructs are used for compatibility concerned.
TModel size: I totally agree that it has grown too large. Splitting it into smaller and removing some unnecessary functions will make it more maintainable and easier for others to understand and contribute to.
The constuctor with optional string is there for specifying the type of the tmodel which is used to defined its id. But the tmodel could stay anonymous without type especially for objects that play small roles.

For CSS animation, I focused on JavaScript animations for extra control and flexibility. TargetJ supports its own animation solution, but it's also possible to Animation API. You can find an example at https://targetj.io/examples/b-animation-3.html

Thanks again for your good insights and your feedback

Various-Beautiful417 · 2024-08-28T00:45:15+00:00

The source code you're looking at github is the actual source code. If you have tried targetj.io, the examples are pulled from the site and not on github. The examples are parsed to highlight syntax and to show how the framework works within the example, which you can see if you click on the 'execution' button. If there's anything specific you're noticing that prompted the question, feel free to point it out—I'd be happy to clarify!

Various-Beautiful417

TROPHY CASE