#anyway tl;dr there are many solutions to my problem but the best one IMO is to just not make my mod depend on anything else

[rohirric-hunter]

Skyrim constantly minimizing itself issue solved by running it in windowed mode. Not sure why this fixed it but sure, why not

#im wondering if as a first mod i should maybe clean out my mods list and only use a few while testing this #on the other hand it gave me a lot of confidence to see how well it ran with a good stack of mods on there #i do have to be more careful about dependencies i think #a bit of googling indicates that the issue was that 'reverting' changes is not the same as 'deleting' them #so in the specific instance of what happened -- adding an item from a mod to a characters inventory and then removing it later -- #there was still some junk data referencing the old mod #im thinking i can probably make a mod that isnt dependent on anything #and then add patches for if people use other mods #that is when the other mod author doesnt allow you to just copy their stuff straight into your mod #for example i can give them hairdos from ks hairdos because the mod author gave blanket permission to do that as long as my mod is free #anyway tl;dr there are many solutions to my problem but the best one IMO is to just not make my mod depend on anything else

[jyndor]

so I was talking to my friend @timelordthirteen about some shit and I decided to just share with you all about the importance of actually explaining shit instead of just saying it. the Left, I am looking at you bitch (ily bitch but)

lol would put a read more but tumblr's being a petty little bitch today ❤

shitposting is fun. dunking on asshat right wingers is fun. you know what is not fun? seeing people not understand the basic terminology that we use in the ~discourse*

but. if we are going to use terminology, if we are going to inject regular old laypeople conversations with (imo) unneccessary amounts of academic terms, then we should try to use them correctly** because in many cases misusing them means we as leftists do not have a full understanding of what the fuck we're on about. this dilutes both the meanings of these terms and their purposes. I know I am wordy as fuck and can be hard to understand sometimes (thanks adhd) so what I am about to say is a little ironic, but clarity is fucking important when it comes to strategy and organizing.

so I am going to examine some commonly misused concepts and terms today. yay.

1. THEORY, PRAXIS AND FRAMEWORKS FOR ANALYSIS weeee yes I am fun at parties tyvm

what is a framework? a structure, in this case, for analyzing some bullshit we deal with irl. that's it lol but I use it a lot so I figured I'd define it here. examples of frameworks are: intersectionality, marxism, queer theory. seriously, if you can think it, it has already been analyzed through the queer lens.

what is theory? ideas, knowledge in the abstract based on looking at shit happen and analyzing that shit. it is useful because it can help us articulate what we are going through in our shitty lives. this is why I often recommend people learn about chomsky's manufacturing consent (theory of why we get the info we get from the media tl;dr), not because I think chomsky is the ultimate leftist grandpa but because this site needs some media literacy lmao. and btw, this clip narrated by amy goodman is a great, trippy little 4:30 min long video that explains the basics of manufacturing consent so you don't have to open a book or use drugs!

theory can help serve as a framework to understand what the fuck is happening to us irl, but imo is kind of an incomplete understanding of shit without lived experience (aka - theory v praxis). this is one reason why we should listen to marginalized groups on their own shit and not talk over them - because all of the research and theory in the world does not make me a Black woman living in Flint (aka - ground up organizing v technocracy). it is not about being nice, or politically correct, although we should be nice and we should care about people just because they're people. if you understand the why of listening to marginalized groups, you understand that it is mainly about communities knowing their own problems best and therefore having the best solutions for those problems.

2. MARXISM, CAPITALISM AND OTHER BUZZWORDS (and leftists need hobbies)

so marxism is a framework for socioeconomic analysis observed by mr kpop himself, karl marx (and his sugar daddy friedrich engels). because leftists love to argue, there are so many kinds of marxism, and if you ever feel like you are shouting into the void too much, just look up some arguments between stalinists and trotskyists. it's just... magical. no, I am not defining tankie here.

as many people smarter than I am have said (read: kwame ture seriously watch this video it's iconic), karl marx did not discover socialism or invent it or whatever, he observed capitalism and saw how shitty it is, like any other sane person would do. the point of marxism is not karl marx (which he would say) or tankies or fuckin guillotines***

things that marxism is:

- an analytical tool for looking at the world

- a theory which was used to develop the basis of different kinds of post-capitalist economic systems like communism and socialism

things that marxism is not:

- a system of economics or government lmao marx did not govern dick

- scary

marx looked at capitalism and said "this is definitely gonna fail someday because it's clearly unsustainable, I mean the proletariat is bigger than the bourgeoisie who owns everything uh yeah so I can do basic fucking math. if I have one capitalist and fifteen hundred workers, eventually that capitalist is gonna lose his damn head because he is gonna hoard all that wealth and his workers are gonna get pissed that they don't have their basic fucking needs met. lmao now put on some kpop, freddy" or something. idk that might not be a direct quote.

what is capitalism? (besides horseshit) a system of economics where industry is privately owned. and yes, this includes publically traded corporations because they are still owned by individuals (shareholders) even if they aren't privately owned by one person or a group of partners. truly a nightmare to live in, and we hate to see it.

what is the proletariat? well, the working class. and the bourgeoisie is the owner class, the capitalist class. the rich.

and this is something else that we need to discuss, tumblr. if you are going to say "eat the rich" please understand who you are talking about. we're not talking about random actors or musicians, or doctors or lawyers, even if they make better than a liveable wage. even if they often have zero class consciousness, meaning they don't ~see class, like colorblind racism for classism.

anyone who has to sell their labor for wages and is not part of the owner class is working class. this includes people who cannot work for any multitude of reasons (disability, can't find work, caretaker, etc) and also white collar workers who might be well off in relatively high paying jobs because they don't own the means of production, or capital that is used to produce shit. so yes, that rich actor who is a part of a union is actually part of the working class in marxist theory. when we say eat the rich, we mean jeff bezos, not john boyega. jeff bezos owns the means of production. john boyega is a working actor who is in a union.

this is important not because we shouldn't get pissed off when actors and celebrities do tone deaf shit like singing about imagining no possessions in their mansions while people starve during a pandemic. they need to put their money to good use, have some class consciousness, instead of asking fans to donate to causes that they could fund. but they are not the bourgeoisie until they start owning the means of production. and there is no doubt that many of them do, which is why we might eat gwyneth paltrow but we won't eat john boyega.

and by the way, eating the rich is metaphorical, a reference to french revolution-era philosopher jean-jacques rousseau's quote: "when the people shall have nothing more to eat, they will eat the rich." obviously I don't even need to explain it but I will anyway. basically, the people will forcibly redistribute the wealth of the rich if they have nothing else. this is why there are some very smart capitalists who are in favor of reforms and raising taxes, because they recognize the danger to their necks in not providing for basic needs of the working class. no, "eat the rich" does not mean be pro-cannibalism. but there are many capitalists who would prefer to die than lose their hoard so

oh, and one last thing. "no ethical consumption in capitalism" is tossed around a lot and it's a million percent true, but I need all of us to understand that it is not an excuse to support harmful practices but it is also not meant to shame consumers. it is rather an understanding that we as consumers are not responsible for the monstrous impact of capitalism. we live in it, we have no choice but to consume, and sometimes (most of the time) that means we have to buy shit that was produced in unethical ways. unfortunately supply chains being what they are, all consumption causes harm in some way.

it is a reminder that individual actions are not going to have the impact of collection actions. this is why plastic bag bans, though well-meaning, are not going to have the same impact on climate catastrophe as, say, banning fossil fuels would.

I am a vegetarian and I can recognize that I am doing a whole lot of nothing by not supporting factory farms, and when I was a vegan I wasn't doing much either. boycotts without mass support don't have much evidence of working. this is why bds exists - boycott divestment and sanctions. boycott, meaning don't support goods from various conpanies connected to something, divestment, meaning get companies/countries/institutions to remove their money from something, and sanctions, meaning getting countries to penalize a country for their bad behavior until they comply.

this is what the anti-apartheid south africa movement did and what palestinian rights organizers support for israeli apartheid.

do not allow legislators to put the burden of fixing the ills of society that capitalism created on consumers' shoulders.

3. INTERSECTIONALITY (because it deserves its own section)

I don't have as much to say on this as I did the last bit because holy shit capitalism, man.

intersectionality, a term that was coined by law professor kimberlé crenshaw in the late 80s to serve as a framework for people to critically assess how legal structures impact Black women differently due to class, race and gender. it is not incompatible with marxism (in fact marxism has been argued to be a form of intersectionality).

intersectionality can and should be used to examine why the Black queer experience is unique, for example. I also want to acknowledge that professor crenshaw isn't the only person to come up with intersectionality; sojourner truth spoke about it even if she didn't coin the term, for example. patricia hill collins, another influential af Black feminist academic****, created frameworks for viewing intersectionality. also you can read her book black feminist thought here for free.

intersectionality has been used - improperly - by liberal feminists***** to excuse bad behavior from leaders who pretend to care about women while creating and enforcing legislation that harms women. anyone who stans politicians at all needs help. it has also been misrepresented as essentialism, which it is also not (essentialism is the idea that everything has some assets that are necessary to its identity) because intersectionality isn't saying that every Black queer woman has the same experience, just that Black queer women might experience similar issues because of a system that negatively views them as Black and queer and women.

intersectionality does not excuse kamala harris for prosecuting poor moms of truant kids.

okay if you guys have things to add please do because I want us to educate each other instead of always talking shit. both is good.

* I am not calling out people for not being academic enough or not speaking english or not reading enough theory because LOL I am a 2x neurodivergent college dropout who radicalized by working retail and not by hearing karl marx talk dirty to me. also, not everyone speaks english like, I am truly not shitting on people.

** I recognize that language is fluid and ever changing, and that is a good thing. But diluting terms that serve specific purposes is not ever going to be good.

*** and I don't want to dismiss intra-leftist theory discourse (🤢) because I know how annoying it is to hear bernie sanders lumped in with liz warren, or bernie sanders lumping himself in with post-capitalists lmao of course I get it. but twitter discourse is not dismantling capitalism so ANYWAY

**** actually crenshaw built on collins' work (black feminist thought) and the collins built on crenshaw' work we love to see it.

***** I should go ahead and define liberal feminism as well as rad fem and terf and shit because people use them all very very loosely, especially terf (not every transphobe is a terf but every terf is a transphobe, it's like the rectangle/square thing). but I am exhausted with this so next time.

#marxism #word vom #intersectionality #kpop idol karl #truly apologize for my mess

[countessalmaviva]

So am I the only one who would be mad if Netflix went in the Francisco/Alba direction??? Like, so mad! I think their time has passed, he's married, they're not the same people, he spies on people, he said all that crap to her, & thinks women are incapable, whereas Alba genuinely developed feelings and is in a relationship with Carlos and he's been nothing but good and loving to her!! (She said he makes her happy 😪) I just don't want him to have his heart broken!!!! 😩

Hi! Sorry for the late reply - I wanted to give this a proper answer! It’s below as a) it’s long and b) spoilers.

I 100% agree with everything you’ve said! I would be mad if Netflix decided to, in the second season/second half of the first season (idk what they’re planning on doing, I’ve seen conflicting reports) drop all the Carlos/Alba development they’ve done and decide to only focus on Francisco/Alba. I think they’ve put so much effort (particularly eps 5-8) in building up Carlos and Alba’s relationship that it would be a shame to see it ruined in favour for an inferior pairing.

I think Francisco and Alba could have worked if the show had been dedicated solely to that from the beginning (like Bambu did with Velvet and Gran Hotel - it was obvious from episode 1 who their OTP was). If the show had made it clear that Francisco and Alba would only ever be destined for each other and would never be with anyone else then yeah, maybe I could have got on board with the forbidden love (seems to be my preferred type of ship, anyway). However, my first problem with F/A is exactly that: it doesn’t seem to be the direction that Bambu/Netflix intended from the beginning (or if they did, they certainly didn’t show it very well).

Firstly, as you’ve said, their time has passed - 10 whole years, as Francisco likes to continually remind us. The teenage Francisco and Alba that were in “love” (they were only 15) are not the mid-twenties Francisco and Alba that they are now. They’re completely different people, who’ve been through many different experiences in the time that they were apart - Francisco’s even married someone else! I don’t know how much he does love Elisa, but still, it’s pretty shitty marrying someone (much less the sister of your best friend) whilst still 100% being in love with someone you haven’t seen for several years, or will probably never see again. After all, it’s not as if Alba or he engineered their meeting at the company. I think what annoys me most is that Alba even quite clearly says to him in episode 3 “estás enamorado de mi recuerdo” (”you’re in love with my memory”). And it’s true: he attributes characteristics to her - like the White Lady thing) based on who she was when she was 15. He refuses to accept the inevitability she’s changed.

