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

React I love you, but you're bringing me down

marmelab.com

Post reply on HN
Print view View original

491–500 of 574 posts

Re: React I love you, but you're bringing me down

#491

Post by not_kurt_godel »

sph wrote: post #488
not_kurt_godel wrote: post #462

Earlier quoted context omitted.

They essentially created a unique type for every. single. variable. I'm talking like, if you needed string constant for an error message on Input 1 on Form 3, there was an ErrorLoadingMessageForInput1OnForm3 type declared for that instead of defining it as a string. The types were never reused - like if you had the same error message on Form 2, there'd be a separate ErrorLoadingMessageForInput1OnForm2 type for the sa…

That's not code written by an experienced dev like you said. They might have worked long enough to think they're experienced, but this is proof they're just terrible if not a complete hack that's in the wrong line of business.

Yeah...unfortunately they managed to fool me (and the rest of the team) in the hiring process. It was a nice day when they were finally forced off but also unfortunately it's been an ongoing, multi-year scourge dealing with the codebase they left behind. It works just well enough that it's not worth scrapping and totally replacing yet (at least as far as management is concerned) but it's virtually impossible to make changes/updates to it and maintain your sanity.

Re: React I love you, but you're bringing me down

#492

Post by rk06 »

ssijak wrote: post #313
randomsearch wrote: post #210

Earlier quoted context omitted.

Vue is learnable in a single day. React is almost as easy to learn. Just hire React devs and give them a couple of days with Vue, no problem

There is a difference in being able to write something that runs and writing idiomatic something which uses all the libraries idiomatically that runs.

If you think everyone, with React on resume, is in the latter category, then I have a bridge to sell to you.

Re: React I love you, but you're bringing me down

#493

Post by dogcomplex »

chrisco255 wrote: post #440
vore wrote: post #428

Earlier quoted context omitted.

