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

281–290 of 319 posts

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

#281

Post by jsguy »

I think there are some interesting points here, though many (including the author) seem to forget: React is a UI library, not a framework. This means it is up to the user to decide and implement everything else, such as:

* Code splitting * Loading of the code (at appropriate times, eg: ) * Any other optimisations

I think the author simply failed to do this well and then blamed the library for their own shortcomings, and moved on to the 'next shiny thing'.

There are plenty of patterns you can use to make your React app responsive, and many tools to help you achieve that, it's just a matter of being able to implement those tools effectively.

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

#282

Post by crooked-v »

beaker52 wrote: post #153
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…

Wow, hello quantumly-entangled developer twin. All this Gatsby, Next, React hydration, multiple roots stuff is what I'm traversing at the moment. Even down to the ` ` example. I'm having discussions about these things almost every day. And then to finish it off, you mention the pit of success which has been a key focus of my recent attention too. I could imagine myself writing this exact post, even down to the word '…

When it comes to the mobile-desktop thing, check out Rebass, which uses actual generated CSS under the hood so it's properly performant (especially if you handle it right by precompiling all the static CSS at build time with babel-plugin-emotion), but lets you write media query-dependent attributes directly with your component use. For an example: https://rebassjs.org/box and resize the page back and forth

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

#283

Post by acdha »

debaserab2 wrote: post #226
ricardobeat wrote: post #61

Earlier quoted context omitted.

> return the full html every time The post mentions their HTML size decreased - most likely due to reduction in intermediate components and nesting. Note that with an SPA you need to send templates (in the js bundle) + data (json api) to the client, which by definition will be at least as large as static HTML for the same content : HTML is nothing more than the template and content already baked in. In practice the J…

> which by definition will be at least as large as static HTML for the same content Not really by definition - tables rendered on the server side are a good example of a payload that can easily be larger than template + dataset.

Transfer compression will usually take that down to the point where it's negligible. By the time you're talking enough data for this to matter, things like pagination will likely be far more important.

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

#284

Post by deergomoo »

RandoHolmes wrote: post #166
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…

This all indicates that browsers and html/css are bad tools for creating UI. Long term I think we'll eventually see the ability to interact with the local system via the browser, and we'll start seeing more things like "QT for the web". Because if we don't, at some point it's all going to just fall over.

Yes. HTML is a terrible platform for applications. It provides basically nothing and I am continually surprised that it doesn’t seem to be a major focus for improvement like JS and CSS.

I don’t need more types of semantic rectangle, I need actual real UI controls that are efficiently rendered and accessible by default, so I don’t have to build everything from scratch.

The fact that there’s no built-in element for things like dropdown menus is mind boggling to me. That’s GUI component #0; menus have existed for as long as GUIs have!

I feel that Houdini may eventually solve CSS’ shortcomings for application UI layout, but being stuck with HTML is like trying to build an aeroplane with sticks and mud.

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

#285

Post by one_comment »

kilburn wrote: post #225
davidwparker wrote: post #216

Earlier quoted context omitted.

If you're truly having issues with CSS and rendering different sizes, I'd recommend taking the time to really learn CSS inside and out. I find it incredibly simple nowadays to do both Mobile/Desktop (+Tablet) with CSS and media queries. I may have agreed with you in the past, but not so much anymore.

There are still some things that are impossible to achieve with CSS alone, even if you have the luxury of only needing to work with evergreen browsers (remember we are speaking of content-heavy sites here, which are the most prone to still have to support older browsers). Example: I have a stack of boxes of varying heights. On mobile they are fine as is (one below the other). On tablet I want them in two columns but…

Hmm, why did the CMS allow for such a setting in the first place? It seems to me that allowing this is the problem... But this might be a structural/org-political that you have to solve then

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

#286

Post by ClumsyPilot »

svachalek wrote: post #210
Shorel wrote: post #197

Earlier quoted context omitted.

And who decides which is which? You?

These days nothing is purely static and very little is purely interactive/dynamic. However most sites lean clearly to one side or the other, no judgment call or personal defensiveness required.

Most sites straddle the muddy line in-between, or start off as webpages and mutate into web-apps over time as more functionality gets added on.

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

#287

Post by tomc1985 »

nawgz wrote: post #237
tomc1985 wrote: post #209

Earlier quoted context omitted.

> 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. Huh? Something like Rails lets you iterate on server-side stuff extremely quickly. There is a lot of functionality you can implement that doesn't need JS at all

Never developed in Rails - does it handle: * composable templates * reusable JS snippets * hot reloading in your browser And additionally, given that the topic is "building web applications", I can't really understand how you think you can build interactivity without JS. Are you proposing form-based updates or is your understanding of "application" different than GP and mine?

> * hot reloading in your browser

We recently added this "feature" to our react-on-rails codebase, and the only thing I can ask is... why?

Hot reloading on Unreal Engine is a hot mess with all sorts of little caveats to think about. Meanwhile I can hit F5 and as long as my browser is configured right I can guarantee there's no old cruft to deal with. Why in the world would I want to add that kind of uncertainty in my work codebase??

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

#288

Post by bernawil »

piranha wrote: post #234
bernawil wrote: post #213

Earlier quoted context omitted.

the template rendering lives side by side with the controllers, why would it make an api call? But something similar but not the same as that was the norm during the jquery era before the early js frameworks arised (backbone, ember et all). You had your full-stack server-side MVC framework render initial views and from there the js would pick up and all UI interactivity would be ajax calls to the restful(ish) api. It…

> why would it make an api call Because this introduces clear separation of concerns? You don't need to make this API call via HTTP, you can just call a function. You don't even need to generate/parse JSON! I know that because this is what we are doing. Just calling a function called "httpapp". :)

Well, but then it's not the same api call and that's the point: that in the old mvc frameworks it was painful having to support controllers that both rendered html and json for doing both SSR and Ajax.

Around the time the first js FE frameworks came out, people finally became confident enough to have pure js clients and only json APIs.

And finally gatsby, next.js, etc. brought a new twist to the SSR and Ajax api combo.

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

#289

Post by Davertron »

onion2k wrote: post #184
Davertron wrote: post #172

Earlier quoted context omitted.

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).

It's not virtualized. It's not even a list. It's a very large SVG with lots of foreignObject bits in it. The app is a diagramming tool - imagine Visio but for lawyers to map out contracts and ownerships between hundreds of corporations.

Sorry, someone else mentioned a virtual list component and I assumed it was you without looking at the username.

That's pretty impressive, I've run into perf issues with far fewer actual DOM nodes than that!

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

#290

Post by flukus »

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…

> 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 ok, adding an endpoint to spit out html is super simple, it's just printf statements with angle brackets.

Beside that I find endpoints need to be somewhat coupled to the UI anyway, otherwise the endpoint needs to be a superset of all possible data and all the complications that come with that.

Post reply on HN