Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A tale of webpage speed, or throwing away React

solovyov.net

Post reply on HN
Print view View original

41–50 of 319 posts

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

#41

Post by adventured »

ojosilva wrote: post #22

In short, the OP changed the architecture from a client-side rendered app (in React) to a server-side rendered one (built on a custom-made framework cloned from Intercooler.js) and that resulted in a significant performance improvement for their app. Overall not a good critique of React as such to justify the "throwing away React" title in the front page of HN. In fact, not a lot of good conclusions can be drawn from…

6-12 months from now another article will be warranted, the author will have changed their mind again. That's the pattern you see throughout the entire thing, non-stop jumping. It's a solid bet as an indicator of the lack of maturity as a developer, incessant tech hopping.

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

#42

Post by sovietmudkipz »

llimos wrote: post #17

For sites that are content-heavy I've started wondering if it makes sense to have the content server-side rendered the old-fashioned way, and use multiple React roots for the parts of the page that need to be interactive. You can still use Redux etc. for managing app state globally (though not React context), and you get most of the gains of load time, and of using React where you need it. It seems everyone uses but…

At my old company we did this approach for some of our pages. We were transitioning away from our old codebase page by page but rewriting the codebase took longer.

New features were still desired so we built/repurposed react/redux components into what we called “hybrid” pages. It worked great for us!

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

#43

Post by arethuza »

kome wrote: post #38
hliyan wrote: post #28

When I first read the haiku at the bottom of the HTMX homepage, I had a flash of insight. javascript fatigue: longing for a hypertext already in hand What are we doing? State management libraries? Hypermedia is the engine of application state. Send data to client as HTML and have the client apply styles over it, rather than converting from JSON to local objects and storing in some sort of reactive data store. You wil…

you are SO right... but web developers have decided to go for complexity over simplicity and elegance. IMHO this happened just because complexity and fads generate so much more money, in the long run.

It would help if there was some objective way of measuring "elegance" in software.

Some people think hammer factory factories are elegant.... ;-)

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

#44

Post by [deleted] »

piranha wrote: post #29
capableweb wrote: post #16

Earlier quoted context omitted.

> I'm not sure they set up code splitting Don't think that matters. I've written (from scratch and inherited) and deployed many ClojureScript frontends, from one page ones with lots of interactivity to 30+ pages/sections, none of them reaching the size of 2.5MB minified (when using the production settings for Closure Compiler). Add in SSR and/or code splitting and the weight should be nowhere near there, leading to t…

Oh yeah, binary assets. Yeah, it is certainly binary assets. We just embed node.js in there. /s

[deleted]

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

#45

Post by matsemann »

piranha wrote: post #29
capableweb wrote: post #16

Earlier quoted context omitted.

> I'm not sure they set up code splitting Don't think that matters. I've written (from scratch and inherited) and deployed many ClojureScript frontends, from one page ones with lots of interactivity to 30+ pages/sections, none of them reaching the size of 2.5MB minified (when using the production settings for Closure Compiler). Add in SSR and/or code splitting and the weight should be nowhere near there, leading to t…

Oh yeah, binary assets. Yeah, it is certainly binary assets. We just embed node.js in there. /s

When people are discussing one's article (I assume it's yours based on your profile) I know it's easy to go into defense. People may criticize, and that hurts. But before lashing out as you do in some comments here, consider that the readers don't have the same background and context as you, and we all discuss based on those. Throwing out React is a huge step for most projects, it may have been good for you, is probably not right for many, and is certainly a discussion worth having.

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

#46

Post by kungato »

hliyan wrote: post #28

When I first read the haiku at the bottom of the HTMX homepage, I had a flash of insight. javascript fatigue: longing for a hypertext already in hand What are we doing? State management libraries? Hypermedia is the engine of application state. Send data to client as HTML and have the client apply styles over it, rather than converting from JSON to local objects and storing in some sort of reactive data store. You wil…

Why does is handling state on the backend better than handling it on the frontend? You will always have the cost of waiting for the server to return the full html every time you want something to happend and still you will have cases where you are handling state on the frontend

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

#47

Post by piranha »

tnova wrote: post #37
piranha wrote: post #27

Earlier quoted context omitted.

The thing is that your tools should be making good this easier than bad things. And React is the opposite of that.

So youb are saying that React makes it easier to do bad things than good things? Would you mind extending on that?

I tried to do that in the article. But the thing is that when you're writing a little piece of code React makes it dead easy to make hover in your code. There a lot of little things like that.

You start out with good intentions, but after 4 years of different people certain parts of codebase start looking really weird even with code review. You just can't catch every little detail.

And this is why tools should make it easier to do good thing (good as in what you'd want to see in the end).

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

#48

Post by hliyan »

kungato wrote: post #46
hliyan wrote: post #28

When I first read the haiku at the bottom of the HTMX homepage, I had a flash of insight. javascript fatigue: longing for a hypertext already in hand What are we doing? State management libraries? Hypermedia is the engine of application state. Send data to client as HTML and have the client apply styles over it, rather than converting from JSON to local objects and storing in some sort of reactive data store. You wil…

Why does is handling state on the backend better than handling it on the frontend? You will always have the cost of waiting for the server to return the full html every time you want something to happend and still you will have cases where you are handling state on the frontend

Theoretically, you have a point. Practically, you are reading this comment on a website that not only does exactly this, but refreshes the entire page (rather than a small block of HTML, intercooler-style). The performance benefits are evident.

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

#49

Post by Brajeshwar »

Here is an old story from 2016 but I hope this 3-part article is useful. We used React during its early days, to help Aditya Birla with one of their eCommerce websites.

1. https://alarisprime.blog/e-commerce-case-study-building-fast...

2. https://alarisprime.blog/e-commerce-case-study-building-fast...

3. https://alarisprime.blog/e-commerce-case-study-building-fast...

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

#50

Post by piranha »

piranha wrote: post #29
capableweb wrote: post #16

Earlier quoted context omitted.

> I'm not sure they set up code splitting Don't think that matters. I've written (from scratch and inherited) and deployed many ClojureScript frontends, from one page ones with lots of interactivity to 30+ pages/sections, none of them reaching the size of 2.5MB minified (when using the production settings for Closure Compiler). Add in SSR and/or code splitting and the weight should be nowhere near there, leading to t…

Oh yeah, binary assets. Yeah, it is certainly binary assets. We just embed node.js in there. /s

> consider that the readers don't have the same background and context as you, and we all discuss based on those.

Okay, so how about not inventing outrageous ideas on the spot and just consider what is written?

It's equally as hard to unload what's been boiling in your brain for last half a year. I'm reading comments and trying to decide where to expand my post, of course, but this "binary" thing just got me laughing.

Post reply on HN