Another thing that annoys me is how, even if Alba was still in love with him (which I think she is in a way, maybe more out of the fond memories of their former relationship rather than being passionately in love with him now) is that, despite the fact that she tells him on numerous occasions throughout the series that she a) doesn’t love him and b) doesn’t want to be with him. Whether it’s true or not, he continually neither respects nor accepts her wishes, through either telling her he doesn’t believe her or professing his own love once again, even when he knows that she’s with Carlos. To me, I feel like not only is that a shitty thing to do to a woman who you claim to love, but also to your best friend, who you’ve, intentionally or not, screwed over a few times.

There’s also how, like you’ve mentioned, how he spies on people yet tries to be morally righteous with others, specifically Carlos and Alba, treats his wife terribly (as mentioned above) and just acts in a terrible manner pretty much constantly. It makes me doubt how genuine his love for Alba is - I think that he is in love with who she was, and due to the traumatic way in which their relationship ended, hasn’t quite been able to let her go. He also sees her as the sole solution to his unhappiness - he says that he’d leave everything for her, and I do think he would, but whether he would find the happiness he’s desperately looking for I’m unsure.

And then there’s Carlos, aka the character I never thought I’d love but somehow do. Going into the show, I was biased towards Francisco purely because of Yon (I’ve seen him in multiple things and he’s a great actor - unfortunately I don’t think that Las chicas del cable has rewarded him an opportunity to show it), yet a few episodes in it became the complete opposite. Carlos became one of my favourite characters, probably because he was a mix of comedy and drama, and has strengths and weaknesses - he feels like a developed, realistic character. With regards to the Carlos/Alba relationship, I ship it 100%, as I do think that they genuinely have feelings towards each other. Primarily (episode 1-4 ish), they both had their motivations within their relationship (Alba wanted the blueprints, Carlos most likely wanted sex) yet seemed to find a real connection with each other, transforming their relationship into something serious. The moment when it changed for me was the scene at the end of ep 4, when Carlos tells Alba that he wants to take their relationship slowly, yet she ends up kissing him. At that moment they both pretty much simultaneously realise that, despite how they began, it wasn’t want they wanted now.

They’re good for each other, as well - they’re supportive (e.g. her investment into the project), yet challenge and motivate each other; it’s a positive relationship, and feels organic - it gradually gets more serious: they kiss, she meets his parents, they have sex, get engaged etc. For Alba especially, she didn’t have to do all that if she didn’t have feelings for him - she could’ve just clandestinely gotten close to him and stolen the blueprints like that. Her feelings also show in how she acts and what she says in the monologues - how Victoria and Beltrán figure out how the photos of F/A kissing at the train station become more significant for her, or how she even tells Francisco that, although in the beginning she was doing it all for him, things have now “changed”, e.g. she’s conflicted over her feelings. The most telling thing of all is how Alba honestly states that Carlos “makes her happy”, a feeling she’s not felt for ten years. When she’s with him, she truly is herself, which is why she told him about Argentina, something which imo was not easy for her to do.

The only way that F/A could be together now is if Elisa dies (as I can’t see him divorcing her), something I hope doesn’t happen, as I’d love for Netflix/Bambu to explore her character. Yet the fact that they’ve cast Yon and Blanca in those roles, as well as introduced the Francisco-Alba-Carlos love triangle so soon makes me believe that they’re planning to have C/A break up pretty quickly after she explains to him about why Francisco called her “Alba”, and then F/A have a long, passionate affair. That would really disappoint me, not only because it is probably the most cliched trope ever, but because it wouldn’t make sense within the story that has been crafted so far! It would also be detrimental for Carlos’ character, since I can’t see him quickly getting over Alba, probably leading him down a similar path that Cristina from Velvet went down after season 2 (and if anyone’s seen Velvet, they know how that shit ended. Tl;dr, terribly). 

Actually, tl;dr all of it: I want Carlos and Alba to be together, because they’re perfect for each other, and if they went down the F/A path I wouldn’t be pleased as they quite clearly are not the same people anymore and their relationship just wouldn’t work, at least until Francisco realised that Alba is capable of making her own decisions, even if he has reservations about them.

Sorry for such a long reply, I didn’t realise that I had so many feelings! If there’s any more questions/gif requests/discussions then I’m happy to share my feelings! xoxo

#las chicas del cable #cable girls #india watches spanish tv shows #india has opinions #francisco x alba #carlos x alba

[kinetic-elaboration]

February 10: Thoughts on 4x02 Heavy Lies the Crown

I sat down to write my reaction to 4x02 and wrote basically a novel because I have no self-control. I talk so big about being barely invested in the source material anymore and then this happens. I cannot be trusted.

I wrote this before I saw any fandom reactions at all so it’s really just my unfiltered and uninfluenced thoughts.

Tl;dr version:

Team Jaha all the way

Loved the Arkadia stuff especially the Clarke and Jaha stuff and Clarke’s speech

Intrigued by the possibility of waiting out the radiation in the Ark

Interested to see Bryan develop, worried about Miller/Bryan

Legit thought Bellarke were going to kiss when they were saying goodbye

I would have voted with Miller and Monty but I also think that Bellamy’s final decision was the only possible outcome morally and narratively and that for this reason that whole story line was meh for me

A+ Monty characterization

Why does no one care that the Arkadia government has been decimated? This is some grade A nonsense.

...Jasper

*

I'm probably going to nit pick a lot and sound like I didn't like, but overall I actually really did. I'm never going to stop being nostalgic for what the show could have been, but I think it's doing the best it can to come back from the mess of S3.

I'm going to organize my thoughts by storyline this time since, I don’t have definite negatives and definite positives like last week.

POLIS

I have made the tentative decision to avoid absolutely as much as possible all content beyond the actual episodes themselves—that includes preview scenes and bts stuff released before the show airs, as well as interviews, Twitter statements, etc. (I will watch the trailers because I just love trailers in general but that's it.) I have a variety of personal-preference reasons for doing so but I think the opening of this episode really solidifies my episodes-only position. Because such a fucking meal was made about the glowing butterflies, and what did we get? Literally, no one lied: we did see a glowing butterfly, very first thing. But everything that glowing butterflies are associated with (associations the people doing the teasing are very well aware of)--including early S1, the glowing forest, the beauty of the Earth, a sense of calm, etc.--was missing. We get the exact opposite instead: mutilation, death, blood, loss, grief. Wow. I was not impressed. In fact, I felt very cheated. I guess one central reason I'm cutting extras out of my viewing experience is because I feel that most of them are designed to create this reaction, designed to tease and trick on the one hand, or just to outright spoil on the other. They decrease my enjoyment of the show and make me feel like I'm being fucked with for sport.

Not to make too big a deal out of it though, because I feel like my language is harsher than my emotions... Anyway I didn't like the intro is what I'm saying. I don't want to say too much because this is a larger point about the episode but one I'm not sure is fair on my part but...it felt a little too...on the nose? Rote? Like a very simple story was told very quickly and unsubtly: we know Ilian has issues because ALIE had him kill his whole family like it doesn't get shorter and simpler than that. And considering I have nothing but negative associations with ALIE, I'm a little...don't subject me to this please.

I'll reserve most of my judgment because he's barely been introduced but so far Ilian is boring and I don't care about him. Next.

Also boring: Trishanakru (sp?). Again, I know it's early, but what I got out of this episode was that, for all they spend so much fucking time on the Grounders, the PTB really do not have very many ideas for them. Because so far the total variation of the clans has been in degree of warlike qualities (average: Trikru; high: Azgeda; low: Flokru). If we hadn't been told Ilian and dead guy were part of a new clan about twenty times I would have just straight up assumed they were Trikru because they're pretty much impossible to distinguish. And I know, I'm being unfair because it's only been one episode but like...I'd always been under the impression there were real and obvious differences among the 12 clans? If there aren't I literally never have to see any other clans I mean it's bad enough I have to be subjected to those ugly white Azgeda tattoos or the Undergrad Common Room aesthetic of Luna's people.

Kane and Abby: everything's going along in just exactly the way I'd expect with them, which means that my interest level is pretty low tbh. I have a very calm sort of appreciation for them, but no particular thoughts or high emotions. Nothing wrong with two attractive people in bed. But like...the main plot point of their relationship was about Abby deciding what to do with Jake's ring and considering I've already thought about that in a fandom context repeatedly and in more depth—without even being a hardcore Kabby shipper—I was a little underwhelmed by it here. Also actually a little disappointed that she ultimately took it off. Like I know why she had to but I also thought that Kane's earlier statement about Jake being a part of her was his acceptance that she would continue to wear it, and I thought there was something rather nice about that—because Jake was his friend too, and what's really wrong with someone whose spouse is dead simultaneously remembering the deceased and having a relationship with someone else? IDK. I guess...it was all fine but not very deep.

Octavia: I have to say I'm kind of surprised by Octavia so far because I was under the impression that she would immediately cut ties with everyone and have a totally separate story line. So that she's still hanging out, at least in body if not spirit, with Kabby and that she hasn't been, like, universally shunned or even officially banished or whatever is just.. I'm not sure what to make of it. What I mean is: does no one but Bryan care that she assassinated the Chancellor? (Also tbt that time she had a big fit about Bellamy attempting to assassinate the Chancellor lol how times have changed.) I'm personally pretty ready to forget literally everything from S3 in a lot of ways but realistically stuff that happened mere days ago in the show should probably be addressed and it's just really weird to me that there's been next to no consequence for her. Also I don't think the show has any idea what to do with O now (which is also why I have an eye-rolly reaction to 'Lincoln died to further O's story line' arguments because IMO almost the opposite happened: Lincoln died and O's story fell apart.) Anyway I don't care about her.

I am STILL BOTHERED by the fact that O got a tattoo in the S2-S3 hiatus but we only got the barest hints of it in S3 and are only getting full views of it now, a season later. And no one's ever mentioned it. I mean maybe this is my Conservative view of tattoos but imo inking your skin is like kinda a big deal and even if you don't think it is in the here and now... tats are a Grounder thing, a permanent alteration of your body that only Grounders do...so it feels like her getting one is sort of a big deal within this society and I would have liked to see it, if not on screen, at least...like a plot point? Or honestly why the fuck even do it. Like literally why subject to Marie to additional make up, why take on the added burden of continuity checks about her tattoo, if it's not even remotely important to your story??

Speaking of tattoos, I forgot to say this before, but if literally everyone has tattoos (and pretty much every Grounder we've ever encountered has had tattoos, whether they're warriors or not, as far as I can tell), how does it help a Spy not to have them? I mean...if there's only one person hanging out with no tats...would you not automatically suspect that person of spying?? Also it kinda looked like Echo did have a tattoo in that fight scene with Roan, a black one on her arm, but it was hard to tell. Coulda been her shirt I dunno.

AKA the world building on this show leaves a lot to be desired but what's new.

These people are shit at keeping secrets for real.

ARKADIA

I'm intrigued by this idea that they could hide out in the Ark itself during the radiation—for a lot of reasons. I fucking love the Ark, first of all. It's an idea I hadn't previously thought of or seen anyone else think of so it's actually surprising to me, and creative, and unexpected, unlike a lot of the rest of the show at this point. It's way better than going into space, which is tragic in its comic ridiculousness. It makes a nice full circle. I think there's something O.Henry sad about it in a way too because if that's the solution they use...they'll live, but they'll never see the outside again. They're creating another Mt. Weather in a way (and I think they semi-know it: "If there's another Mt. Weather out there, the Grounders will know")--and we know how that worked out for them. (I think the lesson from Mt. Weather, honestly, is that if you can't evolve you don't get to live.) Then of course there's the lifeboat problem which, personally, at this point, is getting a little boring. But I definitely caught Raven saying at the end that only "a hundred" of them would fit without the water machine, so that's either significant or bad story telling.  

Also finally my boy Monty coming back into the genius fold. I'm still a little...wary of how they're developing Monty because I remain dissatisfied with his post-Mt. Weather story but what can you do. Promising so far at least.

I literally stopped the video and laughed when I saw the Bellamy/Miller/Bryan scene because of Bryan's gratuitous shirtlessness. Like...I know the implication is not that Bellamy walked in on anything because Bryan was in pajamas and Miller was dressed but it was still fucking hilarious to me anyway because I have the sense of humor of a 12-year-old and always will. (More on them below.)

TEAM JAHA all the way. Okay, I've been thinking a little more about him and... I think it's important to differentiate between liking a character as a character and liking a character in universe. By liking a character in-universe I mean 'if X were a real person, I would like him. I agree with his choices, his sense of morality, and he has an agreeable personality.' Sometimes I dislike Jaha in-universe; I think he was objectively wrong in S2 when he chose the City of Light over getting Our Heroes out of Mt. Weather. But it also isn't important to me to like a character in-universe. Plenty of characters do bad or wrong things and if everyone always did the right thing, there'd be no conflict and no story. What I can't stand is characters who don't make sense as characters and I've been, as I said, uncertain about Jaha. I don't think the show's done him any favors by separating him from so much of the cast for so long (aside from Murphy, has he had any extended interaction with any major cast member since S1? This isn't a real question. The answer is no.) He has often just been not as entertaining as other characters because of this. And I think he's on a long arc, starting all the way back in mid-S1. Combine these things—a long arc that requires a long attention span to understand, developed slowly and in separation from most of the rest of the main cast and main events—and you have a good recipe for a widely-disliked character. I don't dislike him, but I've been frustrated by him, and uncertain how to separate in-universe frustration from badly-drawn-character frustration. BUT I increasingly think that Jaha is an excellently drawn character, probably one of the more consistent on the entire show (certainly way more consistent than Kane lol), and I'm really enjoying seeing him, the real him, again. Jaha is sounding a lot more like his S1 self. And bringing him together with Clarke is A+. More of this please. More philosophical conversations about leadership I can get behind. I love that he used to be an engineer. I love that he's unflappable—never defending himself, never self-flagellating for others' sick pleasure. I love the hair (or...lack of hair). I love the lines he's given, like the 'no leader sets out wanting to lie to their people' one. (I stg if that line doesn't make its way into fandom lore I will riot. I need recompense for every single Clarke "I bear their burdens" gifset I've ever seen.) Just...yes, more Jaha, good stuff.

