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

Also

> This isn’t just an inconvenience. It’s technofeudalism.

There are so many of these in the article. It's like a spit to the face

Yeah the writing is obvious ChatGPT-slop sadly.

Edit: Related post on the front page: https://news.ycombinator.com/item?id=45722069

Not sure why so much love for the idea the article is slop. I suffer through slop regularly and this article didn't press that button for me at all.

I've been using Svelte's custom elements (web components) to make components that slot into pages on an existing .net / alpine.js site. It's been a great dev experience and results in really portable components. Each component is it's own bundle (achieved via separate vite configs - you can also organise to bundle groups of components work together). Each of the tools in the tools section is a svelte custom element https://www.appsoftware.com/tools/utilities/calculators

I will keep using Next.js, because that is what SaaS vendors support on their extension SDKs, and I have better things to do than build an ecosystem.

Alternatives are great for those without these kinds of constraints.

In which case, I rather use traditional Java and .NET frameworks with minimal JavaScript, if at all.

I would choose vue because you can still get paid for it but react is king by jobs. If you're playing in the hobby space then between liveview, datastar etc, there is plenty of cool stuff moving the needle. React is nice and simple IMHO which is why average devs like me enjoy it.

Hmm but Svelte docs is one of the most unfriendly I ever read through.

A big advantage with Vue is also that it has options and composition API, so if one feels janky you can still try the other. I've tried moving away from Vue just to test some other frameworks but none have given me such an easy way to manage state, reactivity, modularity... I always come back to it.

vue is better, the problem is it's been dead for more than 3 years now.

> 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've been there myself as a Dev and later on as a manager. You have to really watch out not getting locked into local minima here. In most cases its not bundle size that wins this but engineering an app that can gracefully work offline, either by having the user manually pre-load data or by falling back to good caches.

To be honest, as long as your app isn’t doing something crazy complex, it’s going to be fast enough for most people even on the slowest stack. I wouldn’t worry about it, personal efficiency is way more important most of the time I’d say.

> Maybe I’m just web framework jaded.

At the end of the day there have been a lot of new things in web development but none of them are of such a significance that you’re missing out on anything by sticking with what works. I personally just like to go with a mature backend framework (usually Laravel or Django) and minimal JS on the frontend. I’ve tried many of the shiny new libraries but have not seen much reason to switch over.

I’ll speak for you:

You’ve stopped caring because it. never. ends. Really.

It’s 10,000 words and a curious mixture of dense and sparse. There’s quite a bit of duplication (especially of figures), a fair bit of circumlocution in the narrative sections, and a lot of meaninglessly precise figures, half of which should have been omitted altogether. I am confident it could be significantly improved by a hard cap of 5,000 words, and suspect even 2,000 words could still be better (though 1,000 would definitely be too short to convey it all). Even apart from that, it definitely needed a table of contents, to set expectations.

As a general challenge to people: write your article, then see if you can halve its length without losing much. If it felt too easy, repeat the process! There’s a family of well-known quotes that amount to “sorry for writing a long letter, I didn’t have time to write a short letter”. Concise expression is not the easiest, but very valuable. Many a 100-page technical book can be improved by reduction to a one-page non-prose overview/cheat sheet (perhaps using diagrams and tables, but consider going more freeform like you might on a whiteboard) plus a ten page abridged version.

Mhh, I found it repeated sentences again and again. It was kinda odd to read at times.

This isn't just poor writing, it's ChatGPT-padded slop.

But the same is true for the content itself, no business is paying you to actually build the same app 10x, especially so if it's something as trivial as a kanban board.

I'm a fan of Solid for the same reasons.

I particularly like that (JSX aside) it's just JavaScript, not a separate language with its own compiler like Svelte (and by the sounds of it Marko, which I hadn't heard of before). You can split your app into JS modules, and those can all use Solid signals, even the internal bits that don't have their own UI.

How would you compare it to Preact?

It's not about being closed to other languages, it's about being economically pragmatic in many, many cases.

As shown in the article, you can build ONCE an app that loads in milliseconds by just providing an url to any potential customer. It works on mobile and on desktop, on any operating system.

The native alternative requires:

- Multiple development for any platform you target (to be widely used you need *at least* ios, android, macOS and windows.) - Customers are required to download and install something before using your platform, creating additional friction.

And all of this to obtain at most 20-30ms better loading times?

There are plenty of cases where native makes sense and is necessary, but most apps have very little to gain at the cost of a massive increase in development resources.

Native to the web like web components or a native platform?

The problem of native apps isn't the language but the app stores.

Web deployment is easier, faster and cheaper.

The article is a bit disappointing in that it focuses too much on bundle size. Bundle size is important for sure, especially in rural areas with poor mobile signal, but time-to-interactive is imho more important, and that's where resumable frameworks like qwik and marko6 shine

Solid is great for raw rendering speed, but it hydrates just like react (unless you use an islands framework on top like astro which has its own limitations), while qwik and marko are resumable out of the box

This is a solved problem. All modern javascript bundlers append a hash to the filename, so even if cached indefinitely the js that hits the browser will update when it has changed as the url will change.

There are also other solutions if you need to preserve the url that are cleaner than appending a query string, like etags

