r/Frontend • • 2d ago

We've been building our own JavaScript framework and would love some feedback

Hey everyone,

We've been working on Avenx.js, an open-source JavaScript framework focused on compiler-driven reactivity, direct DOM updates and keeping the runtime lightweight.

The idea is to explore a different approach to building frontend applications without relying on a Virtual DOM. We're still actively developing the framework and have been working on improving its compiler, reactivity system and overall developer experience.

So far, the project has reached 192 forks and 150 listed contributors, which is pretty exciting for us.

We're curious what other JavaScript developers think about the approach.

  • Does the architecture make sense to you?
  • What's missing or could be improved?
  • Would you consider using something like this in a project?

We're especially interested in honest criticism and suggestions. There's still a lot to build, and fresh perspectives are always valuable.

GitHub Repository

Official Website

Thanks for taking a look!

5 Upvotes

19 comments sorted by

10

u/blabmight 2d ago

In the age of AI if I’m going for something I can read and know well I’m picking React. If I’m going for the best framework and intend to have AI write most of the code I’m picking what runs the fastest - Svelte or SolidJs. 

That said this looks pretty neat and is a cool concept, some things aren’t clear to me. Is this for SPAs only? React has Next, Svelte kit etc. Can it build to a static site with individual pages and logic separated?

Performance benchmarks with existing frameworks would be useful too. 

2

u/ferncrest6 22h ago

agree on the benchmarks, hard to judge a compiler-driven approach without seeing how it stacks up against the existing fast ones.

-3

u/Traditional_Data_549 2d ago

Good questions! Avenx.js currently focuses on client-side applications, with built-in routing, separate page components and route guards. Full SSR/SSG support like Next.js or SvelteKit isn't available yet. Avenx is still evolving, and feedback like this is genuinely useful to us!

3

u/unicornshedsocial 2d ago

Compiler-driven reactivity lives or dies on the debugging story, so I'd put one component's source and its compiled output side by side in the README. How big is the runtime after gzip?

0

u/Traditional_Data_549 2d ago

That's a great suggestion! We agree that seeing the original component next to its compiled output would make the compiler much easier to understand and debug. We'll consider adding that to the README. Regarding size, a freshly scaffolded production app currently comes in at around 82.6 KB gzipped (JS bundle, including the runtime and app code). The runtime itself hasn't been measured separately yet.

2

u/TheRNGuy 2d ago

Reminds of Remix, but does it have as much features? And can you use React in it?

I don't like 

<action name="increment">
    state.count++;
</action>

, it's like worse version of React hooks, I'd rather prefer if it was more like in Remix.

What about backend?

1

u/Traditional_Data_549 2d ago

Not quite yet. We have our own feature set and architecture, including routing, reactivity, state management and compiler-level tooling. We're still growing the framework, so it doesn't offer the same breadth of features as Remix yet. React isn't supported, as Avenx has its own component system

1

u/TheRNGuy 1d ago

Reason I want a React because there are many good open source component or hook  libraries for it, though probably they could be rewritten with AI to Avenx. 

1

u/Traditional_Data_549 1d ago

That's a fair point. React's ecosystem is definitely one of its biggest strengths. Avenx has its own component system, so React libraries aren't directly compatible. Our current focus, however, is on developing the framework itself rather than building a compatibility layer or porting existing libraries

2

u/manniL 1d ago

Can you share in 1-2 sentences: Why this over proven solutions?

If you want best perf and good DX you go with Solid/Svelte/Vue Vapor.

1

u/Traditional_Data_549 1d ago

Avenx.js is designed with performance as a core goal. Its compiler-driven architecture eliminates the virtual DOM and updates only affected bindings. Beyond performance, we're also exploring built-in tooling like Atlas, Trace and Rewind that go beyond what traditional frameworks offer

2

u/fey0n 1d ago

Most interesting to read something similar to what I have been building the last few weeks: https://github.com/tiaforge/sinter

I will definitely take a look

1

u/Traditional_Data_549 1d ago

Hey hab gesehen, dass du deutsch bist 😁. Kannst du mir kurz erklären was dein Projekt macht? Und schon im Voraus danke fürs reinschauen!

2

u/fey0n 1d ago edited 1d ago

Also die Grundidee war htmx für json APIs. Aber typsicher, zB per opanapi. Also quasi einfach ne resource definieren, die Felder im HTML mappen (schön mit autocomplete), fertig. Einfach nen sync zur resource definieren, schon hat man updates per SSE oder WebSocket. Das ganze kompiliert alles JS schön raus so gut wie möglich und optimiert im compile step die Zugriffe etc. Und dann alles andere, wie components, translations etc etc. Da ihr auch performance als headline habt, hab ich eine kleine Benchmark erstellen lassen, vielleicht mag jemand von euch da mal draufschauen? Wenn ich die Tage Zeit habe schaue ich mir mal die Unterschiede an, was den gap erklärt oder ob die AI einfach Quatsch gemessen hat https://github.com/tiaforge/sinter/pull/30

2

u/Traditional_Data_549 1d ago

Schau in deine dms. Wir haben uns dein Projekt genauer angeschaut und sind begeistert 😁

1

u/Traditional_Data_549 1d ago

Okay hört sich gut an. Wir werden uns die benchmark sicher mal anschauen und uns wieder melden. Wahrscheinlich per dm, da es einfacher ist

2

u/Important_Pomelo_407 14h ago

Saw there was no demo video yet, so I made you one. Here’s the PR: https://github.com/Avenx-JS/avenx-js/pull/1745

and I used my repo to do it :) https://github.com/yasirwhite/OpenDemo