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

291–300 of 319 posts

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

#291

Post by nwienert »

tomc1985 wrote: post #287
nawgz wrote: post #237

Earlier quoted context omitted.

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?

> * hot reloading in your browser We recently added this "feature" to our react-on-rails codebase, and the only thing I can ask is... why? Hot reloading on Unreal Engine is a hot mess with all sorts of little caveats to think about. Meanwhile I can hit F5 and as long as my browser is configured right I can guarantee there's no old cruft to deal with. Why in the world would I want to add that kind of uncertainty in my…

Whenever you’re doing design or interactivity focused tasks, and actually in many cases debugging logic, hot reloading is not only a huge step function improvement, but a categorically different thing.

The analogy I like to make is this: imagine a painter had to wait 3 seconds for every stroke they made to show up. Would they be as good? Would they try out as many variations? Discover new paths they could go because they had the time to “test that weird idea real quick a few times”?

Hot reloading works especially well on React (and not I assume on game engines) because React, with hooks, used algebraic effects, which means all side effects are properly understood by the system and are undoable. So it’s not as hacky at all as you’d imagine.

I never understood the hate for HMR as a concept. Perhaps your implementation wasn’t great, but as a general concept it’s literally a game changer.

The same people who cast shade on it seem to always embrace incremental compilation (like in Rust) for some reason, too.

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

#292

Post by tomc1985 »

nwienert wrote: post #291
tomc1985 wrote: post #287

Earlier quoted context omitted.

> * hot reloading in your browser We recently added this "feature" to our react-on-rails codebase, and the only thing I can ask is... why? Hot reloading on Unreal Engine is a hot mess with all sorts of little caveats to think about. Meanwhile I can hit F5 and as long as my browser is configured right I can guarantee there's no old cruft to deal with. Why in the world would I want to add that kind of uncertainty in my…

Whenever you’re doing design or interactivity focused tasks, and actually in many cases debugging logic, hot reloading is not only a huge step function improvement, but a categorically different thing. The analogy I like to make is this: imagine a painter had to wait 3 seconds for every stroke they made to show up. Would they be as good? Would they try out as many variations? Discover new paths they could go because…

I guess I can see it in that regard, and knowing the implementation of it is complete and robust helps a lot. And I can see how this is useful for interface design; most of the good IDE gui toolkits of the past preview live as well.

But I also think this lessens the requirement for a solid mind's eye and ability to visualize changes before you make them. Having come from desktop development (with "live" gui development kits like VB) into webdev I guess I got used to code-a-bunch-of-stuff-and-hit-reload pattern.

As long as it doesn't get in my way, I'm cool with it.

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

#293

Post by naniwaduni »

nawgz wrote: post #238
mawise wrote: post #236

Earlier quoted context omitted.

+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

> No one doubts that React isn't the tool for this area

you would think so, but there are an awful lot of people don't seemed to be stopped by that

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

#295

Post by bmarkovic »

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've only used Vue SSR / Nuxt this way, so there might be a fundamental difference in the implementation, but hydration process in it isn't blocking, and whether or not it's slow greatly depends on how heavy your webapp is.

The page that he browser is hit with has ALL the content pre-rendered (sans CSS) in that first HTTP HTML response, and it behaves like a classical webpage henceforth until the moment that the interactivity bits are being hydrated which is deferred.

I concur that it's still a bad idea to use SSR SPAs for use-cases where a non-dynamic HTML page would work decently well, and there are ways to pack some of these frameworks (Vue in particular) so that it's a JS dependency of an otherwise functional webste (i.e. progressive degradation) for a lot of the in-between use-cases, but when what you're building is heavily leaning towards being essentially a web application (say, an e-commerce site, webmail client etc) then SSR is certainly the most viable option for a decent user experience that isn't full reloads on every click, but also doesn't take ages to become interactive.

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

#296

Post by bmarkovic »

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…

It is also a frustrating experience to endure reloads on every click if what the user is using feels like a web application and you're essentially placing that burden of reducing the interaction roundtrip time on your infrastructure which gets expensive really really fast.

Most web-thingies are neither 100% plain websites nor 100% plain webapps, most are in the middle, some are heavily leaning on one side or the other.

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

#297

Post by aabhay »

bmarkovic wrote: post #295
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've only used Vue SSR / Nuxt this way, so there might be a fundamental difference in the implementation, but hydration process in it isn't blocking, and whether or not it's slow greatly depends on how heavy your webapp is. The page that he browser is hit with has ALL the content pre-rendered (sans CSS) in that first HTTP HTML response, and it behaves like a classical webpage henceforth until the moment that the inte…

Vue’s hydration is much better, partially because the templating system allows more of the pages to be rendered. I’ve had react apps that had various convoluted systems that ended up rendering as basically blank pages before hydration due to dynamic state based on cookies, etc.

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

#298

Post by krzepah »

Kuinox wrote: post #232
krzepah wrote: post #147

Earlier quoted context omitted.

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 wor…

There is a find feature in the specs already. My users actually need to be able to interact with a lot of rows.

I can just bind ctrl-f to my search feature.

Also, it doesn't take 3 seconds to load but few ms as well.

See, you don't just pick a tech, you need to start from the specs and get what the user need.

Also, in pure HTML (because i tried it) ; the same rendering would be hanging anytime you try to act on something.

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

#299

Post by krzepah »

tluyben2 wrote: post #148
krzepah wrote: post #144

Earlier quoted context omitted.

Maybe implement authentification properly and store a refresh token that you can use to trigger auth on app load.

It is absolutely fixable, but the extra complexity invites people not to fix it while on the server it works as default. I have integrated some very popular backends the past months and their portals are all SPAs and they all have this issue; hit refresh and you lost where you are, thrown back to login.

There is a great article that went uncommented on HN about Architectural Decision Records.

https://github.com/joelparkerhenderson/architecture_decision...

The simplest of them include "consequences" of architectural decision. For PWA these include the development of that kind of features.

Now to be absolutely honest. I prefer having a dedicated back-end that does one thing well and a front end that does one thing well. Even if I have to put in extra effort with few features just to have my source-code more dedicated and therefore cleaner to work with.

The thing is that PWA not only included the front-end dev, they also reduced the complexity of back-end. And that's a huge win I'd pay with these kind of features happily.

Stop crying around on HN and go dev your feature

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

#300

Post by krzepah »

crooked-v wrote: post #247
krzepah wrote: post #143

Earlier quoted context omitted.

Why on earth would you specify your styling in your JS ?

Being able to dynamically supply theming is a big one. For example: const Header = styled('header')` font-family: ${({ theme }) => theme.fonts.header}; color: ${({ theme }) => theme.colors.primary}; backgroundColor: ${({ theme }) => theme.colors.primaryBackground}; ` ...where the theme object can be swapped out on the fly for different sections of a web app.

Thanks i haven't thought about that one. But i'd definitely try to stick up to css even if I'd have to dev that feature. Maybe by trying to change the var(--color) i've setup in my colors.css ;

I'd note out that this feature is also so edgy that the pushed argument shouldn't even occur that much.

It would be like "Oh hei, I need to dig up that super edgy star shaped hole using that shovel so I'm using it that way. Oh see, when I use it that way i'm inclined to do X. Therefore my shovel is encouraging me to do X."

Post reply on HN