10 ms·

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

237 points by 0xblinq 1y ago

chanon 1y ago
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.
- fud101 1y ago
  How would you compare it to Preact?
  - chanon 1y ago
    Never used Preact so unsure
- iainmerrick 1y ago
  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.
deleted 1y ago
[deleted]
ochre-ogre 1y ago
Any reason the url is '10-kanban-boards'? I noticed this when I copied the url to share.
0xblinq 1y ago
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).
- appsoftware 1y ago
  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 https://www.appsoftware.com/tools/utilities/calculators
  - aitchnyu 1y ago
    Can we build the elements as part of light dom? Do they call their destructor when we navigate away?
- fud101 1y ago
  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.
  - MarcelOlsz 1y ago
    >React is nice and simple IMHO which is why average devs like me enjoy it. Maybe years ago. Now it's a bloated beast.
    - nawgz 1y ago
      Can you give some examples? I feel like React is still pretty much just React, having developed with it for a decade now. Hooks was the only meaningful API (surface) change, no?
      - brazukadev 1y ago
        https://react.dev/reference/react-compiler/directives/use-no-memo https://react.dev/reference/react-compiler/directives/use-no... "use no memo" react now needs you to declare what you are not using, using a language "feature" that does not exist. It is crazy how people keep denying reality wrt React.
IlikeKitties 1y ago
> The web is mobile. Build for that reality. Ugh. That thinking is what gets you things like mandatory login via apps for your desktop. And not every application makes sense on a phone. And some Web Applications just require low latency high bandwidth internet to work properly.
- masklinn 1y ago
  > 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.
  - IlikeKitties 1y ago
    >If nothing else, think of it as a Trojan horse to make software suck less. My experience has been that the proliferation of mobile devices has made my desktop experience consistently worse and I struggle to come up with an example where it didn't.
  - exe34 1y ago
    > But the vast majority do not. yeah and that's why they are shit and barely work. Even a php app without decorations would be faster and better for most applications.
- HelloUsername 1y ago
  > That thinking is what gets you things like mandatory login via apps for your desktop. "the web is mobile" = strictly "apps" ?
hi_hi 1y ago
I'd be interested in seeing React Native in this comparison. I'm not overly familiar with it, but we use it at work. I've no idea if I should expect it to be quicker or slower than something like Next.
- koolala 1y ago
  What do you hope to see from the result of that comparison?
  - hi_hi 1y ago
    To gauge where RN sits on the spectrum of fast to slow.
