There really aren't any scenarios I can think of that an element would need to have `grid-column` set without being wrapped in another grid, so for that reason it is generally safer to set `grid-column` on all children than it is to set `max-width`. I would be surprised if I added an element only to discover that its width was being modified by a wildcard rule, less so with `grid-column` because grid placement is arguably the concern of the grid.
As a side note, I like this technique and have already had a good opportunity to apply it instead of the old padding & negative margins method or even flexbox + stretch (and I like flexbox), neither of which actually worked for this very specific case.
1. You can implicitly return things so it provides nice syntactic sugar
2. Using an arrow function results in `this` being bound in the way you'd expect (coming from something like C++) in all cases without having to call .bind(this) anywhere. I'll never forget seeing promise chains starting with `const that = this;` in order to keep the right reference throughout the promises.
3. You use it for the previous 2 reasons and use it everywhere in order to be consistent
I fall into category 3 which is why I list it. It's not a technical reason so much as a code style reason so it is definitely subject to the opinions of each developer.
For example, an arrow function accessing variables outside its scope is much slower, something you will notice when processing a lot of data in nodejs.
And if you're working in the browser and trans-pilling down to ES5, babel needs to do a lot more work.
But as long as people are aware of the trade-offs, they can use whatever works for them.
> Looking at your comment history, seems like anyone who technically differs with you gets downvotes, I'm sure that's not how it supposed to work, bring it on anyway.
Probably a side-effect of what I usually choose to comment on, which are things that are objectively wrong or seriously misleading :) I think the HN voting system is poor, so I don’t use it, myself.
> Remember, an arrow function shares the same scope with [its] parent function
Exactly like a non-arrow function, then?
> Do you have any evidence to the contrary? I have experienced it when processing heaps of textual data in nodejs (the same engine that runs chrome). My script was crashing for no apparent reason, and just changing the arrow functions solved it.
Not only is that not evidence, it doesn’t support what you originally said. Slower ≠ crashing for no apparent reason.
If you mention which version of Node this was, I can go looking for evidence.
> Probably a side-effect of what I usually choose to comment on, which are things that are objectively wrong or seriously misleading :) I think the HN voting system is poor, so I don’t use it, myself.
Do you have any evidence that you do not use it?
> Remember, an arrow function shares the same scope with [its] parent function
>> Exactly like a non-arrow function, then?
No, not exactly. It looks like I need to be more explicit, here goes: Remember, an arrow function's BODY shares the same scope with its parent function
> Do you have any evidence to the contrary? I have experienced it when processing heaps of textual data in nodejs (the same engine that runs chrome). My script was crashing for no apparent reason, and just changing the arrow functions solved it.
>> Not only is that not evidence, it doesn’t support what you originally said.
It is called ANECDOTAL evidence, and yes, it is a thing. If you want SCIENTIFIC evidence, sorry I just do not have the time and energy. If you want to believe that arrow functions are a drop-in replacement for normal functions and that they are always better and faster in all situations, go ahead and believe that. And you'll do just fine, as long as all you are doing with JS is React and basic UI wrangling stuff.
> Slower ≠ crashing for no apparent reason.
My friend, this is a discussion, not a scientific thesis or a legal document. I do not have to explicitly explain every little detail and cover every little phrase so that someone does not misqoute me. Be generous enough to try and understand something someone is saying. So, to rephrase that too, when I say "crashing for no apparent reason" I mean "crashing for no apparent reason that I could find by looking at the code over and over again searching for bugs or typos". And yes, it was crashing due to timeout and memory issues. Please dont start arguing about how crashing and timing out are not technically the same thing.
> No, not exactly. It looks like I need to be more explicit, here goes: Remember, an arrow function's BODY shares the same scope with its parent function
Exactly like a non-arrow function, then?
I don’t mind if you don’t have the energy to support your claim, but I will recommend that you don’t make claims like “arrow functions are slower” if you can’t back them up properly or even provide any detail.
I also get the impression that you don’t know how arrow functions actually differ from non-arrow functions (see above), so your anecdote that you couldn’t figure out the bug doesn’t make a strong case.
> Do you have any evidence that you do not use it?
My browser was crashing for no apparent reason and stopping voting on HN solved it.
The company isn't paying for your time in the car but it is paying for the space your desk in the office occupies. Would you argue that someone who drives 30 minutes more to the office than an otherwise equivalent coworker should be paid more?
It's possible, isn't it? The person with the longer commute may be able to use it to negotiate for a higher salary. Particularly if they have another option with a shorter commute.
Perhaps I misunderstand you or have overlooked something.
On one hand, if you are worth $N to the company sitting in an office and produce the same output working from home, that output is still worth >$N to the company.
On the other hand, if the company isn't limited by geographic restrictions, it can find people who may produce an equivalent output and are willing to work for less.
So it is a balance between how in demand your skills are and how competitive the market is for those skills. In my opinion, if a company is in need of an employee and is willing to pay $N for the employee, simply being remote should not reduce that amount. It has advantages for all parties involved (improved employee satisfaction, lower office overhead, etc).
Ultimately it is a negotiation, the the company can try to justify paying you less because of cost of living adjustments unless you can negotiate otherwise. It's in their interest to get your labor for the best price possible.
I do agree that debugging async JS code is tricky depending on how your calls are structured. However, JavaScript is definitely debuggable. Stepping through minified code is a solved problem thanks to sourcemaps.
As a side note, I like this technique and have already had a good opportunity to apply it instead of the old padding & negative margins method or even flexbox + stretch (and I like flexbox), neither of which actually worked for this very specific case.