I suppose after three years, we can consider my review of JavaScript Frameworks an annual event now. For 2025, I had a hard time writing the articl...
For further actions, you may consider blocking this person and/or reporting abuse
Isomorphic-First exists because developers are tired of being told to rebuild everything every two years. Islands and Server Components promised to solve all our problems but just created new ones. Tools like Tanstack Start and SolidStart are popular because they don't force you to throw away your existing knowledge—you can keep building SPAs the way you know while gradually adding server features. That's what good framework evolution should be: adding capabilities without demanding you start over from scratch each time.
That was the tension, to help adoption RSCs were sold as React++ because they sort of are on paper, but (in Next atleast) it is a different architecture as a result. It was always going to be start from scratch for the pure version of the solution.
There is a range of solutions where Islands make sense. And in theory there should be one where Next-style RSCs do as well. I just think it is a hard when because it is an existing framework because they need to meet developers in the middle instead maximizing first on the range where they truly shine. Which is much closer on the specturm to Islands.
I love how Astro positioned Islands and I think that is where Next needed to be. Then they could focus on the types of issues that really matter in that segment like code side, or serialization size. Instead of being the solution that theoretically delivers across the board but sort of misses on all sides. While I believe that on the whole something like Next RSCs are more applicable to more developers, it doesn't best represent the historical (and vocal) proponents of React who adopted it to make highly interactive applications. Sometimes in trying to satisfy everyone you satisfy no one.
Surprising that the article doesn't mention new or forthcoming browser API or web standards at all. The Navigation API is a really big deal for any framework that deals with routing (also URLPattern API). Other interesting things like streamHTMLUnsafe() also happening...
The challenge with standards is until they are adopted by everyone(ie all browsers) they are basically unusable for frameworks. We can use feature detection, and offer fallbacks, but that bloats code size and can lead people to polyfills which are sort of worst of all worlds being non-native and needing to be generalized often suffering in performance.
It often means that while we pay attention aligning with standards prematurely unless they carry API shape benefits is not particularly beneficial. It makes us last to pick up newest ecmascript features too. You don't want to push transpilation on your users, and often it is better to write stuff your own way than trust what transpilation will generate. Im super careful even with TS around that.
The best path is often to leave room so user space can try the features first and incorporate when good patterns are found.
Also this article tends to focus on new general direction capabilities and not so much refinements or simplification of things already being done. If AsyncContext landed in every browser for example it would be a very different story.
You're right. We'll work together!.
Can you recommend me best resources for learn python and Javascript from scratch?
I read every year your heading, at least I know better what happend in a JS FW world. On my work I was modernize a 7 years old react legacy codebase, nothing fancy.
I maded my own back to basic voyage started with no-build system on begining of 2025. Which is lead to create JS game for hackhaton: dev.to/pengeszikra/javascript-grea... . I would like to make a bit complex game system coding without using react or any other JS framework. Meanwhile rush the hackhaton duedate so this test is how to say try to simulate a real use case. So I changed from no-build to vite, which give option to implement JSX with a single function github.com/Pengeszikra/flogon-gala...
The reactive state handling is another worst case scenario by: github.com/Pengeszikra/flogon-gala... signal function ( I like your FW also but do not used ) based on Proxy. At the end this is nothing more just a play with a JS. Maybe in this year I will continue to make something real stable.
Welcome to being a Framework author. You've already taken your first steps.
Don't take that as a jab. It is just how it always starts. Often nothing comes of it, but you find yourself building the next piece, then the next piece. As tooling/platform improves and awareness of better patterns proliferates it becomes easier and easier to get to a functional base.
What I've found is each time I do the iteration myself though things don't get simpler because I'm aware of more holes and considerations. I simplify from my previous iteration by adjusting boundaries with newer understanding but I can never return to where I started.
You are forgotten about $mol framework
It's fixed all web frameworks problem used ( you don't believe ) technicall review !
Virtual rendering
Adaptation for anything screen
Localization from the box
You need to look at mol.hyoo.ru
I'm familiar with it. Biggest obstacle for $mol is sadly probably the language barrier. I've read the author's (dev.to/ninjin) reactive article series: dev.to/ninjin/components-of-reacti.... Parts of it are very interesting but even I find it difficult to follow. I know there are a lot of demos on the website and benchmarks, but it hasn't caught my eye in a specific way in terms of topical discussions. This is probably not because of some lacking capability but more so that finding a way of pinpointing the painpoint sentiment that developers feel at the given time and showing how to circumvent it is a bit of an art rather than a science. $mol remains efficient and capable but I have no idea how to fit it into the current conversation.
Base rules are simple I think
Html - view.tree
TS - ts ( no changes )
Css - view.css.ts ( css in TS )
Base component it is mol_view it can be any html element ( div by default )
Last year I started working on a JS framework. I ended up speed-running a decade of web dev sentiment, everything from 'no-build' vanilla purity, web components (lmao), the 1000 ways to make SPAs, custom DSLs, class components and this.render, server/universal rendering and isomorphism, eventually stepping on every architectural rake possible until I emerged with a very weird, slightly-off-and-kinda-similar-but-not-really clone of Solid.
Your streams were very helpful (the parts that didn't go over my head) in understanding why I was hitting walls in the first place. I’ve gotten many features working based on your ideas. It’s definitely a science project compared to the giants, but it’s been the best way to realize why the ecosystem moved the way it did, and grasp aforementioned past constructs.
I can't understand any of the async or transition stuff yet, but I'll get there when the next rake hits me in the face 😄. Keep the flag flying, have a wonderful year, and good luck with the Solid 2.0 launch.
I might be over-thinking here, but it feels like the web development ecosystem is slowly circling back toward something more like the traditional stack — plain HTML, JavaScript, and server-rendered pages — just dressed up with modern syntax and tooling. With SSR being so popular now, it often feels like JavaScript frameworks are basically doing what PHP did decades ago: render content on the server, send HTML to the client, and add hydration/reactivity on top.
At the end of the day, all we really need for a “modern” stack are a good router, caching, declarative UI (JSX or similar), and reactive state — everything else feels like an abstraction layer that adds complexity without fundamentally changing what the web actually delivers.
So maybe it’s not about reinventing the wheel, but combining SSR and CSR in sensible ways, and simplifying rather than adding yet more concepts and terminology.
Agentic js frameworks or plugins