5 ms·
Ive been writing a react application with my wife for the last couple of months (something we started at the YC hackathon in November actually). It’s been a few
by blhack 7y ago
Ive been writing a react application with my wife for the last couple of months (something we started at the YC hackathon in November actually). It’s been a few years since I’ve written any react, so it’s been nice having her there to help me.
Maaaaaan...it’s like I’m learning how to program again. There is SO MUCH focus on shorthand and abstractions and stuff, all seemingly in the name of being “concise” that it produces code which to me is extremely difficult to read. It feels like I’m doing everything “wrong” when I read the documentation, and this would have been a lot harder without her there to pair program with.
Especially when I’m switching between golang on the backend (where I’m comfortable) and react on the front, it highlights how much they seem like totally opposite philosophies.
I’ll say this, which is probably mostly due to me growing up on python: code should read like a description to the computer of what you are trying to do, and even if somebody barely speaks the language you’re writing in, they should still be able to read what you’re doing. This doesn’t just help others, it helps you need less cognitive overhead when reading your own code back.
Saying the same thing with less characters rapidly approaches the point of inverse return, and it seems like most of the recommendations in the JS world right now just want to keep pushing us further and further into that inversion.
- madeofpalk 7y agoWhat are some examples of React's focus on shorthand and abstraction? React is fairly small and doesn't really encourage much at all. The one 'battle' that I often find myself in is "should this be a seperate component?" but that's more of a people problem and something that every language and framework will have.
- blhack 7y agoInstead of writing <ComponentName someVariable={true}> It’s just <ComponentName someVariable> Of course there might be some completely valid reason for this, but it’s baffling to me why you would want this type of shorthand, instead of just explicitly writing what you mean. Of course in golang this could be something like: var someVariable //is false someFunction(someVariable) But I would (personally) not write code like this if I could avoid it. It would be: someVariable := false someFunction(someVariable) It’s a little bit longer, but imo takes slightly less mental overhead to read.
- madeofpalk 7y agoIt's a shorthand, and its similar to what HTML does. If you don't like the optional shorthand, don't use it? I don't understand how this is something exclusive to React, or something it specifically encourages.
- blhack 7y agoYeah you might be right, and it definitely possible this is common and I’m just weird for not liking it.
- christophilus 7y agoIt’s common, but you’re not weird. I’ve done a lot of React and front end programming, and I hate this pattern, too.
- detaro 7y agoit mirrors HTML syntax: https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#boolean-attributes https://html.spec.whatwg.org/multipage/common-microsyntaxes....
- deleted 7y ago[deleted]
- woutr_be 7y agoI'm with you on this one, I've seen people rewrite things like this, and to me this is just personal preferences, and it's something that the team need to agree on.
- iamaelephant 7y agoHooks.
- gherkinnn 7y agoHoCs