I like Clarke's new/old outfit and shorter hair but I don't like that little pouf on the top. That must go. I also like, tentatively (it's always tentatively with me and Clarke because if I were to rewatch 2x16 tomorrow I'd insta-hate her again so), where Clarke is going. I like that she's still pragmatic and a little ruthless but that this is mixed in with that old idealism of hers. I do think she's becoming more of her old S1 self, while still taking into account her other experiences and how she's grown and changed. So...yeah I don't feel I have much in terms of analysis on her after having only seen this episode once, but I'm encouraged.

I know I literally just said mere hours before watching this episode that the show had abandoned the relationship between Clarke and Raven but then what do you know, a pleasant surprise: they are interacting again. I liked it. I will always want more because they're one of my favorite relationships on the show but this was so good. I like seeing Raven challenge Clarke and Clarke actually take it into account. I like the tension between them. I like seeing Raven owning her own department. And I liked the tension with Jaha because it's consistent with her general character, very hard nosed and unforgiving.

...There's a part of me that wants to ship Monty/Raven but it's just so hard to ship, in-universe, Monty or Jasper with pretty much any other character because they're so much younger. I know the show doesn't treat them like they're younger and at this point pretty much every delinquent (except Bellamy) is in the "rough contemporaries" category but... Raven is still 19 or almost 19 and Monty is still 15 maaaaybe 16, and that's a big gap, it just is. It makes me semi-uncomfortable. Especially because, even though I think difference in life experience matters more than difference in calendar age, I still think Monty and Jasper were introduced as like the little brothers of the group and it's hard for me to break out of this conception of them.

I know we didn't really see anything new with Jasper in this episode, like that wasn't in trailers or whatever (I didn't see the shower scene clip before I watched 4x02 so I that was semi-new to me), but... I still love him. He is definitely incredibly damaged and it's still fairly remarkable to me that literally no one seems to recognize that he is sick—but I have no problem watching incredibly damaged characters so I am having a good old gay time with his story. Just don't let it end in death. As always, I love any reference to him and Monty being stoner dorks and the high five did not disappoint when given greater context. Actually it got better. And I'm glad he has a spear-scar still, although—and I have no idea how spears or scars work so maybe it was realistic—I wish it had been bigger/more obvious.

I'm pretty angry that my characterizations of Jasper and Monty re: their sexualities are backwards in the angst story and almost everything else I've written of them. Dammit fandom, letting your gay!Monty headcanon seep into my brain. I have no problem with seeing Monty as gay, but there was never actually any indication that he was and, more importantly, there was indication that he's into girls going all the way back to the pilot ("Note to self: next time save the girl," and, from mid-S1: "Are you kidding me? That was there for the taking."). Anyway, it's fine; sexualities are there to be messed with in fic. More importantly, bi!Jasper becomes increasingly canon for me every day. Monty's all "I am hella uncomfortable with your nudity" and there's Jasper like "I give no fucks anymore, I'm enjoying my slow suicide and I'm going to do whatever, wanna hug???? We can get high later and whatever happens happens!"

Fuck, Jasper's taste in music is bad though. IMO. As with the Violent Femmes song in 3x01, I get that the lyrics work well and I get why this song was chosen, but I just thought both songs were obnoxious to listen to. UGH. Where's my Joy Division.

I definitely thought, when Clarke was saying goodbye to the road trippers, that she and Bellamy were going to affectionately kiss goodbye. Like, obviously I didn't think this in the intellectual sense. I just had this sudden flash of feeling: this is where the goodbye kiss goes. And then when it didn't I had to sit back and think—all this happened in a handful of seconds obviously—oh yeah, they're not established yet. That's how easy and natural their chemistry is. It's really refreshing.

Clarke's speech at the end was very interesting. Honestly... I know why it had to be her, narratively speaking, but I kinda wish in a way it had been Bellamy. Because I like his speeches more. But it wouldn't make sense so this isn't a criticism. I liked that she was responding to Jasper and Raven and Jaha all at once. (And I especially liked the call back to Jasper, the sort of delayed convo, survive versus live versus thrive.) I thought it was an interesting moment too because not only did it call back to the Ark government's season 1 decisions, but it also called back to Bellamy's early decisions on the ground. I'm thinking in particular to how he used the threat of the Grounders to inspire the camp to work and build a wall—and listen to him, of course. He instinctively harnessed the threat and used it to power the forming of the community. He was even willing to lie to keep it together: to let everyone believe Wells had been killed by a Grounder, even when Bellamy knew better. And that's what Clarke's doing, she's giving a version of the truth to the people to inspire them and to get them to work. I wonder if Bellamy sees this parallel too.

It's been 9 days since Clarke pulled the lever and now not only does Arkadia not have a council but it doesn't even have a chancellor and no one cares. NO ONE CARES. All of their government is totally gone, not just Pike but Kane and Abby (the prior de facto leaders), Sinclair (the head of a major department)...Jaha is around but he's clearly disgraced and powerless...who is running the show??? By which I mean, lol Clarke obviously. But why?? How? From where does her authority with non-delinquents derive? It's just this really weird hole in the story line imo because she's a child who 99% of the people have never met (okay arguments can be made about S2 but imo she was more Grounder-liaison than Arkadia head of state) and there's just... no...explanation...of how the  community survives on the day-to-day. Except for the scene where Jasper oversees the party, which I guess, fair enough, is probably what would happen. This is all the more frustrating for me because the idea of a leaderless lawless community coming together was a major initial theme/plot of the very first episodes, and I've been missing it ever since, and here's another opportunity to engage in those themes and questions again and instead it's like...don't look over here at this humongous plot hole!!! Don't look!!

FARM STATION

I'm so tense about Miller/Bryan because in my opinion it makes sense to keep them alive and keep them together but with this show who ever freaking knows. They're the only long-term couple on the show, and the only m/m couple the show has ever had; their story's barely been told; Bryan couldn't stand on his own at this point and I feel like the pr nightmare of killing another queer kid just isn't worth it... But there have been plenty of other nonsense deaths on this show and I don't trust it. So. Anyway. I'm tense but I'm liking what I'm seeing so far. I like that we're seeing more of who Bryan is. I like that they're not forgetting where he came from or what his experiences are. I like that he's a little hard and a little on edge and a little dangerous because I think that's a good sort of person for Miller and it's more interesting. I like that they addressed his sudden change of heart last season because, while I'm not bothered really by everyone's easy forgiveness of him (I think it made narrative sense if not in-universe sense—not ideal but I can live with it), I do think that they organized that episode around the surprise of his about-face, without really explaining why he made the decision he did. Because that decision making process occurred off-screen in order to keep the surprise. I mean obviously it was pretty clear he did it For Love but I'm nevertheless glad they're discussing it.

I'm a little confused as to how Miller/Bryan ended though... I asked my mom (before I watched) if they broke up and she said no and I agree that on its face that does not look like a break up. It looks like a fight. If I were Miller or Bryan I would view it as a fight not an ending. BUT. This show doesn't really do relationship arcs, so much as it does relationship plot points here and there and you have to fill in the rest. I think. I guess it's hard to tell given how few relationships there have been, as opposed to hook ups or more informal romances, but that's sort of my feeling. A developing theory. So I guess I mean I wouldn't put it past the show to just act, next time we see one or both of them, like it's obvious they're not together anymore. I hope that's not how it goes down but I'm floating the possibility.

I asked my mom about M/H content too, so I could brace myself, and she said that, had she not known they were together, she would not have guessed based on 4x02. I agree and that makes me happy. The less of that the better. Also...while obviously I know that there's more to a relationship than just kissing or fucking, and that it's a bit silly to say "well I couldn't tell they were a couple because they didn't kiss in this episode..."—that in fact is not what I'm saying. Or what my mom was saying. My point is more that, if a couple has a basis for being a couple, like any sort of compatibility at all, you'll see it all the time, not just when they're on a date or in bed together. But what is the basis for the M/H relationship? There's nothing there to remind you why they're together when they're not...literally together...because it's random!! Because we know nothing of their common likes or interests, nothing of their way of interacting, nothing of what they like about each other, nothing about what makes them compatible—nothing! They're two names drawn out of a hat! Like the moment I thought that Bellarke would kiss even though they're not a couple...that could never happen with M/H because they have no substance! AT ALL! You can think they're cute as much as you fucking like but that doesn't give this story line any weight and I will continue to judge it harshly and bitterly until my contrary heart stops beating.

As to the actual Farm Station story line... the eternal small tragedy of high expectations I guess. I was...underwhelmed but I don't know why. I wanted to like it. I was looking forward to it. And I can't quite pinpoint what didn't do it for me in the narrative. But it seemed a little off.

One possibility is that it just didn't go into the details I most like. I am desperate for more info about the Ark, so if we're going to go to Farm Station, let's fucking go to Farm Station. Let's take a tour. Let's see Monty's bedroom. Let's take the space weed from behind the wall idc. Let's let Bryan and Monty interact even more than they did. Let's reminisce about the past. Realistically and objectively, I know that's not the focus of the show or the episode and I did get several small details of the sort I love and I shouldn't complain. I'm not complaining exactly. I'm just saying this might be a source of my personal disappointment.

Another possibility: the alleged Big Moral Decision of the Week was an easy one. Too easy. I feel a bit weird saying this because I actually came to the opposite conclusion of the majority, and not only did I come down on the Miller + Monty side of the debate (the first and so far only time they have agreed on anything in case anyone was keeping track of the State of their Relationship), but it was an incredibly obvious and easy decision for me morally speaking. Which is sort of a separate problem but I'll get to that in a minute.  

However, what I really mean by it was too easy is that the actual conclusion, to save the immediate victims at the expense of later people, was literally the only place the narrative could go. Which meant that the conclusion wasn't a surprise, and the tension leading up to the conclusion was lacking. Bellamy as a character, regardless of what one thinks of the 3a massacre, cannot handle more immediate deaths on his hands, in terms of casual viewer reactions and after all of this consistent narrative shaming. He just can't be seen standing over dead bodies, literally or just-off-screen, right now in the story. So obviously he's going to save the slaves. Also it's only 2 episodes in and there's no way they can come home with the magical mystical life saving machinery this early. It's too easy. Not that one problem can't be solved and then followed by ten more new problems but that's not how this show operates. It piles on the problems, resolves some mid-season, and the rest at the very end. The only moment of actual surprise I felt was when I saw them walk out with the thing, but even then I recognized in about 0.2 seconds that it was a fake out—of the audience and of the Grounders themselves. When the seemingly deep debate is about a non-issue it loses all of its sense of importance and becomes essentially a waste of episode time instead of the center of the episode.

So that being said... I know it's a hard argument to make to say simultaneously that the conclusion of the narrative is obvious and that I came to an equally obvious opposite conclusion. And I also know that something can be obvious and still narratively tense/morally gray/difficult to watch/otherwise captivating (for example: destroying Mt. Weather in 2x16). BUT. I think there is a disconnect between how obvious it was and how obvious it was supposed to be. I think the intention was for it to be a reasonable-people-can-disagree sort of thing. I think it was supposed to cause internal conflict in the viewer and its conclusion was meant to anger at least some of the audience. But that's not how it worked out for me. Perhaps this will sound callous, but I really did not care about the enslaved Sky People. I have no idea who these people are. I don’t even get what they're doing there, like what the purpose of them for Azgeda is. I'm sure they used the word 'slave' not just to be accurate but to immediately bring up certain associations in the viewers' minds; it's a really charged term for good reason. And obviously, intellectually, I know slavery is bad, and Azgeda is bad, and these are Sky People, and Bryan et. al. know them, and that girl is really small and sad looking. But none of this resonated for me emotionally. Maybe I'm dead inside. But it felt an awful lot like being told instead of being shown. I cared about the Mt. Weather people, because I knew some of them well after an entire season and because I'd been mediating on the tragic impossibility of their situation in general for roughly as long. Their deaths were narratively and in-universe inevitable, even heavily foreshadowed, but it still hurt to see. These people? They matter less to me than saving all the characters I already know, people who may have to be sacrificed later in order to protect these Unknowns now. It's no contest. This is obviously very much a question of perspective—Harper made a good point in saying it's like them at Mt. Weather, because Jaha then wanted to do essentially what Miller and Monty wanted to do in 4x02, which is to say sacrifice a few of his own to save the many, and I thought that Jaha was objectively wrong in that instance. (Part of that is that the narrative later proved him wrong: almost all of his merry band of cultists died on the journey to the CoL. But even up front, the idea of sacrificing the main characters is untenable within the story, so he was automatically wrong.) But it's the narrative's job to shape the perspective, and it has a lot of power to make an issue morally gray or clear black and white. I don't think the narrative did its job in this instance.

I'm still not sure I'm doing a good job explaining (or defending) my lack of emotional response here. Basically, I felt like the Farm Station story, like the intro with Ilian, and like the Kabby stuff as well, was paint-by-numbers. It was 'okay let's get this done, one two three, all the bases touched, story complete.' Rote. It didn't have the nuance of the show at its best, like the last episodes of Season 2 or even the Clarke and Jaha convo in this very episode.

I did like the scene where Monty confronts his father's killer, first because of Bryan's line about this being "Monty's kill" because it speaks to how he lived for four months during the S2-S3 hiatus and that interests me, but also because I thought that scene was spot on for how I see Monty. He is ruthless in a lot of ways but he's not a hands-dirty type. He doesn't hesitate in his moral judgments and as far as we know he doesn't have much of any regrets (I've been annoyed at him not reacting enough to Mt. Weather—maybe he really isn't plagued by guilt about it at all—an interesting possibility but one I still think should be on screen a little). He's very sure of himself. But he's barely even held a firearm (like once in S2 and then a little in S3), I'm pretty sure his only one-on-one kill is his own mother...and that's pretty unusual on this show. (Clarke, Bellamy, Jasper, Octavia, Miller, and Harper, and I'm going to have to assume Bryan, have all killed, sometimes with their bare hands, and/or were consistently using firearms going back to S1.) I definitely would have been surprised to see him axe that Ice Nation fellow in the face. But I also would have been shocked to see Monty show him mercy. I thought that the route they went, having him sentence the man to death without ever touching him, was such a good choice, a powerful moment for real without being out of character.

