
Things People Eventually Learn About JavaScript Projects - octosphere
https://blog.usejournal.com/10-things-you-will-eventually-learn-about-javascript-projects-efd7646b958a
======
ng12
> React: when you need total control over the architecture and build, but only
> for webapps built with components. React-ecosystem development takes time
> and requires a lot of planning beforehand. React pays back plenty, but only
> if you know what you are doing.

Complete nonsense. React is not any more complicated than Vue and I think it's
significantly easier for newbies to grok than Angular (with some non-trivial
anecdotal evidence to back this up). I do not understand where this perception
comes from. My best guess is that React scales well to complicated
applications which makes people think that's what it's geared for. Maybe I'm
lucky that I learned React in the "early days" before this perception was
common.

~~~
duxup
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.

~~~
_bxg1
FWIW, Angular, Vue, Polymer, Ember, etc. all use the same component-ish
pattern; it's the architecture du jour. That's great that you were able to
pick up React right off the bat, but the concept of components isn't what sets
it apart.

~~~
duxup
I guess I kinda implied it was a reactism, but that wasn't my intent.

I was just noting how someone else new really doesn't find React as big a hill
to climb as the article. The componentisms are just something that make it
easy for me.

~~~
_bxg1
Yeah no worries, I just wanted to make sure you had a clear understanding of
the landscape

~~~
duxup
I appreciate it, perspective and the landscape are things I really want to
learn.

------
DogLover_
Same old recommendations.

Some things to consider imo:

1\. 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.

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.

3\. "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.

~~~
globuous
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.

~~~
anonytrary
Using single char variables is fine and IMHO leads to more concise code
without sacrificing readability. When you are looping over a set, it's very
common to think about it like `for all x in Xylophones do {...}`. For example
in a nested loop, I would much rather prefer `i` and `j` over
`iterativeAuxiliaryVariable1` and `iterativeAuxiliaryVariable2`. Never using
single character variables as a "best practice" is just bad advice. As with
pretty much everything in programming, the real answer is "it depends".

------
stareatgoats
Always interesting to hear someones distilled opinions about what constitutes
best practices. There are mainly 2 things I'd personally add: (1) to keep an
eye on 'Time-to-Interactive', it doesn't seem to be of concern at all to the
author. Also, (2) Npm is a great resource, but I would not reuse components I
might find there without some serious research, dependencies can get totally
unmanageable.

------
mal10c
I think those points could be applied to most languages. My personal favorite
is "Make things embarrassingly obvious." I've been programming for nearly 20
years and I can say without a doubt that's one of the most useful things to
keep in mind on large scale projects. Keeping things obvious allows me get
through bugs, and get the product to the customer faster.

------
Sharlin
Perhaps this is aimed at _very_ junior developers, but it pains me that
"organize your code into multiple files by functionality" is something that
must be separately mentioned.

------
mLuby
A couple of those points could be boiled down to "use a strict linter with
most of the rules turned on".

~~~
tehlike
or typescript?

~~~
wildpeaks
Or even both because Eslint has a Typescript parser too now.

