Live data from Hacker News

If not React, then what?

infrequently.org

131–140 of 756 posts

Re: If not React, then what?

#131

Earlier quoted context omitted.

I don't have any context, but I do have trouble imagining that any of your projects have scale/complexity above brochure-ware if you haven't run into this.

If you have trouble imagining, here's one such project: https://github.com/baobabKoodaa/ouija

Jesus Christ, a 1300 line single file codebase.

Re: If not React, then what?

#132
post #40

Turbo morphing. It’s part of Hotwire. Re-Render the full page server side, app takes response, applies only the changes needed. Preserves scrolling state, etc. Super simple pattern for building dynamic sites. https://turbo.hotwired.dev/handbook/page_refreshes#morphing

This is the way.

It achieves 95% of the effect, and you maintain one implementation, not two.

Re: If not React, then what?

#133
post #108
post #4

> Frameworkism isn't delivering. It isn't? I find React to be great to work with.

If React is so great how come Amazon isn't using it in their store? I think last year an Amazon frontend engineer wrote some tweets explaining they tried React and it was too slow. So they keep using Java for SSR and sprinkle vanilla JS. They were still using jQuery until a couple of years ago and probably still are in some parts of their site.

Because Amazon Store is and aleays was an armpit of webdesign? It's the worst designed e-commerce site and decades of tinkering only brought it half way towards basic level of decency that was obvious to a beginner web developer making their own first e-commerce site from scratch in PHP 20 years ago?

Re: If not React, then what?

#134
I don't think the author of this article actually understands the pressures that increasingly drive all frontend development into javascript frameworks, but those pressures are actually very straightforward:

• A large portion of the cost of maintaining a code repository goes toward maintaining the build.

• Multiple builds per repo create significant costs.

• Any web application with a UI _requires_ a frontend build for CSS/JS. Anyone around from the JQuery/pre-SASS days will recall the mess that lack of things like dependency management and ability to control import order caused.

• If the frontend build is already baked into the process, you can save costs by _only_ using a frontend build.

• SPA patterns are the easiest to use with a frontend build, have the most examples/comprehensive documentation.

Re: If not React, then what?

#135
post #70

Earlier quoted context omitted.

Do you not care about most of your potential customers, or do you only cater to high net worth people? If so, then sure, substandard devices and connections can be ignored. If you’re Target, on the other hand, you probably shouldn’t ignore them. I find it extremely odd that this was even a question on this site. Do you think the problem you’re solving should impact your tech stack at all, or is your tech stack more i…

You're making the same mistake as the author. I get unnecessarily aggro too, but a plain reading of their comment isn't "they only cater to high net worth people" or they're advocating for such. Its "hey we're talking about 3G connections at this point, which are mostly shut down, and we don't cover developing markets" Note most of this is nonsensical too. His primary thing is "you don't need client side code because…

I keep hearing the "SPA is actually lightweight" argument but it's never materialized for me, the fastest sites are SSRs that are mostly static. The saving from HTML vs JSON just isn't that much over the wire and mobile CPUs and memory are a bottleneck.

I have a newer iPhone and Safari is still full-refreshing pages constantly due to memory.

Re: If not React, then what?

#136

Earlier quoted context omitted.

What do you find hard to learn about react? I think a lot of tutorials are really bad, might be the problem.

Not GP. Started using React at work around 2017. The hooks API is just awful. Those complaints are extremely well-trodden ground at this point so I won't rehash. I'm using Lit.js for personal stuff instead these days. Shadow DOM isn't perfect but web components with Lit has been pretty low-surprise so far, which I can't say for Hooks React.

> The hooks API is just awful

Hard disagree. Hooks are 100% what is best about React these days and custom hooks make organizing or encapsulating and sharing behaviors between components a total breeze.

Re: If not React, then what?

#137
post #105

Earlier quoted context omitted.

It's easy for developers to forget who the "app" is actually for. Users don't care how it was implemented or how nice the code looks, they just want it to work.

Right. That's precisely why full page reloads/updates every time some action is done (mouse click for example) would be completely unacceptable for most apps I've worked on. I've worked mostly on apps not websites.

The overwhelming majority of default HTML actions (no JS) that happen from a mouse click do not trigger a page load. You're trying to make it sound like selecting an item from a dropdown or selecting a textbox to enter text will cause a complete page load every time unless you use an SPA framework and that's just literally completely untrue.

By your measure though, it sounds as though you'd be fine if these page loads in the javascriptless world were done in iframes, since then only some portion of the site is being reloaded?

I'm using that to illustrate the argument is absurd and the basis on which it is made seems also absurd.

SPAs are heavy and frequently written poorly, often eschewing the principles of loading only the bare minimum for a kitchen-sink approach. If you view the web as having only those two options to accomplish "real work" then yeah, you're gonna thing that SPAs are the only way. It's not reality though.

Re: If not React, then what?

#138
post #73

WOW this is a long article! Still waiting for the substance though... The only point I can agree with is that React is stupidly hard to learn. It feels like a tool made for aliens, though once you master it, it can be pretty efficient. Sorry to be the bearer of bad news, but the JS-free web isn't coming back. And if you're using modern JS, you might as well use React (or a similar tool). The user won't be able to tel…

Cannot agree more! Mastering React is ridiculously hard for what it is. There are so many “buts,” “it depends,” and subtle differences to navigate, like useEffect vs. useLayoutEffect. But don't forget useEffect is an evil in the first place and so on, and so on. It feels like a clever proof of concept with a leaky abstraction at its core, one that no amount of effort can truly fix, no matter how much they throw at it…

You shouldn't write a single useEffect in the first year or two of your career in React.

Why people are so keen on stabbing themselves just because there's one or two weird shaped forks in the kitchen drawer. Why do suddenly everyone tries to use it for spreading butter or peeling eggs?

Just understand what unidirectional data flow is and you are golden. You know the entirety of React you should be using for your first year of full-time job.

Re: If not React, then what?

#139

Earlier quoted context omitted.

I don't have any context, but I do have trouble imagining that any of your projects have scale/complexity above brochure-ware if you haven't run into this.

If you have trouble imagining, here's one such project: https://github.com/baobabKoodaa/ouija

I have a lot of "framework free" single-developer projects as well (such as https://bongo.to ), but that isn't really what I think we are talking about here. Single developer projects can do whatever they want, it isn't a problem. The problem comes when you have to work with distributed teams, juniors, etc. One way or another a large team still has to come to agreements about how to do things, and without an external reference it will have to be made up in an ad-hoc manner instead. This often leads to issues, many of us have noticed.

Re: If not React, then what?

#140
post #126

Earlier quoted context omitted.

Do not base your company’s tech decisions on FAANG companies unless your company is a FAANG company. Your challenges are likely very different from theirs

You're missing the point of my comment. Someone is contesting that "frameworkism isn't delivering" when we have objective data to prove that it is in fact not delivering. The Amazon store is just a good example because there's a lot of data about it, not because it's FAANG.

What I read from what you said is “Chevy trucks are good? Oh yeah, if trucks are good, why does the post office use non-Chevy, non-truck, fleet cars?”

Please help me understand where I misunderstand

Post reply on HN