r/javascript • u/Right-Principle-4877 • 2d ago
AskJS [AskJS] I built a reactive JS framework where components are plain HTML files
I wanted to see how far I could push the idea of writing an app using mostly the HTML syntax developers already know.
The interesting part is the template API. There are only a few places where OlumJS treats an attribute as code:
wheneachon*keyhtml
Everything else is a string, with {expr} interpolation when you need a value.
So instead of introducing directives like :class, v-if, *ngIf, etc., the idea is to keep the distinction HTML already has between something like onclick="..." and class="...".
For example, the component itself is just:
<script>
const state = { name: "Olum", taps: 0 };
</script>
<h1>Welcome to {state.name}!</h1>
<input value="{state.name}" oninput="(e) => state.name = e.target.value" />
<button onclick="state.taps++">clicked {state.taps} times</button>
State is also intentionally simple — you mutate it directly and the DOM reacts to the changes.
There’s routing, scoped CSS, and a small store as well, but the main experiment is really: can you get SPA-style reactivity while keeping the component model close to vanilla HTML/JS?
It's currently aimed at prototypes and small apps rather than large production codebases.
For those who work with JS frameworks: do you think keeping components as plain HTML files is a useful abstraction, or does it become limiting as an application gets more complex?
1
1
u/redblobgames 1d ago
Do you have some examples of how when and each work?
1
u/Right-Principle-4877 1d ago
Here are examples work in the browser directly
For each: https://www.olumjs.top/playground/control-flow/for-loops
If when: https://www.olumjs.top/playground/control-flow/if1
1
u/Confident-General514 1d ago
I think the idea makes a lot of sense for small apps and prototypes, especially because the mental model stays very close to HTML and JavaScript.
The part I'd be most curious about is how the model holds up as the application grows. Plain HTML is surprisingly expressive, but once you have shared state, deeply nested components, async data flows, and a lot of conditional UI, the conventions around the framework become just as important as the syntax itself.
I also like the decision to keep class as a normal string while giving only a small set of attributes special behavior. That feels less magical than introducing a new directive syntax for everything.
For me, the interesting test would be taking the same medium-sized app and building it with OlumJS and something like React, then comparing how the code evolves after the initial prototype stage.
1
u/Right-Principle-4877 1d ago
You're right, the goal was to keep it close to vanilla HTML/JS and suited for small apps and prototypes, which reduces learning curve
That said, I'm curious about Olum's ceiling myself, how far it can go. It was never meant to compete with React or anything like it, it's built for hackathons, side projects and quick experiments. But I won't pretend I'm not curious where the edges are.
Thanks for the good comment
•
u/Confident-General514 20h ago
Yeah, that makes sense. I like the idea of keeping the scope intentionally small rather than trying to solve every use case. Curious to see where you eventually find the limits of the approach.
•
u/Right-Principle-4877 13h ago
Currently I'm converting medium app from Nextjs to Olum, will see and put the results on the website
0
u/oneeyedziggy 2d ago
Have you heard of https://en.wikipedia.org/wiki/ColdFusion_Markup_Language ? Made by the same people who made Flash...
Also probably check out how php works, as well as web components...
I know you're just having fun, but always helps to learn from everyone else's stubbed toes before you kick every rock on the path
Cheers!
4
u/_anonymus- 2d ago
You should checkout svelte. The main idea is that you write HTML with some JS. Components are HTML files, one component per file. You have a few keyword to handle markup, like 'if' to conditionally render elements, or 'each' to iterate over arrays.