Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If not React, then what?

infrequently.org

Post reply on HN
Print view View original

551–560 of 756 posts

Re: If not React, then what?

#551

Post by gf000 »

slotrans wrote: post #467
ls_stats wrote: post #303

Earlier quoted context omitted.

>Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. that was the case in 2015 when entry level android devices were quite slow, nowdays a cheap $200 android phone has at least 4-6GB of RAM and an eight core processor. if that isn't enough for your react powered site, you are doing something very wr…

Multiple times daily I encounter sites that are brutally slow not just on my beefy Android phone, but on my 3GHz+ 8-core 64GB desktop machine. You need to take performance seriously or it will just be bad. Most of the industry has chosen to be bad.

Well, tracking and advertisement will be doing it, not react.

Re: If not React, then what?

#552

Post by grey-area »

branko_d wrote: post #540
grey-area wrote: post #537

Earlier quoted context omitted.

Nobody needs an SPA, it’s a stylistic choice, not a need.

Ugh, that's just the fundamentalistic, non-engineering approach that we need less of. Everything is a trade-off, and SPAs offer a trade-off that is right for some cases and wrong for others.

I disagree that SPAs are the only solution to some problems. This is an orthodoxy which people buy into but there are always a few different approaches possible. What do SPAs actually offer which is unique?

There are multiple possible solutions to most problems, including gmail or google maps for example. Just because you want to load code and data dynamically doesn’t mean you need to buy into SPAs (the followers of which I’d argue are far more fundamentalist in insisting you can only use SPAs).

Re: If not React, then what?

#553

Post by gf000 »

martinald wrote: post #364
ls_stats wrote: post #303

Earlier quoted context omitted.

>Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. that was the case in 2015 when entry level android devices were quite slow, nowdays a cheap $200 android phone has at least 4-6GB of RAM and an eight core processor. if that isn't enough for your react powered site, you are doing something very wr…

Keep in mind that React is very single threaded (as is nearly everything in javascript). These phones might have 8 cores; but they tend to have the same single thread performance as 10+ year old iPhones.

That assumes that the bottleneck is JS parsing/execution. The browser itself is not single-threaded and can load/parse resources in parallel.

And I don't buy that most websites would have react as the bottleneck, over the million other js libs, ads and tracking.

Re: If not React, then what?

#554

Post by hlandau »

Most webapps would be dramatically improved if the developers were banned from using any JavaScript on the client side in the first version, and allowed only to apply progressive enhancements from there.

Re: If not React, then what?

#555

Post by troupo »

hasanhaja wrote: post #312
troupo wrote: post #270

Earlier quoted context omitted.

> A fun thing about reading Alex is that you can tell he's had the same arguments over and over again for a decade now and he's frustrated with having to keep on making the same points and getting the exact same responses. The sad part is that it's the same increasingly hostile arguments he's making while he spent the decade making sure that browsers remain bloated and tech requires Javascript to even barely function…

> and tech requires Javascript to even barely function: see his entire work on web components. I'm confused by this characterization of web components. While they can minimally work without JS now (i.e., declarative shadow DOM), the whole premise builds atop of how the web and the browser works, and that is progressive enhancement. Your browser starts showing you the content before all of the content has finished dow…

> the whole premise builds atop of how the web and the browser works

