A tale of webpage speed, or throwing away React • Hacker News Board

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

#141

Post by _benj » Mon, Aug 24, 2020, 2:14 PM UTC

nthj wrote: post #139

_benj wrote: post #121

Earlier quoted context omitted.

I agree with you, even thought I might personally prefer Elixir/Phoenix :-) In my particular case thought I've been opting for Golang given that my web app needs to perform a little more that CRUD. And in regards to the CRUD part I've been heavily relying on PostgreSQL functions, thus instead the pain of a ORM I just have simple raw sql `SELECT * FROM api.get_user_data(?,?);` I'm not saying that is not possible to to…

Sounds like you and I have similar approaches, and I just have more CRUD to manage in my case. For e.g. payment processing endpoints, I use Golang. Managing 3rd party SDKs is nicer in Golang, imo. I also heavily rely on Postgres views, which ActiveRecord just sees as read-only tables, so my Rails code can still call `user.api_data_entries` without any ORM wrangling.

nice!

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

#142

Post by jevgeni » Mon, Aug 24, 2020, 2:16 PM UTC

theobeers wrote: post #54

jevgeni wrote: post #32

Surprised Solid hasn’t been mentioned. This: https://github.com/ryansolid/solid

Ah, thanks! I was leafing through the Svelte tutorial recently, and I knew I’d read about this other project, but I couldn’t remember the name.

I like it more than Svelte, personally. A little bit less magic (i.e. easier to reason about) and more performance.

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

#143

Post by krzepah » Mon, Aug 24, 2020, 2:28 PM UTC

ricardobeat wrote: post #124

madeofpalk wrote: post #77

Earlier quoted context omitted.

I cannot see how react encourages you to forget :hover in CSS.

You can argue it is not React's fault as usual, but this is how: setState('active')} /> const styles = StyleSheet.create({ active: { backgroundColor: 'purple' } }) progressing into: setState('active')} onHover={() => setState('hover')} /> const styles = StyleSheet.create({ active: { backgroundColor: 'purple' } hover: { backgroundColor: 'blue' } }) which is frictionless and 'clean', vs the alternative: const styles =…

Why on earth would you specify your styling in your JS ?

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

#144

Post by krzepah » Mon, Aug 24, 2020, 2:35 PM UTC

tluyben2 wrote: post #132

kungato wrote: post #46

Earlier quoted context omitted.

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

I have not seen a good case of this. Can you point out one? Managing state on the server is trivial; sessions and database and that is it. How does handling on the client work? Well it works if you double up on the server; it is a crime when there is some SPA that manages state client side; something goes wrong and it is stuck, press reload, state gone; login page. It is annoying to me as dev, it is creating serious…

Maybe implement authentification properly and store a refresh token that you can use to trigger auth on app load.

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

#145

Post by leon_sbt » Mon, Aug 24, 2020, 2:36 PM UTC

Like what some people said 5/100 on the page speed score is pretty bad. My site used to have this. It boiled down to two things that caused it.

1) I wasn't code splitting by page, and had a couple heavy dependencies (which made things worse)

2) I wasn't pre-rendering my create-react app via react-snap. Meaning during the CI build react-snap runs Puppeteer visits each page on the site, and generates ready-to-go html versions of each page.

Those two changes took me from a 7/100 to a 95+/100 in short order. Makes logical sense too. Now a days the site hovers at 85/100. But I don't have the time right now to reinvestigate it.

With the options at the time, I'm happy with my tech choices. If I had to start with React again today. I would do Next.JS with a static build output. Would save me a bunch of time scaffolding things.

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

#146

Post by [deleted] » Mon, Aug 24, 2020, 2:37 PM UTC

krzepah wrote: post #143

ricardobeat wrote: post #124

Earlier quoted context omitted.

