5 ms·

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 wh

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

thomasreggi 10y ago
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.
keithwhor 10y ago
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

thomasreggi 10y ago

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.

keithwhor 10y ago

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