Things People Eventually Learn About JavaScript Projects

I think this sentiment comes from the fact that React is not a complete solution, and for big projects, you will have to make several impactful decision about architecture as it relates to using React.

Angular and Vue don't encounter this as much because they are more broad, and more opinionated.

n00b webdev here.

React's component-ish nature and such actually makes things easier for me to digest / manage. No painful planning needed and I can move stuff around at will.

I put React on everything (even if only for practice).

It was a bit intimidating at first (like a couple weeks...) but it doesn't take long for for the fundamental React-isms to become second nature / my preferred way of doing the front end.

Seriously? Complete non-sense? React projects are frequently broken down into lots of small components with custom model/controller architectures depending on what third party tools you throw in with it. There are many areas where bloat and technical debt can add up if you do not properly plan before hand. Particularly in scenarios where you may be getting into front-end development for the first time i.e. when creating a MVP for your start-up. In this scenario and others like it React may not pay back plenty.

While these issues exist in other libraries/frameworks they are somewhat mitigated by clearer first-party conventions or front-runners in the third party ecosystem which dictate specific architectures.

- React takes way more configuration to get started than Vue. You can technically use either of them with or without build tools, but without Babel and Webpack, Vue is still reasonably usable and React is laughably obtuse.

- React out of the box may not be any more complicated than Vue, but it also does a whole lot less than Vue does. Chiefly, you don't get tracking of deep state changes without adding a second (state management) framework on top, and the major ones designed for use with React are also designed for scale, and require tons of boilerplate and highbrow programming theory to get up and running with (I'm looking at you, Redux).

- React itself is pretty highbrow, forgoing straightforward OOP concepts for functional-programming ideals. Which isn't a bad thing! But it makes it harder for newcomers who just want to get the text on their page to match up with what's being typed in an input.

> Thus making such advice not very useful.

Even with a squash, I think there is value in committing frequently and with good commit messages.

Meaningful commit messages on the feature branch make it easy to compile a list of changes for the PR; in the case of GitHub, the squashed commit's message for the PR lists the individual commits that make it up in the larger text box, which can be nicely formatted into bullet points.

The Clojure world has a set single-letter naming conventions that, since they are widely accepted, greatly improve readability. If you see an argument named `f`, you can be sure it is a function. `m` is a map, while `k` and `v` are used for keys and values, respectively. `x` and `y` are numbers and `n` is always an integer.

> Using x as variable name can sometimes increase readability. For generic functions that are close to mathematics it is not a sin to use such variable names. Though way to often I get pointed out to rename it to something more descriptive. Longer variable names can also leads to worse readability since a linter will now make 1-liner split into a 4-liner.

I've rarely seen cases where abstract short variable names have improved readability on their own.

Where it has helped, either there is a comment explaining what the variable is for, or there is a strong convention already in the domain, like using x,y,z in graphics programming to indicate position.

Also... I haven't really encountered linter issues with longer variable names. Do you mean linters that enforce maximum line widths? That seems increasingly rare these days.

> "Commit daily,... . Give meaningful commit messages." I am starting to see a trend where PRs get squashed into one commit. Thus making such advice not very useful.

As a general point of practice, squashes should merge together into semantically meaningful packages, and big multi-purpose commits are the actual no-no. So for example I'll squash together two commits that say "Fixed ABCD issue by doing XYZ" and "Fixed accidental regression caused by XYZ" to just the first message. The fact that I also needed to fix a regression is fine being documented in the bug tracker only, since someone looking at a commit diff will spot the extra XYZ related changes anyway.

1. The number of cases where a one-character variable name is a good choice is small, and those are usually limited to the scope of a single loop, a lambda parameter, etc. A good linter should understand that.

Though naming is hard, and coming up with a descriptive and short name is often not easy. It's a worthy exercise, though, it makes you think about what this thing really is, and can even uncover bugs.

2. Test the public interface. Don't write, rewrite, or remove tests that test specific implementation details, to say nothing of trivial things like getters / setters. In a a good test suite, 20% of tests break during a big refactoring, but the remaining 80% show you that you're still on the right track. Most of the broken tests are often easy to fix mechanically, and those that need thinking, would need thinking anyway. They test the actually changed stuff.

3. Commit more than daily; commit with every change worth looking at, or reverting to. Spend these 15 seconds thinking up a good commit message.

Squashing on development branches is both counter-productive, hostile to code reviewers, and needless. Git can auto-squash commits on a merge for ages. Github has a checkbox for it, so does Bitbucket. Use that.

Regarding your first point, in side projects, I've started doing things like this:

  for c in customers:
    return c.first_name + c.last_name

or:

  customers.map(c => c.first_name + c.last_name)

I've started doing this because I didn't like having "customers" and "customer", I found this very un-readable. It also makes it simpler to follow what's going on since I have less code to parse.

And because I never use 1-lettered variable names (unless it's a counter like i, j, k), I find it very easy to read when this convention occurs in my code.

Higher level tests require less refactoring

> 2. Tests: "With increasing complexity your codebase will become much harder to maintain and control — tests will do it for you." Good intentions here but be careful. Tests can cause people not wanting to refactor/fix because now they have to fix the structure of the tests. Refactor means more than changing the implementation of functions.

Isn't the entire point of tests that you can refactor the code under test without changing the tests themselves? Otherwise how do you ensure that you have not introduced bugs in the code by doing your refactor because you've changed the thing that tested the code in the first place.

A refactor of the tests should be done independently of the code under test.

or typescript?

If you look past the first line, it's all just general software development advice and has pretty much nothing to do with JavaScript. I'm not really sure why it's on HN at all.

The author wasn't suggesting JavaScript being an "adventure" was a good thing. If you build web applications JavaScript is pretty much a fact of life. This article provides pretty reasonable advise on how to make it manageable.

JS is probably the language most junior devs are familiar with, these days. And, partially due to that, also probably the one with the worst and hackiest real-world practices.

I took the more control to mean React gives you more choice over what libraries you want to include in your architecture, whereas Angular/VueJs. are more opinionated.

HTTP call libraries are a good example. Angular comes with HttpClient in the box, and while it might be possible to use something else, Angular is really going to prefer if you makre your HTTP calls using HttpClient.

As I understand it, React does not have a parallel. React shrugs its shoulders and says "use what you want," whether it's just using fetch or some other JS library.

Total control is maybe an extreme way to put it, but React certainly more "fill in the blank" than the other frameworks.

I don't understand your point, or maybe it's just the tone.

You seem to be treating "static typing is better" as a fact of life that people working with dynamic languages eventually learn if they're "lucky".

This is completely at odds with, well, reality: static vs dynamic has been going on for over sixty years, essentially since the first days of computer science. You fall in one camp, all the power to you, but it isn't better and doesn't make you "more lucky".

They have their pros and cons and many a paper and book has been written comparing them.