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

191–200 of 319 posts

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

#191

Post by mattmanser »

heavenlyblue wrote: post #106
dsego wrote: post #95

Earlier quoted context omitted.

On top of that, js animations are still better for controlling timing and events or for a more realistic natural motion (springs instead of timed easing).

I would say that what JS animations are even better at is justifying inflated budgets of the projects made for people who are not very familiar with tech. Is there ever a real reason for animations that doesn't make the interface feel sluggish and unresponsive? In the other hand if you actually set the animation delay to something incredibly low, all of your animation needs could be easily solved by animating the tra…

Animations are effective, and I say that as someone who really hate slow ones.

If you start paying more attention to the apps you use, especially ones made by bigger companies, and you'll notice how effective some of them can be.

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

#192

Post by romaniv »

JeremyNT wrote: post #165
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 love seeing more work in this space! This sounds similar to the approach Basecamp has taken, with tools like stimulus.js (combined with with Rails UJS and Turbolinks). You can make a really responsive page with normal server-side HTML templates that "sprinkle" in the ajax functionality. Tools like this feel very familiar to those of us who got started before the rise of the modern JS framework. It's kind of fun to…

http://quickenloans.github.io/Behaviors.js/

Once I got past certain mental blocks, it became fairly obvious that you can structure all your GUI scripts to be configured and to interact with one another via DOM.

The next insight was to use CSS selectors for targeting.

Then using consistent name prefixes and separating behaviors into self-contained libraries.

The stuff above was proof-of-concept. The possibilities behind this approach are mostly unexplored.

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

#193

Post by withinboredom »

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?

They're probably talking about the :disabled pseudo-selector.

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

#194

Post by Shorel »

If anything should be learned from this article is this:

"We need to look at it from two sides: if it’s good for developers and if it’s good for users."

It is a pity this change in thinking required the pressure from Google Pare Rank, but now I see it as something very positive.

Always remember: code is written once, and executed thousands or even millions of times.

No optimization is worse than "premature optimization", and you probably misunderstand what "premature optimization" means anyway.

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

#195

Post by IggleSniggle »

commandlinefan wrote: post #125
_benj wrote: post #102

Reading all of the cynicism on the comments I wonder if we are taking into account the business context for the development of the app. I’m not a fan of react even though I use it daily, but the licentious nature of react allows me to build/modify features pretty quickly, albeit, low quality. I’m as idealist as the next person about a good architecture, but if the code you are writing is for a new product that is sti…

> react let’s you do pretty much whatever you want Ok, so I haven't gotten around to learning React yet, but I understand it to be the next iteration of what Angular, which I have learned, was trying to be. Angular "let you do whatever you wanted", too, which made me wonder why it was even there in the first place. Javascript lets me do whatever I want, I just have to write a lot of code to do that. In theory, a fram…

React is very very little, is not really a framework, l and honestly I think most folks are really either talking about JSX when they talk about React or they are talking Create-React-App and it’s ecosystem (which really is much more like a framework).

JSX comes down to being a convenient way to write HTML in your JS instead of JS in your HTML. After that, it’s just vanilla js.

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

#196

Post by corytheboyd »

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

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

#197

Post by Shorel »

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…

And who decides which is which? You?

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

#198

Post by [deleted] »

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.

[deleted]

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

#199

Post by mattmanser »

onion2k wrote: post #119
schwartzworld wrote: post #115

Earlier quoted context omitted.

I don't know what bandwidth has to do with react managing the DOM.

A naively built app will do things like take some user input from a form, send it off to an API and await the response, and then update the UI when if the request is successful or display an error if there's a problem. That means the user has to wait for the request to complete before moving on to their next task. In other words, the DOM update waits for the network. If you have a slow connection that feels horrible…

Ugh, this has got to be one of my biggest bugbears with SPAs. This pattern fails far more than you obviously think it does, and when it does fail, it's usually handled so poorly it's worse than the 'cure' you're peddling.

Give me a clean, server-side form submission any day over the "has it worked, hasn't it?" inconsistency of SPAs.

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

#200

Post by recursivedoubts »

corytheboyd wrote: post #196
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 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.

Post reply on HN