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

161–170 of 319 posts

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

#161

Post by [deleted] »

smichel17 wrote: post #135
smichel17 wrote: post #81

Earlier quoted context omitted.

I can second this. I'm working on two projects, one paid and one volunteer. One is using vanilla css/html (requirement to work without js) and the other is using react. Doesn't matter which is which. To set the context for the following statement, I've discovered that I prefer developing the nojs site. This mainly comes down to all the things that the browser does for me, but I have to handle manually in React, but i…

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…

[deleted]

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

#162

Post by rimunroe »

smichel17 wrote: post #135
smichel17 wrote: post #81

Earlier quoted context omitted.

I can second this. I'm working on two projects, one paid and one volunteer. One is using vanilla css/html (requirement to work without js) and the other is using react. Doesn't matter which is which. To set the context for the following statement, I've discovered that I prefer developing the nojs site. This mainly comes down to all the things that the browser does for me, but I have to handle manually in React, but i…

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?

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

#163

Post by [deleted] »

hliyan wrote: post #28

When I first read the haiku at the bottom of the HTMX homepage, I had a flash of insight. javascript fatigue: longing for a hypertext already in hand What are we doing? State management libraries? Hypermedia is the engine of application state. Send data to client as HTML and have the client apply styles over it, rather than converting from JSON to local objects and storing in some sort of reactive data store. You wil…

[deleted]

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

#164

Post by nprateem »

cityzen wrote: post #159
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…

Kind of off topic but when the word "hydration" become a technology term? I see it all over and it's never really made sense to me. The definition is specific to fluid: 1 : to cause to take up or combine with water or the elements of water 2 : to supply with ample fluid or moisture Maybe I'm old school but the word "populate" makes a lot more sense than hydrate when talking about data.

Over 10 years ago with various ORMs.

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

#165

Post by JeremyNT »

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 see articles like the OP's pop up where people are rediscovering these techniques.

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

#166

Post by RandoHolmes »

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…

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.

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

#167

Post by nightski »

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 designed largely independently of any one use case.

If you ever need to switch away from intercooler you are going to have a large undertaking not just on the front end, but now on the back end as well.

But I might be missing something.

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

#168

Post by ric2b »

hliyan wrote: post #48
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

Theoretically, you have a point. Practically, you are reading this comment on a website that not only does exactly this, but refreshes the entire page (rather than a small block of HTML, intercooler-style). The performance benefits are evident.

> The performance benefits are evident.

I mean, this website only loads a very small amount of text and has barely any user state besides a list of comments and posts. I would hope that it loads quickly.

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

#169

Post by RandoHolmes »

cityzen wrote: post #159
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…

Kind of off topic but when the word "hydration" become a technology term? I see it all over and it's never really made sense to me. The definition is specific to fluid: 1 : to cause to take up or combine with water or the elements of water 2 : to supply with ample fluid or moisture Maybe I'm old school but the word "populate" makes a lot more sense than hydrate when talking about data.

think powdered milk. You hydrate it by adding water.

Same idea, only for objects. You hydrate them by adding data.

The term has been used for probably 20+ years.

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

#170

Post by vijaybritto »

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…

Is it possible to make components like Dropdown with autocomplete in this? Should we be making use of Extensions for that?
Post reply on HN