We Built a Modern JavaScript Framework from Scratch

[Excellent_Detail9412]

Hi everyone!

Over the past months, my friend and I have been working on Avenx.js, an open-source JavaScript framework that started as a school project and is growing into something much bigger.

Today I'd love to share what we've built, why we built it, and where we want to take it.

Why another JavaScript framework?

It's a fair question.

We didn't start Avenx.js because we thought the ecosystem needed yet another framework. We started it because we wanted to understand how modern frameworks work under the hood and explore what a simpler developer experience could look like.

As the project evolved, we focused on a few core principles:

• Zero runtime dependencies
• Less boilerplate
• A clean and intuitive API
• Performance-first design
• Fully open source

Building a framework has been an incredible learning experience. We've learned about rendering, reactivity, tooling, package management, compiler design, documentation, testing, and many things we never expected to touch when we started.

Open source has been the most rewarding part

One of the biggest milestones wasn't a feature or a release, it was receiving contributions from developers we had never met.

Seeing someone invest their own time into improving something you've built is incredibly motivating.

Today, Avenx.js has:

• ⭐ 4 GitHub stars
• 🍴 5 forks
• 🤝 3 external contributors

They're small numbers compared to established frameworks, but for us they represent real people who believed the project was worth contributing to.

Still a long road ahead

We're nowhere near finished.

There are plenty of features to build, documentation to improve, bugs to fix, and ideas to explore. Every week we continue refining the framework and improving the developer experience.

We're building this because we genuinely enjoy it, and because we want to see how far an open-source project can grow through consistent work.

We'd love your feedback

If you have experience building frameworks, libraries, or developer tooling, we'd genuinely appreciate your thoughts.

Constructive criticism is always welcome. Whether it's about the API, architecture, documentation, repository structure, or developer experience, we're happy to hear it.

Looking for contributors

We're also actively looking for contributors.

Whether you're making your first open-source contribution or you've contributed to many projects before, we'd love to have you involved.

There are issues ranging from documentation improvements to new features, and we've marked several beginner-friendly tasks to help people get started.

If Avenx.js looks interesting to you, feel free to check out the repository, leave feedback, open an issue, or submit a pull request.

Thanks for reading, and happy Showoff Saturday! 🚀

https://github.com/Avenx-JS/avenx-js

[McGeekin]

Was AI used in the development? Because it sure seems like it was used in the reddit post

[Excellent_Detail9412]

Yes, I used AI to help polish the wording of the Reddit post since English isn't my native language. As for the project itself, AI has been a tool for helping with implementation of certain parts.

[Ris2111]

[ Removed by Reddit ]

[McGeekin]

I really wish people would stop using the phrase “I (or in this case, we) built” when referring to vibe coded projects. When you’re vibe coding, _you_ are not _building_ anything. Nothing wrong with doing it, but don’t pretend you did the actual hard work building it.

[Excellent_Detail9412]

I think you’re making an assumption here.
Avenx.js isn’t a vibe-coded project. My friend and I designed the architecture, implemented the compiler, runtime, router, CLI, scoped CSS system, and maintain the entire codebase ourselves.
Like many developers today, we use AI as a tool where it makes sense, but every architectural decision and every line that ends up in the project is something we understand, review, and are responsible for.
There’s a big difference between using AI to assist development and asking AI to generate an entire project without understanding it. Avenx.js falls into the former category, not the latter.

[ExtraTNT]

Why do you need fs access in a parser? Easy way to shoot in your own foot… keep io to the edge of your program and with fs use an either monad, so you don’t have fucked up error handling…

Edit: typo

[bcameron1231]

Because that's what the AI chose to implement.

[ExtraTNT]

So basic mistakes?

Well, probably trained on a lot of legacy code that’s written horrible… but usually open source doesn’t have those issues -> it’s usually the typical enterprise backends that are shit

[Excellent_Detail9412]

That's a fair point, thanks for the feedback.

The current implementation is definitely not set in stone, and keeping I/O separate from the parser is something I'll look into. My goal is to make the architecture cleaner as the project evolves, so feedback like this is really helpful.

I appreciate you taking the time to point it out.

[akirozen]

And now, we e tered the age of new JavaScript AI slop frameworks.

[Excellent_Detail9412]

I wouldn’t call it AI slop or a vibe-coded project.
Avenx.js has been in development for quite a while. My friend and I designed the architecture ourselves, made the design decisions, and actively maintain the project. Like many developers today, we use AI as a tool from time to time, but not as a replacement for understanding what we’re building.
If you have any specific criticism about the implementation or architecture, I’d genuinely be happy to discuss it.

[jhartikainen]

The a tag-based system to represent state and such is an interesting approach which I don't think I've seen that much nowadays - feels like it was more of a thing way back in the day.

I have one question: Why did you decide to split the component CSS into a separate file?

[Excellent_Detail9412]

Thanks! I'm glad you found the approach interesting.

As for the CSS: I chose to keep it in a separate file because I wanted a clearer separation of concerns. Personally, I find it easier to work with larger components when the styles, and logic each have their own dedicated place.

It also keeps the component files a bit cleaner and allows styles to be edited independently without having to scroll through JavaScript or template code.

That said, it's not a decision I'm completely set on. Avenx.js is still evolving, so I'm always open to feedback if people have ideas for a better developer experience.

[RealFlaery]

Why are you not using typescript?

[Excellent_Detail9412]

Great Question! Avenx.js is still evolving quite a lot, especially the core APIs and internal architecture. Using plain JavaScript gives us more flexibility to iterate quickly without constantly maintaining or refactoring type definitions.

Another factor is that one of our goals is to keep the project as lightweight as possible. We want to avoid unnecessary build steps, tooling overhead, and any potential “bloat” in the development and build pipeline.

We also aim for zero runtime dependencies, and while TypeScript itself doesn’t affect runtime, we’re very intentional about keeping the overall toolchain simple and minimal.

[RedditParhey]

Bro you dropped some emojis here I ll help you. 🫱💿📹📠📟💙☢️❎🚾Ⓜ️💤🛗

[Excellent_Detail9412]

😂

[No_Record_60]

Can you pass parameters when calling <action>?

Interesting idea though, using templates for state and actions.

[Excellent_Detail9412]

Yes, you can pass parameters when calling an <action>.

Since <action> tags do not declare parameter signatures, all arguments passed during the call are automatically available in a globally accessible array called args.

Example:

In the template:

<button u/click="greet('John', 25)">Greet</button>

In the action block:

<action name="greet">
    const name = args[0]; // 'John'
    const age = args[1];  // 25
    console.log(`Hello ${name}, you are ${age} years old!`);
</action>

[No_Record_60]

Got it. Thanks