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

201–210 of 319 posts

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

#201

Post by withinboredom »

dwheeler wrote: post #116
lr4444lr wrote: post #64

Earlier quoted context omitted.

Because the user can't be trusted - on several levels.

Treating 10KB of JavaScript as equal to 10KB of HTML is a big mistake. They transition over a network in the same amount of time, but HTML is far faster to process. Websites with large HTML sizes often display far faster than the same information that use JavaScript client-side frameworks. Often the framework is still trying to figure out which way is up, while the HTML version is already being displayed. It's a trad…

I wrote a game engine with a DSL that renders as detail/summary html blocks. It wasn't hard to end up with a page that was hundreds (or thousands) of megabytes. Any given browser really had no issue until it was over several hundred megabytes.

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

#202

Post by dangoor »

Udik wrote: post #53
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…

In general, these posts sound a bit like this: I tried jQuery, and after a while it all became a mess; took up a Backbone project, and was good for a while, but eventually it became too complex; then I worked on Angular and that seemed a big improvement, but then... and finally with React my architectures are clean. While the reality is more like this: I had 6 months of programming experience and used jQuery and made…

I disagree with the reality you present. There are a lot of people, myself included, with a considerable amount of experience who found that maintaining jQuery/Backbone code to be complex and error-prone and React presented a solution to this problem with a programming model that looks more like an immediate mode GUI (even though it ultimately paints to a retained mode DOM).

I don't think it's worthwhile to minimize the actual, useful impact React has had for web apps.

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

#204

Post by corytheboyd »

tom_walters wrote: post #60
Udik wrote: post #53

Earlier quoted context omitted.

In general, these posts sound a bit like this: I tried jQuery, and after a while it all became a mess; took up a Backbone project, and was good for a while, but eventually it became too complex; then I worked on Angular and that seemed a big improvement, but then... and finally with React my architectures are clean. While the reality is more like this: I had 6 months of programming experience and used jQuery and made…

Pretty much. It's similar to discovering the power of salt and pepper in cooking. When you first use it everything tastes better. But the next step is not to increase the amounts you use in every dish, it's to explore the much wider world of cooking with herbs/spices/etc. If your mindset is persistently "this framework/tool will solve all our problems" you're always going to have a bad time. Understanding the pros/co…

I’d just like to expand on this, as I think it’s a great comparison!

Carefully picking tools is important, but also, don’t adopt more tools than you need to.

One common example I have seen is pulling in a CSS-in-JS library to do something that SASS can easily do... when SASS is already incorporated into the build process.

SASS offers a fairly complex set of features if you care to learn about them, and the module system (in development) is going to solve @import global scoping issues very elegantly.

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

#205

Post by hombre_fatal »

ralls_ebfe wrote: post #177
gvjddbnvdrbv wrote: post #138

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

Probably because of how awkward it is. You essentially have this weird html-emitting "client-server" moving part in a limbo where it's still a one-to-many server. And it has to duplicate client code you probably still need anyways in the Javascript that runs in the browser (and, don't you want to do take advantage of some client benefits like being able to work offline or cache locally?). And this bonus moving part is only for your web clients, not something you use for any other client (iOS, Android, etc).

NextJS is something that folds over some of this, but it's not without its issues.

Of course, no better way to find out than try it for yourself. When I have the question of "why don't people just do X?", trying X myself is a quick way to realize why, and unfortunately it's never because I'm the first genius to have thought of it.

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

#206

Post by corytheboyd »

recursivedoubts wrote: post #200
corytheboyd wrote: post #196

Earlier quoted context omitted.

I love seeing people invest time in this area, kudos. One thing that’s a bit hard for me to justify though are the examples like “click to edit”. There is a very noticeable delay as you wait for the network request with the edit document, whereas you typically won’t see that with client-side view logic. Is this just not a problem that htmx is trying to solve?

That response will be as fast as your server is, which is typically fast. I stuck a 300ms delay in the mock server to make it seem a little less instant: view-source: https://htmx.org/js/demo.js I didn't want people to think I was misleading them about what was going on. I would typically expect a simple edit form to return in sub 50ms.

> That response will be as fast as your server is, which is typically fast.

I do agree here. Also, if you’re careful about it it would be really easy to just scale the shit out of the document builder, add caching, etc.

Looking forward to following your project, it’s very interesting to me!

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

#207

Post by JMTQp8lwXL »

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.

You might get better performance with the element instead of SVG. I've noticed React can struggle with SVGs containing complex subtrees.

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

#208

Post by smichel17 »

rimunroe wrote: post #162
smichel17 wrote: post #135

Earlier quoted context omitted.

The first reason is what ricardobeat mentioned — with JSX, I'm writing my display "html-ish" code at the same time as the business logic. If I'm managing the state of, say, a form, and I want the submit button to be disabled when (condition), the obvious solution is to add `disabled={condition}`, rather than a conditional className or attribute to then match on in css. When I'm doing everything in one file, switching…

> If I'm managing the state of, say, a form, and I want the submit button to be disabled when (condition), the obvious solution is to add `disabled={condition}`, rather than a conditional className or attribute to then match on in css. I'm confused, are you saying you would prefer to disable the submit button without adding the `disabled` attribute?

Hmm, good point. I was trying to simplify a real-world example to shorten it, but ended up with something nonsensical. I was starting to share a better example but then realized I have other things I ought to do right now… I have it saved, will come back if I have more time later.

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

#209

Post by tomc1985 »

aphextron wrote: post #126
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…

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.

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

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

#210

Post by svachalek »

Shorel wrote: post #197
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…

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.
Post reply on HN