I feel like I haven't said much of anything about Bellamy....again, wonderful. He is such a great leader with these kids. I think he really walks the line between military-style leader and just straight up Dad. (And yes I thought he was adorable with the small child at the end.) It might be more subtle than last episode, but I still think groundwork is being laid for Bellamy to fully come into his own as a leader, to the same extent that Clarke already (BIZARRELY AND PREMATURELY) has, if not more. Basically what I'm saying is Blake for Chancellor 2018.

I have long headcanoned that Farm Station crashed in Pennsylvania. It's cold and snowy enough to be "Ice Nation" territory; close enough to be reached within a day by Rover, as we saw in 3x01 (and here? IDK how long this episode was supposed to cover but it looked like a pretty short period to me); but far enough away that Pike, Hannah, Bryan, et. al. could easily be lost for 3-4 months without running into our heroes in Virginia. I still think this is a plausible theory but man, those mountains do not look passably Pennsylvanian to me. Not that I'm a Pennsylvanian mountain expert. And not that they shot in Pennsylvania honestly. Anyway my headcanon remains.

I thought the moment with Clarke meeting Riley again was really sweet. It somehow helped more than the Bryan stuff at the Station itself to remind me that these are Sky People—not just poor mistreated human beings but poor mistreated friends and neighbors. Also again this is my favorite society so seeing some more unexpected connections among them was cool. I do hope we see Riley again, not because I care about him yet, but because it's annoying to see someone obviously foregrounded as a New Character to Watch only for them to disappear. Like with Mel in season 2. Ruined expectations are really annoying and not to be confused with "being realistic" or "being shocking."

#the 100 #the 100 spoilers #s4 reactions #clarke griffin #raven reyes #thelonious jaha #monty green #jasper jordan #nathan miller #bryan #bryan the 100 #bellamy blake #spoiler alert grounders boring #occasional shit talking even though i liked a lot of it #the year 2017 #2017: fandom thoughts #2017: the 100 s4

[techscopic]

I Don’t Hate Arrow Functions

TL;DR

Arrow functions are fine for certain usages, but they have so many variations that they need to be carefully controlled to not break down the readability of the code.

While arrow functions clearly have a ubiquitous community consensus (though not unanimous support!), it turns out there’s a wide variety of opinions on what makes “good” usage of => and not.

Configurable linter rules are the best solution to wrangling the variety and disagreement of arrow functions.

I released proper-arrows ESLint plugin with several configurable rules to control => arrow functions in your code base.

Opinions are like noses…

Anyone who’s followed me (tweets, books, courses, etc) for very long knows that I have lots of opinions. In fact, that’s the only thing I’m an expert on — my own opinions — and I’m never at a loss for them!

I don’t subscribe to the “strong opinions, loosely held” mantra. I don’t “loosely hold” my opinions because I don’t see any point in having an opinion if there isn’t sufficient reason for that opinion. I spend a lot of time researching and tinkering and writing and trying out ideas before I form an opinion that I would share publicly. By that point, my opinion is pretty strongly held, by necessity.

What’s more, I teach based on these opinions — thousands of developers in different companies all over the world — which affords me the opportunity to deeply vet my opinions through myriad discussion and debate. I’m tremendously privleged to be in such a position.

That doesn’t mean I can’t or won’t change my opinions. As a matter of fact, one of my most strongly held opinions — that JS types and coercion are useful in JS — has been shifting lately, to a fairly significant degree. I have a much more rounded and deepened perspective on JS types and why type-aware tooling can be useful. And even my opinion on => arrow functions, the punchline of this article, has evolved and deepened.

But one of the things many people tell me they appreciate about me is, I don’t just state opinions, I back those opinions up with careful, thought-out reasoning. Even when people vehemently disagree with my opinions, they often compliment me on at least owning those opinions with backing.

And I try to inspire the same in others through my speaking, teaching, and writing. I don’t care if you agree with me, I only care that you know why you have an technical opinion and can earnestly defend it with your own line of reasoning. To me, that’s a healthy relationship with technology.

Arrow Functions != functions

It is my sincere belief that the => arrow function is not suitable as a general purpose replacement for all (or even most) function functions in your JS code. I genuinely don’t find them more readable in most cases. And I’m not alone. Any time I share an opinion like that on social media, I often get dozens of “me too!” responses peppered in with the scores of “you’re totally wrong!” responses.

But I’m not here to rehash the entire debate over => arrow functions. I’ve written extensively about my opinions on them, including these sections in my books:

“You Don’t Know JS: ES6 & Beyond”, Ch2, “Arrow Functions”

“Functional-Light JavaScript”, Ch2, “Functions Without function“ (and the preceding section on function names).

Whatever your preferences around =>, to suggest that it’s only a better function is to be plainly reductive. It’s a far more nuanced topic than just a one-to-one correspondence.

There are things to like about =>. You might find that surprising for me to say, since most people seem to assume I hate arrow functions.

I don’t (hate them). I think there are definitely some important benefits.

It’s just that I don’t unreservedly endorse them as the new function. And these days, most people aren’t interested in nuanced opinions in the middle. So since I’m not entirely in the pro-=> camp, I must be entirely in the opposition camp. Not true.

What I hate is suggesting they’re universally more readable, or that they’re objectively better in basically all cases.

The reason I reject this stance is because I REALLY DO STRUGGLE TO READ THEM in many cases. So that perspective just makes me feel dumb/inferior as a developer. “There must be something wrong with me, since I don’t think it’s more readable. Why do I suck so much at this?” And I’m not the only one whose impostor syndrome is seriously stoked by such absolutes.

And the cherry on top is when people tell you that the only reason you don’t understand or like => is because you haven’t learned them or used them enough. Oh, right, thanks for the (condescending) reminder it’s due to my ignorance and inexperience. SMH. I’ve written and read literally thousands of =>functions. I’m quite certain I know enough about them to hold the opinions I have.

I’m not in the pro-=> camp, but I recognize that some really do prefer them, legitimately. I recognize that some people come to JS from languages that have used => and so they feel and read quite natural. I recognize that some prefer their resemblance to mathematical notation.

What’s problematic IMO is when some in those camps simply cannot understand or empathize with dissenting opinions, as if there must just be something wrong with them.

Readability != Writability

I also don’t think you know what you’re talking about when you talk about code readability. By and large, the vast majority of opinions on code readability, when you break them down, are based on a personal stance about preferences in writingconcise code.

When I push back in debates about code readability, some just dig in their heels and refuse to support their opinion. Others will waive off the concerns with, “readability is all just subjective anyway”.

The flimsiness of that response is stunning: two seconds ago they were vehemently claiming => arrow is absolutely and objectively more readable, and then when pressed, they admit, “well, I think it’s more readable, even if ignorants like you don’t.”

Guess what? Readability is subjective, but not entirely so. It’s a really complex topic. And there are some who are undertaking to formally study the topic of code readability, to try to find what parts of it are objective and what parts are subjective.

I have read a fair amount of such research, and I’m convinced that it’s a complicated enough topic that it can’t be reduced to a slogan on a t-shirt. If you want to read them, I would encourage you doing some google searching and reading of your own.

While I don’t have all the answers myself, one thing I’m certain about is, code is more often read than written, so perspectives on the topic which ultimately come from “it’s easier/quicker to write” don’t hold much standing. What needs to be considered is, not how much time do you save writing, but how clearly will the reader (future you or someone else on the team) be able to understand? And ideally, can they mostly understand it without pouring over the code with a fine-toothed comb?

Any attempt to justify writability affordances with unsubstantiated claims about readability benefits is a weak argument at best, and in general, nothing but a distraction.

So I roundly reject that => is always and objectively “more readable”.

But I still don’t hate arrow functions. I just think to use them effectively, we need to be more disciplined.

Linters == Discipline

You might be of the (incorrect) belief that linters tell you objective facts about your code. They can do that, but that’s not their primary purpose.

The tool that’s best suited to tell you if your code is valid is a compiler (ie, the JS engine). The tool that’s best suited to tell you whether your code is “correct” (does what you want it to do) is your test suite.

But the tool that’s best suited to tell you if your code is appropriate is a linter. Linters are opinionated collections of rules about how you should style and structure your code, so as to avoid likely problems — according to the authors of those opinion-based rules.

That’s what they’re for: to apply opinions to your code.

That means it’s almost certain that these opinions will, at one time or another, “offend” you. If you’re like most of us, you fancy yourself pretty good at what you do, and you know that this thing you’re doing on this line of code is right. And then the linter pops up and says, “Nope, don’t do it that way.”

If your first instinct is sometimes to disagree, then you’re like the rest of us! We get emotionally attached to our own perspectives and abilities, and when a tool tells us we’re wrong, we chuff a little bit.

I don’t get mad at the test suite or the JS engine. Those things are all reporting facts about my code. But I can definitely get irritated when the linter’s opinion disagrees with mine.

I have this one linter rule that I enabled a few weeks ago, because I had an inconsistency in my coding that was annoying me on code re-reads. But now this lint rule is popping up two or three times an hour, nagging me like a stereotypical grandma on a 90’s sitcom. Every single time, I ponder (for just a moment) if I should just go disable that rule. I leave it on, but to my chagrin.

So why subject ourselves to this torment!? Because linter tools and their opinions are what give us discipline. They help us collaborate with others.

They ultimately help us communicate more clearly in code.

Why shouldn’t we let every developer make their own decisions? Because of our tendency toward emotional attachment. While we’re in the trenches working on our own code, against unreasonable pressure and deadlines, we’re in the least trustable mindset to be making those judgement calls.

We should be submitting to tools to help us maintain our discipline.

