Rendered at 15:57:20 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
rco8786 1 days ago [-]
> Measured, not vibes
Sort of ironic considering that there are a LOT of vibe tells in the copy throughout this page. It's a neat looking project, it's a shame that every other sentence has Claude's fingerprints all over it.
mcintyre1994 1 days ago [-]
Which is ironic because the author works at OpenAI!
christophilus 1 days ago [-]
Yeah. I thought it sounded like OpenAI more than Claude, though maybe they’ve converged. It’s been a while since I used Claude.
ddevnyc 1 days ago [-]
There's enough inbreeding^W distillation happening that whatever OpenAI tone you're thinking of is probably Claude's tone (and vice-versa)
ameliaquining 15 hours ago [-]
You really think the big American labs are distilling each other? That surprises me.
ddevnyc 15 hours ago [-]
Think? I know it
ameliaquining 13 hours ago [-]
How do you know?
trueno 1 days ago [-]
claudes still claude. still as load-bearing as ever. the ladies have no idea how absolutely right i am every day
ricardobeat 1 days ago [-]
Would look more appealing without the AI flavour. If you're vibe coding, do yourself a favor and write website copy yourself - it's the only evidence of human input or oversight your project will have.
gbjcantab 1 days ago [-]
It’s especially grating in this case because Dominic Gannaway, the creator of Octane, is the real deal (creator of Inferno, former React core team member, former Svelte core team member); so the project landing page looks like generic 2026 slopcoded abandonware, but it is in fact a real project made by someone who’s one of the great minds of frontend framework development (with heavy Claude use apparently, to be clear).
lioeters 23 hours ago [-]
Sad to see formerly talented software developers become mediocre and bland, losing their unique flavor and personality. Maybe there's still some insight or idea that's their own creation, but it's obscured by the same text and code generation service, a soul-less corporate voice. It's possible language models will mature to better emulate that ineffable quality of having a "heart" or "taste", but it would still be empty without a person on the other side.
dzonga 3 hours ago [-]
yeah I agree - the talent behind inferno - is getting overshadowed by the use of 'llms'. when the talent has its own creative personality & flair
trueadm 22 hours ago [-]
We’re looking to address the feedback with the website copy. Thank you for the feedback!
throwaway27448 1 days ago [-]
I still think code quality itself reigns supreme. I couldn't give less of a damn about a website.
catlifeonmars 24 hours ago [-]
Code quality at one point in time is useful, but what you want is dependability over time and responsiveness to security fixes; this means looking at the maintainer and their attention to detail.
Sure, the website by itself doesn’t mean anything, but placed into context it could mean the maintainer doesn’t put much effort into clear, unambiguous communication.
trueadm 21 hours ago [-]
We’ll address the website content :) thank you for the feedback
Guillaume86 1 days ago [-]
Just took a glance so I may be completely wrong, fell free to ignore, but if I understand correctly, tsrx is just syntactic sugar for normal tsx code and does not enable anything new?
If this is the case: I think introducing tsrx as part of Octane muddies the water a bit and makes me more hesitant to try (even if it is optional).
The idea to make tsx files more readable may be interesting but in that case it should go into its own separate project, and maybe just put a lang toggle in Octane docs and a page about tsrx compat, that way if people are intrigued by the new syntax they can just look it up but the docs stay focused.
adzm 1 days ago [-]
agreed, tsrx is neat as supported but personally i'm not a fan of it, makes me think of angular and more domain specific language stuff. the whole tsrx angle makes me wary of this project entirely, which is a shame, since octane does sound pretty neat. i'll still check it out, but this was indeed my initial reaction upon seeing tsrx here
trueadm 21 hours ago [-]
TSRX allows for better runtime generated guarantees, especially around loops which generates faster runtime logic from it. We can’t assume too much statically when reading something.map as the method might have different heuristics
aatd86 1 days ago [-]
I recognize this comparison style. Definitely generated by Claude. haha
vivzkestrel 1 days ago [-]
- please post 10 new frontend frameworks daily to HN
- i ll take that over the AI, GPT, LLM, Agent stuff on HN anyday now
Semiapies 12 hours ago [-]
What, you don't like hearing about how someone used the new AI to AI an AI in order to bash something together that will never get updates?
adzm 1 days ago [-]
An interesting feature is this:
> A current-state getter. useState and useReducer return [state, update, getState], so a delayed callback can read the latest value instead of a stale capture.
There are currently a few workarounds in React for this, and using other state management libs also give you non-reactive access to current state, but this is a big help in certain situations.
For example, a callback / event that you pass to all your child elements, that needs to access the current state when run, therefore normally needs to be recreated with the new state captured (in useCallback) whenever state changes, which then causes all child components to re-render. Non-reactive access to current state in callbacks avoids this entirely.
There are some hacks that fix this by wrapping the updated callback in a ref and updating it with an event (for example, https://usehooks-ts.com/react-hook/use-event-callback useEventCallback as implemented various places) and returning a stable reference to a function that calls that saved one, though I always wonder if there are downsides to this.
xpl 1 days ago [-]
Does it have any overlaps with React Compiler — like the auto-memoization that they have?
Also, is there any read on the downsides / shortcomings / caveats of Octane vs. vanilla React?
trueadm 21 hours ago [-]
The Octane compiler has overlap in terms of memoization but also goes far further
exceptione 23 hours ago [-]
The copy reads like it is react but improved. Which begs some questions: what strings are attached and why wouldn't the authors of react adopt this? What reasons would developers have to not switch from react to octane?
trueadm 19 hours ago [-]
I mean I created Octane coming from being one of the authors of React from years ago. Octane makes breaking changes compared to React to improve on things that aren’t that important in 2026. For example the synthetic event system - which takes up 13kb of React’s payload and adds overhead over just using the correct DOM events.
mapcars 1 days ago [-]
It seems like an attempt to port Svelte's features to React-like api?
xpl 1 days ago [-]
The model is a bit different from React (no deps, hooks can be under ifs) — do coding agents recognize it or they get confused when they see that code?
But it doesn't have the repeating yourself/over-emphasising that you sometimes see in LLM instructions when someone is trying to fight the model's default assumptions
hellohello2 22 hours ago [-]
Looks interesting. But does anyone really like the useState useContext etc. React model? Might as well make a better one if you are going to be compiling no?
ksec 1 days ago [-]
I think the Github link [1] does a much better job at explaining what it is.
This looks like an interesting project but reading these AI slop web pages is so exhausting. At least turn your brain on long enough to explain what your project does
adithyassekhar 1 days ago [-]
It took a while to render when I clicked the Differences from React button on an iphone 17.
christophilus 1 days ago [-]
Same. I think it’s just a link, and its content took a while to load. Looks like it’s the docs site vs the marketing page.
Tajnymag 1 days ago [-]
I'm surprised how good Vue Vapor mode is from the performance comparison table.
purerandomness 1 days ago [-]
Funny how Vue Vapor 3.6 beta and Ripple 0.3 show the exact same performance (1.0) as Octane, but their bars are a tiny bit longer so the Octane team can pretend to have a justification to put their implementation on top.
Classic statistics dark pattern.
trueadm 1 days ago [-]
We just run a script that runs the benchmarks and updates the chart. It’s rounds numbers too. We’ve been as honest as possible in all the benchmarks - there’s no point in lying about a metric.
ARussell 1 days ago [-]
It would be nice to see how this differs from SolidJS.
torment-nexus 1 days ago [-]
This is an interesting problem. A similar approach that worked for us was to only load the tools the agent actually needs for each task.
epolanski 1 days ago [-]
Interested in experimenting with Octane, wish that docs emphasized more the SSR aspect of it, because I'm looking for a Ruby/Phoenix/Php alternative in TypeScript land, and one with React-like apis would be cool.
trueadm 1 days ago [-]
It has all the same SSR APIs as React. The Octane website is rendered with Octane and the source is in the GitHub repository if you’re interested to see how it works
atraac 1 days ago [-]
Weren't there RedwoodJs, BlitzJs and few others that did that already?
trueno 1 days ago [-]
theres gonna be a lot more at this rate. everyones tribalistic preferences about how web frameworks should be made... is never going to get solved. now everyone can just spend a week of their claude max plan making whatever framework they want. ive done it like twice now in the past year just for shits and giggles, it is fun but i wont pretend like i know where any of this is going, i think a hybrid of ssr and a blend of "the client should do some work" is probably the prevailing strats that will scale. something like aggrid is a very performant js datatable so i personally am not inclined to try and reinvent that from the backend, rather a backend has full coverage over its api surface but largely just sets/configures/sends data to but lets aggrid do what aggrid does. component models and diffing changes and all of that though and sending lil dom updates... shouldve never been purely on the front end to begin with. front end runtimes are about to get way smaller.
my favorite part of using whatever this weird ssr hybrid landscape ive been in is just not using graphql lol. i can just rawdog sql now for most things like the lords of data intended. its fantastic
angrybards 18 hours ago [-]
I've been working on my own framework for several years now. I chat to AI about it but otherwise it is hand coded. It is interesting looking at how much effort goes into framework development when in theory an AI can spin up precise code that does just what is needed for the situation, assuming it isn't hallucinating or going off the rails of course. But I don't think we have seen a truely vibe coded, AI just doing what is optimal framework come out of the woodwork even though the space has had a lot of time to show something. I'm interested to see what it looks like when it happens.
epolanski 1 days ago [-]
Didn't like the apis nor both being built on top of react crap.
projektfu 23 hours ago [-]
[dead]
KoleSeise1277 1 days ago [-]
[dead]
cpt100 1 days ago [-]
Why are people still building these frameworks? Can't we just use LLMs to build the best JS framework?
Sort of ironic considering that there are a LOT of vibe tells in the copy throughout this page. It's a neat looking project, it's a shame that every other sentence has Claude's fingerprints all over it.
Sure, the website by itself doesn’t mean anything, but placed into context it could mean the maintainer doesn’t put much effort into clear, unambiguous communication.
If this is the case: I think introducing tsrx as part of Octane muddies the water a bit and makes me more hesitant to try (even if it is optional).
The idea to make tsx files more readable may be interesting but in that case it should go into its own separate project, and maybe just put a lang toggle in Octane docs and a page about tsrx compat, that way if people are intrigued by the new syntax they can just look it up but the docs stay focused.
- i ll take that over the AI, GPT, LLM, Agent stuff on HN anyday now
> A current-state getter. useState and useReducer return [state, update, getState], so a delayed callback can read the latest value instead of a stale capture.
There are currently a few workarounds in React for this, and using other state management libs also give you non-reactive access to current state, but this is a big help in certain situations.
For example, a callback / event that you pass to all your child elements, that needs to access the current state when run, therefore normally needs to be recreated with the new state captured (in useCallback) whenever state changes, which then causes all child components to re-render. Non-reactive access to current state in callbacks avoids this entirely.
There are some hacks that fix this by wrapping the updated callback in a ref and updating it with an event (for example, https://usehooks-ts.com/react-hook/use-event-callback useEventCallback as implemented various places) and returning a stable reference to a function that calls that saved one, though I always wonder if there are downsides to this.
Also, is there any read on the downsides / shortcomings / caveats of Octane vs. vanilla React?
But it doesn't have the repeating yourself/over-emphasising that you sometimes see in LLM instructions when someone is trying to fight the model's default assumptions
[1] https://github.com/octanejs/octane
Classic statistics dark pattern.
my favorite part of using whatever this weird ssr hybrid landscape ive been in is just not using graphql lol. i can just rawdog sql now for most things like the lords of data intended. its fantastic