Hacker News new | past | comments | ask | show | jobs | submit login
React profiling component to measure the "cost" of rendering (github.com/bvaughn)
75 points by rbanffy on June 16, 2018 | hide | past | favorite | 54 comments



It doesn't look like this gives more information than the built in profiling tools[0] React already has.

So it looks like an interesting project to learn the component lifecycle and some React internals, but if you need to make your react apps faster you should probably use the provided profiling tools.

[0] https://building.calibreapp.com/debugging-react-performance-...


The current debugging tools use the User Timing API, which according to the post have large overhead, and don’t account for ‘yield’ time when async rendering is enabled (this is kind of the TL;dr for the whole proposal).


Everytime a project is reimplemented via react, it's much worse then before. A recent example is Reddits redesign.

Is using React always bad for the user or are there any examples out there, not behind a login, that show a good usecase for React?


That’s just total nonsense. React is a tool like any other, and it can be used to build simple UIs or overwrought complex ones.

My team have just reimplemented a UI in React that was previously built using static pages progressively enhanced using JS. And you know what? It’s faster, easier to use, more accessible, looks better, and well-tested (though unfortunately I can’t show it off, because it’s a commercial product).

I would guess you are just conflating bad UI decisions like Reddit’s with the fact that React is now popular for building UIs.


It's not total nonsense - trends and tools dictate the way you think. It's like with PowerPoint - it's an excellent tool if you know how to speak publicly; if you don't (like most people using it), it makes you create a horror show - to the point people routinely attribute this to PowerPoint itself.

SPAs are basically PowerPoint of web development.


Reddit could have been rebuilt in react and looked exactly the same, and no one would have ever noticed. The problem with the new reddit design isn't react, it's designers.


But we all agree the new site is terrible right? It's especially awful if you don't allow cookies because every page you load you get the "we made a new look!" pop-up.


Yes, the new Reddit design is terrible. Reminds of their app which is also bad.


The new design is bad enough that I have significantly reduced the time I spend on Reddit. Now if they retire the old site, I can kick one social media addiction.


Switch to the 'classic' or 'compact' layout, not the default 'card' layout.


The screaming laptop fan, janky scrolling and slowly loading interface would have tipped me off pretty quickly. Its why I backed the hell out of the reddit beta, its unusable.


React itself does not dictate that you use the SPA paradigm. React + React Router = SPA. React alone can be paired with .NET, PHP, or whatever server rendered framework you want to use for traditional, multi-page apps.


React is just a framework, it's all but impossible to tell if a site is made with it. So the examples of a good usecase for React are out there by the hundred, you just don't know they're using React because you don't think twice when using them.

The most common reason for bloat is people trying to make a site a single page app when it isn't necessary. You can do that with React, but you can also do it with Angular or Ember or plain JS if you're a masochist.


>it's all but impossible to tell if a site is made with it

Do you mean visually? You can usually identify which SPA a site was built with by looking at the live DOM for a couple of seconds.


He meant by the look of it. Of course if you look at the actual JavaScript code that is running in the browser you'll see React.


If you have the React debug browser extension it lights up when it detects react. There is a way for the project to not as its supposed to be only for development.

Anyways, I'm a huge fan and supporter of React.

However, sadly, you can tell sites that use React due to a few bugs.

The most noticeable is/was funnyness with input box focus and state. Facebook's embedded Messenger on web always bugs out on me by not accepting the text im typing.


One way to tell is that the site is extremely slow.


Why are you assuming that the causal factor is with the framework?

The reason they're shitty is because they're heavier weight and "mobile first" usually comes with a certain amount of tradeoffs for other devices. React in and of itself as a means of managing data flow is very elegant IMO.

It just happens that if you tell any random group of engineers to do a full rewrite, they're going to settle on whatever is currently popular.


One factor that the framework makes worse is linking and tabs. The further everything goes towards single page apps, the harder it is to bookmark things or open them in new tabs. The frameworks people use to make single page apps usually come with tools to give everything urls and solve this problem, but using those is more work for the devs, so the tendency is for things to become harder to open in a new tab or come back to.


For now I am assuming nothing. I just ask for examples of user friendly sites made with react.


> I assume nothing

> every time a site gets reimplemented in react, it gets worse


That's an observation.

And nobody came up with a counterexample yet.