It’s similar to how TDD advocates submit to the discipline of writing tests first, in a formal set of steps. The discipline and the bigger picture outcome of the process are what we value most, when we’re level headed enough to make that analysis. We don’t institute that kind of process when our code is hopelessly broken and we have no idea why and we’re just resorting to trying random code changes to see if they fix it!

No. If we’re being reasonable, we admit that the overall good is best served when we set up reasonable guidelines and then follow the discipline of adhering to them.

Configurability Is King

If you’re going to knowingly subject yourself to this finger wagging, you (and your team, if applicable) are certainly going to want some say-so in what rules you’re required to play by. Arbitrary and unassailable opinions are the worst kind.

Remember the JSLint days when 98% of the rules were just Crockford’s opinions, and you either used the tool or you didn’t? He straight up warned you in the README that you were going to be offended, and that you should just get over it. That was fun, right? (Some of you may still be using JSLint, but I think you should consider moving on to a more modern tool!)

That’s why ESLint is king of the linters these days. The philosophy is, basically, let everything be configurable. Let developers and teams democratically decide which opinions they all want to submit to, for their own discipline and good.

That doesn’t mean every developer picks their own rules. The purpose of rules is to conform code to a reasonable compromise, a “centralized standard”, that has the best chance of communicating most clearly to the most developers on the team.

But no rule is ever 100% perfect. There’s always exception cases. Which is why having the option to disable or re-configure a rule with an inline comment, for example, is not just a tiny detail but a critical feature.

You don’t want a developer to just have their own local ESLint config that overrides rules while they commit code. What you want is for a developer to either follow the established rules (preferred!) OR to make an exception to the rules that is clear and obvious right at the point where the exception is being made.

Ideally, during a code review, that exception can be discussed and debated and vetted. Maybe it was justified, maybe it wasn’t. But at least it was obvious, and at least it was possible to be discussed in the first place.

Configurability of tools is how we make tools work for us instead of us working for the tools.

Some prefer convention-based approaches to tooling, where the rules are pre-determined so there’s no discussion or debate. I’m know that works for some developers and for some teams, but I don’t think it is a sustainable approach for generalized, broad application. Ultimately, a tool that is inflexible to the changing project needs and DNA of the developer(s) using it, will end up falling into obscurity and eventually replaced.

Proper Arrows

I fully recognize my usage of the the word “proper” here is going to ruffle some feathers. “Who is getify to say what is proper and not?”

Remember, I’m not trying to tell you what is proper. I’m trying to get you to embrace the idea that opinions about => arrow functions are as varied as all the nuances of their syntax and usage, and that ultimately what is most appropriate is that some set of opinions, no matter what they are, should be applicable.

While I’m a big fan of ESLint, I’ve been disappointed by the lack of support from built-in ESLint rules for controlling various aspects of => arrow functions. There are a few built-in rules, but I’m frustrated that they seem to focus mostly on superficial stylistic details like whitespace.

I think there are a number of aspects that can hamper => arrow function readability, issues that go way beyond what the current ESLint ruleset can control. I asked around on twitter, and it seems from the many replies that a lot of people have opinions on this.

The ultimate linter would not only let you configure rules to your liking, but build your own rules if something were lacking. Luckily, ESLint supports exactly that!

So I decided to build an ESLint plugin to define an additional set of rules around => arrow functions: proper-arrows.

Before I explain anything about it, let me just point out: it’s a set of rules that can be turned on or off, and configured, at your discretion. If you find even one detail of one rule helpful, it would be better to use the rule/plugin than not.

I’m fine with you having your own opinions on what makes => arrow functions proper. In fact, that’s the whole point. If we all have different opinions on => arrow functions, we should have tooling support to let us pick and configure those different opinions.

The philosophy of this plugin is that, for each rule, when you turn the rule on, you get all of its reporting modes on by default. But you can of course either not turn the rule on, or turn the rule on and then configure its modes as you see fit. But I don’t want you to have to go hunting for rules/modes to turn on, where their obscurity prevents them from even being considered. So everything comes on per rule.

The only exception here is that by default, all rules ignore trivial => arrow functions, like () => {}, x => x, etc. If you want those to be checked, on a per-rule basis you have to turn on that checking with the { "trivial": true } option.

Proper Arrows Rules

So what rules are provided? Here’s an excerpt from the project overview:

"params": controls definitions of => arrow function parameters, such as forbidding unused parameters, forbidding short/unsemantic parameter names, etc.

"name": requires => arrow functions to only be used in positions where they receive an inferred name (i.e., assigned to a variable or property, etc), to avoid the poor readbility/debuggability of anonymous function expressions.

"location": restricts where in program structure => arrow functions can be used: forbidding them in the top-level/global scope, object properties, export statements, etc.

"return": restricts the concise return value kind for => arrow functions, such as forbidding object literal concise returns (x => ({ x })), forbidding concise returns of conditional/ternary expressions (x => x ? y : z), etc.

"this": requires/disallows => arrow functions using a this reference, in the => arrow function itself or in a nested => arrow function. This rule can optionally forbid this-containing => arrow functions from the global scope.

Remember, each rule has various modes to configure, so none of this is all-or-nothing. Pick what works for you.

As an illustration of what the proper-arrows rules can check for, let’s look at the "return" rule, specifically its "sequence" mode. This mode refers to the concise return expression of => arrow functions being a comma-separated sequence, like this:

var myfunc = (x,y) => ( x = 3, y = foo(x + 1), [x,y] );

Sequences are typically used in => arrow function concise returns to string together multiple (expression) statements, without needing to use a full { .. } delimited function body and an explicit return statement.

Some may love this style — that’s OK! — but a lot of folks think it favors clever terse style coding over readability, and would prefer instead:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Notice that it’s still an => arrow function and it’s not even that many more characters. But it’s clearer that there are three separate statements in this function body.

Even better:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

To be clear, the proper-arrows rules don’t enforce trivial styling differences like whitespace/indentation. There are other (built-in) rules if you want to enforce those requirements. proper-arrows focuses on what I consider to be more substantive aspects of => function definition.

Concise Summary

You and I almost certainly disagree on what makes good, proper => arrow function style. That’s a good and healthy thing.

My goal here is two-fold:

Convince you that opinions on this stuff vary and that’s OK.

Enable you to make and enforce your own opinions (or team consensus) with configurable tooling.

There’s really nothing to be gained from arguing over opinion-based rules. Take the ones you like, forget the ones you don’t.

I hope you take a look at proper-arrows and see if there’s anything in there which you could use to ensure your => arrow functions are the best form they can be in your code base.

And if the plugin is missing some rules that would help define more proper arrows, please file an issue and we can discuss! It’s entirely plausible we may add that rule/mode, even if I personally plan to keep it turned off!

I don’t hate => arrow functions, and you shouldn’t either. I just hate uninformed and undisciplined debate. Let’s embrace smarter and more configurable tooling and move on to more important topics!

The post I Don’t Hate Arrow Functions appeared first on David Walsh Blog.

I Don’t Hate Arrow Functions published first on https://appspypage.tumblr.com/

[suzanneshannon]

I Don’t Hate Arrow Functions

TL;DR

Arrow functions are fine for certain usages, but they have so many variations that they need to be carefully controlled to not break down the readability of the code.

While arrow functions clearly have a ubiquitous community consensus (though not unanimous support!), it turns out there’s a wide variety of opinions on what makes “good” usage of => and not.

Configurable linter rules are the best solution to wrangling the variety and disagreement of arrow functions.

I released proper-arrows ESLint plugin with several configurable rules to control => arrow functions in your code base.

Opinions are like noses…

Anyone who’s followed me (tweets, books, courses, etc) for very long knows that I have lots of opinions. In fact, that’s the only thing I’m an expert on — my own opinions — and I’m never at a loss for them!

I don’t subscribe to the “strong opinions, loosely held” mantra. I don’t “loosely hold” my opinions because I don’t see any point in having an opinion if there isn’t sufficient reason for that opinion. I spend a lot of time researching and tinkering and writing and trying out ideas before I form an opinion that I would share publicly. By that point, my opinion is pretty strongly held, by necessity.

What’s more, I teach based on these opinions — thousands of developers in different companies all over the world — which affords me the opportunity to deeply vet my opinions through myriad discussion and debate. I’m tremendously privleged to be in such a position.

That doesn’t mean I can’t or won’t change my opinions. As a matter of fact, one of my most strongly held opinions — that JS types and coercion are useful in JS — has been shifting lately, to a fairly significant degree. I have a much more rounded and deepened perspective on JS types and why type-aware tooling can be useful. And even my opinion on => arrow functions, the punchline of this article, has evolved and deepened.

But one of the things many people tell me they appreciate about me is, I don’t just state opinions, I back those opinions up with careful, thought-out reasoning. Even when people vehemently disagree with my opinions, they often compliment me on at least owning those opinions with backing.

And I try to inspire the same in others through my speaking, teaching, and writing. I don’t care if you agree with me, I only care that you know why you have an technical opinion and can earnestly defend it with your own line of reasoning. To me, that’s a healthy relationship with technology.

Arrow Functions != functions

It is my sincere belief that the => arrow function is not suitable as a general purpose replacement for all (or even most) function functions in your JS code. I genuinely don’t find them more readable in most cases. And I’m not alone. Any time I share an opinion like that on social media, I often get dozens of “me too!” responses peppered in with the scores of “you’re totally wrong!” responses.

But I’m not here to rehash the entire debate over => arrow functions. I’ve written extensively about my opinions on them, including these sections in my books:

“You Don’t Know JS: ES6 & Beyond”, Ch2, “Arrow Functions”

“Functional-Light JavaScript”, Ch2, “Functions Without function“ (and the preceding section on function names).

Whatever your preferences around =>, to suggest that it’s only a better function is to be plainly reductive. It’s a far more nuanced topic than just a one-to-one correspondence.

There are things to like about =>. You might find that surprising for me to say, since most people seem to assume I hate arrow functions.

I don’t (hate them). I think there are definitely some important benefits.

It’s just that I don’t unreservedly endorse them as the new function. And these days, most people aren’t interested in nuanced opinions in the middle. So since I’m not entirely in the pro-=> camp, I must be entirely in the opposition camp. Not true.

What I hate is suggesting they’re universally more readable, or that they’re objectively better in basically all cases.

The reason I reject this stance is because I REALLY DO STRUGGLE TO READ THEM in many cases. So that perspective just makes me feel dumb/inferior as a developer. “There must be something wrong with me, since I don’t think it’s more readable. Why do I suck so much at this?” And I’m not the only one whose impostor syndrome is seriously stoked by such absolutes.

And the cherry on top is when people tell you that the only reason you don’t understand or like => is because you haven’t learned them or used them enough. Oh, right, thanks for the (condescending) reminder it’s due to my ignorance and inexperience. SMH. I’ve written and read literally thousands of =>functions. I’m quite certain I know enough about them to hold the opinions I have.

I’m not in the pro-=> camp, but I recognize that some really do prefer them, legitimately. I recognize that some people come to JS from languages that have used => and so they feel and read quite natural. I recognize that some prefer their resemblance to mathematical notation.

What’s problematic IMO is when some in those camps simply cannot understand or empathize with dissenting opinions, as if there must just be something wrong with them.

Readability != Writability

I also don’t think you know what you’re talking about when you talk about code readability. By and large, the vast majority of opinions on code readability, when you break them down, are based on a personal stance about preferences in writingconcise code.

When I push back in debates about code readability, some just dig in their heels and refuse to support their opinion. Others will waive off the concerns with, “readability is all just subjective anyway”.

The flimsiness of that response is stunning: two seconds ago they were vehemently claiming => arrow is absolutely and objectively more readable, and then when pressed, they admit, “well, I think it’s more readable, even if ignorants like you don’t.”

Guess what? Readability is subjective, but not entirely so. It’s a really complex topic. And there are some who are undertaking to formally study the topic of code readability, to try to find what parts of it are objective and what parts are subjective.

I have read a fair amount of such research, and I’m convinced that it’s a complicated enough topic that it can’t be reduced to a slogan on a t-shirt. If you want to read them, I would encourage you doing some google searching and reading of your own.

While I don’t have all the answers myself, one thing I’m certain about is, code is more often read than written, so perspectives on the topic which ultimately come from “it’s easier/quicker to write” don’t hold much standing. What needs to be considered is, not how much time do you save writing, but how clearly will the reader (future you or someone else on the team) be able to understand? And ideally, can they mostly understand it without pouring over the code with a fine-toothed comb?

Any attempt to justify writability affordances with unsubstantiated claims about readability benefits is a weak argument at best, and in general, nothing but a distraction.

So I roundly reject that => is always and objectively “more readable”.

But I still don’t hate arrow functions. I just think to use them effectively, we need to be more disciplined.