bschwindHN 1y ago
(I'll be that guy since the article emphasizes a good mobile web experience so hard) You might want to fix your horizontal scroll on mobile. I should basically never have a full page horizontal scrollbar on a page that is mostly just text.
koolala 1y ago
Can Marko run static without a server? Can any of these?
- aetherspawn 1y ago
  Yeah, Svelte can.
  - jakewins 1y ago
    Can’t most of them? Certainly React and Angular can as well.
- mulhoon 1y ago
  Nuxt can too
- mpeg 1y ago
  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.
mrasong 1y ago
This post made me open up the Svelte docs again.
CraigJPerry 1y ago
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.
- Mashimo 1y ago
  Mhh, I found it repeated sentences again and again. It was kinda odd to read at times.
- input_sh 1y ago
  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.
  - mkl 1y ago
    They'd comfortably pay for 10 AI-assisted versions. It's a trivial demo app so that implementing it 10 times is feasible - it's just to learn what to build their main app in.
    - input_sh 1y ago
      I wouldn't measure how good/fast/performant a library is looking at the results of the very first LLM attempt at doing a trivial task using that library. If you don't know the libraries well enough to spot some improvements the LLM missed, the only thing you're judging is either how sane the defaults are or how good the LLM is at writing performant code using that library, none of which are equivalent to how good the library is. Also, performing well in a prototype scenario is very different than performing well in production-ready scenario with a non-trivial amount of templates and complex operations. Even the slowest SSGs perform fast when you put three Markdown posts and one layout in them, but then after a few years of real-world usage you end up in a scenario where the full build takes about half an hour. Kinda cool that you can do that in an afternoon, but absolutely useless as a benchmark of anything.
grebc 1y ago
Thanks for posting, a lot of effort went into that and I think the quality shines through in the write up. I write pretty lean HTML/vanilla JS apps on the front end & C#/SQL on the backend; and have had great customer success on mobiles with a focus on a lot of the metrics the author hammers home.
Akhu117 1y ago
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
- croes 1y ago
  The problem of native apps isn't the language but the app stores. Web deployment is easier, faster and cheaper.
- ale 1y ago
  Native to the web like web components or a native platform?
- gbalduzzi 1y ago
  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.
evertheylen 1y ago
Interesting to see Marko and Solid topping the performance metrics. Ryan Carniato* was a core team member of Marko and started Solid. I wouldn't be surprised if SolidStart can eventually lower its bundle size further. *) https://github.com/ryansolid https://github.com/ryansolid
- mpeg 1y ago
  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
  - senjin 1y ago
    I wish he would have combined Astro with solid instead of HTMX for a more direct comparison
speedgoose 1y ago
> 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?
- sunaookami 1y ago
  Yeah the writing is obvious ChatGPT-slop sadly. Edit: Related post on the front page: https://news.ycombinator.com/item?id=45722069 https://news.ycombinator.com/item?id=45722069
  - lorenstewart 1y ago
    Jeez! Y'all are quite harsh. I wrote this in sections and then tried to stitch it all together. I did my best to remove repetition, but overall it's my writing edited with the help of AI to moderate some of my personal biases. The value here is both checking out the code (written by me with the help of the maintainers of each framework) as well as tables for lighthouse scores and bundle sizes. I personally think the most important parts of the post are these two related parts: (1) the technofeudalism section (2) developing lightweight apps so a business does not feel the need to have a separate native codebase along with a specialized native team ($$$). I was hoping this post was a gift to many people by doing all this work for y'all, or at least providing a foundation from which you can fork and modify for your own use. It is an open question for everyone if start up time on cellular is something you need to worry about. All the other non-sense here misses the point.
  - lukan 1y ago
    Can you guys share actual errors in the article, that indicate real slop? On first glance it seems very legit and personally I would be very hesistant judging something GPT slop based on some writing style.
    - xnorswap 1y ago
      How about this? >> Marko delivers 12.6 kB raw (6.8 kB compressed). Next.js ships 497.8 kB raw (154.5 kB compressed). That’s a 39x difference in raw size that translates to real seconds on cellular networks. Sorry, it isn't 2006, cellular networks aren't spending "seconds" in the difference between 13kB and 500kB. Payload size can matter, but it's complete nonsense that 500kB would translate to "real seconds". Just spotted this section: >> The real-world cost: A 113 kB difference at 3G speeds (750 kbps) means 1.2 seconds for download plus 500ms to 1s for parse/execution on mobile CPUs. Total: 1.5 to 2 seconds slower between frameworks. 3G is literally being decommissioned, and 3G isn't 750kbps, it's significantly faster than that. > On first glance it seems very legit Yes, that's exactly the danger of AI slop. It's very plausible, very slick and very easy to digest. It also frequently contains unchecked errors without any strong signals that would traditionally go along with that.
ale 1y ago
Comparing something like next.js to other frameworks doesn’t make much sense anymore given that most webdevs choose DX and easy deployment above anything else. Vercel’s growth is proof of that.
- rk06 1y ago
  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
gethly 1y ago
I prefer to use whatever I'm more comfortable with than something that is measurably the fastest horse in the stable. Trading dev time, skill and comfort for few kb of memory and few ms of speed seems pointless to me. By the way, my "horse" of choice is Quasar(based on Vue) and has been for years now.
jtrn 1y ago
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.
- zwnow 1y ago
  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.
- hdjfjkremmr 1y ago
  vue is better, the problem is it's been dead for more than 3 years now.
  - qmmmur 1y ago
    What do you mean? Vue is perfectly capable and mature
  - jtrn 1y ago
    The only way this makes sense is if you are looking at the Vue 2 GitHub page. The new Vue 3 is at 52k stars on GitHub, has multiple releases per month, and is ranked 7th A-tier framework in the "State of JS" framework rankings. It holds second place in frontend framework "experience with" and "sentiment," just behind React, with 6+ million weekly downloads on socket.dev and npmstats, ahead of both Angular and Svelte. So, I guess we have a different definition of "dead."
panstromek 1y ago
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.
h33t-l4x0r 1y ago
150kb downloads almost instantly, even on 3G. Most websites have an image bigger than that somewhere on their homepage. It's not worth changing how I work.
- panstromek 1y ago
  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).
  - h33t-l4x0r 1y ago
    Nextjs with ssr is very light on client resources, I'm not sure about the other frameworks but I imagine it's comparable.
