Ask HN: How do you maintain and organize JavaScript?
I'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'd love if every function I write was accessible, and nothing I ever write was locked away in some file or class. I'd love some way to manage all the code I write.
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 / tooling issue?
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?
I don't feel like anything exists to maintain all the code you write over a lifetime, rather than on a project-by-project basis.
6 comments
[ 2.1 ms ] story [ 22.3 ms ] thread* 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
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
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.
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.