Good on you, but this doesn't prove anything imo. People are almost always positively biased toward attractive faces due to the halo effect. Biologically/psychologically this is a result of one's facial bone structure, skin, and bodyfat levels.
So being shabbily dressed and having stubble is mostly irrelevant here. Maybe you were just much better looking than the other (poor) bloke.
Maybe I wasn't being clear in the last line of my response. I agree with this "People are almost always positively biased toward attractive faces due to the halo effect."
The point I'm trying to make is in addition to that there might be other forms of appearance-based biases: for ex maybe a scientist is expected to project an image of being nerdy, or detached-ly pensive, etc
It's a fallacy to think that the only outcome of COVID is binary (i.e. death or perfect recovery).
Just browse r/covidpositive. There are so many "survivors" who say they still have so much internal organ pain 4 months after being diagnosed, and now they feel hopeless, have suicidal ideation, etc.
And from the sounds of it, a lot of these people are in their 20s-40s and could run a marathon pre-COVID.
C'mon, let's be real... most devs are working on features/products that will never see the light of day. Or they're restyling the company's "contact us" form for the thousandth time.
The market is not efficient. A software developer being paid $100k doesn't mean they're providing the world with $100k of value. it just means they convinced management/HR to pay them $100k for turning up 250/365 days.
I suggest checking out "bullshit jobs" by David Graeber :)
Sure, people don't always ship. Companies and investors pay to throw things at the wall and see what sticks. It doesn't all stick, but if they threw nothing, nothing would.
The individual may not provide 100k, but N developers probably provide (at least) 100Nk value. That or the market is very broken.
As an aside, you and the parent both say "most", which I would doubt but is difficult to prove either way.
> it just means they convinced management/HR to pay them $100k for turning up 250/365 days.
I mean isn't value based on what you can convince someone else to pay for the service/product. Are Mac's really valued at 10 grand or whatever, but rather simply what they've convinced someone to pay for that.
Also, isn't that the same for plumbers for example? Plumbers being paid around $150/hr (this is what is the going rate for a good plumber in Australia) are providing the world with $150/hr of value. It just means that they convinced the customer to pay them $150/hr for turning up to their house and taking a look at a leaky tap, one that could be fixed in about 5 mins.
Yes. As a frontend developer, my default mode now is to almost always go straight to searching issues in the GitHub repo of an npm package I'm using.
I only end up on SO when googling very generic questions about React, TypeScript or JavaScript (and sometimes CSS). Also, the top Google results from SO are often from ~2017 or earlier which puts me off
I really enjoyed Bryan's book. I'd always thought uni was ridiculously overpriced, but hearing it straight from the mouth of a professor really hammered the point home for me.
I believe we are on the verge of the education bubble bursting, just like the housing bubble a decade earlier
Yeah, totally agree. Ironically COVID has made me realise how much I want to work in an office now, as I'm going slightly insane from the lack of social contact.
Moving forward, the best middle ground for most jobs would probably be half the traditional working week in an office, the other half from home. Or something like that.
"Online education used to be like online dating: only something losers would do. But now it seems to moving towards the default way of doing business."
As a self-taught developer and proud of it, I like this quote. A lot. It's easy to let yourself fall into a toxic mindset where you (and many employers) unjustifiably feel inferior because you didn't take the traditional 4-year college route.
But in less than a decade, hearing of couples who met on Tinder has gone from a novelty to the norm, reminding us of how quickly societal paradigm shifts can happen (for the better, imo).
Only fools with zero foresight ever said anything like that. These days I would think less of a person paying $20,000 tuition per year over the person who did all the same work online for free.
Can you please explain what you mean by every component re-rendering? Maybe I'm just ignorant, but I don't think that's correct (unless you made a really bad app).
Other than that I agree with the gist of your post
Yeah, I also don't think that's correct, in most cases. React updates the entire tree internally when anything changes, but actually only changes DOM nodes who's prop or state has changed. The problem is, the check of props and state that React does by default is naive, in that it doesn't check if something is deeply equal, only shallow. So using numbers in props works correctly, but not array of numbers. So if you use anything other than booleans, numbers, strings and so on, where equality works as expected, only changed components will render to the DOM. But if you have arrays or objects, the checks React does will always trigger an update of the DOM, as `[] === []` or `[] == []` will never return true, even though they are the same. The way to work around this is to implement your own `shouldComponentUpdate(newProps, newState) <boolean>` and do your own equality checks.
Maybe a side-effect of the poor equality we have in JS-land.
> Yeah, I also don't think that's correct, in most cases.
Actually, stupidcar assessment is completely correct.
> React updates the entire tree internally when anything changes, but actually only changes DOM nodes who's prop or state has changed.
Sorry, but you're mixing up a lot of concepts here!
When you tell react(-dom) to render, it recursively calls all the render() methods of your entire component hierarchy and updates the entire virtual DOM, but only mutates the actual browser's DOM for the parts that are changed.
Yes, there are ways to block a render based on prop staleness using shouldComponentUpdate/PureComponent/React.memo. These are explicit optimisations on top of the default render-everything model.
Props and State play into this story quite a bit differently.
When a component-local state changes react only renders that specific component (with everything below it). Props are passed down on every render and are by default not compared for staleness so don't prevent re-renders. Props and DOM updates have nothing to do with each other: props are properties of components, not the DOM! Sure, the DOM can be directly or indirectly be influenced by those props.
> Maybe a side-effect of the poor equality we have in JS-land.
Yes, this is true. A lot of reacts's quirks are a result of JS's poor notion of equality.
> A lot of reacts's quirks are a result of JS's poor notion of equality.
God, yes. And I'm amazed everyday to run into senior engineers that do not understand how equality works in JS.
People are also easily confused if they happen to use Redux, because Redux also adds a layer of memoization for you and will not re-render if none of the state (props) or dispatch functions change.
> Yeah, I also don't think that's correct, in most cases. React updates the entire tree internally when anything changes, but actually only changes DOM nodes who's prop or state has changed.
That internal tree update is the root cause of all the problems. During that update, React runs all the javascript in the component, and that of all of it's child components, which then run their child components till the entire tree is done.
Sure, only a small part of the actual DOM will change. But the sheer wastage that happens to update that small part is criminal.
If you have a React Tree that outputs the HTML that is your full page some of your components in that tree will not be re-rendered because the virtual DOM tells you you do not need to re-render them (where we us re-render to mean the React render function is called for that particular part of the tree) but the last render of that component is still saved somewhere and when your whole tree is ready to re-render the HTML of your page (where re-render means actually sending changes to the DOM and causing all the page to re-render)
I don't know enough about how React internals work but I suppose if you have a parent that re-renders but a child does not (React render called again), both will still render (HTML render) at the time of updating the DOM, as I cannot see a logical way that it could not be so.
If I understand you correctly, you have it backwards.
If a component renders in React, that is, the render function is called, then ALL children's render() function are also called, unless you do specific optimizations such as React.memo.
So the whole tree is rerendered.
When it comes time to apply those changes to the DOM, that is, generating HTML on the page, wherever your render() functions returned the same result as before, the DOM is not touched.
As you said yourself, only children components will be re-rendered. This is relative to the component that had it's state changed (using setState or the useState hook). So not the whole tree rerenders, only the affected component and it's children. And again, when we speak as "re-render", the render() functions of the components are called and then the VDOM diffing happens. That is, even if child components got -rerendered (in react terms), there might not be a DOM update at all (which is the slow, costly operation).
> That is, even if child components got -rerendered (in react terms), there might not be a DOM update at all (which is the slow, costly operation).
Crawling a large React tree's render stack is also a costly operation. Not as much as DOM manipulation but it is still costly, and React is created in such a way that it requires you to include everything in that stack, even if it never changes. Which is one reason we have Portals.
(i hope i'm not spreading misinfo, i'm not super experienced with React)
it may be that way with regular Components, but afaik Pure components are smarter - the idea of Pure components is that react only rerenders the components when the props change. (or something in a hook, if you're using those). though i guess a Pure component is basically equivalent to what you'd get with memo?
Yes, of course, I realized how the html re-render part works just now reading your reply, which I had known before but forgotten. sort of embarrassing.
So being shabbily dressed and having stubble is mostly irrelevant here. Maybe you were just much better looking than the other (poor) bloke.