- sgt 1y ago
  If it was only 150kB for most sites. Usually that's followed up with multiple assets, API calls, often chained. Making the site slow.
  - h33t-l4x0r 1y ago
    150kb is the difference in size between the 2 frameworks. That's going to be true for all sites.
- troupo 1y ago
  See Performance Inequality Gap https://infrequently.org/2024/01/performance-inequality-gap-2024/ 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
- mpeg 1y ago
  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 At these sizes, an islands/resumable based approach can trim a ton of loading time on mobile
forrestthewoods 1y ago
Great post. Im moderately annoyed that on Safari mobile it has an incorrect and super annoying horizontal scroll.
pu_pe 1y ago
Excellent work, I love experiments like these. Unsurprisingly the site is also lightning fast to load.
ChrisMarshallNY 1y ago
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.
- theK 1y ago
  > 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.
  - ChrisMarshallNY 1y ago
    > good caches Some of the most challenging code that I write, is about caches. Writing good cache support is hard.
    - theK 1y ago
      I think writing good cache support _can_ be very, very hard. But in cases as grandparent describes, you do have significant wiggle room.
      - ChrisMarshallNY 1y ago
        I write native apps (see "not my bailiwick," above). It's fairly difficult, for me. The app can do a lot, but sometimes, the data needs to be fresh. Making the decision to run an update can be difficult. Also, I write free software, for nonprofits, so the hosting can sometimes be a bit dodgy.
deleted 1y ago
[deleted]
efilife 1y ago
> This isn’t just an inconvenience. It’s technofeudalism. > This isn’t a todo list with hardcoded arrays. It’s a real app with database persistence (appears twice) this article was written by ChatGPT. I'm tired
pbreit 1y ago
Seems overly concerned with bundle size which I'm not sure really ever matters? Certainly smaller is better but is it that big of an impact?
- panstromek 1y ago
  Yes, it matters a lot, especially on mid/low end devices.
delbronski 1y ago
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.
- jama211 1y ago
  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.
- ivape 1y ago
  I’ll speak for you: You’ve stopped caring because it. never. ends. Really.
- pell 1y ago
  > 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.
samwillis 1y ago
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.
kburman 1y ago
Any reason to not include native application given how important mobile experience was.
- PeterStuer 1y ago
  Appstores complicate lifecycles by orders of magnitude.
- mkl 1y ago
  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.
RayFrankenstein 1y ago
The guy is such a web zealot that he refuses to make the sensible engineering tradeoff that favors speed and offline capabilities over platform ubiquity. Most sane people would write a native app for this sort of thing if money was on the line.
antiloper 1y ago
> ... all deliver instant 35-39ms performance. The real differentiator? ... Thanks ChatGPT for your valuable slop. Next article.
ShaneWrn 1y ago
[dead]
econ 1y ago
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.
- mpeg 1y ago
  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
  - econ 1y ago
    I want clean urls, I don't want to update every page or dynamically stich them together for each page view, I don't want a server cache for dynamically stitched together static content. These are expensive hacks to work around a lack of basic functionality. It reminds me of one kid taking something from another and refusing to give it back because they are larger. People make websites, they think they control what goes on on the page. This isn't unreasonable to think. In fact, everything should be made to preserve that idea. A situation where they just can't change the page shouldn't exist. Abstracting it away or otherwise working around it doesn't make it any less wrong. Some browsers have a magic key combo to force reload. I suppose the solution is to put up a modal and ask the user to "reinstall" the web page. I have a lot of static pages with minimal html/css that thanks to lazy loading and caching consume very little bandwidth. The technology is truly wonderful, clicking around feels like a desktop application.
    - mpeg 1y ago
      I'm not entirely sure what your point is. You don't want the complexity of a server cache but you want "clean urls" – having a hash in a filename does not necessarily make it worse, in fact it's closer to a pure url since one of the principles of hypermedia is that each url should point to a unique resource Urls like /v2/yourfile.js are probably closer to that philosophy. Or /[hash]/yourfile.js.