Huh? react-hooks/exhaustive-deps does exactly that: it statically infers dependencies and is very noisy if you forget one, and the React team recommends that you always have it on. In fact, the React docs have this to say, right in the documentation for useEffect ( https://reactjs.org/docs/hooks-reference.html#conditionally-... ): The array of dependencies is not passed as arguments to the effect function. Conceptual…

The useEffect dependency array defines the values for which you want the effect function to trigger any time those values change. It is not always the case that you want an effect to trigger for every value used inside of an effect. Sometimes you only want an effect to run once (i.e. the empty array passed as deps). Sometimes a value changes too frequently to list as a dependency: https://reactjs.org/docs/hooks-faq.h…

Not to mention some of those variables auto-included are pointers to arrays/objects which won't trigger a change if their contents change, so you actually need a hash (or something more clever and specific) of the contents which should trigger a re-render... e.g. rendering the contents of a list sorting would want to listen to the 'sortBy' state rather than the list contents - even if the component wouldn't have used sortBy otherwise...

(this is all just bringing back painful memories - hopefully which aren't the same problem now? - from a project where I was the only developer on the team learning these intricacies, and having to figure out why everyone was getting infinite render loops or static components in weird situations, even as they blindly followed their linter useEffect suggestions... Needless to say, our code lucked ugly as hell after all this was done "right".

In retrospect I might have done all this at the app state level, pre-processing the inputs for each component with something like a 'usesEffect' boolean and a 'changeTriggers' array, then some generalized auto-reader util functions to parse that with default boilerplate behavior, just to get that stuff out of my frontend components... I suspect that would only move the problem up, but at least then you're just modifying json instead of also muddying all your templates. Subcomponent wrapping or something like that could work too. Idk. Gross stuff. Was unfortunately necessary with a ton of asyncronous calls and big data lists.

Maybe DB/API-fetched State > Frontend Parser & useEffect/Async Logic > Actual JSX Component Rendering separation...? (so - Model Controller View?) If it wasn't all already inherited legacy code mighta structured it like that more, instead of just rawdogging API results in JSX.

Re: React I love you, but you're bringing me down

#494

Post by aastronaut »

halfjoking wrote: post #490
cercatrova wrote: post #482

Earlier quoted context omitted.

You're mixing up server side and client side. The point of GraphQL is to make a client request only what data it needs rather than making X different REST calls then combining and filtering them in the client side. That's it, that's the entire purpose. (If you then ask, why not have REST calls that give specific pieces of information, ie have sorts and filters within the query parameters, and be able to take a table…

So if front-end devs get everything they need client side, what’s the point of having backend devs? https://imgflip.com/i/6u4obk

SPAs and REST APIs moved a lot of the complexity around data to the client side. GraphQL moved it back to the server side. I think that's a reasonable decision, as the client - compared to the server - runs in a much more unpredictable environment. Of course some backend devs complain about more work, especially work that could be moved to the client side at first. Making things the proper way is hard, yes.

Re: React I love you, but you're bringing me down

#495

Post by KronisLV »

Hawxy wrote: post #413
KronisLV wrote: post #308

Earlier quoted context omitted.

> Vue 3 with the composition API looks fantastic on paper. (I haven’t used it in any meaningful way) Recently worked on migrating a large codebase over from a legacy solution to Vue 3 with composition API, it was a pretty enjoyable experience, especially with Pinia! Though I'd say that the problem was that most component libraries/frameworks out there actually don't support Vue 3 well enough. Last I checked, only the…

> Most of the other ones considered weren't quite there yet From what I recall, quasar managed to update very quickly. Vuetify is currently in Beta for Vue 3 as they went with a greenfield rewrite to deal with tech debt. I rolled it out to a production site recently and it works well. BootstrapVue completely dropped the ball, despite the corporate sponsorships the original maintainers went missing for a whole year &…

> From what I recall, quasar managed to update very quickly.

This is true, at least there now is Vue 3 support, just checked: https://quasar.dev/

Though I can't edit the original post anymore. Oh well, thanks for clearing that up.

Re: React I love you, but you're bringing me down

#496

Post by dogcomplex »

pgamble wrote: post #62

Relatively new react developer here (still learning in fact!), I liked this article although it shook me a bit and made me wonder "am I wasting time with some of this stuff? maybe I should be looking ahead to the next 'best framework'". Id be interested in hearing people's thoughts: what would be best to learn for maximum applicability in the ~3 year timeframe?

Hmm. Toughie.

React kinda ate the web world well, so it's not a terrible bet that it'll keep it going for 3 years...

If you like data layer / DB stuff (and if you're strictly a frontend dev) my suggestion is to just get comfortable with SQL / Postgres / SQLite, and just dbs in general, as that stuff has remained pretty darn stable for a while. Only really replaceable by even-simpler (though less versatile) approaches like giant plain key-value stores, file-system-style storage (NoSQL), or added versatility to Excel spreadsheets (lol it may be more viable to let companies just keep using those than moving to a DB nowadays just to let office workers use what's comfortable). I learned SQL 15 years ago and still glad to have it now surprisingly - though it's maybe sometimes more powerful than I need. But good value there.

For frontend: JS, React, npm, docker containers, maybe Vue?... that's about as deep granularity as I'd go for predicting what'll keep another 3 years. Libraries, state management, all the tooling, etc etc - you'll probably relearn more than 3 times over during that... Welcome to (a hopefully well-paid) hell.

Re: React I love you, but you're bringing me down

#497

Post by dogcomplex »

vore wrote: post #117
pgamble wrote: post #62

Relatively new react developer here (still learning in fact!), I liked this article although it shook me a bit and made me wonder "am I wasting time with some of this stuff? maybe I should be looking ahead to the next 'best framework'". Id be interested in hearing people's thoughts: what would be best to learn for maximum applicability in the ~3 year timeframe?

Learn the theory, not the framework.

lol this is the wrong job for that. Join a game development team that uses assembly and C and cares about filling a gpu efficiently if you want to learn real programming. Here theory is philosophizing about the best way to organize a garbage dump to take our mind off the shoveling.

Re: React I love you, but you're bringing me down

#498

Post by dogcomplex »

Throwing my message in a bottle here, in hopes someone can answer:

What is currently the best way to handle the complexity once you have a ton of asyncronously-loaded JSX components which have complex conditional rendering logic based on multiple inputs and datatypes? (including defaults, local variables, and all kinds of other stuff)

At this point I'm inclined to just handle all the data processing logic and when-will-it-render logic in some intermediary controller and then keep the visual templating barebones and strictly separated, though it feels quite un-React-like to do this, and almost more trouble (and certainly more boilerplate) pushing vars through the stack and separating Controller / View than to just let my JSX be messy with useEffect hooks. I suppose this is when I should use a React class component? Or a subcomponent? Or a custom hook..? Or maybe I should just modify (global) state - even grosser from data duplication perspective, but at least then all the data processing is in one clearly defined format instead of scattered throughout templating files.

Last I checked (and burned out) this was the major React hurdle, and the downside of React's simple-by-default templating. This complex stuff got real ugly real fast. What's the elegant solution here, if any? Any improvement?

Re: React I love you, but you're bringing me down

#499

Post by WHATDOESIT »

pier25 wrote: post #361
WHATDOESIT wrote: post #332

Earlier quoted context omitted.

Lol, you really think someone is going to stray off the well-supported path for apps like these for 1-10% gain? This app shows a loading indicator quite a lot. Speed is important but nobody cares about raw speed this much. What we care about is a well-maintained library with significant ecosystem that's still going to be there in 2030 and it's super-easy to find devs and/or get help. The libs there are beta quality a…

"nobody cares about speed but give me async rendering because React is too slow"

The point is I'm not going to compare against small libs with no ecosystem, slow maintenance, small community and low amount of developers ready to use it - these new libs sound nice but it's beta software, not something to be used in production for apps like I work on. Speed is important but not this important.

What remains is React, Angular and Vue - and out of these React wins by a huge margin, also thanks to async rendering.

I'm looking forward having another look at the remaining libs in a few years.

Re: React I love you, but you're bringing me down

#500

Post by wiredearp »

bigDinosaur wrote: post #480
wiredearp wrote: post #119

Earlier quoted context omitted.

In React terms, "functional" almost always implies the opposite of purely functional. It just means that the component is declared by a function instead of a class. First time you call it, the function can assign state that it may reference in future calls, not unlike the methods of a class. How they actually go about this is however almost entirely weird.

Classes in JS are just functions anyway, and functions can have state. Saving the state of a function is a different thing, but of course JS allows that, too. Why is it weird?

Class instances are objects and it's the objects that have state. Functions can only abuse themselves as objects to store state.

function johnson() { johnson.state = {}; }

This is however shared state and the state will be reset whenever the function is called a second time. So what you normally do with a function is to pass the state via arguments and now the same function can work with different states. React could totally do this via props or as a second argument.

function Johnson(props, state) {}

Instead they changed the laws of functions so that a function can act different the first time it is called and also be called the first time multiple times if and when the function calls a functions that looks like JavaScript but follow different rules [1].

This is weird.

[1] https://reactjs.org/docs/hooks-rules.html#only-call-hooks-at...

Post reply on HN