
Ask HN: How do you maintain and organize JavaScript? - thomasreggi
I have written so much javascript over the years, specifically nodejs. I have tons of folders and files of code that is in some half-baked state. It&#x27;s safe to say I&#x27;m overwhelmed and unorganized. I feel like I write the same couple of functions over and over again, reinventing the wheel again and again.<p>I&#x27;m reaching out to the community looking for some alternative. I want to write code, test it, document it, and manage deps all in one place, and forget about it. I want naming conventions for files and folders as well as functions themselves. I&#x27;d love if every function I write was accessible, and nothing I ever write was locked away in some file or class. I&#x27;d love some way to manage all the code I write.<p>Does anyone else feel this way? Am I just too lazy to make things npm modules, or is there something larger at play here? Is this all an IDE &#x2F; tooling issue?<p>What can I do to lower the barrier-of-entry to just write code, and stop fiddling with files, folders, modules, repos, function naming, etc?<p>I don&#x27;t feel like anything exists to maintain all the code you write over a lifetime, rather than on a project-by-project basis.
======
zachrose
> What can I do to lower the barrier-of-entry to just write code, and stop
> fiddling with files, folders, modules, repos, function naming, etc?

If your goal is to _write code_ with as little overhead as possible, put your
code in a JavaScript file and bring it into the global namespace of your site
with a <script> tag.

> I feel like I write the same couple of functions over and over again,
> reinventing the wheel again and again.

If your goal is to organize your code so you don't have to write as much of
it, then fiddling with files, folders and modules is a worthwhile investment
of your time.

At the risk of inducing JavaScript fatigue, I recommend using a tool that will
compile single JavaScript files out of multiple linked CommonJS modules. There
are two main tools that do this, Webpack and Browserify, and they're by-and-
large interchangeable. Use Webpack if you want to be told which one to use.

> I want naming conventions for files and folders as well as functions
> themselves.

Naming conventions are orthagonal to the actual organization of your code. Be
aware that different projects use different conventions, and hopefully make
peace with that. For your own projects, find a style guide you like and stick
with it. I like this one:
[http://nodeguide.com/style.html](http://nodeguide.com/style.html).

------
mifreewil
> Am I just too lazy to make things npm modules, or is there something larger
> at play here?

Yes. If you want to re-use your JavaScript, build small CommonJS modules. ES6
modules are here, but the loading part is still TBD.

Use Browserify or Webpack to package up the modules if you want to use them in
the browser.

------
niftylettuce
Here are a few recommendations of mine, from shipping dozens of huge projects
(extremely quickly 1-2 mo each) with a lot of overlap:

* Use utility functions wherever you can from NPM packages such as `lodash`, `underscore`, `validator` and `underscore.string`.

* Use as many IDE plugins as you can; syntax highlighting, marking 80th or 100th character column

* I recommend using VIM or an IDE that utilizes muscle memory as much as possible, here's my config [https://github.com/niftylettuce/.vim](https://github.com/niftylettuce/.vim) (take a look at the plugins I use and the `vimrc` file contents)

* Use `eslint` with a nice `.eslintrc` file. For ES6/ES7, here's mine [https://github.com/glazedio/glazed/blob/master/.eslintrc](https://github.com/glazedio/glazed/blob/master/.eslintrc) (basically every time I file save in VIM, it checks these ESLint rules and highlights the lines in red that have issues and describes them in the VIM footer/help section at bottom of the editor)

* Use a simple MVC folder organization. See what I did here with Glazed at [https://github.com/glazedio/glazed](https://github.com/glazedio/glazed).

* Don't use overly complex frameworks or SPA's unless absolutely 100% needed. It usually just slows you down - and from a user-perspective having a backend templating language vs. SPA to render views is transparent to them (they don't even really see the difference, they just want functionality!).

In general, you really can't avoid having to manually write all the fluff code
you consider to be "reinventing the wheel over and over again". This is stuff
you will encounter with every project. Projects are very similar in setup, but
different in functionality. You just have to make writing _that_ code_ faster,
through the use of copy/paste, string replacement, and helper functions. If
you start writing shorter bits and blocks of code, then you will be able to
transition from one project to another more seamlessly. These thoughts you
have are why I came up with Glazed, the practices around it, and everything
that's baked in (so I didn't have to do so much of this manual stuff I could
just clone it as a boilerplate and get going, then copy code over for unique
things from various projects).

 __Take a look here for additional tools and tips I use to write projects
quickly and recommend to
others[https://github.com/glazedio/glazed#advice](https://github.com/glazedio/glazed#advice)
__

~~~
keithwhor
Biggest point to hammer home home here is use MVC folder organization. Use a
framework that already exists, if possible. Standardize your process for
creating webapps so you (and your team) can get to writing the code that
actually matters as quickly as possible. Ideally you want to decide on;

A) Your code style, file organization

B) Your HTTP routing

C) Your views or data format (JSON responses only?)

D) Your database

E) How you interface with your database

F) How you maintain your database (migrations, etc.)

G) Testing

Pick these for yourself. Use the same processes repeatedly. Document the
processes. _This is where opinionated frameworks save huge amounts of time_.
You'll find the process that works best for you, but if every developer you
meet has a process that is somewhat orthogonal at one level, you'll have to
create a new one when you work together. This is a waste of time. One of the
reasons Rails is so outstandingly popular is because it gave a common set of
tools to backend developers and a set of patterns everybody could share.

These sorts of questions about organization are the ones I had when I first
built Nodal [1], and I was frustrated to find the best MVC solutions in the
Node space didn't give me anything close to what I was working with coming
from Django and Rails. That said - use what works for you. Bonus points if it
also works for the other developers you're working with. ;)

[1] [https://github.com/keithwhor/nodal](https://github.com/keithwhor/nodal)

------
lightlyused
Keep it simple, don't be scared to make mistakes, and re-factor when you see a
better way of doing things.