This is the config I use with Typescript projects, if you're looking for
inspiration: [https://www.npmjs.com/package/@wildpeaks/eslint-config-
types...](https://www.npmjs.com/package/@wildpeaks/eslint-config-typescript)

~~~
Zalastax
How does it compare to using TSLint?

------
ranci
The last thing I want in a project I am working on is for the main programming
language itself to be "an adventure'. Software development is hard enough, I
don't need anymore "adventures" from the underlying language or tools.

~~~
sandyarmstrong
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.

~~~
collinf
I come to HN to avoid these Medium articles shilling their personal twitter
account disguised an article that has already been written 25 times.

Your typical Medium article:

6 reasons why you need Async in your Javascript code!

(generic article with no _new_ points being made)

By the way, follow me on Twitter and like my start up on Instagram!

/s

~~~
jazoom
With an interjection after every paragraph repeating what you just read, in
larger font, with "TWEET THIS" underneath.

------
the_cat_kittles
things you will learn about javascript:

\- hosting is cool and can help you arrange code more intuitively

\- closures are useful

\- knowing the actual language itself and not just frameworks is very good

\- use a linter and style checker because the language is too flexible if
working with a team

\- chrome debugging console mastery is a boon

\- code preprocessors like grunt and babel etc are annoying but can be useful

\- reading the actual language specs is a very good way to be knowledgeable (i
never did, but my coworker who did was super helpful because of this)

\- using imports and modular patterns is probably a good idea (they got this
one, kudos!)

\- its very easy to bloat up a project with npm, making stuff yourself is
often totally ok, and often very good

\- most people do not know the actual language, and confuse frameworks and
patterns with the language

\- one of javascripts greatest strengths is its ubiquity, you can run programs
on any almost any web connected device almost instantly. you can use this to
great effect

i write those because i think this article is mostly making points that are
generic and dont apply specifically to js. im sure i forgot alot, just
freestyled!

------
prithvi24
Although unit tests are important, I think it is pretty important to emphasize
the importance of a static type checker like flow. It is expensive to invest
in test coverage, and static type checking is a good proxy to help capture
many regressions. Sure its not perfect, but we should encourage it as a "best
practice".

------
komali2
>Focus on making things simple, without a need for documentation or comments.

I had a coworker that would love to make super long underscore chains without
any comments. Drove me insane. I still find them here and there and break them
apart into line by line commented dead simple code.

When I was in a bootcamp we'd do code golfy type things, taking advantage of
the newest ES features to shrink stuff way down. Was cool then, now when I see
answers like that on stack overflow I'm tempted to repost them "in English."

------
a13n
Aren't these great recommendations for any programming language? Simplify your
code, use version control, write tests, use helpful names...

What does this have to do with JavaScript?

~~~
Sharlin
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.

------
hashrate
> Angular / VueJS / Ember: when you need a webapp done quick and reliable, >
> in exchange allowing a big black-box instead of an architecture.

Here we have the typical "coder" mindset, It's very clear reading these line
that the developer has never experienced with those frameworks as both Angular
and Vue has very strong and well designed architecture which are obviously
open source.

Unfortunately it's very rare these days to find developers that can argue
passed beyond "Google Trends Charts" and "Github Stars" about what makes a
good or bad framework and why X is better than Y or why X architecture is more
efficient than Y.

> React: when you need total control over the architecture

Could the author be more specific here ? I don't remember "Ruby on Rails" to
give much freedom in terms of architecture yet it empowers thousands of large
traffic web apps without any problems.

It sounded as very common beginner beliefs which is "It's not possible to do
this with [Angular/Vue]".

Hence the majority of the article isn't really specific to JS.

~~~
britch
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.

~~~
TheCoelacanth
It's supposed to be a bad thing that React doesn't add yet another way of
making HTTP calls? There is already a standard way of doing that (fetch). Why
should a web framework add another one?

------
jasim
If you are lucky, the thing you will eventually learn about JavaScript is to
use either TypeScript, Flow, Elm, Reason, or PureScript.

If you are unlucky, you might get attached too much to design decisions made
by Brendan Eich because he didn't have enough time to design the language, and
nobody knew how big the web was going to get. Also because statically typed
functional programming was so far marred by lack of good learning material and
bad tooling. That has changed. Now is the time to get back to start using
scripting languages for scripting, and more sophisticated languages for
building more sophisticated things, which rich front-end applications
definitely are.

Many writings about programming that get popular are predicated on dynamic
languages, and thus about coping with them rather than stretching the limits
of what you can make the computer do. "Name your variables", "write comments",
"use framework X over Y". These things stop being a worry once you let the
compiler become your pair-programmer and tell it through types what you're
trying to do, and it'll become your safety harness, and the types your tools
of thought. Amazing stuff.

~~~
luord
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.

~~~
jasim
I should've been better with the tone. My view still holds.

I know programmers who've written large swaths of Haskell and OCaml, who
however reach for the eminently dynamic Racket for its metaprogramming. They
know the relative strengths of each paradigm better than most of us and have
fine judgement. However junior programmers (<10 years) who haven't spent the
effort required to learn other paradigms and are religious about whatever
language they chose to learn as an accident of history are missing out
tremendously.

Most of the static vs dynamic type research has always been about C++ based
static types (which combines Simula-67's object system with Pascal's types -
more history here:
[https://twitter.com/jasim_ab/status/991948718508130304](https://twitter.com/jasim_ab/status/991948718508130304))
contrasted first against LISP and later with languages like Python, Ruby, and
Javascript. Statically typed FP is totally different, and there are papers on
either side of the bias to point to. I will recommend the Elm Language as a
good starting point for anyone interested in seeing what Typed FP truly can
be.

~~~
seanmcdirmid
Most of the research in static types occurs in the FP community. Even most of
the research about OO static types is not about C++, heck, you won’t find much
research on C++’s type system at all. Java would dominate from the late 90s,
before that it’s a box, but I’m sure there is much more research on even BETA
(a language most people have never heard of) than C++.

C++ has and always will be a pariah in the research community.

~~~
jasim
Hey Sean, thanks for chiming in. Do you think C++ isn't liked in academia
because of any bias against languages that are more practical than formal, or
anything in the language's nature itself?

~~~
seanmcdirmid
C++ is just super hard in its design: it can’t be parsed easily, so for a long
time custom compilers were impossible. It’s support for generics was based on
was basically macro expansion, it’s multiple inheritance scheme was poorly
thought out. It was just painful to do anything with it as a user of the
language or an implementer. OOP people were never much of a formal crowd, and
they had plenty of niche languages to base their research around (smalltalk,
CLOS, Eiffel, BETA, ...).

And when Java came along, acedemics breathed a sigh of relief: finally they
could work on a “practical” language that wasn’t totally insane. And everyone
else who really didn’t need to be using C++ in the first place has similar
ideas.

~~~
jasim
Got it, thanks!

------
_bxg1
Most of this is pretty nonspecific to JS, just basic general good-practices.

------
aylmao
Good article. This applies to all projects-- JavaScript or not.