Either the question is disingenuous, or you just don't understand that the choice of UI framework (such as React) has no significant impact on the visual design of a site or app. There are caveats, because certain paradigms can make implementing certain designs more challenging, but for the most part they are unrelated.


Now you are assuming he doesn’t know what he’s talking about. The choice of framework can certainly affect performance, especially for UI interactions (which is the case with reddit), and might encourage patterns (for example, async loading everything) that can have significant impact on the user experience.


> every time I see a site that was reimplemented in react, it looks worse to me

_That_ is an observation.

You stated a fact, which you derived from your observations.


Instagram, Twitter's mobile site (mobile.twitter.com/home), React's own documentation page, Facebook itself, Wolfram Alpha, CoinBase, WordPress, CodeAcademy, Atlassian, http://builtwithreact.io/ thousands of other sites. What a weird and lazy comment. UX is completely orthogonal to the tech driving it except where performance is concerned.


We made greatbigstory.com with React. It's not the best website around, but you should have seen it before we got our grubby mitts on it.


FYI, you're using the development build of React in production. Switching to prod version for your deployed site should yield some performance gains.


Nice website!


Thanks!


6 months in I rewrote my meteor app in react for a startup. At the time I was worried it was one of those developer procrastination moments, but it ended up as a HUGE win for us. Our customers are amazed at how fast we can implement features and fix problems, which I credit to react and doing things client-side as much as possible (i.e. pouchdb).

Alas, there's a login.


Twitter Lite and Airbnb are obvious examples not behind a login.

I'm sure there are countless good examples in this list: https://github.com/facebook/react/wiki/Sites-Using-React

But React and other SPA libraries will always excel more for more complex UIs, those sorts of things tend to be behind logins.


The claim that Twitter "Lite" is an improvement is a collective delusion of the web development community, spread by Google and Twitter PWA evangelists. By every measure, except 'shininess', it performs worse that both Twitter.com and the old legacy mobile.twitter.com (which can still be accessed if you set your user agent to something like a Blackberry).

Even from a warm cache, Twitter Lite takes longer to display your timeline compared to desktop Twitter. Compared to the legacy mobile twitter site, the PWA version is 15x slower at showing your timeline [1]

And this is all the while ignoring the UX annoyances of the PWA version. When loading the timeline, you're presented with about three different loaders, all flashing about the screen.

[1]: https://twitter.com/joshhunt/status/980769162770485249


Yep, first load is slower. But loads of any click you make are faster. That's the trade-off.


But first load (and repeat loads of the first page you visit) is the only thing that matters. The primary use case of Twitter is the timeline - if you've made displaying that slower, you failed to make a faster site. You blew it.

Of course I know nothing about the complexities of Twitter internally and technically, but I don't understand how they managed to make it slower than the Desktop Twitter, and claim that they built a better experience when they clearly haven't.

---

Edit: I just did a tiny bit of by-the-eye comparisons between Desktop Twitter and Twitter Lite, and loading Notifications seems a bit faster on Twitter Lite. Loading Profile might be the tiniest bit faster on Twitter Lite, but I suspect there's a lot of DOM jank that slows displaying the next page. Showing DMs is slower on Twitter Lite compared to Desktop Twitter.

But even so, what does this have to do with the PWAs that Google+Twitter evangelise? My understanding is that PWAs are all about speeding up the warm-cache 'first load' [1], and once that's loaded, there's not really much that the PWA technologies will do for you. Both Desktop Twitter and Twitter Lite are Single Page Apps that fetch views from API calls - there's nothing inherently different about Twitter Lite's approach that will make it faster at that compared to Desktop.

[1]: 'First load' seems to be the wrong name to call this, but unsure of a better, more concise phrase.


>The primary use case of Twitter is the timeline - if you've made displaying that slower, you failed to make a faster site. You blew it.

It’s not at all clear this is true. Does explore get a lot of traffic? Comments? Maybe interactions are more valuebale than pageviews?

What if I’m in the elevator, and I want to check my twitter feed?

Obviously I know none of these things, but those are assumptions I wouldn’t make easily.


> Maybe interactions are more valuebale than pageviews?

They are, to Twitter. Twitter is driven by engagement, not by user needs.


> The primary use case of Twitter is the timeline - if you've made displaying that slower, you failed to make a faster site. You blew it.

The timeline isn't a single page, it effectively scrolls in infinitely. And maybe it's just me, but as I read Twitter I very frequently tap on a tweet to see expended content, the bio of who wrote it, and so on.

