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

231–240 of 319 posts

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

#231

Post by hinkley »

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…

The Zen of jQuery moment for me was realizing that many of our bugs came from trying to separate the source of authority from the system of record.

It was a tremendous amount of busy work keeping metadata about DOM elements stored separately from the DOM elements, and hanging the values off the element was so much simpler in initial implementation, maintenance, and exploring other people's code.

Everyone was so excited about the virtual DOM in React 'n friends, whereas I saw both the functionality and the excitement as warning signs that I should stay away. I hoped this would turn out to be a fad, but it's a little long in the tooth for that scenario to play out now. For a while I watched news articles for the chinks in its armor, these days I'm more focused on other tools that satisfy niches, and wondering what will end up being the 'CSS3/ES6' moment for React where the browser does 20% of the work to have 80% feature parity with React.

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

#232

Post by Kuinox »

krzepah wrote: post #147
lgl wrote: post #90

Earlier quoted context omitted.

> A complex page can have up to 60,000 DOM nodes under React's control with thousands of event listeners. It starts in about 3s and never drops below 60fps Can one really make such affirmations regarding client rendered web apps? I'm assuming these numbers aren't solely measured on localhost in some state of the art development machine/device so won't it depend on the client's machine specs, browser, usage, bandwidth…

This is how i manage more than 60,000 DOM nodes https://github.com/developit/preact-virtual-list ; actually i think i could handle 600,000 and still have no problem.

You just removed an usefull features from the user.

The virtual list make ctrl+f not working anymore, and I hate every single react page using it. Suddendly, on this webpage using virtual list, you ctrl+f something, dont find it, because the element does not exist.

A vue or angular manage your 60k elements list without any issue, you dont need to virtualize your list, and the search feature your your browser keep working.

And if your don't use a virtual list, react get performance issues starts when you get only a few hundreds of elements and you want to filter them.

Also, it start 'instantly' with other frameworks, not in 3 seconds, but below 500ms.

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

#233

Post by kbenson »

kilburn wrote: post #219
kbenson wrote: post #217

Earlier quoted context omitted.

I stop reading the webapp/react specific posts on HN for a year, and now there's such foreign terminology that I can't even understand the comments of one. Hydration? From context I assume it's something to do with rendering trees and the Dom, but really, I'm just grasping. So out of hand. It feels like Javascript webdev is recursively devouring itself into a completely separate type of programming.

hydrate [1] is the API call by which you tell React to initialize itself against a pre-rerendered DOM. In contrast, render [2] is the call by which you tell react to generate the DOM nodes itself. The idea is not that complicated: 1. You send the page's full HTML to the client. This is good for SEO and to quickly get the page to show. This HTML has been generated by running React on the server and capturing the outpu…

Thanks, and yeah, I got most of that from some Googling around afterwards, but I do want to note that I had encountered your first link, and that it itself is somewhat recursively defined with terminology that is glossed over:

ReactDOM.hydrate(element, container[, callback])

Same as render(), but is used to hydrate a container whose HTML contents were rendered by ReactDOMServer. React will attempt to attach event listeners to the existing markup.

Searching for hydrate in the React docs leads you to the hydrate method, which describes itself in terms of its use to hydrate a container. The crazy thing is that there's numerous blog posts that purport to tell you what react hydration is, which do the exact same thing and define it in terms of itself. Partly, this may be React (and the community's) reliance on you knowing what that concept is, but that's particularly unacceptable in article that purport to explain it.

Is it really so hard for these reference docs and explanatory sources to say something along the lines of "hydration in React is the act of fleshing out a server delivered model of the page that came with poor or no data with rich data delivered later in the process" ?

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

#234

Post by piranha »

bernawil wrote: post #213
ralls_ebfe wrote: post #177

Earlier quoted context omitted.

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.

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

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

#235

Post by nightski »

mattmanser wrote: post #185
nightski wrote: post #167

Earlier quoted context omitted.

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…

If you don't need a rest API, all it does is make everything far more complicated, i.e. every page now has two end-points, one for the html, one for the data. It's trivial in most web frameworks to have an endpoint respond in two ways, one with all the html including head, menus, footers, etc. if you hit it with a GET, the other just the snippet if you hit it with an Ajax request. A REST API is basically a massive ov…

Fair points. A couple of notes though - intercooler needs two endpoints as well. One for the page, and another for any dynamic HTML.

I mean I switched from jQuery to knockoutjs to react all on one application and the API served all those transitions well. So I'm speaking from personal experience here. But that is anecdotal and maybe it's not typical.

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

#236

Post by mawise »

tomc1985 wrote: post #209
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. 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

+1 to this. I wanted to build a private blogging app/site with a big focus on speed and performance, it might not be popular anymore but I went with Rails. Server-side rendering lets the browser do what it's good at. The only thing that would make pages load faster would be to stick them behind a CDN (which doesn't play nice with the privacy aspect). If anyone is interested I put up a page talking about the project: https://simpleblogs.org

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

#237

Post by nawgz »

tomc1985 wrote: post #209
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. 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?

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

#238

Post by nawgz »

mawise wrote: post #236
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

+1 to this. I wanted to build a private blogging app/site with a big focus on speed and performance, it might not be popular anymore but I went with Rails. Server-side rendering lets the browser do what it's good at. The only thing that would make pages load faster would be to stick them behind a CDN (which doesn't play nice with the privacy aspect). If anyone is interested I put up a page talking about the project:…

See but the parent comment is about "web applications" not "web pages". You are describing a web page - there is limited or no interactivity, what is there can be reasonably handled by forms. No one doubts that React isn't the tool for this area

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

#239

Post by collyw »

AtlasBarfed wrote: post #109
tom_walters wrote: post #60

Earlier quoted context omitted.

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…

It's almost like all "modern JS" are written by new programmers hired on the cheap by companies to work on their new hip UI frontends. IMO UI is generally something new programmers like because of the visual/visceral "I built that", but once you get exposed to the sheer annoyance of UIs, programmers will migrate to backend. So the most experienced people don't want to be constantly undercut in price by the incoming "…

The JavaScript world changes so fast that no one is ever going to be very experienced in the the they are using. I imagine that is partially to blame for all the crap we see in the front end.

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

#240

Post by nawgz »

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…

>Flexbox won't work because you don't have a fixed height

Are you saying the issue is that flexbox will force everything to have the same height? I am relatively sure that `flex: 0 0 fit-content;` on the children and `flex-wrap: wrap; flex-direction: column;` on the parent will do what you want

Post reply on HN