4 ms·
> your comment perfectly encapsulates my experiences > feels like so many people actually writing in React are just effing CRAZY Same here. We had an experien
by not_kurt_godel 4y ago
> your comment perfectly encapsulates my experiences
> feels like so many people actually writing in React are just effing CRAZY
Same here. We had an experienced-but-batshit-crazy dev create a React site with approximately 250,000 LOC to support 3 forms with a max of 4 simple inputs and a 3-column data table view. To this day it makes my head spin how it is even theoretically possible to write that much code for so little functionality - much less _actually do it_. And don't even get me started on how unmaintainable it is - IIRC I tried to update the string content of an error message once and it required changing something like 57 lines in 10 files (or maybe it was 1 line in 57 different files? something like that...).
- molszanski 4y agoSweet pumpkins, I feel the pain. Architecture astronaut combined with a spaghetti aficionado. When one talks to people who have been around you hear amazing stories like that. thedailywtf material
- pdntspa 4y ago> We had an experienced-but-batshit-crazy dev create a React site with approximately 250,000 LOC to support 3 forms Holy moly. I've seen some bloat but that takes the cake.
- not_kurt_godel 4y agoThey 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 same string. And then every interaction between any 2 variables had its own type of types. Like if Form 3 was displaying the error message, there'd be a type for Form3DisplayingErrorLoadingMessageForInput1OnForm3. Which of course, is distinct from Form3DisplayingErrorLoadingMessageForInput1OnForm3AndErrorLoadingMessageForInput2OnForm3. And then those types were combined to create even more types, and so on until you had literally tens of thousands of lines of _just_ type declarations for variables and every possible permutation of UI state sitting atop a recursive pyramid of smaller subsets of the permutations (and so on until it eventually got to actual variable declarations). An then all that was piped through the craziest clusterfuck of redux butchery imaginable with a similar dynamic of explosively exponential growth of references and types and states and properties and so on. Like I said, it still hurts my brain thinking about it.
- sph 4y agoThat'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.
- not_kurt_godel 4y agoYeah...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.
- selfmodruntime 4y agoSo you're using the code of a maniac to judge an entire framework?