You can argue it is not React's fault as usual, but this is how: setState('active')} /> const styles = StyleSheet.create({ active: { backgroundColor: 'purple' } }) progressing into: setState('active')} onHover={() => setState('hover')} /> const styles = StyleSheet.create({ active: { backgroundColor: 'purple' } hover: { backgroundColor: 'blue' } }) which is frictionless and 'clean', vs the alternative: const styles =…

Why on earth would you specify your styling in your JS ?

[deleted]

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

#147

Post by krzepah » Mon, Aug 24, 2020, 2:39 PM UTC

lgl wrote: post #90

onion2k wrote: post #19

We need to look at it from two sides: if it’s good for developers and if it’s good for users. React was great at former and terrible at later. React is not "bad for users". Developers build complex, fast apps with React all the time. It can be fast, but if you make mistakes with it then it's easy to make something very, very slow. The app I work on is huge. It's ~8MB of uncompressed React + Redux in development (much…

> A complex page can have up to 60,000 DOM nodes under React's control with thousands of event listeners. It starts in about 3s and never drops below 60fps Can one really make such affirmations regarding client rendered web apps? I'm assuming these numbers aren't solely measured on localhost in some state of the art development machine/device so won't it depend on the client's machine specs, browser, usage, bandwidth…

This is how i manage more than 60,000 DOM nodes https://github.com/developit/preact-virtual-list ; actually i think i could handle 600,000 and still have no problem.

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

#148

Post by tluyben2 » Mon, Aug 24, 2020, 2:39 PM UTC

krzepah wrote: post #144

tluyben2 wrote: post #132

Earlier quoted context omitted.

I have not seen a good case of this. Can you point out one? Managing state on the server is trivial; sessions and database and that is it. How does handling on the client work? Well it works if you double up on the server; it is a crime when there is some SPA that manages state client side; something goes wrong and it is stuck, press reload, state gone; login page. It is annoying to me as dev, it is creating serious…

Maybe implement authentification properly and store a refresh token that you can use to trigger auth on app load.

It is absolutely fixable, but the extra complexity invites people not to fix it while on the server it works as default.

I have integrated some very popular backends the past months and their portals are all SPAs and they all have this issue; hit refresh and you lost where you are, thrown back to login.

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

#149

Post by krzepah » Mon, Aug 24, 2020, 2:41 PM UTC

RedShift1 wrote: post #9

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

You can do server-side rendering with react. I'm pretty sure ppl started doing so at least 5 years ago

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

#150

Post by ricardobeat » Mon, Aug 24, 2020, 2:43 PM UTC

dceddia wrote: post #134

ricardobeat wrote: post #124

Earlier quoted context omitted.

You can argue it is not React's fault as usual, but this is how: setState('active')} /> const styles = StyleSheet.create({ active: { backgroundColor: 'purple' } }) progressing into: setState('active')} onHover={() => setState('hover')} /> const styles = StyleSheet.create({ active: { backgroundColor: 'purple' } hover: { backgroundColor: 'blue' } }) which is frictionless and 'clean', vs the alternative: const styles =…

The thing is, React works with plain CSS too. I think a lot of newcomers see that JSX looks like React-flavored HTML and naturally assume that React will have its own flavor of CSS, but it doesn’t. There are libraries for CSS-in-JS of course, third party ones. But implementing :hover on a button in React can be done just the same as in plain old HTML - with a bit of CSS in a .css file. Or for active/inactive states,…

That doesn't change the reality that there are a million projects out there using css-in-js - about 50% according to developer surveys. I doubt they are all written by newcomers.

The fact that React is a plain view library and doesn't provide / interfere with the rest of your tooling is precisely the problem in my opinion, and does not exempt it from the resulting mess. The lack of standards has led to the proliferation of a thousand supporting libraries, all special in their own way, in turn making the definition of 'good practices' nearly impossible; it also gives way to flavour-of-the-month development practices, where popularity (and not necessarily quality/fit) determines what libraries most people use. Similar discussions can be had around SSR, accessibility, bundling, compiling, code splitting, animations, component APIs, state management, persistence, fetching data, and so on.