Linters == Discipline

You might be of the (incorrect) belief that linters tell you objective facts about your code. They can do that, but that’s not their primary purpose.

The tool that’s best suited to tell you if your code is valid is a compiler (ie, the JS engine). The tool that’s best suited to tell you whether your code is “correct” (does what you want it to do) is your test suite.

But the tool that’s best suited to tell you if your code is appropriate is a linter. Linters are opinionated collections of rules about how you should style and structure your code, so as to avoid likely problems — according to the authors of those opinion-based rules.

That’s what they’re for: to apply opinions to your code.

That means it’s almost certain that these opinions will, at one time or another, “offend” you. If you’re like most of us, you fancy yourself pretty good at what you do, and you know that this thing you’re doing on this line of code is right. And then the linter pops up and says, “Nope, don’t do it that way.”

If your first instinct is sometimes to disagree, then you’re like the rest of us! We get emotionally attached to our own perspectives and abilities, and when a tool tells us we’re wrong, we chuff a little bit.

I don’t get mad at the test suite or the JS engine. Those things are all reporting facts about my code. But I can definitely get irritated when the linter’s opinion disagrees with mine.

I have this one linter rule that I enabled a few weeks ago, because I had an inconsistency in my coding that was annoying me on code re-reads. But now this lint rule is popping up two or three times an hour, nagging me like a stereotypical grandma on a 90’s sitcom. Every single time, I ponder (for just a moment) if I should just go disable that rule. I leave it on, but to my chagrin.

So why subject ourselves to this torment!? Because linter tools and their opinions are what give us discipline. They help us collaborate with others.

They ultimately help us communicate more clearly in code.

Why shouldn’t we let every developer make their own decisions? Because of our tendency toward emotional attachment. While we’re in the trenches working on our own code, against unreasonable pressure and deadlines, we’re in the least trustable mindset to be making those judgement calls.

We should be submitting to tools to help us maintain our discipline.

It’s similar to how TDD advocates submit to the discipline of writing tests first, in a formal set of steps. The discipline and the bigger picture outcome of the process are what we value most, when we’re level headed enough to make that analysis. We don’t institute that kind of process when our code is hopelessly broken and we have no idea why and we’re just resorting to trying random code changes to see if they fix it!

No. If we’re being reasonable, we admit that the overall good is best served when we set up reasonable guidelines and then follow the discipline of adhering to them.

Configurability Is King

If you’re going to knowingly subject yourself to this finger wagging, you (and your team, if applicable) are certainly going to want some say-so in what rules you’re required to play by. Arbitrary and unassailable opinions are the worst kind.

Remember the JSLint days when 98% of the rules were just Crockford’s opinions, and you either used the tool or you didn’t? He straight up warned you in the README that you were going to be offended, and that you should just get over it. That was fun, right? (Some of you may still be using JSLint, but I think you should consider moving on to a more modern tool!)

That’s why ESLint is king of the linters these days. The philosophy is, basically, let everything be configurable. Let developers and teams democratically decide which opinions they all want to submit to, for their own discipline and good.

That doesn’t mean every developer picks their own rules. The purpose of rules is to conform code to a reasonable compromise, a “centralized standard”, that has the best chance of communicating most clearly to the most developers on the team.

But no rule is ever 100% perfect. There’s always exception cases. Which is why having the option to disable or re-configure a rule with an inline comment, for example, is not just a tiny detail but a critical feature.

You don’t want a developer to just have their own local ESLint config that overrides rules while they commit code. What you want is for a developer to either follow the established rules (preferred!) OR to make an exception to the rules that is clear and obvious right at the point where the exception is being made.

Ideally, during a code review, that exception can be discussed and debated and vetted. Maybe it was justified, maybe it wasn’t. But at least it was obvious, and at least it was possible to be discussed in the first place.

Configurability of tools is how we make tools work for us instead us working for the tools.

Some prefer convention-based approaches to tooling, where the rules are pre-determined so there’s no discussion or debate. I’m know that works for some developers and for some teams, but I don’t think it is a sustainable approach for generalized, broad application. Ultimately, a tool that is inflexible to the changing project needs and DNA of the developer(s) using it, will end up falling into obscurity and eventually replaced.

Proper Arrows

I fully recognize my usage of the the word “proper” here is going to ruffle some feathers. “Who is getify to say what is proper and not?”

Remember, I’m not trying to tell you what is proper. I’m trying to get you to embrace the idea that opinions about => arrow functions are as varied as all the nuances of their syntax and usage, and that ultimately what is most appropriate is that some set of opinions, no matter what they are, should be applicable.

While I’m a big fan of ESLint, I’ve been disappointed by the lack of support from built-in ESLint rules for controlling various aspects of => arrow functions. There are a few built-in rules, but I’m frustrated that they seem to focus mostly on superficial stylistic details like whitespace.

I think there are a number of aspects that can hamper => arrow function readability, issues that go way beyond what the current ESLint ruleset can control. I asked around on twitter, and it seems from the many replies that a lot of people have opinions on this.

The ultimate linter would not only let you configure rules to your liking, but build your own rules if something were lacking. Luckily, ESLint supports exactly that!

So I decided to build an ESLint plugin to define an additional set of rules around => arrow functions: proper-arrows.

Before I explain anything about it, let me just point out: it’s a set of rules that can be turned on or off, and configured, at your discretion. If you find even one detail of one rule helpful, it would be better to use the rule/plugin than not.

I’m fine with you having your own opinions on what makes => arrow functions proper. In fact, that’s the whole point. If we all have different opinions on => arrow functions, we should have tooling support to let us pick and configure those different opinions.

The philosophy of this plugin is that, for each rule, when you turn the rule on, you get all of its reporting modes on by default. But you can of course either not turn the rule on, or turn the rule on and then configure its modes as you see fit. But I don’t want you to have to go hunting for rules/modes to turn on, where their obscurity prevents them from even being considered. So everything comes on per rule.

The only exception here is that by default, all rules ignore trivial => arrow functions, like () => {}, x => x, etc. If you want those to be checked, on a per-rule basis you have to turn on that checking with the { "trivial": true } option.

Proper Arrows Rules

So what rules are provided? Here’s an excerpt from the project overview:

"params": controls definitions of => arrow function parameters, such as forbidding unused parameters, forbidding short/unsemantic parameter names, etc.

"name": requires => arrow functions to only be used in positions where they receive an inferred name (i.e., assigned to a variable or property, etc), to avoid the poor readbility/debuggability of anonymous function expressions.

"location": restricts where in program structure => arrow functions can be used: forbidding them in the top-level/global scope, object properties, export statements, etc.

"return": restricts the concise return value kind for => arrow functions, such as forbidding object literal concise returns (x => ({ x })), forbidding concise returns of conditional/ternary expressions (x => x ? y : z), etc.

"this": requires/disallows => arrow functions using a this reference, in the => arrow function itself or in a nested => arrow function. This rule can optionally forbid this-containing => arrow functions from the global scope.

Remember, each rule has various modes to configure, so none of this is all-or-nothing. Pick what works for you.

As an illustration of what the proper-arrows rules can check for, let’s look at the "return" rule, specifically its "sequence" mode. This mode refers to the concise return expression of => arrow functions being a comma-separated sequence, like this:

var myfunc = (x,y) => ( x = 3, y = foo(x + 1), [x,y] );

Sequences are typically used in => arrow function concise returns to string together multiple (expression) statements, without needing to use a full { .. } delimited function body and an explicit return statement.

Some may love this style — that’s OK! — but a lot of folks think it favors clever terse style coding over readability, and would prefer instead:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Notice that it’s still an => arrow function and it’s not even that many more characters. But it’s clearer that there are three separate statements in this function body.

Even better:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

To be clear, the proper-arrows rules don’t enforce trivial styling differences like whitespace/indentation. There are other (built-in) rules if you want to enforce those requirements. proper-arrows focuses on what I consider to be more substantive aspects of => function definition.

Concise Summary

You and I almost certainly disagree on what makes good, proper => arrow function style. That’s a good and healthy thing.

My goal here is two-fold:

Convince you that opinions on this stuff vary and that’s OK.

Enable you to make and enforce your own opinions (or team consensus) with configurable tooling.

There’s really nothing to be gained from arguing over opinion-based rules. Take the ones you like, forget the ones you don’t.

I hope you take a look at proper-arrows and see if there’s anything in there which you could use to ensure your => arrow functions are the best form they can be in your code base.

And if the plugin is missing some rules that would help define more proper arrows, please file an issue and we can discuss! It’s entirely plausible we may add that rule/mode, even if I personally plan to keep it turned off!

I don’t hate => arrow functions, and you shouldn’t either. I just hate uninformed and undisciplined debate. Let’s embrace smarter and more configurable tooling and move on to more important topics!

The post I Don’t Hate Arrow Functions appeared first on David Walsh Blog.

I Don’t Hate Arrow Functions published first on https://deskbysnafu.tumblr.com/

[techscopic]

I Don’t Hate Arrow Functions

TL;DR

Arrow functions are fine for certain usages, but they have so many variations that they need to be carefully controlled to not break down the readability of the code.

While arrow functions clearly have a ubiquitous community consensus (though not unanimous support!), it turns out there’s a wide variety of opinions on what makes “good” usage of => and not.

Configurable linter rules are the best solution to wrangling the variety and disagreement of arrow functions.

I released proper-arrows ESLint plugin with a variety of configurable rules to control => arrow functions in your code base.

Opinions are like noses…

Anyone who’s followed me (tweets, books, courses, etc) for very long knows that I have lots of opinions. In fact, that’s the only thing I’m an expert on — my own opinions — and I’m never at a loss for them!

I don’t subscribe to the “strong opinions, loosely held” mantra. I don’t “loosely hold” my opinions because I don’t see any point in having an opinion if there isn’t sufficient reason for that opinion. I spend a lot of time researching and tinkering and writing and trying out ideas before I form an opinion that I would share publicly. By that point, my opinion is pretty strongly held, by necessity.

What’s more, I teach based on these opinions — thousands of developers in different companies all over the world — which affords me the opportunity to deeply vet my opinions through myriad discussion and debate. I’m tremendously privleged to be in such a position.

That doesn’t mean I can’t or won’t change my opinions. As a matter of fact, one of my most strongly held opinions — that JS types and coercion are useful in JS — has been shifting lately, to a fairly significant degree. I have a much more rounded and deepened perspective on JS types and why type-aware tooling can be useful. And even my opinion on => arrow functions, the punchline of this article, has evolved and deepened.

But one of the things many people tell me they appreciate about it me is, I don’t just state opinions, I back those opinions up with careful, thought-out reasoning. Even when people vehemently disagree with my opinions, they often compliment me on at least owning those opinions with backing.

And I try to inspire the same in others through my speaking, teaching, and writing. I don’t care if you agree with me, I only care that you know why you have an technical opinion and can earnestly defend it with your own line of reasoning. To me, that’s a healthy relationship with technology.

Arrow Functions != functions

It is my sincere belief that the => arrow function is not suitable as a general purpose replacement for all (or even most) function functions in your JS code. I genuinely don’t find them more readable in most cases. And I’m not alone. Any time I share an opinion like that on social media, I often get dozens of “me too!” responses peppered in with the scores of “you’re totally wrong!” responses.

But I’m not here to rehash the entire debate over => arrow functions. I’ve written extensively about my opinions on them, including these sections in my books:

“You Don’t Know JS: ES6 & Beyond”, Ch2, “Arrow Functions”

“Functional-Light JavaScript”, Ch2, “Functions Without function“ (and the preceding section on function names).

Whatever your preferences around =>, to suggest that it’s only a better function is to be plainly reductive. It’s a far more nuanced topic than just a one-to-one correspondence.

There are things to like about =>. You might find that surprising for me to say, since most people seem to assume I hate arrow functions.

I don’t (hate them). I think there are definitely some important benefits.

It’s just that I don’t unreservedly endorse them as the new function. And these days, most people aren’t interested in nuanced opinions in the middle. So since I’m not entirely in the pro-=> camp, I must be entirely in the opposition camp. Not true.

What I hate is suggesting they’re universally more readable, or that they’re objectively better in basically all cases.

The reason I reject this stance is because I REALLY DO STRUGGLE TO READ THEM in many cases. So that perspective just makes me feel dumb/inferior as a developer. “There must be something wrong with me, since I don’t think it’s more readable. Why do I suck so much at this?” And I’m not the only one who’s impostor syndrome is seriously stoked by such absolutes.

And the cherry on top is when people tell you that the only reason you don’t understand or like => is because you haven’t learned them or used them enough. Oh, right, it’s my ignorance. SMH. I’ve written and read literally thousands of =>functions. I’m quite certain I know enough about them to hold the opinions I have.

