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.
Can you recommend me best resources for learn python and Javascript from scratch?
You're right. We'll work together!.
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.
Thank you for a really thoughtful essay. I come from a purely backend background, and I'll be honest — I've leaned heavily on AI for frontend work. When it inevitably breaks, I'm painfully aware of how junior and ignorant I am of the mental models that experienced web developers have internalized over years.
So yeah, I'm becoming the vibe coder that many look at with a scarlet letter. But I've been finding that the pattern of letting AI build while it works, and then coming back when it breaks to clean up, compact, and really think about the right primitives — that cycle actually teaches me. AI is basically a statistical shotgun: it sprays a wide pattern of plausible-looking code, and most of it is wrong or fragile in ways I wouldn't have noticed before. But the act of sorting through what broke and why is what forces me to actually understand the fundamentals. I have AI to thank for that, in a backwards kind of way.
And reading this, I think it's a shame that more people don't get — especially if you're newer to this — what it feels like for someone who has spent years carefully thinking about their primitives, their libraries, their APIs, to watch people just smash things together with AI and call it done. Your imagery in the article captures that. It cheapens the time and thought and care that went into the craft, and I wish more people on the AI-assisted side could sit with that for a moment.
But I also think there's something that the more veteran side might not fully see either. The patronizing tone, the disgust — when it's directed at someone who is simply trying to make things and learn, who wants some autonomy and agency without committing to a years-long apprenticeship before they're "allowed" to build — that's its own kind of alienating. I think there's room for more guidance and discourse there rather than a divide.
Admittedly, a lot of this didn't fully make sense to me before reading your article.
But I actually went into the documentation for concepts you mentioned, and I came away thinking differently about web development. So thank you for that.
I don't have an issue with people using tools the way they see fit. I was more commenting that what once served as guideposts is now just being circumvented. The guidance is built into the APIs themselves. Like if the APIs are designed with intent to help people fall into a "Pit of Success" the idea is that there is some desired outcome from the author in terms of best practices. On a per case usage it doesn't matter, do what works for you. It's more of a question of if this is systematic change is there a problem. Like you might know what's better for you. And I don't necessarily mean in the technical sense, I mean with your circumstance. But as a trend that is more interesting. And I'm not even saying it is something I can judge as good or bad, because it is happening regardless of what anyone thinks.
So to me the gatekeeping aspect is sort of separate. I'm definitely on the side of education. I went to school to learn things, I learned a lot more things outside of school. Engineering involves working in specific problem domains which require learning. I'm not suggesting what the bar is, but there is a bar in pretty much any endeavor. That bar will be set by whoever is responsible for the outcome. Whether that is your team, organization, or yourself. Obviously the growth of potential information in this domains is at odds with people entering it at the rate we are seeing, but that's classically where abstractions are created. Those were API abstractions before, but now maybe they are AI. So to me atleast it is more of the same in a sense. And over time you learn a bit of what lies beneath. We(designers of these libraries) just have to consider that when looking at the shape of solutions.
This article is focused of this video: youtube.com/watch?v=wkXvv0iJffg
So in a way we will close the circle and make our way back to MeteorJS. 🤣 Though we will have to modernize it (which is already under way) or create a modern version of it.
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.
Just use data star, So much simpler way of development
Agentic js frameworks or plugins