# Shared Code

Nodewood uses the same language for the back-end API and the front-end UI - JavaScript. While there are a lot of languages you can use for your API, this is only one language you can use on the front-end (barring some fancy cross-compiling), so if you're going to be using the same language for both, there's just one game in town. Thankfully, the Node.js (opens new window) ecosystem exists and is mature and stable, which makes accomplishing our goal very easy.

This, of course, leads to the question: Why would you want to use the same language for the front-end and the back-end? In two words: "code re-use". In a lot more words, you can write models, validation, and libraries and then use that code in both your UI and API, instead of re-implementing the same validation and common business logic twice. This gets you some impressive benefits:

  • It's faster to write code across your whole application: If you only need to write a significant portion of your business logic once, you only have to figure out the implementation once, you only have to write one set of tests, and the same validation that works on your forms can be used on your API back-end that accepts those forms as input.
  • It's easier to maintain over time: If you use a different language on the back-end as you do on the front-end, any improvements or bug fixes you make to duplicated code has to be implemented on both the API and the UI, in different languages, potentially using different idioms, and requires separate tests.
  • One language makes it easier to specialize or hire: If you're a solo founder, sticking to one language makes it easier for you to specialize deeply in that language and become more productive. If you're looking to hire freelancers or build a team, having just one language in your stack increases your chances of finding the right hire, versus trying to find the perfect polyglot.

Nodewood has two main focuses for shared code: models, where common business logic is typically kept, and validation, which can be used for UI form validation or API input validation. Any further shared code can be placed in a feature's /lib folder, which is explicitly outside of the api and ui folders for this reason.