Comment by azangru | Hacker News Reader

Comment by azangru | Hacker News Reader

> Keeping up to date with Angular, React, Vue, Riot, Ember, Knockout is fun.

Since the author himself raised the issue of _JavaScript_ frameworks...

Imagine you did not learn frameworks. You completely ignored what's going on the the JavaScript world. You stuck to the basics. JavaScript the good parts, design patterns, clean architecture... Object-oriented software, for good measure.

Then suppose you get a job that requires you to write React.

I know that React itself is very simple (although I think it did take me a couple of days to learn the basics of it), but not having studied it, how would you know what your options are? How would you know which way of writing React will be less painful, or what questions you need to ask yourself regarding the architecture of your app? Without keeping track of what's going on in the community, how will you make informed decisions.

Besides, the evergreen books that the author mentions mostly come from the same school of thought — it's object-oriented programming. Will they prepare you for thinking in React? Remember, seasoned programmers, no doubt accustomed to the best practices of their times, denounced React for its lack of "separation of concerns", i.e. for how it mixed layout, logic, and perhaps even styles. It took a while to realise that thinking in terms of components may have its merits, and may even be superior that thinking in terms of technologies (markup/styles/logic). This is one of the paradigmatic shifts that was brought about by React, a humble framework.

Then suppose you get a job that requires you to write React.

I had a job interview where the interviewer asked, "What framework would you install to accomplish x?"

My response was along the lines of, "I wouldn't use a framework. It's a simple problem, so you just write a function to do it. You don't need to throw yet another framework on the fire."

We had a brief discussion where he couldn't wrap his brain around the concept of just programming something, and not loading a bunch of frameworks to accomplish each task.

I didn't get the job. Later, I found out more about the company and realized that was a good thing.

I feel you :-) I could very well be that interviewer, reaching for a framework to do something that can be easily done in vanilla JS, but feeling that the framework will make it even simpler. (E.g. after using a framework that will handle syncing my state with my UI I find that I don't want to do the same with plain JS). But I've had my share of arguments that made me appreciate the opposite viewpoint as well.

Had the same deal with a guy running a startup factory. I'm pretty sure he couldn't program his way out of a paper bag without frameworks, which is why the alternative wasn't even on his radar. With people like that running the show, it's really no wonder we're going downhill fast.

> How would you know which way of writing React will be less painful, or what questions you need to ask yourself regarding the architecture of your app? Without keeping track of what's going on in the community, how will you make informed decisions.

Write your application logic in easily testable vanilla JavaScript and use React for rendering application state into DOM.

Note that the React docs won’t teach you this. They’ll tell you about Enzyme but they won’t tell you how to make React more of an implementation detail and less of a “framework” that your entire application is tightly coupled too.

> Write your application logic in easily testable vanilla JavaScript and use React for rendering application state into DOM.

The question is, should the logic be in the central core of the application, or should it be spread around among the components?

The concentric structure of a cleanly architected app will suggest that the app logic should be centralized, while the framework should just be an implementation detail. However, centralizing and abstracting away the logic makes for code that is 1) harder to delete; 2) harder to code-split.

> The question is, should the logic be in the central core of the application, or should it be spread around among the components?

There are probably many such questions and at this point we’re trying to solve a problem that may not exist in an application we know nothing about. However, with test coverage (and maybe also type annotations) you can delete or move that code around with greater confidence, which means your decision doesn’t have to be as hard or permanent.

> Write your application logic in easily testable vanilla JavaScript and use React for rendering application state into DOM.

This is the point of React. It's why it was released hand-in-hand with Flux and later Redux. If you're not doing this, you're architecting your code poorly and no framework can save you.

Notice how the community has been trying to move away from the centralized Redux though? Trying to co-locate inside single components presentation logic and the data needed to render this component? I am not saying it's necessarily a good thing, but it is... interesting.

Reply on news.ycombinator.com