Maybe I'm the anomaly! But you know who'd know? Twitter. They'll have a huge analytic dataset telling them exactly how people interact with their site. Maybe they tailored Twitter Lite to that?

Time and time again on Hacker News you see people assess a project with a base assumption that the creators are basically idiots. Maybe give the Twitter devs the benefit of the doubt about how they prioritised features.


My 'issue', which is wildly off topic from the original post, is that Twitter Lite is hailed as the epitome of Progressive Web Apps by both Google and Twitter. Google helped Twitter build it.

They claim that it's a faster site because of PWA, but the site is slower where all the PWA technologies would help out. Where there are speed improvements, it's got nothing to do with service workers.


Twiiter Lite is an example of a horribly designed website: it's jerky, it has inconsistent behaviour, it has multiple UX issues.

It loads reasonably fast, and that's the only thing that's good about it. As a representative of a good React site, it is not.


Twitter lite: Where is that?

AirBnB: I love AirBnBs service, but I totally hate the UI. It's slow and clunky and gets into the way like nothing else. A single page of a room loads over 5MB of data, scrollinig is laggy, everything feels just terrible.


> Twitter lite: Where is that?

https://mobile.twitter.com

> AirBnB ...

Maybe not the best example. I think they still have a lot of legacy cruft they need to fix. I still think their homepage/search UX is pretty good. And like someone else said, it's not like 'React' is the cause of slowness.


    mobile.twitter.com
I really don't like it. It's one of these typical slow react experiences where everything I do results in me staring at a loading animation.

For example the search experience: I type something and before the typeaheads show up there is a loding bar on top of them. And when I hit enter, I get a loading spinner in the center of the screen.

Another example: When I click on a tweet and then click the back button. The page where I came from could be shown instantly. Instead I get some type of fade-in effect on some elements.

Etc etc. The whole experience feels terrible clunky on mobile.twitter.com.

Compare that to Googles search for example, where everything feels instant. Typeaheads, result pages ... when I click through to a result and hit the back button - I'm instantly at the same result page where I was before.


> these typical slow react experiences

Again, this is a really bad generalisation you're making. It is ludicrous to attribute the types of slowness you're talking about to React.

> Compare that to Googles search for example

Do you think it's fair to compare anyone's search to Google's?


Well, sorry but you're wrong about React. You haven't shown any evidence that these things are related to React at all.

Here's some counter-evidence though - https://reactjs.org - that site is built with React and everything is instant.

Also, my own React apps perform instantly and that's because I didn't put in a shitload of JS to do things like track your mouse pointer and do other types of analytics like Twitter probably does.


    reactjs.org
When I visit it, the lower half of the screen makes a jump to the left after about 3 seconds. That already makes me feel uneasy.

In the 'Tutorial' section, everytime I click on an entry on the right, the screen at first jumps up for a fraction of a second before jumping down again.


Sounds like there might be something seriously wrong with your computer, your device, network or your browser then. What’s your set up?

I just looked at it on like four different devices and didn’t have any problem. It works perfectly for me on Windows 10 with Chrome, Mac High Sierra/Chrome and iOS 11 / Safari iPad and iPhone.

If you don’t believe me, I will post a screen cast on imgur if you’d like.


Yup, screen cast please.

You can see the jumping on webpagetest.org:

https://www.webpagetest.org/video/compare.php?tests=180616_B...

With a slow connection, on the initial load the first jump happens at 6s and another one at 8.5s.

When I click on one of the links, it happens much faster because everything is cached. But I can still see the jump everytime I click a link to a new section in the tutorial.

I don't think the type of browser plays a role here. I get the glitches on Chrome and Firefox. And testing it on browserling.com shows that they also happen on Internet Explorer.


The jump is the anchor '​#​h​o​w​-​t​o​-​f​o​l​l​o​w​-​a​l​o​n​g'. A mechanism that's existed since the beginning of the internet. https://www.w3.org/MarkUp/1995-archive/Elements/A.html ‍️


Anchors by themselves do not make browsers jump in erratic ways. Try Wikipedia. No glitches when you click on sections.


Here it is on my iPhone, arguably the slowest device that I tried it on - https://imgur.com/a/Wf2bXmq


Not really counterevidence, they use gatsby to create static sites from react code, it is not a PWA


People can make bad products using any technology.


Discord.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: