--- title: Apparently the Frontend Framework I Wanted Already Existed description: A long-time Vue developer recounts years of evaluating frontend frameworks (React, Solid, Qwik, Astro, HTMX) while disliking JSX and wanting a compiler-driven,... canonical: https://daily.dev/posts/apparently-the-frontend-framework-i-wanted-already-existed-a1r5v80fk twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Apparently the Frontend Framework I Wanted Already Existed | daily.dev og:description: A long-time Vue developer recounts years of evaluating frontend frameworks (React, Solid, Qwik, Astro, HTMX) while disliking JSX and wanting a compiler-driven,... og:url: https://daily.dev/posts/apparently-the-frontend-framework-i-wanted-already-existed-a1r5v80fk og:image: https://api.daily.dev/og/posts/a1R5v80Fk.png og:image:alt: Apparently the Frontend Framework I Wanted Already Existed og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Apparently the Frontend Framework I Wanted Already Existed **[loman](https://daily.dev/sources/avk0fm9g4cjeuutyalk2j)** · [@loman](https://daily.dev/loman) · 11 min read · 47 upvotes · 11 comments ## Summary A long-time Vue developer recounts years of evaluating frontend frameworks (React, Solid, Qwik, Astro, HTMX) while disliking JSX and wanting a compiler-driven, HTML-first architecture with fine-grained reactivity and no virtual DOM. After starting to build a custom framework in JavaScript and Go, the author discovers Marko already implements nearly the exact model they wanted: HTML-first syntax, compile-time dependency analysis, fine-grained interactivity boundaries independent of component boundaries, and server-rendering-first architecture instead of bolted-on hydration. The piece is a personal reflection acknowledging Marko's smaller ecosystem and tooling tradeoffs while praising its architectural alignment with the author's preferences. ## Content I've been looking for a frontend framework like Marko for a long time, although I didn't actually know I was looking for Marko. I've worked professionally in Vue for years, and over that time I've spent an unreasonable amount of energy looking at basically every frontend framework that seemed like it might fix the things that bother me about modern frontend development. React, Solid, Qwik, Astro, HTMX, smaller experimental frameworks, weird compiler projects... pretty much anything that looked like it was trying to rethink the same pile of problems instead of just rearranging them. The annoying part was that I kept liking pieces of all of them. React obviously has the ecosystem, and regardless of how much people enjoy fighting about it, it changed how frontend applications are built. Solid takes a lot of the things React developers actually like and gives them a much better reactive model. Qwik is even more interesting to me because it questions hydration itself and asks why the browser should repeat work the server already did. Then I look at the code and, somehow, there it is again... ## JSX I know JSX won. I know millions of people love it, and I know someone will happily explain to me that JSX isn't actually HTML and that, technically, that's the entire point. I understand the argument. I still hate it. I've just never liked the idea that building interfaces should start with JavaScript and then bolt on a syntax that looks vaguely like HTML. It obviously works, but it's always felt backwards to me. I want markup to feel like markup, JavaScript to feel like JavaScript, and the compiler to be responsible for figuring out how those pieces become an application. That is probably a big part of why Vue always made more sense to me. ## Vue Got Closer A Vue single-file component still looks like the web. There's a template, there's JavaScript, there's CSS, and I don't have to mentally pretend they're all the same thing just because the framework technically can. For a long time, that was enough. But the more I've learned about rendering models, compiler design, resumability, fine-grained reactivity, SSR, and what the browser is actually doing underneath all these abstractions, the less interested I've become in frameworks that mostly give me a nicer way to manage runtime complexity. I don't really want a better virtual DOM anymore. Increasingly, I don't want one at all. I don't want the browser reconstructing information it already received from the server. I don't want component boundaries deciding how much JavaScript gets shipped, and I don't want static content getting dragged into a giant client-side application just because something interactive happens to exist nearby. Static things should be static. Interactive things should be interactive. The compiler should be smart enough to know the difference. That feels like it should be a painfully boring opinion, but frontend development has somehow managed to turn it into architecture. ## What I Actually Wanted After looking at enough frameworks that each got 70 or 80 percent of the way toward what I wanted, I eventually stopped thinking in terms of individual frameworks and started thinking about the model itself. What did I actually want? No JSX. No virtual DOM. Fine-grained reactivity. HTML as the primary language. A compiler doing as much of the work as possible. Server rendering built into the architecture instead of bolted onto it afterward. Very little JavaScript unless something on the page genuinely required JavaScript. I wanted components because they're useful for organizing software, not because I wanted every component boundary to become some sacred runtime concept. I wanted the server and browser to behave like two parts of the same system instead of two applications awkwardly handing control back and forth. Most of all, I wanted the compiler to know enough about the application that I didn't have to keep telling it things it should already be able to figure out. At some point, that turned into the much more dangerous thought every developer eventually has: Maybe I should just build the damn thing. ## So I Started Building It And I actually did. Not because I thought I was going to casually replace React over a weekend, but because I wanted to understand what the architecture would look like if I started with the constraints I cared about instead of inheriting someone else's. I played with that model in JavaScript first — no JSX, no virtual DOM, fine-grained signals, serializable state, compiler-driven updates, and as little runtime machinery as I could reasonably get away with. Then, because apparently I wasn't making my life difficult enough, I started thinking about what the same idea would look like in Go. Go source goes into a compiler. Static HTML comes out. A tiny JavaScript runtime handles the parts that actually need to be interactive, with some serialized representation of the reactive graph giving the browser only what it needs to continue. Was that necessarily the right architecture? I had no idea. That wasn't really the point. The point was that I'd stopped shopping for frameworks and started trying to understand the problem well enough to design one. By then I had backed myself into a pretty specific set of architectural preferences, and I was mostly trying to figure out whether anyone else had built around the same ideas. Then I tried Marko. ## Then I Tried Marko The weird part wasn't that Marko showed me some completely foreign way of thinking about frontend development. It was the opposite. It felt familiar, almost annoyingly so. Marko starts from HTML. That sounds like marketing until you actually use it, but the distinction matters. React starts with JavaScript and gives JavaScript a way to describe UI. Marko feels much closer to starting with HTML and asking what HTML needs in order to become an application language. Apparently that difference matters to me more than I realized. The syntax itself wasn't even what really sold me. Not having JSX was mostly just the first sign that Marko was approaching the problem from a direction I already liked. The more I looked underneath it, the more interesting it became. ## The Compiler Is What Got Me Marko analyzes reactive dependencies at compile time, which means updates can be targeted directly instead of building a virtual representation of the page and diffing it against another virtual representation of the page because, apparently, we all collectively decided that was a perfectly normal thing to do. That immediately made sense to me. Then I started looking at how Marko handles client-side JavaScript, and that was probably the point where I really started paying attention. Marko can analyze interactivity at a much finer level than the component itself. Static content can stay static even when it lives inside the same component as something interactive, which means your component boundaries can remain an organizational decision instead of accidentally becoming a network-performance decision. I love that. If I split something into a component because it makes the code easier to maintain, why should that automatically mean the browser now needs another chunk of JavaScript? Those are two completely different concerns. One exists for developers, the other exists at runtime, and I'd rather have the compiler understand that difference than force me to restructure the application around whatever happens to bundle well. This is one of the things that kept coming up while I was thinking about building my own framework. If the compiler can see the whole picture, why am I manually drawing boundaries around things it should be capable of understanding itself? Make the compiler smarter. Make the runtime dumber. That trade makes a lot of sense to me. ## Then There's the Server The server side of Marko was another one of those moments. One of the stranger things we've normalized in frontend development is having the server do a bunch of work, send the result to the browser, and then have the browser do another bunch of work to reconstruct what it was just given. We call that hydration, which sounds considerably nicer than "doing some of this twice." Marko's model is much closer to what I've wanted: render on the server, stream HTML when possible, serialize the state needed by the interactive parts, and let the browser continue from there instead of pretending the page was born on the client. Again, Marko isn't the only framework thinking about this stuff. Qwik has done an enormous amount of work around resumability. Solid has excellent fine-grained reactivity. Astro has pushed hard on shipping less JavaScript in the first place. There are a lot of smart people attacking different parts of the same problem. What surprised me about Marko was how many of those ideas showed up together, inside a framework that still felt fundamentally HTML-first. That was the combination I had been looking for. ## I'm Not Joining a Cult Now, I'm not about to turn this into one of those framework articles where someone discovers a technology on Tuesday and by Thursday everyone still using React is apparently a moron. Marko has tradeoffs. Its ecosystem is obviously nowhere near React's. The tooling isn't always as frictionless as what you get inside the giant React/Vue gravity well. There are syntax choices that still make me stop and stare at them for a second, and using a smaller framework always means accepting that eventually you may become the first person on Google to encounter your particular stupid problem. That matters, especially in actual companies. Technical elegance is not the only thing that decides whether a framework is a good business choice, and "I really like how this compiler works" is not, by itself, a migration strategy. I'm also still early enough with Marko that it would be ridiculous for me to claim I've found the final answer to frontend development. I haven't. I may eventually find something in Marko that drives me completely insane. Honestly, that's usually how this goes. But what I have found is the first framework in a long time that doesn't immediately make me start redesigning it in my head. ## That's the Part That Got Me Usually I try a framework and think, "I like this, but I'd change this part." Then another part. Then another. Eventually I've mentally replaced half the framework with the thing I actually wanted, which is more or less how I ended up experimenting with building my own in the first place. With Marko, I kept having the opposite experience. I'd read another part of the architecture and think, yeah... that's roughly what I wanted. Then I'd keep reading and realize they'd already thought about another problem I had been trying to solve. That was equal parts satisfying and irritating. There's something humbling about spending months circling a set of ideas, thinking you're slowly assembling the shape of the framework you wish existed, only to discover that another team has been exploring many of those same ideas for years. There's also something reassuring about it. It means the things that were bothering me weren't imaginary, and the constraints I kept arriving at weren't completely insane. I hadn't invented some brilliant new model of frontend development. In a lot of cases, I'd just independently stumbled toward problems that other people had already spent a very long time thinking about. And honestly, that's probably more useful. ## Apparently I Was Looking for Marko I wasn't really looking for "a better React." I wasn't looking for "Vue, but faster." I wasn't even looking for "Solid without JSX," although I would've happily taken that too. I was looking for a frontend model where HTML could remain HTML, JavaScript existed because something actually needed JavaScript, the compiler was responsible for eliminating unnecessary work, and the server and browser behaved like two parts of the same system instead of two applications awkwardly negotiating custody of the page. I wanted fine-grained reactivity without a virtual DOM. SSR without treating the server as an afterthought. Components without making component boundaries sacred. Performance that came from the architecture instead of a checklist of optimizations I had to remember after everything was already built. And, yes, I wanted all of that without JSX. Seriously. No JSX. I'm still not going to tell anyone to rewrite their application in Marko. I'm not even sure yet where Marko ultimately fits into the things I build. But after years of trying frameworks where my reaction was almost always some variation of "this is close, but..." Marko was the first one in a long time that made me stop and think: Wait. This is basically what I've been looking for. Apparently the frontend framework I wanted had been sitting there the entire time. I was just busy trying to invent it. ## Community discussion Top comments from developers on daily.dev. **@apperside** · 4 upvotes > I didn't know about Marko, but this excellent article made me want to absolutely try it 🙂 **@user45613** · 3 upvotes > "It felt familiar, almost annoyingly so." - so true; great article!!! **@opensas** · 2 upvotes > Just out of curiosity, have you tried SvelteKit? It seems like it might tick most of the features you are looking for **@goldene\_avocado** · 1 upvotes > No offense but i aint reading allat **@ristotoldsep** · 1 upvotes > ‘Static things should be static’ shouldn’t feel radical, yet here we are. ## Similar posts on daily.dev - [After 8 Years of Building With React, I Started My Last Project Without It](https://daily.dev/posts/after-8-years-of-building-with-react-i-started-my-last-project-without-it-niszlr77n) · Medium · 34 upvotes · 9 comments - [Modern Frontend Complexity: essential or accidental?](https://daily.dev/posts/modern-frontend-complexity-essential-or-accidental--yrurnb4gq) · Lobsters · 2 upvotes · 0 comments - [Why Vanilla JS](https://daily.dev/posts/why-vanilla-js-cz2v0zzj5) · Hacker News · 99 upvotes · 25 comments - [The front-end architecture trilemma: Reactivity vs. hypermedia vs. local-first apps](https://daily.dev/posts/the-front-end-architecture-trilemma-reactivity-vs-hypermedia-vs-local-first-apps-tmledjdds) · InfoWorld · 19 upvotes · 0 comments - [Mastering Frontend Tradeoffs: The 2026 Guide for Senior Devs](https://daily.dev/posts/mastering-frontend-tradeoffs-the-2026-guide-for-senior-devs-rrh1cjln0) · The New Stack · 131 upvotes · 13 comments --- Tags: [#webdev](https://daily.dev/tags/webdev), [#jsx](https://daily.dev/tags/jsx) [View this post on daily.dev](https://daily.dev/posts/apparently-the-frontend-framework-i-wanted-already-existed-a1r5v80fk) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"DiscussionForumPosting","mainEntityOfPage":"https://daily.dev/posts/apparently-the-frontend-framework-i-wanted-already-existed-a1r5v80fk","headline":"Apparently the Frontend Framework I Wanted Already Existed","text":"A long-time Vue developer recounts years of evaluating frontend frameworks (React, Solid, Qwik, Astro, HTMX) while disliking JSX and wanting a compiler-driven, HTML-first architecture with fine-grained reactivity and no virtual DOM. After starting to build a custom framework in JavaScript and Go, the author discovers Marko already implements nearly the exact model they wanted: HTML-first syntax, compile-time dependency analysis, fine-grained interactivity boundaries independent of component boundaries, and server-rendering-first architecture instead of bolted-on hydration. The piece is a personal reflection acknowledging Marko's smaller ecosystem and tooling tradeoffs while praising its architectural alignment with the author's preferences.","url":"https://daily.dev/posts/apparently-the-frontend-framework-i-wanted-already-existed-a1r5v80fk","datePublished":"2026-09-27T23:10:09.404Z","dateModified":"2026-09-27T23:10:30.857Z","author":{"@type":"Person","name":"loman","url":"https://daily.dev/loman","image":"https://avatars.githubusercontent.com/u/71104656?v=4","description":"I create things, I break things, I write them down. Repeat.","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":440}},"image":"https://media.daily.dev/image/upload/s--uCt3c69a--/f_auto/v1790550609/posts/a1R5v80Fk?_a=BAMAMicg0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":47},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":11}],"comment":[{"@type":"Comment","text":"I didn’t know about Marko, but this excellent article made me want to absolutely try it 🙂","datePublished":"2026-09-29T02:13:06.526Z","url":"https://daily.dev/posts/a1R5v80Fk#c-zMpVBVFyl","author":{"@type":"Person","name":"Apperside","url":"https://daily.dev/apperside","image":"https://avatars.githubusercontent.com/u/5955338?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4}},{"@type":"Comment","text":"“It felt familiar, almost annoyingly so.” - so true; great article!!!","datePublished":"2026-09-28T07:37:15.392Z","url":"https://daily.dev/posts/a1R5v80Fk#c-bnza2nz97","author":{"@type":"Person","name":"Veselin Ivanov","url":"https://daily.dev/user45613","image":"https://media.daily.dev/image/upload/s--nc0o8dM8--/f_auto/v1782457323/avatars/avatar_JYf2mTyl8QY4B2HJp3soD?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"Just out of curiosity, have you tried SvelteKit? It seems like it might tick most of the features you are looking for","datePublished":"2026-09-30T17:36:06.201Z","url":"https://daily.dev/posts/a1R5v80Fk#c-luiQV642G","author":{"@type":"Person","name":"opensas","url":"https://daily.dev/opensas","image":"https://avatars.githubusercontent.com/u/481687?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"No offense but i aint reading allat","datePublished":"2026-09-30T04:29:43.400Z","url":"https://daily.dev/posts/a1R5v80Fk#c-G6WEGHGfh","author":{"@type":"Person","name":"Daniel","url":"https://daily.dev/goldene_avocado","image":"https://avatars.githubusercontent.com/u/275533154?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}},{"@type":"Comment","text":"‘Static things should be static’ shouldn’t feel radical, yet here we are.","datePublished":"2026-10-02T11:41:01.616Z","url":"https://daily.dev/posts/a1R5v80Fk#c-n9iDdAcAj","author":{"@type":"Person","name":"Risto Tõldsep","url":"https://daily.dev/ristotoldsep","image":"https://lh3.googleusercontent.com/a/ACg8ocLDWc6mZn0JwNmXXw6WY0L_HJ6pegzRttooC5VgtXESHSj3MNYx=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/sources/avk0fm9g4cjeuutyalk2j","name":"loman"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"loman","item":"https://daily.dev/sources/avk0fm9g4cjeuutyalk2j"},{"@type":"ListItem","position":3,"name":"Apparently the Frontend Framework I Wanted Already Existed"}]} ```