Live data from Hacker News

React is holding me hostage

emnudge.dev

421–430 of 553 posts

Re: React is holding me hostage

#421
post #216

Earlier quoted context omitted.

I have a beefy machine and fast internet. Yet, JIRA is annoyingly slow. Half the time, pages on my bank’s website take forever to load, or don’t load at all. I don’t have any numbers, just some anecdotal experience like the above. It is not just speed. The UI of many sites suck too. Amazon, GoDaddy, for example. Then there are ads. We don’t see ads in between content anymore. It is content within ads these days. I am…

Jira is a not very good product, implemented by worse engineers, that happens to be better than its competitors (ironically proving the point I made further up thread).

> implemented by worse engineers

Jira is a 20 years old piece of software. I'm sure today's engineers do their best with the constraints they have. And I'm sure the 2002 engineers did their best with this period's assumptions and solutions.

I hate Jira as a product, but please don't attack people like that, have you never had to work on a product you're not 100% satisfied with? :/

Re: React is holding me hostage

#422
React is the most "framework" framework out there especially when hook come out, it completely dictates you how you write your program, and it's very easy to go into traps if you don't know how hooks are implemented. I'd much rather use a reactive UI framework like Solid because they use a much simpler concept

Re: React is holding me hostage

#423
post #105

Earlier quoted context omitted.

I get so lost in these conversations, because I've been the lead on a relatively complex React app for literally years now and none of any of this has mattered or come up in any way whatsoever. Our app is plenty fast/responsive, maintenance hasn't been perfect but it's been manageable, same with new features... The learning curve around context was a bit steep but we get it now and haven't had any issues since. It's…

Depends on what kind of so your building. For a while, a lot of the form libraries out there triggered huge numbers of rerenders and caused perf issues. That's still a problem, though some of it has gotten better uncontrolled components. Timing-based UIs are (such as a sequence of triggered animations) can get really messy really fast. I've seen some really messy bugs in a app that had visuals and audio tied to diffe…

Forms were annoying but `react-hook-forms` eliminated any random issues we had, and now forms are fine. Again, context saves the day here by letting me grab the form context within nested components to keep everything humming.

I don't know if we have any "timing" based components, though we manage global state using Apollo Client and again, haven't really had any issues with that.

Re: React is holding me hostage

#424

Earlier quoted context omitted.

Well, don't use those. Pure React is enough 95% of the time, and then an additional 4.9% can be handled with jotai in a couple of places. React + GraphQL + jotai is my preferred stack

> Don't use those...then an additional 4.9% can be handled with jotai... Needing Jotai on top of React's defacto state management is the issue. TFA talks about an ecosystem of libraries that attempt to fix React's shortcomings. Pure React does have undeniable shortcomings like proper, non-brittle routing.

I agree with you about routing. Something so core about building web apps should be treated as a first class citizen of the ecosystem.

I don't think jotai adds a lot of complexity though, and like I said most of the time you don't need it. It just makes syntax a bit nicer to read and write, but you could do it with context if you really wanted to.

Re: React is holding me hostage

#425

The whole thing around React is odd to me. People laugh at web development, especially the frontend, for changing libraries every week but you read a thread like this and everyone is so sure that React is a bad library and we should be using some newer library instead. I work with React daily and it has issues, but I find most issues can be worked around without much trouble. It's easy to hire people, onboard people,…

> It's easy to hire people, onboard people Yes they'll know the React part. It's the Redux/Mobx/React Router/whatever snowflake libraries you chose part that will be more difficult. I really don't like incomplete solutions personally.

Its all about preferences, I tend to prefer seasoned devs who have had the chance to try different things and form their own opinions. Someone who has relied on framework magic they don't understand through their careers tend to be less resilient to change

Re: React is holding me hostage

#426

Earlier quoted context omitted.

SPAs exist because of the developer experience and user experience, the support for complexity is an added bonus. Everything can be done with SSR, but some things are terrible with SSR (oh, you need real-time updates? have some meta http-equiv refresh header, and observe the beauty of the page going blank and re-rendering every second). Before you ask about the developer experience: it's about having developers that…