I’m not in the pro-=> camp, but I recognize that some really do prefer them, legitimately. I recognize that some people come to JS from languages that have used => and so they feel and read quite natural. I recognize that some prefer their resemblance to mathematical notation.

What’s problematic IMO is when some in those camps simply cannot understand or empathize with dissenting opinions, as if there must just be something wrong with them.

Readability != Writability

I also don’t think you know what you’re talking about when you talk about code readability. By and large, the vast majority of opinions on code readability, when you break them down, are based on a personal stance about preferences in writingconcise code.

When I push back in debates about code readability, some just dig in their heels and refuse to support their opinion. Others will waive off the concerns with, “readability is all just subjective anyway”.

The flimsiness of that response is stunning: two seconds ago they were vehemently claiming => arrow is absolutely and objectively more readable, and then when pressed, they admit, “well, I think it’s more readable, even if ignorants like you don’t.”

Guess what? Readability is subjective, but not entirely so. It’s a really complex topic. And there are some who are undertaking to formally study the topic of code readability, to try to find what parts of it are objective and what parts are subjective.

I have read a fair amount of such research, and I’m convinced that it’s a complicated enough topic that it can’t be reduced to a slogan on a t-shirt. If you want to read them, I would encourage you doing some google searching and reading of your own.

While I don’t have all the answers myself, one thing I’m certain about is, code is more often read than written, so perspectives on the topic which ultimately come from “it’s easier/quicker to write” don’t hold much standing. What needs to be considered is, not how much time do you save writing, but how clearly will the reader (future you or someone else on the team) be able to understand? And ideally, can they mostly understand it without pouring over the code with a fine-toothed comb?

Any attempt to justify writability affordances with unsubstantiated claims about readability benefits is a weak argument at best, and in general, nothing but a distraction.

So I roundly reject that => is always and objectively “more readable”.

But I still don’t hate arrow functions. I just think to use them effectively, we need to be more disciplined.

Linters == Discipline

You might be of the (incorrect) belief that linters tell you objective facts about your code. They can do that, but that’s not their primary purpose.

The tool that’s best suited to tell you if your code is valid is a compiler (ie, the JS engine). The tool that’s best suited to tell you whether your code is “correct” (does what you want it to do) is your test suite.

But the tool that’s best suited to tell you if your code is appropriate is a linter. Linters are opinionated collections of rules about how you should style and structure your code, so as to avoid likely problems — according to the authors of those opinion-based rules.

That’s what they’re for: to apply opinions to your code.

That means it’s almost certain that these opinions will, at one time or another, “offend” you. If you’re like most of us, you fancy yourself pretty good at what you do, and you know that this thing you’re doing on this line of code is right. And then the linter pops up and says, “Nope, don’t do it that way.”

If your first instinct is sometimes to disagree, then you’re like the rest of us! We get emotionally attached to our own perspectives and abilities, and when a tool tells us we’re wrong, we chuff a little bit.

I don’t get mad at the test suite or the JS engine. Those things are all reporting facts about my code. But I can definitely get irritated when the linter’s opinion disagrees with mine.

I have this one linter rule that I enabled a few weeks ago, because I had an inconsistency in my coding that was annoying me on code re-reads. But now this lint rule is popping up two or three times an hour, nagging me like a stereotypical grandma on a 90’s sitcom. Every single time, I ponder (for just a moment) if I should just go disable that rule. I leave it on, but to my chagrin.

So why subject ourselves to this torment!? Because linter tools and their opinions are what give us discipline. They help us collaborate with others.

They ultimately help us communicate more clearly in code.

Why shouldn’t we let every developer make their own decisions? Because of our tendency toward emotional attachment. While we’re in the trenches working on our own code, against unreasonable pressure and deadlines, we’re in the least trustable mindset to be making those judgement calls.

We should be submitting to tools to help us maintain our discipline.

It’s similar to how TDD advocates submit to the discipline of writing tests first, in a formal set of steps. The discipline and the bigger picture outcome of the process are what we value most, when we’re level headed enough to make that analysis. We don’t institute that kind of process when our code is hopelessly broken and we have no idea why and we’re just resorting to trying random code changes to see if they fix it!

No. If we’re being reasonable, we admit that the overall good is best served when we set up reasonable guidelines and then follow the discipline of adhering to them.

Configurability Is King

If you’re going to knowingly subject yourself to this finger wagging, you (and your team, if applicable) are certainly going to want some say-so in what rules you’re required to play by. Arbitrary and unassailable opinions are the worst kind.

Remember the JSLint days when 98% of the rules were just Crockford’s opinions, and you either used the tool or you didn’t? He straight up warned you in the README that you were going to be offended, and that you should just get over it. That was fun, right? (Some of you may still be using JSLint, but I think you should consider moving on to a more modern tool!)

That’s why ESLint is king of the linters these days. The philosophy is, basically, let everything be configurable. Let developers and teams democratically decide which opinions they all want to submit to, for their own discipline and good.

That doesn’t mean every developer picks their own rules. The purpose of rules is to conform code to a reasonable compromise, a “centralized standard”, that has the best chance of communicating most clearly to the most developers on the team.

But no rule is ever 100% perfect. There’s always exception cases. Which is why having the option to disable or re-configure a rule with an inline comment, for example, is not just a tiny detail but a critical feature.

You don’t want a developer to just have their own local ESLint config that overrides rules while they commit code. What you want is for a developer to either follow the established rules (preferred!) OR to make an exception to the rules that is clear and obvious right at the point where the exception is being made.

Ideally, during a code review, that exception can be discussed and debated and vetted. Maybe it was justified, maybe it wasn’t. But at least it was obvious, and at least it was possible to be discussed in the first place.

Configurability of tools is how we make tools work for us instead us working for the tools.

Some prefer convention-based approaches to tooling, where the rules are pre-determined so there’s no discussion or debate. I’m know that works for some developers and for some teams, but I don’t think it is a sustainable approach for generalized, broad application. Ultimately, a tool that is inflexible to the changing project needs and DNA of the developer(s) using it, will end up falling into obscurity and eventually replaced.

Proper Arrows

I fully recognize my usage of the the word “proper” here is going to ruffle some feathers. “Who is getify to say what is proper and not?”

Remember, I’m not trying to tell you what is proper. I’m trying to get you to embrace the idea that opinions about => arrow functions are as varied as all the nuances of their syntax and usage, and that ultimately what is most appropriate is that some set of opinions, no matter what they are, should be applicable.

While I’m a big fan of ESLint, I’ve been disappointed by the lack of support from built-in ESLint rules for controlling various aspects of => arrow functions. There are a few built-in rules, but I’m frustrated that they seem to focus mostly on superficial stylistic details like whitespace.

I think there are a number of aspects that can hamper => arrow function readability, issues that go way beyond what the current ESLint ruleset can control. I asked around on twitter, and it seems from the many replies that a lot of people have opinions on this.

The ultimate linter would not only let you configure rules to your liking, but build your own rules if something were lacking. Luckily, ESLint supports exactly that!

So I decided to build an ESLint plugin to define an additional set of rules around => arrow functions: proper-arrows.

Before I explain anything about it, let me just point out: it’s a set of rules that can be turned on or off, and configured, at your discretion. If you find even one detail of one rule helpful, it would be better to use the rule/plugin than not.

I’m fine with you having your own opinions on what makes => arrow functions proper. In fact, that’s the whole point. If we all have different opinions on => arrow functions, we should have tooling support to let us pick and configure those different opinions.

The philosophy of this plugin is that, for each rule, when you turn the rule on, you get all of its reporting modes on by default. But you can of course either not turn the rule on, or turn the rule on and then configure its modes as you see fit. But I don’t want you to have to go hunting for rules/modes to turn on, where their obscurity prevents them from even being considered. So everything comes on per rule.

The only exception here is that by default, all rules ignore trivial => arrow functions, like () => {}, x => x, etc. If you want those to be checked, on a per-rule basis you have to turn on that checking with the { "trivial": true } option.

Proper Arrows Rules

So what rules are provided? Here’s an excerpt from the project overview:

"params": controls definitions of => arrow function parameters, such as forbidding unused parameters, forbidding short/unsemantic parameter names, etc.

"name": requires => arrow functions to only be used in positions where they receive an inferred name (i.e., assigned to a variable or property, etc), to avoid the poor readbility/debuggability of anonymous function expressions.

"location": restricts where in program structure => arrow functions can be used: forbidding them in the top-level/global scope, object properties, export statements, etc.

"return": restricts the concise return value kind for => arrow functions, such as forbidding object literal concise returns (x => ({ x })), forbidding concise returns of conditional/ternary expressions (x => x ? y : z), etc.

"this": requires/disallows => arrow functions using a this reference, in the => arrow function itself or in a nested => arrow function. This rule can optionally forbid this-containing => arrow functions from the global scope.

Remember, each rule has various modes to configure, so none of this is all-or-nothing. Pick what works for you.

As an illustration of what the proper-arrows rules can check for, let’s look at the "return" rule, specifically its "sequence" mode. This mode refers to the concise return expression of => arrow functions being a comma-separated sequence, like this:

var myfunc = (x,y) => ( x = 3, y = foo(x + 1), [x,y] );

Sequences are typically used in => arrow function concise returns to string together multiple (expression) statements, without needing to use a full { .. } delimited function body and an explicit return statement.

Some may love this style — that’s OK! — but a lot of folks think it favors clever terse style coding over readability, and would prefer instead:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Notice that it’s still an => arrow function and it’s not even that many more characters. But it’s clearer that there are three separate statements in this function body.

Even better:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

To be clear, the proper-arrows rules don’t enforce trivial styling differences like whitespace/indentation. There are other (built-in) rules if you want to enforce those requirements. proper-arrows focuses on what I consider to be more substantive aspects of => function definition.

Concise Summary

You and I almost certainly disagree on what makes good, proper => arrow function style. That’s a good and healthy thing.

My goal here is two-fold:

Convince you that opinions on this stuff vary and that’s OK.

Enable you to make and enforce your own opinions (or team consensus) with configurable tooling.

There’s really nothing to be gained from arguing over opinion-based rules. Take the ones you like, forget the ones you don’t.

I hope you take a look at proper-arrows and see if there’s anything in there which you could use to ensure your => arrow functions are the best form they can be in your code base.

And if the plugin is missing some rules that would help define more proper arrows, please file an issue and we can discuss! It’s entirely plausible we may add that rule/mode, even if I personally plan to keep it turned off!

I don’t hate => arrow functions, and you shouldn’t either. I just hate uninformed and unenforced debate. Let’s embrace smarter and more configurable tooling and move on to more important topics!

The post I Don’t Hate Arrow Functions appeared first on David Walsh Blog.

I Don’t Hate Arrow Functions published first on https://appspypage.tumblr.com/

[suzanneshannon]

I Don’t Hate Arrow Functions

TL;DR

Arrow functions are fine for certain usages, but they have so many variations that they need to be carefully controlled to not break down the readability of the code.

While arrow functions clearly have a ubiquitous community consensus (though not unanimous support!), it turns out there’s a wide variety of opinions on what makes “good” usage of => and not.

Configurable linter rules are the best solution to wrangling the variety and disagreement of arrow functions.

I released proper-arrows ESLint plugin with a variety of configurable rules to control => arrow functions in your code base.

Opinions are like noses…

Anyone who’s followed me (tweets, books, courses, etc) for very long knows that I have lots of opinions. In fact, that’s the only thing I’m an expert on — my own opinions — and I’m never at a loss for them!

I don’t subscribe to the “strong opinions, loosely held” mantra. I don’t “loosely hold” my opinions because I don’t see any point in having an opinion if there isn’t sufficient reason for that opinion. I spend a lot of time researching and tinkering and writing and trying out ideas before I form an opinion that I would share publicly. By that point, my opinion is pretty strongly held, by necessity.

What’s more, I teach based on these opinions — thousands of developers in different companies all over the world — which affords me the opportunity to deeply vet my opinions through myriad discussion and debate. I’m tremendously privleged to be in such a position.

That doesn’t mean I can’t or won’t change my opinions. As a matter of fact, one of my most strongly held opinions — that JS types and coercion are useful in JS — has been shifting lately, to a fairly significant degree. I have a much more rounded and deepened perspective on JS types and why type-aware tooling can be useful. And even my opinion on => arrow functions, the punchline of this article, has evolved and deepened.

But one of the things many people tell me they appreciate about it me is, I don’t just state opinions, I back those opinions up with careful, thought-out reasoning. Even when people vehemently disagree with my opinions, they often compliment me on at least owning those opinions with backing.