t00 1y ago
Am I missing something here? The mobile SPA app can be deployed using tools like capacitor to a device and the framework along with all static content is loaded into the app bundle. In such case it makes no (realistic) difference which framework is selected and it matters more how the background/slow transfers are handled with data-only API requests, possibly with hosted images. With the background workers PWA can be built as well, streamlining installation even more.
- iainmerrick 1y ago
  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.
  - t00 1y ago
    As much as I agree with app deployment headaches, apps provide something a website cannot (except PWA) - ability to do stuff offline, log and register data which can be uploaded when connection is re-established. When talking about user experience - launching the app, selecting new -> quote -> entering details -> save -> locking the phone without worrying or waiting, knowing that it will eventually get uploaded, is much more convenient than walking with the phone around the property to get better reception to even load the new quote page. UX matters, and user does not care if the native wrapper or 500kB of js is there or not, as long as the job is done conveniently and fast.
willsmith72 1y ago
> 40ms round-trip time In that case how can you possibly get 35ms FCP? Am I missing something?
Raydii 1y ago
[dead]
android521 1y ago
it doesn't matter. in 10 years, few people will access websites directly.
gloosx 1y ago
> 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?
- brazukadev 1y ago
  That is a decision that the React team decided to make and it alienated many of its users.
ozim 1y ago
Let’s be honest: “desktop-only” is usually an excuse to skip performance discipline entirely No, it is excuse not to invest money in places where users won't pay. For questions about mobile - yeah we get requests for showing it on mobile but app in app store is hard requirement, because of discoverability. People know how to install app from app store and then they have icon. Making PWA icon is still too much work for normal people. I would need "add to home screen" button in my website that I could have user making icon with single click, then I could go with PWA.
oulipo2 1y ago
Interesting, in my case I'm using Capacitor (since I need bluetooth and it's not well supported across browsers), and I want the app to be able to work offline too for some features, so I don't really care about the bundle size (it ships with the native app) and I prefer SPA than MPA so I can build it once and ship it with the code
maelito 1y ago
If I trust this article, React is a (relative) catastrophe. Can someone explain why ? What precisely would make React sooo slow and big compared to other abstractions ?
- simjnd 1y ago
  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_chrome_141.0.7390.55.html https://krausest.github.io/js-framework-benchmark/2025/table...
  - maelito 1y ago
    > It is pretty established at this point that React has (relative) terrible performance. > it is slow You're not answering my question, just adding some more feelings. > The React runtime itself is 40 kB React is < 10 kb compressed https://bundlephobia.com/package/react@19.2.0 https://bundlephobia.com/package/react@19.2.0 (add react-dom to it). That's not really significative according to the author's figures, the header speaks about up "to 176.3 kB compressed". > Most frameworks have moved on to use signals to manage state updates. When state change This is not kilobytes or initial render times, but performance in rendering in a highly interactive application. They would not impact rendering a blog post, but rendering a complex app's UI. The original blog post does not measure this, it's out of scope.
Mashimo 1y ago
This made me look at our current app, it's a whooping 10MB just to get on the landing page. Build with Angular. .. creating a maintenance issue right now.
muzani 1y ago
I'm surprised there's no mention of Flutter. If the goal is mobile performance, Flutter would be top of mind - you can build to both native apps and web.
deleted 1y ago
[deleted]
todotask2 1y ago
Reference to SpeedCurve, they have a skip link on their home page yet nowhere id="main" was found.
alex-moon 1y ago
I greatly appreciated this article and have found the data very useful - I have shared this with my business partner and we will use this information down the road when we (eventually) get around to migrating our app from Angular to something else. Neither of us were surprised to see Angular at the bottom of the league tables here. Now, let's talk about the comments, particularly the top comment. I have to say I find the kneejerk backlash against "AI style" incredibly counter-productive. These comments are creating noise on HN that greatly degrades the reading experience, and, in my humble opinion, these comments are in direct violation of all of the "In Comments" guidelines for HN: https://news.ycombinator.com/newsguidelines.html#comments https://news.ycombinator.com/newsguidelines.html#comments Happy to change my mind on this if anyone can explain to me why these comments are useful or informative at all.
tripu 1y ago
“Next-gen frameworks [Marko, SolidStart, SvelteKit, Nuxt] deliver instant performance. […] The real performance story isn't splitting hairs over 3ms differences, it's the massive gap between next-gen and React/Angular.”
- lorenstewart 1y ago
  A maintainer refactored the Analog app, so it's doing much better than before. The post has been updated.

