A tale of webpage speed, or throwing away React

#1

Post by todsacerdoti » Mon, Aug 24, 2020, 9:25 AM UTC

A tale of webpage speed, or throwing away React
solovyov.net

Re: A tale of webpage speed, or throwing away React

#2

Post by ForHackernews » Mon, Aug 24, 2020, 9:58 AM UTC

Is this approach similar to Rails Turbolinks?[0]

[0] https://github.com/turbolinks/turbolinks

Re: A tale of webpage speed, or throwing away React

#3

Post by jack_riminton » Mon, Aug 24, 2020, 10:01 AM UTC

ForHackernews wrote: post #2

Is this approach similar to Rails Turbolinks?[0] [0] https://github.com/turbolinks/turbolinks

I think it’s more similar to Stimulus or StimulusReflex? ie you can declare the targets and actions of the JS within the html tags

Re: A tale of webpage speed, or throwing away React

#4

Post by mariopt » Mon, Aug 24, 2020, 10:07 AM UTC

That 5/100 score is very very strange. Have you tried migrating your react code base to NextJs?

Re: A tale of webpage speed, or throwing away React

#5

Post by terenceng2010 » Mon, Aug 24, 2020, 10:07 AM UTC

In the article though he does not mention whether React with SSR is an option?

Re: A tale of webpage speed, or throwing away React

#6

Post by piranha » Mon, Aug 24, 2020, 10:08 AM UTC

terenceng2010 wrote: post #5

In the article though he does not mention whether React with SSR is an option?

It always had server side rendering. https://solovyov.net/blog/2017/server-side-rendering/

Re: A tale of webpage speed, or throwing away React

#7

Post by lf-non » Mon, Aug 24, 2020, 10:21 AM UTC

Not opposed to server rendering or backend heavy sites, but a lot of people are able to get much better Lighthouse scores for fairly complex sites through a combination of webpack code splitting, service-worker based caching, and CDNs.

So, the problems here may have had more to do with the clojurescript stack (which I am not much familiar with), or author's lack of familiarity with javascript optimization strategies than react, SPA model or client side rendering.

Re: A tale of webpage speed, or throwing away React

#8

Post by ColeyG » Mon, Aug 24, 2020, 10:23 AM UTC

mariopt wrote: post #4

That 5/100 score is very very strange. Have you tried migrating your react code base to NextJs?

Right? I think there was something architecturally wrong with the app that the refactor fixed. It doesn't sound like react was the problem here. I sincerely don't believe that this sort of change and therefore the decrying of react for it makes much sense at all without seeing this guy's code.

Re: A tale of webpage speed, or throwing away React

#9

Post by RedShift1 » Mon, Aug 24, 2020, 10:24 AM UTC

Looks like we've come full circle? First server side rendering, then client side, now server side again?

Re: A tale of webpage speed, or throwing away React

#10

Post by capableweb » Mon, Aug 24, 2020, 10:25 AM UTC

> we’ve discovered that React also leads to some questionable practices. Like hovers in JS (rather than in CSS), drop-down menus in JS, not rendering hidden (under a hover) text (Google won’t be happy), weird complex logic (since it’s possible!), etc.

This is some strange reasoning that I have yet to seen myself. If you can do the hovers states/drop down menus in CSS, why not do them in CSS, even if you're using React? Seems to be blaming something on a library that the library has no care about in the first place (which to be frank, seems relatively common in web dev circles).

> In the worst case, we would serve you 2.5MB of minified (non-gzipped) JS

And holy guacamoly, how do you end up with this?! Seems that something was surely wrong in the compilation options, forgetting to mangle names or something, missing dead-tree elimination maybe?