Of course not. They need Javascript to participate in forms (though a button on WCs still can't work as a submit button), they need JS to handle global styles, they need JS to handle ARIA (there are at least two different proposals for this), they need JS to fix text selection etc. etc.

Nothing in web components two dozen specs builds on top of basic browser functionality.

> Why do you want web components to work without JS? Do you also put the same constraints on frameworks?

That's bot what I wrote. I'm calling Alex Russel's hypocrisy. He's ranting against web frameworks while he's spent the past decade creating tech that needs more and more JS for basic functionality (and more JS to fix issues previous designs and patches) and is literally advised to be used as only through libraries and frameworks

Re: If not React, then what?

#556

Post by gf000 »

archerx wrote: post #504
ls_stats wrote: post #303

Earlier quoted context omitted.

>Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. that was the case in 2015 when entry level android devices were quite slow, nowdays a cheap $200 android phone has at least 4-6GB of RAM and an eight core processor. if that isn't enough for your react powered site, you are doing something very wr…

React sites still feel janky on my 24cores and 48gigs or ram. Which is impressive for all the wrong reasons.

Which react sites? Are you sure you are not a victim of confirmation bias? How often do you check what framework does a smooth and performance website uses?

Because demo sites are snappy on even low-end devices. It's not react itself that causes slowness, but all the other libraries/tracking/ads.

Re: If not React, then what?

#557

Post by baobabKoodaa »

quantadev wrote: post #469
baobabKoodaa wrote: post #392

Earlier quoted context omitted.

First it was "10+ years experience", which would qualify me, but now you shifted the goalposts again to "decades" experience. Lol. I guess you can keep pretending that everybody who matters agrees with you when you just count everybody who disagrees as someone who doesn't matter

I originally typed "seasoned developer" and then I edited it to say decades. Neither one of us has perfect definition of "seasoned developer" in terms of precise years, and it doesn't even matter. But there are some things that are obvious to any seasoned developer and the value of type-safety is one of them. It's not my opinion. Is a fact. And yes if you say you have 10+ yrs and you don't prefer type-safe languages,…

I'm a seasoned developer. Your opinion is just your opinion, not a fact.

Have you heard of Python by any chance? Pretty much the entire field of data science is built on top of a dynamically typed language. Plenty more seasoned developers working in that field.

Re: If not React, then what?

#558

Post by slidehero »

antris wrote: post #519
fleabitdev wrote: post #342

Earlier quoted context omitted.

You're completely right, but I think it's worth adding that the O(n^2) to O(n) change isn't specific to React or UI. That same improvement is often seen when migrating other code from a mutating style to a pure-functional style. "A pure function which transforms the entire input into the entire output" is obviously the simplest possible architecture for many programs, but people hesitate to use that architecture beca…

> "A pure function which transforms the entire input into the entire output" is obviously the simplest possible architecture for many programs, but people hesitate to use that architecture because of performance concerns. In practice, the baseline performance is often faster than they expect, and it can be made much, much faster using strategies like memoisation and fine-grained reactivity. But before React came alon…

> If the user is typing in a form field while an update to the app state comes

Could you give a practical example of what you mean here? I can't quite wrap my head around what kind of interaction you're describing.

Do you mean some kind of scenario like a shared document with multiple people editing it? This is a very niche case.

> This means when the DOM resets, there's no problem with elements getting removed and added back in,

Could you give a practical example of this? I've been building web apps for a long time and I don't know what "when the dom resets" means.

Re: If not React, then what?

#559

Post by leptons »

RedShift1 wrote: post #542
leptons wrote: post #533

Earlier quoted context omitted.

I'm not trying to save you from anything. Stop being dramatic. I honestly don't care what you do or what advice you take.

I'm with albedoa on this one. Loading things only when you scroll to them makes for a terrible scrolling experience.

You obviously didn't read what I wrote or understand it. I specifically said this:

>Sure you can load scripts in-line for stuff below the fold, but make sure it doesn't actually get parsed by the browser until that feature is likely to be visible on the screen."

I specifically said you could load a script in-line for stuff "below the fold" as long as the browser doesn't parse it until it's used. That's very different than doing an HTTP request for a script file while scrolling.

But you know what? Forget it. I'm done trying to explain things to people who think they already know it all and didn't even understand my original comment.

Re: If not React, then what?

#560

Post by codeptualize »

nox101 wrote: post #423
codeptualize wrote: post #361

Earlier quoted context omitted.

This. I still have nightmares sometimes. If you don't use a framework you will probably end up building one, and it's not going to be as good as the existing options.

I don't know if I'm convinced. I have several react projects stuck in dependency hell. If I upgrade from build in node 18+ (from 16) I start getting errors. If I try to upgrade react then 1 of the 3 external widgets I'm using barfs out. If I do manage to get upgrade I get complaints about all the best practices from react 16 that have been deprecated. If I'd written my own all of these issue would disappear because I…

Then do it.. you are free to experience it. Especially if it’s just you on the team you might be totally fine.

I will just say that any project that lasts that long will require maintenance work now and then. The issues you describe seem quite minor and are probably relatively easy to patch up. React provides code mods that do a lot of the heavy lifting, your external widgets have updates, or alternatives.

I would also add that you don’t have to use dependencies with react. It’s always good to be mindful of dependencies and limit them.

It’s the same thing, you choose dependencies to save you time, or you do it yourself.

My main point is that with your own framework you will also run into limitations, causing big rewrites taking days/weeks/months, and/or lots of upfront cost..

Post reply on HN