And I try to inspire the same in others through my speaking, teaching, and writing. I don’t care if you agree with me, I only care that you know why you have an technical opinion and can earnestly defend it with your own line of reasoning. To me, that’s a healthy relationship with technology.

Arrow Functions != functions

It is my sincere belief that the => arrow function is not suitable as a general purpose replacement for all (or even most) function functions in your JS code. I genuinely don’t find them more readable in most cases. And I’m not alone. Any time I share an opinion like that on social media, I often get dozens of “me too!” responses peppered in with the scores of “you’re totally wrong!” responses.

But I’m not here to rehash the entire debate over => arrow functions. I’ve written extensively about my opinions on them, including these sections in my books:

“You Don’t Know JS: ES6 & Beyond”, Ch2, “Arrow Functions”

“Functional-Light JavaScript”, Ch2, “Functions Without function“ (and the preceding section on function names).

Whatever your preferences around =>, to suggest that it’s only a better function is to be plainly reductive. It’s a far more nuanced topic than just a one-to-one correspondence.

There are things to like about =>. You might find that surprising for me to say, since most people seem to assume I hate arrow functions.

I don’t (hate them). I think there are definitely some important benefits.

It’s just that I don’t unreservedly endorse them as the new function. And these days, most people aren’t interested in nuanced opinions in the middle. So since I’m not entirely in the pro-=> camp, I must be entirely in the opposition camp. Not true.

What I hate is suggesting they’re universally more readable, or that they’re objectively better in basically all cases.

The reason I reject this stance is because I REALLY DO STRUGGLE TO READ THEM in many cases. So that perspective just makes me feel dumb/inferior as a developer. “There must be something wrong with me, since I don’t think it’s more readable. Why do I suck so much at this?” And I’m not the only one who’s impostor syndrome is seriously stoked by such absolutes.

And the cherry on top is when people tell you that the only reason you don’t understand or like => is because you haven’t learned them or used them enough. Oh, right, it’s my ignorance. SMH. I’ve written and read literally thousands of =>functions. I’m quite certain I know enough about them to hold the opinions I have.

I’m not in the pro-=> camp, but I recognize that some really do prefer them, legitimately. I recognize that some people come to JS from languages that have used => and so they feel and read quite natural. I recognize that some prefer their resemblance to mathematical notation.

What’s problematic IMO is when some in those camps simply cannot understand or empathize with dissenting opinions, as if there must just be something wrong with them.

Readability != Writability

I also don’t think you know what you’re talking about when you talk about code readability. By and large, the vast majority of opinions on code readability, when you break them down, are based on a personal stance about preferences in writingconcise code.

When I push back in debates about code readability, some just dig in their heels and refuse to support their opinion. Others will waive off the concerns with, “readability is all just subjective anyway”.

The flimsiness of that response is stunning: two seconds ago they were vehemently claiming => arrow is absolutely and objectively more readable, and then when pressed, they admit, “well, I think it’s more readable, even if ignorants like you don’t.”

Guess what? Readability is subjective, but not entirely so. It’s a really complex topic. And there are some who are undertaking to formally study the topic of code readability, to try to find what parts of it are objective and what parts are subjective.

I have read a fair amount of such research, and I’m convinced that it’s a complicated enough topic that it can’t be reduced to a slogan on a t-shirt. If you want to read them, I would encourage you doing some google searching and reading of your own.

While I don’t have all the answers myself, one thing I’m certain about is, code is more often read than written, so perspectives on the topic which ultimately come from “it’s easier/quicker to write” don’t hold much standing. What needs to be considered is, not how much time do you save writing, but how clearly will the reader (future you or someone else on the team) be able to understand? And ideally, can they mostly understand it without pouring over the code with a fine-toothed comb?

Any attempt to justify writability affordances with unsubstantiated claims about readability benefits is a weak argument at best, and in general, nothing but a distraction.

So I roundly reject that => is always and objectively “more readable”.

But I still don’t hate arrow functions. I just think to use them effectively, we need to be more disciplined.

Linters == Discipline

You might be of the (incorrect) belief that linters tell you objective facts about your code. They can do that, but that’s not their primary purpose.

The tool that’s best suited to tell you if your code is valid is a compiler (ie, the JS engine). The tool that’s best suited to tell you whether your code is “correct” (does what you want it to do) is your test suite.

But the tool that’s best suited to tell you if your code is appropriate is a linter. Linters are opinionated collections of rules about how you should style and structure your code, so as to avoid likely problems — according to the authors of those opinion-based rules.

That’s what they’re for: to apply opinions to your code.

That means it’s almost certain that these opinions will, at one time or another, “offend” you. If you’re like most of us, you fancy yourself pretty good at what you do, and you know that this thing you’re doing on this line of code is right. And then the linter pops up and says, “Nope, don’t do it that way.”

If your first instinct is sometimes to disagree, then you’re like the rest of us! We get emotionally attached to our own perspectives and abilities, and when a tool tells us we’re wrong, we chuff a little bit.

I don’t get mad at the test suite or the JS engine. Those things are all reporting facts about my code. But I can definitely get irritated when the linter’s opinion disagrees with mine.

I have this one linter rule that I enabled a few weeks ago, because I had an inconsistency in my coding that was annoying me on code re-reads. But now this lint rule is popping up two or three times an hour, nagging me like a stereotypical grandma on a 90’s sitcom. Every single time, I ponder (for just a moment) if I should just go disable that rule. I leave it on, but to my chagrin.

So why subject ourselves to this torment!? Because linter tools and their opinions are what give us discipline. They help us collaborate with others.

They ultimately help us communicate more clearly in code.

Why shouldn’t we let every developer make their own decisions? Because of our tendency toward emotional attachment. While we’re in the trenches working on our own code, against unreasonable pressure and deadlines, we’re in the least trustable mindset to be making those judgement calls.

We should be submitting to tools to help us maintain our discipline.

It’s similar to how TDD advocates submit to the discipline of writing tests first, in a formal set of steps. The discipline and the bigger picture outcome of the process are what we value most, when we’re level headed enough to make that analysis. We don’t institute that kind of process when our code is hopelessly broken and we have no idea why and we’re just resorting to trying random code changes to see if they fix it!

No. If we’re being reasonable, we admit that the overall good is best served when we set up reasonable guidelines and then follow the discipline of adhering to them.

Configurability Is King

If you’re going to knowingly subject yourself to this finger wagging, you (and your team, if applicable) are certainly going to want some say-so in what rules you’re required to play by. Arbitrary and unassailable opinions are the worst kind.

Remember the JSLint days when 98% of the rules were just Crockford’s opinions, and you either used the tool or you didn’t? He straight up warned you in the README that you were going to be offended, and that you should just get over it. That was fun, right? (Some of you may still be using JSLint, but I think you should consider moving on to a more modern tool!)

That’s why ESLint is king of the linters these days. The philosophy is, basically, let everything be configurable. Let developers and teams democratically decide which opinions they all want to submit to, for their own discipline and good.

That doesn’t mean every developer picks their own rules. The purpose of rules is to conform code to a reasonable compromise, a “centralized standard”, that has the best chance of communicating most clearly to the most developers on the team.

But no rule is ever 100% perfect. There’s always exception cases. Which is why having the option to disable or re-configure a rule with an inline comment, for example, is not just a tiny detail but a critical feature.

You don’t want a developer to just have their own local ESLint config that overrides rules while they commit code. What you want is for a developer to either follow the established rules (preferred!) OR to make an exception to the rules that is clear and obvious right at the point where the exception is being made.

Ideally, during a code review, that exception can be discussed and debated and vetted. Maybe it was justified, maybe it wasn’t. But at least it was obvious, and at least it was possible to be discussed in the first place.

Configurability of tools is how we make tools work for us instead us working for the tools.

Some prefer convention-based approaches to tooling, where the rules are pre-determined so there’s no discussion or debate. I’m know that works for some developers and for some teams, but I don’t think it is a sustainable approach for generalized, broad application. Ultimately, a tool that is inflexible to the changing project needs and DNA of the developer(s) using it, will end up falling into obscurity and eventually replaced.

Proper Arrows

I fully recognize my usage of the the word “proper” here is going to ruffle some feathers. “Who is getify to say what is proper and not?”

Remember, I’m not trying to tell you what is proper. I’m trying to get you to embrace the idea that opinions about => arrow functions are as varied as all the nuances of their syntax and usage, and that ultimately what is most appropriate is that some set of opinions, no matter what they are, should be applicable.

While I’m a big fan of ESLint, I’ve been disappointed by the lack of support from built-in ESLint rules for controlling various aspects of => arrow functions. There are a few built-in rules, but I’m frustrated that they seem to focus mostly on superficial stylistic details like whitespace.

I think there are a number of aspects that can hamper => arrow function readability, issues that go way beyond what the current ESLint ruleset can control. I asked around on twitter, and it seems from the many replies that a lot of people have opinions on this.

The ultimate linter would not only let you configure rules to your liking, but build your own rules if something were lacking. Luckily, ESLint supports exactly that!

So I decided to build an ESLint plugin to define an additional set of rules around => arrow functions: proper-arrows.

Before I explain anything about it, let me just point out: it’s a set of rules that can be turned on or off, and configured, at your discretion. If you find even one detail of one rule helpful, it would be better to use the rule/plugin than not.

I’m fine with you having your own opinions on what makes => arrow functions proper. In fact, that’s the whole point. If we all have different opinions on => arrow functions, we should have tooling support to let us pick and configure those different opinions.

The philosophy of this plugin is that, for each rule, when you turn the rule on, you get all of its reporting modes on by default. But you can of course either not turn the rule on, or turn the rule on and then configure its modes as you see fit. But I don’t want you to have to go hunting for rules/modes to turn on, where their obscurity prevents them from even being considered. So everything comes on per rule.

The only exception here is that by default, all rules ignore trivial => arrow functions, like () => {}, x => x, etc. If you want those to be checked, on a per-rule basis you have to turn on that checking with the { "trivial": true } option.

Proper Arrows Rules

So what rules are provided? Here’s an excerpt from the project overview:

"params": controls definitions of => arrow function parameters, such as forbidding unused parameters, forbidding short/unsemantic parameter names, etc.

"name": requires => arrow functions to only be used in positions where they receive an inferred name (i.e., assigned to a variable or property, etc), to avoid the poor readbility/debuggability of anonymous function expressions.

"location": restricts where in program structure => arrow functions can be used: forbidding them in the top-level/global scope, object properties, export statements, etc.

"return": restricts the concise return value kind for => arrow functions, such as forbidding object literal concise returns (x => ({ x })), forbidding concise returns of conditional/ternary expressions (x => x ? y : z), etc.

"this": requires/disallows => arrow functions using a this reference, in the => arrow function itself or in a nested => arrow function. This rule can optionally forbid this-containing => arrow functions from the global scope.

Remember, each rule has various modes to configure, so none of this is all-or-nothing. Pick what works for you.

As an illustration of what the proper-arrows rules can check for, let’s look at the "return" rule, specifically its "sequence" mode. This mode refers to the concise return expression of => arrow functions being a comma-separated sequence, like this:

var myfunc = (x,y) => ( x = 3, y = foo(x + 1), [x,y] );

Sequences are typically used in => arrow function concise returns to string together multiple (expression) statements, without needing to use a full { .. } delimited function body and an explicit return statement.

Some may love this style — that’s OK! — but a lot of folks think it favors clever terse style coding over readability, and would prefer instead:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Notice that it’s still an => arrow function and it’s not even that many more characters. But it’s clearer that there are three separate statements in this function body.

Even better:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

To be clear, the proper-arrows rules don’t enforce trivial styling differences like whitespace/indentation. There are other (built-in) rules if you want to enforce those requirements. proper-arrows focuses on what I consider to be more substantive aspects of => function definition.

Concise Summary

You and I almost certainly disagree on what makes good, proper => arrow function style. That’s a good and healthy thing.

My goal here is two-fold:

Convince you that opinions on this stuff vary and that’s OK.

Enable you to make and enforce your own opinions (or team consensus) with configurable tooling.

There’s really nothing to be gained from arguing over opinion-based rules. Take the ones you like, forget the ones you don’t.

I hope you take a look at proper-arrows and see if there’s anything in there which you could use to ensure your => arrow functions are the best form they can be in your code base.

And if the plugin is missing some rules that would help define more proper arrows, please file an issue and we can discuss! It’s entirely plausible we may add that rule/mode, even if I personally plan to keep it turned off!

I don’t hate => arrow functions, and you shouldn’t either. I just hate uninformed and unenforced debate. Let’s embrace smarter and more configurable tooling and move on to more important topics!

The post I Don’t Hate Arrow Functions appeared first on David Walsh Blog.

I Don’t Hate Arrow Functions published first on https://deskbysnafu.tumblr.com/