Hacker News Reader

I was fairly recently asked what the point of implementing a web application using React was, and what advantages it would bring over just doing it without a framework/UI library.

I couldn't really give a proper answer there, at the spot. But that doesn't mean I don't have an answer, it just means I wasn't prepared for the question. Like, how do I explain why locality is helpful? I'd need to spend some serious effort planning how to explain such a concept. And that's just a small part of the answer to the question.

My point is that sometimes the answer to the question you're asking is just huge, and requires a lot of context to understand. And providing such answers on the spot is very hard. So I think we should cut people some slack when they can't immediately provide an answer. Sometimes things are just not very obvious.

Just to be clear, I don't want to discuss the merits of React here. My point is just that sometimes things are too complex to explain fully in every situation. Everything cannot be understood from first principles. You need abstractions to be productive. By all means, question the abstractions, but perhaps not always?

Given what you wrote, to me it sounds like the asker suspected React was the wrong tool for the job. Not every front-end required an all-out framework with its own weighty cd/ci pipeline. It’s possible the scope of the project was just some static HTML backed with a snippet of JS. If you are dead set on using React then you need to be ready defend the technical tool _choice_, not React itself.

I'm really struggling to empathize with your point here.

I SUSPECT you are expecting that the questionner is going to hold you to an incredibly high and rigorous bar and in fact I don't think that's true. If you say "It will improve our user's perceived client latency" i expect that is sufficient - IF TRUE.

And this is the key. In software everything is a tradeoff. I don't know what the tradeoffs with using React are, but tenerally the industry trend right now is React is worth it. But why? I think it's a fair question to understand that, otherwise you're just cargo culting an architecture without understanding it.

BTW blindly following a trend is itself a choice and a tradeoff. You might not need a deeper answer for using React than "A lot of people use React, so if we use React it'll be easier to hire people to continue to make changes." That's a valid technical decision to use something!

I'm not a frontend engineer, BTW. However I just googled Javascript Locality and React Locality and found basically nothing reasonable except https://stackoverflow.com/questions/45069206/does-data-local...

So I do feel like i'm going to illustrate my point here and ask you "What is locality in this context? Why is it important? Is React the only way to achieve it? What are we choosing as a tradeoff?"

I think I did a poor job of explaining the situation I was referring to. My point was I could’ve made a better job explaining a concept, but I just wasn’t prepared for or had the capacity to do so at the spot. Explaining complex things in an ad-hoc fashion with no preparation is hard, is what I’m saying.

Locality is about having the code for one feature in one spot. If you can remove a feature by deleting one piece of code at one place, for example an entire file, then the feature is local to that file. It allows you to make changes and remove features without understanding the entire application. Without it, you have to understand the entire codebase to make any changes, which goes from hard to impossible as the project grows. This is why globals are a pain.

Locality is related to code cohesion and loose coupling.

React encourages locality because you’re only supposed to pass data one way, which gives you a sort of tree structure where you can remove a branch without affecting other branches.

Of course you can mess this up in React as well, React is no silver bullet and you can do it without React.

There is so much to talk about here, but none of that is relevant to the point I’m trying to make, which is:

I should probably have been able to explain all of this to the person asking, but it’s a lot harder to do so verbally with no preparation than it is to write it down like this.

The context here might be that we are in a design review - you are presenting a design. Maybe it's verbally, but maybe it's a document.

Ideally it's a document, so you can describe it by writing it down.

But if someone asks a hard question that you didn't prepare for, well you still have to make a best effort to answer it verbally.

You can use "I'll write down my thoughts and get back to you" to SOME things, but not every time.

My original context was rather that of a junior developer asking a more experienced developer what choices to make, and then questioning them. Which is good, but sometimes the knowledge gap is just too wide to deal with then and there.

I also ask these simple questions and it’s funny to watch the head-nodders rush to prevent the question from being answered by the presenter by jumping in with what is often incorrect information. There is a powerful desire to maintain the illusion that the whole room understands what is being said, to the point defending it can be instinctual.

Over time this behavior changes as it becomes known I’ll follow up to a cover-up with even simpler questions. :) Some of them have started asking their own!

> one of the best thing about attaining Seniority at work.. you don't have to worry about proving yourself to anyone

but to reach Senior, you must head nod a lot when you're junior (and then later research it yourself if interested), because otherwise you'll likely be deemed stupid and won't make it to Senior.

Not only deemed stupid, it can also be perceived as an attack by making the presenter "look bad" and up in retaliations.

People remember how they felt a lot longer than who was factually correct.