Ask HN: How do you maintain and organize JavaScript?

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

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

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 (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 (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.

* 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

Thanks for this! This is really helpful. To expand further, I can't tell you how many times I've written something as simple as a promised version of fs exists, and if you do copy and paste something like that into your project you have to bring it's deps (tracking them down in package.json) in and tests (for full coverage into your new project. Alternatively you make it a one-off npm module. It just seems like both those options are cumbersome and inefficient for one function. I'm very much against the MVC setup (I'm working with mainly API's), and as well as OOP in general, and write a ton of very small functions, some that expand on tools like lodash, and that I use a lot. This is where it gets harder and harder to maintain them.

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

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