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

171–180 of 319 posts

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

#171

Post by mixedCase »

christkv wrote: post #100
tom_walters wrote: post #11

This is the typical "we didn't spend any time thinking about our architecture therefore we're going to blame our framework" article. React is a great choice for certain use-cases, but when low-quality developers are allowed to pick it up and apply it to everything you end up in a mess. The same thing happens with literally any tool. If you want speedy initial interaction times and manageable codebases, (and requireme…

React has been god sent for us as we slowly modernise an application that is a mess of server rendered html and hacked together frontend code. Slowly we are rewriting individual pieces as embedded React components (no SPA here) and moving to a proper API layer that the components talk to. The separation of concern has made it a loot easier to increase code coverage and ensure a controlled rollout of new features. We…

> The separation of concern has made it a loot easier to increase code coverage and ensure a controlled rollout of new features.

This can be achieved (and more easily) by separating your templating from your business logic at the package level. If you know what you're doing you can keep things separate and your import graph non-cyclical, if you don't know what you're doing you're going to recreate the mess in your components and API anyway.

Source: Tired of seeing this happen again and again and again and again. And fixing it.

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

#172

Post by Davertron »

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…

This is admittedly nit-picky, but you're not managing 60k DOM nodes if you're using a virtual list, that's the whole point of virtualization. You might have 60k items in your list but you're only ever rendering a tiny subset of those items based on what is visible (with some overlap).

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

#173

Post by RandoHolmes »

andrewingram wrote: post #94
Etheryte wrote: post #21

Earlier quoted context omitted.

Talking of bundle sizes, this isn't inherent to the React point being made here but it's arguably too easy to blow up what you're serving. A common example I like to reference is Moment[1] — unpacked size is 4MB, most of which is different locales. If you _don't_ want to bundle all of those with your project, you have to do extra work, instead of making locales opt-in. Perhaps slightly less used, but a more prominent…

At my last job I always tried to be quite strict about adding additional dependencies, if something was over 10kb it had to be very strongly justified. Our designers wanted to add some SVG animations, they started off with Lottie ( https://bundlephobia.com/result?p=lottie-web@5.7.2 ) because they could export directly from After Effects, but I said no chance because of its file size. Briefly considered Greensock ( ht…

Too many people don't respect the risk of dependencies.

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

#174

Post by chias »

recursivedoubts wrote: post #114

The initial motivation for intercooler.js (which the author forked) was performance. I was working on a large bulk table update and building the table dynamically in javascript. The performance was terrible (this was back in 2012, no idea what it would be like today). I realized that I could just deliver and slam HTML into the DOM and that the browser engine, written in C, was very fast at rendering it. That turned i…

This is everything I never knew I needed.

At a glance through the docs, I'm pretty sure I can replace about 30% of my website's javascript codebase with this. Not to mention that having to actually write the javascript to "spruce" up a form will often lead me to be lazy and just have people deal with an un-spruced-up form.

I'm itching to get off work and try it out for real :) Thank you for all the work you did on this.

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

#175

Post by city41 »

kilburn wrote: post #111

Most people here are criticizing the author for doing some dumb things. I concur, but still think they have a good point. First, keep in mind that the author's use case is a content-heavy app with sprinkles of interactivity. This is very important because it sets the "webpage speed" goalpost to a concrete place: they want good lighthouse/first load times and good SEO. I've fallen into the same pit before. I've used C…

React supporting selective hydration would potentially be a total game changer.

I have recently started using gatsby-plugin-no-javascript. It's a very crude version by removing hydration at the page level. It works pretty well for me because my site is a ton of static pages and then one very interactive app page. I get to build it all in React, get a great developer experience, and then all those static pages are like 20k total (css, images, html, everything) and load in the browser instantaneously.

If we could get this ability, but be able to apply it at a finer granularity than pages, we could probably do some really great things.

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

#176

Post by leeman2016 »

rawoke083600 wrote: post #66

Just use Svelte. It's a super simple API, the "trickiest" part is the "reactive sections" but the whole API and reactivity part you can grok in an afternoon. In the past I have used Angular and React - these days I just always reach for Svelte (speed and simplicity).

I really had a pleasant experience with svelte recently. Highly recommend

Smaller bundles, faster, easier to use ... everything one can ask for

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

#177

Post by ralls_ebfe »

gvjddbnvdrbv wrote: post #138
aphextron wrote: post #126

Earlier quoted context omitted.

It's just apples and oranges. Web pages should never even consider using React. Maybe a bit of vanilla JS/jQuery here and there for whatever interactivity you need, and then server side rendering for the content. Building web applications on the other hand, has been revolutionized by the use of React. I would never seriously consider any other UI rendering library right now because of the sheer volume of support and…

> The alternative of doing things old school with server side templates is ok, but it massively slows down your iteration speed through reliance on tight coupling between backend and frontend. This depends on project size. If a single team is working fullstack then using server side templates gives seriously faster product development iteration. Once you get to more than 5-10 devs and you want separate frontend and b…

Why can't the server-side template rendering code consume an api as much as frontend JavaScript can? I don't see any reason for this to happen in the browser.

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

#178

Post by edoceo »

nightski wrote: post #167
recursivedoubts wrote: post #114

The initial motivation for intercooler.js (which the author forked) was performance. I was working on a large bulk table update and building the table dynamically in javascript. The performance was terrible (this was back in 2012, no idea what it would be like today). I realized that I could just deliver and slam HTML into the DOM and that the browser engine, written in C, was very fast at rendering it. That turned i…

I could definitely see something like intercooler boosting productivity. My only concern (possibly unfounded) is that you end up designing all of your server side endpoints specifically in an intercooler fashion. All of your endpoints must now return an html snippet, which is specific to the design of the page. So you have a lot of page specific endpoints. This is in contrast to a REST api where the api can be design…

When you migrate away from intercooler the new front-end is loading some data-api and some html-blocks from the old way. Move them out in increments.

Intercooler is great for some cases and can make a good transition step moving from all server-side v1 to a fully responsive/dynamic v3

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

#179

Post by avasthe »

cellularmitosis wrote: post #73
avasthe wrote: post #63

Earlier quoted context omitted.

Tangentially related; is there no lint option (similar to use strict) in JS yet to ensure no methods / functions are dynamically called and thus allow effective dead code elimination?

Not in vanilla JS. If you use the flavor of JS accepted by google’s closure compiler, then yes.

If anything, it proves how ineffective standards committees are. Similar to the standard library proposal which seems to be not yet implemented.

Still better than C++ standard people who try to cram infinite complexity into 100 layers of templates every three years for sake of adding a feature as library instead of language feature, with utter ignorance towards debug build performance, compile times and error messages. I have lost respect towards them since I read a C++ performance report and didn't see the mention of inherent STL inefficiencies.

Post reply on HN