I built the same app 10 times: Evaluating frameworks for mobile performance

> This isn’t a todo list with hardcoded arrays. It’s a real app with database persistence, complex state management, and the kind of interactions you’d actually build for a real product.

Can you also tell ChatGPT to fix the layout so the table just above this message is fully visible without horizontal scrolling?

In our small firm, we did a review of the usual suspects when deciding which of the big players would be the right horse to bet on for the future when planing to rewrite our core application.

We ended up with Vue vs. Svelte and landed on Vue/Nuxt since we agreed they have the most intuitive syntax for us, and it seemed like the one with the best trajectory, technologically speaking.

That was one year ago. It's not moving as fast as I would hope, but I still think Vue/Nuxt is a better choice than React at least. This article seems to support this somewhat.

Also, I did a review (with the help of all the big LLMs), and they seem to agree that Vue has the syntax and patterns that are best suited for agentic coding assistance.

The wins with regards to "First Contentful Paint" and "size" is not the most important. We just trust the Vue community more. React seems like a recipe for a bloated bureaucratic mess. Svelte still looks like a strong contender, but we liked the core team of Vue a lot, and most of us just enjoy Vue/Nuxt syntax/patterns better.

This is great write up. I especially appreciate the focus on mobile, because I find it's often overlooked, even though it's dominant device to access the web. The reality of phones is brutal and delivering a good experience for most users in SPA-style archictecture is pretty hard.

"Slowness poisons everything."

Exactly. There's nothing more revealing than seeing your users struggle to use your system, waiting for the content to load, rage clicking while waiting for buttons to react, waiting for the animations to deliver 3 frames in 5 seconds.

Engineering for P75 or P90 device takes a lot of effort, way beyond what frameworks offer you by default. I hope we'll see some more focus on this from the framework side, because I often feel like I have to fight the framework to get decent results - even for something like Vue, which looks pretty great in this comparison.

This is a really good article. It’s not my bailiwick, but it must be extremely useful for folks that work in this space.

> When someone’s standing in front of a potential buyer trying to look professional, a slow-loading app isn’t just an annoyance. It’s a liability.

I liked reading that. It’s actually surprising how few developers think that way.

> Mobile is the web

That’s why.

I know many people that don’t own a computer, at all, but have large, expensive phones. This means that I can’t count on a large PC display, but I also can reasonably expect a decent-sized smaller screen.

I’ve learned to make sure that my apps and sites work well on high-quality small screens (which is different from working on really small screens).

The main caveat, is the quality of the network connection. I find that I need to work OK, if the connection is dicey.

Before starting new projects I would always do research like this and try new things. But I’ve stopped looking at what is out there. I have landed on Django/React(vite). I have mastered this and can go from idea to app running in production in a matter of hours. I know there are better, faster, and more modern alternatives. But I just don’t care anymore. Maybe I’m just web framework jaded. I rather learn something else than look through the docs of yet another web framework.

As somebody using Svelte for a real production application, I can only 100% agree with their recommendations regarding Svelte because of the overall dev experience is unmatched. It just feels right. Easy. Simple. And I'm not even considering performance here as another benefit.

I usually make the analogy of a video game, where you can pick the difficulty. Svelte/SvelteKit is working in the "easy" difficulty level. You can achieve the same end result and keep your sanity (and your hair).

> when I built the first implementations and started measuring, something became clear: the issues I was seeing with Next.js weren’t specific to Next.js. They were fundamental to React’s architecture.

So here some obscure Next.js issues magically become fundamental React architecture issues. What are these? Skill issues?

The author noted that Solid is very similar to React but with a simpler mental model. This has been my experience as well. And its faster too.

I believe the biggest performance hit lives in je inability to force reload a cached file with js (or even html(!)).

Setting a header only works if you know exactly when you are going to update the file. Except from highly dynamic or sensitive things this is never correct.

You can add ?v=2 to each and every instance of an url on your website. Then you update all pages which is preposterous and exactly what we didn't want. As a bonus ?v=1 is not erased which might also be just what you didn't want.

I never want to reload something until I do.

Ignoring the content of the post for a second (which IMO was excellent), the quality of the writing here is remarkable. This is a dry technical topic at heart and yet i enjoyed reading that entire report. It was as informative as i could hope for whilst still being engaging.

What a joy to read.

This is a great comparison, but it depends so much on what sort of website or web app you are building. If you are building a content site, with the majority of visitors arriving without a hot cache bundle size is obviously massively important. But for a web app, with users regularly visiting, it's somewhat less important.

As ever on mobile it's latency, not bandwidth, that's the issue. You can very happily transfer a lot of data, but if that network is in your interactive hot path then you will always have a significant delay.

You should optimise to use the available bandwidth to solve the latency issues, after FCP. Preload as much data as possible such that navigations are instant.

I am the only one shocked that no comparison or test or thinking of native development? Web dev are this closed to other languages? I came here for this kind of comparison because of the article. headline