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

211–220 of 319 posts

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

#211

Post by christkv »

_fat_santa wrote: post #133
christkv wrote: post #100

Earlier quoted context omitted.

React has been god sent for us as we slowly modernise an application that is a mess of server rendered html and hacked together frontend code. Slowly we are rewriting individual pieces as embedded React components (no SPA here) and moving to a proper API layer that the components talk to. The separation of concern has made it a loot easier to increase code coverage and ensure a controlled rollout of new features. We…

Honest question. As someone whose only worked with open source tech in React such as Bootstrap, Semantic UI, Material UI, etc, what is the advantage of a paid UI framework like this? Maybe stability? Besides Semantic UI I found that other frameworks are nowhere near as mature. I guess if you're a big company its a small price to pay but it also seems like you're paying a grand + per month for something with tons of f…

700 usd a year for the library for a developer. It saves us a ton of time as its a B2B business and we use a lot of stuff like a calendar view, gantt diagrams and scheduling. Rewriting it from scratch of adapting a random set of components would be more expensive in time and resources.

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

#212

Post by unethical_ban »

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.

The first time I got even close to a custom web page (internal request system for our team), the devs did this. They wrote it as two Bottle (python) applications: One was the API for the app, the other was the delivery of the Javascript to the client, which called the API.

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

#213

Post by bernawil »

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.

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 was pretty terrible.

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

#214

Post by bharani_m »

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…

This is really interesting. Thanks for all the effort you've put into this project.

I had one quick question - how easy/difficult would it be to integrate another JS library with intercooler or htmlx. For example, let's say a table is fetched dynamically via htmlx, how would we go about integrating a library that does client-side table sorting/filtering?

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

#215

Post by christkv »

mixedCase wrote: post #171
christkv wrote: post #100

Earlier quoted context omitted.

React has been god sent for us as we slowly modernise an application that is a mess of server rendered html and hacked together frontend code. Slowly we are rewriting individual pieces as embedded React components (no SPA here) and moving to a proper API layer that the components talk to. The separation of concern has made it a loot easier to increase code coverage and ensure a controlled rollout of new features. We…

> The separation of concern has made it a loot easier to increase code coverage and ensure a controlled rollout of new features. This can be achieved (and more easily) by separating your templating from your business logic at the package level. If you know what you're doing you can keep things separate and your import graph non-cyclical, if you don't know what you're doing you're going to recreate the mess in your co…

Everything done badly of course causes the same effect. But we are dealing with a massive mess that is the worst case of both worlds.

Since we need to also provide an API going forward to our clients, for our usecase this was a great solution. However we are not doing an SPA, the main framework and navigation is still server driven. The difference is that the "create new user dialog" is now a react component that calls the corresponding api.

Running through the API also makes it easier for us to handle the caching of data at that layer instead of a mix of jquery calls and random div HTML generation.

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

#216

Post by davidwparker »

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…

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.

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

#217

Post by kbenson »

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…

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.

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

#218

Post by 7786655 »

wwright wrote: post #88
hliyan wrote: post #48

Earlier quoted context omitted.

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.

This site also has almost no state at all per-user.

Every time you collapse a thread, that's saved on the server. Then, if you return to the page, it will render those threads collapsed. So that's a decent amount of state.

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

#219

Post by kilburn »

kbenson wrote: post #217
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…

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

2. You send the React stuff (React itself, your pages components, extra libraries you are using, etc.)

3. You hydrate React's virtual dom using the already existing DOM (that the browser has created in step 1). This essentially amounts to telling react to attach the proper event handlers to the DOM so it can continue working as if that DOM was created by React itself.

[1] https://reactjs.org/docs/react-dom.html#hydrate

[2] https://reactjs.org/docs/react-dom.html#render

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

#220

Post by WorldMaker »

chias wrote: post #186
WorldMaker wrote: post #183

Earlier quoted context omitted.

There's an interesting correspondence with water and data going even further back than that in the English language, think about how often you hear variations on "learning through osmosis" or "hopefully I will pick that up through osmosis". Osmosis is specifically diffusion of water. It's fascinating that so many speakers of English refer to it as "learning through osmosis" rather than the more accurate and less wate…

Not sure diffusion is really more accurate than osmosis. It does need to diffuse across the brain membrane, after all ;)

Well, one can assume the eyeballs are akin to an aqueous membrane, but the human ears generally should be non-aqueous for best results. ;)
Post reply on HN