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

301–310 of 319 posts

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

#301

Post by tluyben2 »

krzepah wrote: post #299
tluyben2 wrote: post #148

Earlier quoted context omitted.

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

> Stop crying around on HN and go dev your feature

Not reddit here, people like to talk about and ponder eachother's opinions.

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

#302

Post by Kuinox »

krzepah wrote: post #298
Kuinox wrote: post #232

Earlier quoted context omitted.

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

Now it doesnt work:

- On mobile, using menu to search in browser menus.

- When users use F3 to search, an alternative to ctrl+f.

You added a few bytes to reimplement a browser feature, and spend time on a feature that already exist, because of your tech choice. There is still probably some accessibility issues.

You can have easily 60k rows in HTML without any performance issue, you just need to pay attention...

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

#303

Post by madeofpalk »

schwartzworld wrote: post #277
madeofpalk wrote: post #253

Earlier quoted context omitted.

This is nowhere near a common practice (I've never seen it on any work project, or on community projects). React does not promote or advocate or make it easier to do it this way, rather than the proper way in CSS.

It is actually in the react documentation. https://reactjs.org/docs/dom-elements.html#style I'm not saying that's how it should be done. I'm just clarifying what the author of the article was referring to.

Correct, it is documented. That's what documentation is - to list out and describe the API surface.

The entire documentation block for that is prefixed with a big yellow-box warning:

> using the style attribute as the primary means of styling elements is generally not recommended.

And then it links to https://reactjs.org/docs/faq-styling.html which just says over and over again "use class names"

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

#304

Post by krzepah »

Kuinox wrote: post #302
krzepah wrote: post #298

Earlier quoted context omitted.

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

Now it doesnt work: - On mobile, using menu to search in browser menus. - When users use F3 to search, an alternative to ctrl+f. You added a few bytes to reimplement a browser feature, and spend time on a feature that already exist, because of your tech choice. There is still probably some accessibility issues. You can have easily 60k rows in HTML without any performance issue, you just need to pay attention...

What are you talking about ? Are you saying a search feature is not necessary in my specs because you like using f3 or ctrl-f ?

"On mobile, using menu to search in browser menus" -> This is not a sentence.

I do add a "few bytes" to "reimplement" a "browser feature" ; but the reality is that i HAVE to implement search because it is hitting on 730000 per year records;

How is you ctr-f or f-1 feature is gonna search on 2190000 rows in 3 years ?

Again, you are too happy about your opinion that you spite it out like truth without even understanding specs.

Specs is what allow you to understand what's required, it makes no sense what so ever to talk about technology without understanding WHY you use it in the first place.

Is it meant for public ? employees ? How many rows do they deal with in their actual everyday workflow ?

You are pushing your workflow so much that you don't even consider about your users and that's another red flag for me.

PWAs have given so much in term of capabilities and mastery that I honestly wonder why I'm still talking about such things on HN while proper workflow about architectural design are ignored here.

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

#305

Post by krzepah »

tluyben2 wrote: post #301
krzepah wrote: post #299

Earlier quoted context omitted.

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

> Stop crying around on HN and go dev your feature Not reddit here, people like to talk about and ponder eachother's opinions.

Honestly I like HN but the constant talk about PWA vs pure HTML apps has became tiresome and unproductive. I haven't seen a single argument that's properly stated about why we shouldn't do them.

Having argument alike "Oh I have to dev that feature therefor X sucks" is not a good enough opinion that i would like to read here neither.

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

#306

Post by Kuinox »

krzepah wrote: post #304
Kuinox wrote: post #302

Earlier quoted context omitted.

Now it doesnt work: - On mobile, using menu to search in browser menus. - When users use F3 to search, an alternative to ctrl+f. You added a few bytes to reimplement a browser feature, and spend time on a feature that already exist, because of your tech choice. There is still probably some accessibility issues. You can have easily 60k rows in HTML without any performance issue, you just need to pay attention...

What are you talking about ? Are you saying a search feature is not necessary in my specs because you like using f3 or ctrl-f ? "On mobile, using menu to search in browser menus" -> This is not a sentence. I do add a "few bytes" to "reimplement" a "browser feature" ; but the reality is that i HAVE to implement search because it is hitting on 730000 per year records; How is you ctr-f or f-1 feature is gonna search on…

""On mobile, using menu to search in browser menus" -> This is not a sentence. " -> Sorry, I meant using the browser search feature by invoking it from the contextual menu of your browser, which is the only way to spawn the search toolbar on mobile.

" but the reality is that i HAVE to implement search because it is hitting on 730000 per year records;" -> True, there should be a search feature with a backend API.

"Again, you are too happy about your opinion that you spite it out like truth without even understanding specs."

Yes I want too far, your use case does require extra logic, because it's not good to send that much data to the user. I'm not pushing a workflow, im not a front end dev, but i do maintain frontend apps sometimes, i'm simply angry at React, because it cause pain to me as an user.

It's noticably slower (https://medium.com/dailyjs/a-realworld-comparison-of-front-e...).

The virtual list may be required for your use case, but as a user, I often met virtual list:

- Used for less than 100 elements

- ctrl f is not hooked on the 'webapp search feature'

- the 'webapp search feature' is noticably slower than the browser.

Also, here some reading, from a framework I don't use, about the virtual dom:

https://svelte.dev/blog/virtual-dom-is-pure-overhead

Now, not as an user, but as a software engineer, my soul cry when I see the architecture principle of such a framework fixed with a workaround.

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

#307

Post by hunterloftis »

hinkley wrote: post #231
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 excit…

I think you may be interested in Web Components.

https://developer.mozilla.org/en-US/docs/Web/Web_Components

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

#308

Post by AdmiralGinge »

WorldMaker wrote: post #183
RandoHolmes wrote: post #169

Earlier quoted context omitted.

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.

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…

This threw me straight back to secondary school, we had a teacher with a fearsome reputation who was berating a class of mine for not revising efficiently, he said "you can't just open your book and learn by osmosis" and some very brave kid piped up with "it's not osmosis sir, that's the movement of water across a membrane. We'd be learning by diffusion, not osmosis". At the very least, this proved we'd been paying attention in biology!

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

#309

Post by kilburn »

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…

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

That is what Gatsby / Next.js do too. The issue is that deferring the hydration doesn't mean it is neither non-blocking nor quick. Once hydration is triggered, the browser gets blocked until it finishes. Of course, the speed of the process depends on the site and how much content it has. If you are building an e-commerce site, this will tend to be on the side of heavy (just the full menu structure, footers and such will be quite a lot already).

> but also doesn't take ages to become interactive.

The issue is that a regular old website can be interactive almost immediately. If you have a hydration process interactivity is inevitably delayed for any part that does require javascript to function... and also for the parts that don't, because the browser main thread is blocked for a while doing the hydration and won't respond to your inputs until it has finished.

If you don't believe me, open an incognito chrome window without any active extension, go to nuxt's own documentation site [1], run a lighthouse performance evaluation with the default settings (mobile/simulated) and see what scores you get.

In my laptop it is a 33 overall for performance, with 4.1s FCP, 9.2s TTI, 6.1s LCP and a total blocking time of 2.41s.

You can also test from https://web.dev/measure/, where I'm seeing a 57 overall (much better, but not good) with 3.5s FCP, 7.8s TTI, 4.9s LCP and a total blocking time of 500ms.

That is, the creators of this software have built a documentation site (i.e.: mostly text, very little interactivity) that doesn't get good performance scores. This, along with blogs, is the best use-case I can think of for the technology. And it doesn't perform good (according to Google's-defined objective metrics, not mine!).

[1] https://nuxtjs.org/guides/get-started/installation

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

#310

Post by pattycakes »

deergomoo wrote: post #284
RandoHolmes wrote: post #166

Earlier quoted context omitted.

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.

Yes. HTML is a terrible platform for applications. It provides basically nothing and I am continually surprised that it doesn’t seem to be a major focus for improvement like JS and CSS. I don’t need more types of semantic rectangle, I need actual real UI controls that are efficiently rendered and accessible by default, so I don’t have to build everything from scratch. The fact that there’s no built-in element for thi…

>The fact that there’s no built-in element for things like dropdown menus is mind boggling to me.

You mean the select tag?

Post reply on HN