4 ms·

Well that bug is clearly idiotic, and makes me feel a fool for thinking react.dev would be a strong example of sane SPA architecture to link to. The idea is so

Well that bug is clearly idiotic, and makes me feel a fool for thinking react.dev would be a strong example of sane SPA architecture to link to. The idea is sound, and the basic loading behavior is as I said (not sure what the people who are encountering 1.5 second navigation times are doing), and the existence of an implementation bug doesn't undermine the theoretical soundness of the architecture.... although, as you say, having one on the react docs is embarrassing.

csande17 3y ago
> (not sure what the people who are encountering 1.5 second navigation times are doing) On CPU-limited devices (and my computer with 4x CPU throttling enabled in devtools), react.dev appears to block the main thread for 500-1000ms while navigating to some of the "Learn React" pages—even if all the data for that page is already cached in memory. I remember reading all kinds of blog posts about how Concurrent Mode and Time Slicing were gonna magically solve this by breaking up long tasks and prioritizing above-the-fold content so that it would pop into view faster. It would be funny if, in addition to being unable to correctly use the History API, the React team was also unable to use their own framework's performance features.
ksec 3y ago
>The idea is sound, and the basic loading behavior is as I said Yes, and that is why despite hating the idea from the get go, which was before 2009. I gave it plenty of time to mature. But the truth is, any technology is only as good as the human factor. We aren't perfect, and that is why even basic thing like this we would make mistake. And this example just proves it even more. And I am ignoring the site's performance which felt really slow for what should be a MPA ( and it is not ).