237 points by 0xblinq 1y ago

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.

fud101 1y ago
How would you compare it to Preact?
- chanon 1y ago
  Never used Preact so unsure
iainmerrick 1y ago
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.

deleted 1y ago

[deleted]

ochre-ogre 1y ago

Any reason the url is '10-kanban-boards'? I noticed this when I copied the url to share.

0xblinq 1y ago

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).

appsoftware 1y ago
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 https://www.appsoftware.com/tools/utilities/calculators
- aitchnyu 1y ago
  Can we build the elements as part of light dom? Do they call their destructor when we navigate away?
fud101 1y ago
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.
- MarcelOlsz 1y ago
  >React is nice and simple IMHO which is why average devs like me enjoy it. Maybe years ago. Now it's a bloated beast.
  - nawgz 1y ago
    Can you give some examples? I feel like React is still pretty much just React, having developed with it for a decade now. Hooks was the only meaningful API (surface) change, no?
    - brazukadev 1y ago
      https://react.dev/reference/react-compiler/directives/use-no-memo https://react.dev/reference/react-compiler/directives/use-no... "use no memo" react now needs you to declare what you are not using, using a language "feature" that does not exist. It is crazy how people keep denying reality wrt React.

IlikeKitties 1y ago

> The web is mobile. Build for that reality. Ugh. That thinking is what gets you things like mandatory login via apps for your desktop. And not every application makes sense on a phone. And some Web Applications just require low latency high bandwidth internet to work properly.

masklinn 1y ago
> 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.
- IlikeKitties 1y ago
  >If nothing else, think of it as a Trojan horse to make software suck less. My experience has been that the proliferation of mobile devices has made my desktop experience consistently worse and I struggle to come up with an example where it didn't.
- exe34 1y ago
  > But the vast majority do not. yeah and that's why they are shit and barely work. Even a php app without decorations would be faster and better for most applications.
HelloUsername 1y ago
> That thinking is what gets you things like mandatory login via apps for your desktop. "the web is mobile" = strictly "apps" ?

hi_hi 1y ago

I'd be interested in seeing React Native in this comparison. I'm not overly familiar with it, but we use it at work. I've no idea if I should expect it to be quicker or slower than something like Next.

koolala 1y ago
What do you hope to see from the result of that comparison?
- hi_hi 1y ago
  To gauge where RN sits on the spectrum of fast to slow.

bschwindHN 1y ago