4 letters. HTMX. Or look at https://www.phoenixframework.org/ to see what a web framework would look like if real-time updates mattered. (That said I do find that simple IoT applications like a volume knob for my smart speakers in party mode or that can toggle my lights do work well with websockets + mobx + React.) As for DX, I think waiting for "npm run start" to get out it's own way is a large enough decrement that…

HTMX definitely chips at some of the use cases of SPAs. What percent of cases? I don't have that answer.

And yes, Phoenix is a very interesting thing, but it's most likely only viable because of it being Erlang under the hood (needs a process running for each client, hence ultra cheap Erlang processes being a good fit).

> when you visit some site like anandtech it is by no means accidental that the layout rerenders endlessly because each rerender is a chance that a click on a link is transmogrified into a click on an ad

I think you went a bit too far into the conspiracy theory there. An element for which the height is not defined (via HTML or CSS) gets rendered usually to 1x1 pixel, which forces a redraw if the element turns out later to have width and height (like an image that takes half of a second to download). Which, IMO, means web developers are not bothering to put sizes in delayed-loading elements, which points a bit more to the incompetence side than the malice side. But ads probably not specifying width and height would also indicate significant malice, can't rule that out.

Re: React is holding me hostage

#427

Earlier quoted context omitted.

Your dislike for ‘templates’ is much more a matter of personal preference than you’re letting on. Using language like “still using templates” makes me think that you don’t see any valid opposing view. I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have. But framing non-JSX approaches as objectively inferior is not in tune with the reality, being that this is something sensible peo…

> Templates are a no go for me It’s pretty hard to get more “this is my opinion rather than a statement of objective fact” than this. > I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have. Ok. Um… well, it’s hard to have a discussion if you won’t talk about it… …but, “code” templates allow autocomplete and type checking in a way that is an objectively distinctive superset of text…

VsCode + Volar + Vue + TS do what is expected. Fully typed autocomplete experience, same as for Typescript. Zero problems.

Re: React is holding me hostage

#428
post #70
post #66

Earlier quoted context omitted.

But you can do that with algebraic effects. That’s kind of the point. You keep the clarity of declaring what you want to happen, and abstract the how to the effect handler.

None of that is true in React hooks. The negative sentiment towards hooks that you see here is because it is weird and complicated. Want to see how much simpler code can get when you code without React or any such fat frameworks? Take a look: https://github.com/wisercoder/eureka/tree/master/webapp/Clie... You just need to know JavaScript, HTML and CSS, not much else. The code is simple, and yet maintainable. No need…

https://github.com/wisercoder/eureka/blob/master/webapp/Clie...

I love how you do React. I mean, what's more react-y than blanking the page then appending HTML? I'm gonna call that Rejqueryact, because it's jQuery inside React.

Re: React is holding me hostage

#429

I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless. VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics. The killer feature for…

There's 2 things that I hate about react. 1) JSX - It's terrible. Svelte, Vue, Riot... they all got it right. JSX, mixing a weird syntax of HTML and JS together is just inferior to HTML with additional markup. 2) I don't know why but every react project has crazy levels of abstraction. Everything is 15 layers deep and making any sort of change requires way too much effort to navigate 15 files and code reading to make…

I can’t stand JSX either - it’s using JavaScript to render HTML templates, but it’s not valid JavaScript or HTML. I much prefer libraries like Lit that use tagged template literals for rendering component views - you write real code in the actual language the browser understands, no extra transpile step needed.

Re: React is holding me hostage

#430
post #36

Meh. The most important thing about React is you have to think like React wants you to. It's a very pattern-oriented type of development I haven't seen much of elsewhere. Most of the footguns listed in this article are things you obviously shouldn't want to do because they're not React-y.

Some others would describe it as idiom-orientated.

Thanks! That's probably a better phrasing.
Post reply on HN