The standard solution is to have small top-level HTML files with short expiration (or no caching at all), then all the other assets (CSS, JS, images) have content-hashed filenames and are cached indefinitely.

Vite gives you that behaviour out of the box.

I'm not exactly sure why "big" but it's slow because it has worse change tracking and rendering model, which requires you to do more work to figure out what needs to be updated, unless you manually opt-out when you know. Solid, Vue and other signals based frameworks have granular change tracking, so they can skip a lot of that work.

But this mostly applies to subsequent re-renders, while things mentioned in the article are more about initial render, and I'm not exactly sure why does React suffer there. I believe React can't skip VDOM on the server, while Vue or Solid use compiled templates that allow them to skip that and render directly to string, so maybe it's partially that?

When react came out, it was much faster than its competition. but then others learned from react and improved upon it.

however, React didn't copy from others, so it got slower than "competition"

It is pretty established at this point that React has (relative) terrible performance. React isn't successful because it's a superior technology, it's successful despite being an inferior technology. It's just really difficult to beat an extremely established technology and React has a huge ecosystem, so many companies depend on it that the job market for it is huge, etc.

As to why it is slow, my knowledge is super up-to-date (haven't kept up that well with recent updates), but in general the idea is:

- The React runtime itself is 40 kB so before doing anything (before rendering in CSR or before hydrating in SSR) you need to download the runtime first.

- Most frameworks have moved on to use signals to manage state updates. When state change, observers of that state will be notified and the least amount of code will be run before updating the DOM surgically. React instead re-executes the code of entire component trees, compares the result with the current DOM and then applies changes. This is a lot more work and a lot slower. Over time techniques have been developed in React to mitigate this (Memoization, React Compiler, etc.), but it still does a lot more work than it needs to, and these techniques are often not needed in other frameworks because they do a lot less work by default.

The js-framework-benchmark [1] publishes benchmarks testing hundreds of frameworks for every Chrome release if you're interested in that.

[1]: https://krausest.github.io/js-framework-benchmark/2025/table...

React isn't slow. It can be pretty fast (thanks to hooks like useTransition or useOptimistic, and now React Compiler, etc.) - it's just that it takes a lot of learning and work to use React correctly. Some people don't like that, and that's why other frameworks with different trade-offs exist.

The other thing is that React is too big in terms of kBs of JavaScript you have to download and then parse (and often, thanks to great React ecosystem, you use many other libraries). But that's just another trade-off: it's the price you pay for great backwards compatibility (e.g. you can still use React Class components, you don't have to use hooks, etc.).

Honestly I don't know about mobile apps but React for a desktop website has no performance issue provided that the code is of sufficient quality.

That is a decision that the React team decided to make and it alienated many of its users.

What do you hope to see from the result of that comparison?

but next's dx is no longer good. vite has much better dx, the proof lies in the number of vite based frameworks in the post

Reasons are given near the end:

> Here’s where this gets bigger than framework choice. When you ship a native app to the App Store or Google Play instead of building a web app, you’re not just making a technical decision. You’re accepting a deal that would’ve been unthinkable twenty years ago. Apple and Google each take up to 30% of every transaction (with exceptions depending on program and category). They set rules. They decide what you can ship. They can revoke your access tomorrow with no recourse. You have no alternative market. You can’t even compete on price because the fee is baked into many transactions.

Appstores complicate lifecycles by orders of magnitude.

> some Web Applications just require low latency high bandwidth internet to work properly.

But the vast majority do not. And this haranguing is an opportunity / defensible position to put more efforts and resources into performances. If nothing else, think of it as a Trojan horse to make software suck less.

> That thinking is what gets you things like mandatory login via apps for your desktop.

"the web is mobile" = strictly "apps" ?

All of them can, but you get most benefit of a full-stack javascript framework if you are indeed running server js. But you can build statically in any of them (assuming you are not using any server-only features) and deploy as plain html/js.

Yeah, Svelte can.

Nuxt can too

See Performance Inequality Gap https://infrequently.org/2024/01/performance-inequality-gap-...

Your attitude is exactly why our supercomputers struggle to display even the simplest things with any kind of performance, and why pure text takes multiple seconds to appear

JS can be 100x or even 1000x times more expensive to process than images. JS also blocks the main thread, while images can be processed in the background (and on GPU).

If it was only 150kB for most sites. Usually that's followed up with multiple assets, API calls, often chained. Making the site slow.

The app in the article is a relatively simple demo app. These are the build times and sizes from a real relatively large react SPA I help maintain

  dist/assets/app.css   98.33 kB │ gzip:  17.69 kB
  dist/assets/app.js    1,050.14 kB │ gzip: 244.88 kB
   built in 15.41s

Yes, it matters a lot, especially on mid/low end devices.

A maintainer refactored the Analog app, so it's doing much better than before. The post has been updated.

Does that involve shipping a native wrapper for your web app?

If so, you have the extra cost, effort and bureaucracy of building and deploying to all the different app stores. Apple's App Store and Google Play each have various annoyances and limitations, and depending on your market there are plenty of other stores you might need to be in.

Sometimes you do need a native or native-feeling app, in which case a native wrapper for JS probably is a good idea, other times you want something lightweight that works everywhere with no deployment headaches.