(I'll be that guy since the article emphasizes a good mobile web experience so hard) You might want to fix your horizontal scroll on mobile. I should basically never have a full page horizontal scrollbar on a page that is mostly just text.

koolala 1y ago

Can Marko run static without a server? Can any of these?

aetherspawn 1y ago
Yeah, Svelte can.
- jakewins 1y ago
  Can’t most of them? Certainly React and Angular can as well.
mulhoon 1y ago
Nuxt can too
mpeg 1y ago
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.

mrasong 1y ago

This post made me open up the Svelte docs again.

CraigJPerry 1y ago

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.

Mashimo 1y ago
Mhh, I found it repeated sentences again and again. It was kinda odd to read at times.
input_sh 1y ago
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.
- mkl 1y ago
  They'd comfortably pay for 10 AI-assisted versions. It's a trivial demo app so that implementing it 10 times is feasible - it's just to learn what to build their main app in.
  - input_sh 1y ago
    I wouldn't measure how good/fast/performant a library is looking at the results of the very first LLM attempt at doing a trivial task using that library. If you don't know the libraries well enough to spot some improvements the LLM missed, the only thing you're judging is either how sane the defaults are or how good the LLM is at writing performant code using that library, none of which are equivalent to how good the library is. Also, performing well in a prototype scenario is very different than performing well in production-ready scenario with a non-trivial amount of templates and complex operations. Even the slowest SSGs perform fast when you put three Markdown posts and one layout in them, but then after a few years of real-world usage you end up in a scenario where the full build takes about half an hour. Kinda cool that you can do that in an afternoon, but absolutely useless as a benchmark of anything.

grebc 1y ago

Thanks for posting, a lot of effort went into that and I think the quality shines through in the write up. I write pretty lean HTML/vanilla JS apps on the front end & C#/SQL on the backend; and have had great customer success on mobiles with a focus on a lot of the metrics the author hammers home.

Akhu117 1y ago

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

croes 1y ago
The problem of native apps isn't the language but the app stores. Web deployment is easier, faster and cheaper.
ale 1y ago
Native to the web like web components or a native platform?
gbalduzzi 1y ago
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.

evertheylen 1y ago

Interesting to see Marko and Solid topping the performance metrics. Ryan Carniato* was a core team member of Marko and started Solid. I wouldn't be surprised if SolidStart can eventually lower its bundle size further. *) https://github.com/ryansolid https://github.com/ryansolid

mpeg 1y ago
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
- senjin 1y ago
  I wish he would have combined Astro with solid instead of HTMX for a more direct comparison

speedgoose 1y ago

> 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?

sunaookami 1y ago
Yeah the writing is obvious ChatGPT-slop sadly. Edit: Related post on the front page: https://news.ycombinator.com/item?id=45722069 https://news.ycombinator.com/item?id=45722069
- lorenstewart 1y ago
  Jeez! Y'all are quite harsh. I wrote this in sections and then tried to stitch it all together. I did my best to remove repetition, but overall it's my writing edited with the help of AI to moderate some of my personal biases. The value here is both checking out the code (written by me with the help of the maintainers of each framework) as well as tables for lighthouse scores and bundle sizes. I personally think the most important parts of the post are these two related parts: (1) the technofeudalism section (2) developing lightweight apps so a business does not feel the need to have a separate native codebase along with a specialized native team ($$$). I was hoping this post was a gift to many people by doing all this work for y'all, or at least providing a foundation from which you can fork and modify for your own use. It is an open question for everyone if start up time on cellular is something you need to worry about. All the other non-sense here misses the point.
- lukan 1y ago
  Can you guys share actual errors in the article, that indicate real slop? On first glance it seems very legit and personally I would be very hesistant judging something GPT slop based on some writing style.
  - xnorswap 1y ago
    How about this? >> Marko delivers 12.6 kB raw (6.8 kB compressed). Next.js ships 497.8 kB raw (154.5 kB compressed). That’s a 39x difference in raw size that translates to real seconds on cellular networks. Sorry, it isn't 2006, cellular networks aren't spending "seconds" in the difference between 13kB and 500kB. Payload size can matter, but it's complete nonsense that 500kB would translate to "real seconds". Just spotted this section: >> The real-world cost: A 113 kB difference at 3G speeds (750 kbps) means 1.2 seconds for download plus 500ms to 1s for parse/execution on mobile CPUs. Total: 1.5 to 2 seconds slower between frameworks. 3G is literally being decommissioned, and 3G isn't 750kbps, it's significantly faster than that. > On first glance it seems very legit Yes, that's exactly the danger of AI slop. It's very plausible, very slick and very easy to digest. It also frequently contains unchecked errors without any strong signals that would traditionally go along with that.

ale 1y ago

Comparing something like next.js to other frameworks doesn’t make much sense anymore given that most webdevs choose DX and easy deployment above anything else. Vercel’s growth is proof of that.

rk06 1y ago
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

gethly 1y ago

I prefer to use whatever I'm more comfortable with than something that is measurably the fastest horse in the stable. Trading dev time, skill and comfort for few kb of memory and few ms of speed seems pointless to me. By the way, my "horse" of choice is Quasar(based on Vue) and has been for years now.

jtrn 1y ago

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.

zwnow 1y ago
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.
hdjfjkremmr 1y ago
vue is better, the problem is it's been dead for more than 3 years now.
- qmmmur 1y ago
  What do you mean? Vue is perfectly capable and mature
- jtrn 1y ago
  The only way this makes sense is if you are looking at the Vue 2 GitHub page. The new Vue 3 is at 52k stars on GitHub, has multiple releases per month, and is ranked 7th A-tier framework in the "State of JS" framework rankings. It holds second place in frontend framework "experience with" and "sentiment," just behind React, with 6+ million weekly downloads on socket.dev and npmstats, ahead of both Angular and Svelte. So, I guess we have a different definition of "dead."

panstromek 1y ago

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.

h33t-l4x0r 1y ago

150kb downloads almost instantly, even on 3G. Most websites have an image bigger than that somewhere on their homepage. It's not worth changing how I work.

panstromek 1y ago
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).
- h33t-l4x0r 1y ago
  Nextjs with ssr is very light on client resources, I'm not sure about the other frameworks but I imagine it's comparable.
sgt 1y ago
If it was only 150kB for most sites. Usually that's followed up with multiple assets, API calls, often chained. Making the site slow.
- h33t-l4x0r 1y ago
  150kb is the difference in size between the 2 frameworks. That's going to be true for all sites.
troupo 1y ago
See Performance Inequality Gap https://infrequently.org/2024/01/performance-inequality-gap-2024/ 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
mpeg 1y ago
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 At these sizes, an islands/resumable based approach can trim a ton of loading time on mobile

forrestthewoods 1y ago

Great post. Im moderately annoyed that on Safari mobile it has an incorrect and super annoying horizontal scroll.

pu_pe 1y ago

Excellent work, I love experiments like these. Unsurprisingly the site is also lightning fast to load.

ChrisMarshallNY 1y ago

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.

theK 1y ago
> 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.
- ChrisMarshallNY 1y ago
  > good caches Some of the most challenging code that I write, is about caches. Writing good cache support is hard.
  - theK 1y ago
    I think writing good cache support _can_ be very, very hard. But in cases as grandparent describes, you do have significant wiggle room.
    - ChrisMarshallNY 1y ago
      I write native apps (see "not my bailiwick," above). It's fairly difficult, for me. The app can do a lot, but sometimes, the data needs to be fresh. Making the decision to run an update can be difficult. Also, I write free software, for nonprofits, so the hosting can sometimes be a bit dodgy.

deleted 1y ago

[deleted]

efilife 1y ago

> This isn’t just an inconvenience. It’s technofeudalism. > This isn’t a todo list with hardcoded arrays. It’s a real app with database persistence (appears twice) this article was written by ChatGPT. I'm tired

pbreit 1y ago

Seems overly concerned with bundle size which I'm not sure really ever matters? Certainly smaller is better but is it that big of an impact?

panstromek 1y ago
Yes, it matters a lot, especially on mid/low end devices.

delbronski 1y ago

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.

jama211 1y ago
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.
ivape 1y ago
I’ll speak for you: You’ve stopped caring because it. never. ends. Really.
pell 1y ago
> 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.

samwillis 1y ago

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.

kburman 1y ago

Any reason to not include native application given how important mobile experience was.

PeterStuer 1y ago
Appstores complicate lifecycles by orders of magnitude.
mkl 1y ago
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.

RayFrankenstein 1y ago

The guy is such a web zealot that he refuses to make the sensible engineering tradeoff that favors speed and offline capabilities over platform ubiquity. Most sane people would write a native app for this sort of thing if money was on the line.

antiloper 1y ago

> ... all deliver instant 35-39ms performance. The real differentiator? ... Thanks ChatGPT for your valuable slop. Next article.

ShaneWrn 1y ago

[dead]

econ 1y ago

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.

mpeg 1y ago
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
- econ 1y ago
  I want clean urls, I don't want to update every page or dynamically stich them together for each page view, I don't want a server cache for dynamically stitched together static content. These are expensive hacks to work around a lack of basic functionality. It reminds me of one kid taking something from another and refusing to give it back because they are larger. People make websites, they think they control what goes on on the page. This isn't unreasonable to think. In fact, everything should be made to preserve that idea. A situation where they just can't change the page shouldn't exist. Abstracting it away or otherwise working around it doesn't make it any less wrong. Some browsers have a magic key combo to force reload. I suppose the solution is to put up a modal and ask the user to "reinstall" the web page. I have a lot of static pages with minimal html/css that thanks to lazy loading and caching consume very little bandwidth. The technology is truly wonderful, clicking around feels like a desktop application.
  - mpeg 1y ago
    I'm not entirely sure what your point is. You don't want the complexity of a server cache but you want "clean urls" – having a hash in a filename does not necessarily make it worse, in fact it's closer to a pure url since one of the principles of hypermedia is that each url should point to a unique resource Urls like /v2/yourfile.js are probably closer to that philosophy. Or /[hash]/yourfile.js.

t00 1y ago

Am I missing something here? The mobile SPA app can be deployed using tools like capacitor to a device and the framework along with all static content is loaded into the app bundle. In such case it makes no (realistic) difference which framework is selected and it matters more how the background/slow transfers are handled with data-only API requests, possibly with hosted images. With the background workers PWA can be built as well, streamlining installation even more.

iainmerrick 1y ago
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.
- t00 1y ago
  As much as I agree with app deployment headaches, apps provide something a website cannot (except PWA) - ability to do stuff offline, log and register data which can be uploaded when connection is re-established. When talking about user experience - launching the app, selecting new -> quote -> entering details -> save -> locking the phone without worrying or waiting, knowing that it will eventually get uploaded, is much more convenient than walking with the phone around the property to get better reception to even load the new quote page. UX matters, and user does not care if the native wrapper or 500kB of js is there or not, as long as the job is done conveniently and fast.

willsmith72 1y ago

> 40ms round-trip time In that case how can you possibly get 35ms FCP? Am I missing something?

Raydii 1y ago

[dead]

android521 1y ago

it doesn't matter. in 10 years, few people will access websites directly.

gloosx 1y ago

> 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?

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

ozim 1y ago

Let’s be honest: “desktop-only” is usually an excuse to skip performance discipline entirely No, it is excuse not to invest money in places where users won't pay. For questions about mobile - yeah we get requests for showing it on mobile but app in app store is hard requirement, because of discoverability. People know how to install app from app store and then they have icon. Making PWA icon is still too much work for normal people. I would need "add to home screen" button in my website that I could have user making icon with single click, then I could go with PWA.

oulipo2 1y ago

Interesting, in my case I'm using Capacitor (since I need bluetooth and it's not well supported across browsers), and I want the app to be able to work offline too for some features, so I don't really care about the bundle size (it ships with the native app) and I prefer SPA than MPA so I can build it once and ship it with the code

maelito 1y ago

If I trust this article, React is a (relative) catastrophe. Can someone explain why ? What precisely would make React sooo slow and big compared to other abstractions ?

simjnd 1y ago
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_chrome_141.0.7390.55.html https://krausest.github.io/js-framework-benchmark/2025/table...
- maelito 1y ago
  > It is pretty established at this point that React has (relative) terrible performance. > it is slow You're not answering my question, just adding some more feelings. > The React runtime itself is 40 kB React is < 10 kb compressed https://bundlephobia.com/package/react@19.2.0 https://bundlephobia.com/package/react@19.2.0 (add react-dom to it). That's not really significative according to the author's figures, the header speaks about up "to 176.3 kB compressed". > Most frameworks have moved on to use signals to manage state updates. When state change This is not kilobytes or initial render times, but performance in rendering in a highly interactive application. They would not impact rendering a blog post, but rendering a complex app's UI. The original blog post does not measure this, it's out of scope.

Mashimo 1y ago

This made me look at our current app, it's a whooping 10MB just to get on the landing page. Build with Angular. .. creating a maintenance issue right now.

muzani 1y ago

I'm surprised there's no mention of Flutter. If the goal is mobile performance, Flutter would be top of mind - you can build to both native apps and web.

deleted 1y ago

[deleted]

todotask2 1y ago

Reference to SpeedCurve, they have a skip link on their home page yet nowhere id="main" was found.

alex-moon 1y ago

I greatly appreciated this article and have found the data very useful - I have shared this with my business partner and we will use this information down the road when we (eventually) get around to migrating our app from Angular to something else. Neither of us were surprised to see Angular at the bottom of the league tables here. Now, let's talk about the comments, particularly the top comment. I have to say I find the kneejerk backlash against "AI style" incredibly counter-productive. These comments are creating noise on HN that greatly degrades the reading experience, and, in my humble opinion, these comments are in direct violation of all of the "In Comments" guidelines for HN: https://news.ycombinator.com/newsguidelines.html#comments https://news.ycombinator.com/newsguidelines.html#comments Happy to change my mind on this if anyone can explain to me why these comments are useful or informative at all.

tripu 1y ago

“Next-gen frameworks [Marko, SolidStart, SvelteKit, Nuxt] deliver instant performance. […] The real performance story isn't splitting hairs over 3ms differences, it's the massive gap between next-gen and React/Angular.”

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