For front-end development, how do your organise your code (outside of a framework), and what tools do you use to manage it?

If you want to write a front-end library, or a web application without a framework, what modular style do you follow? And what tools do you choose and why?

Below is a quick list of the options. I am trying to learn more about them atm, so I am curious on your take! Let me know if there is something I missed that may be relevant!

Modular "Styles"

1. ES6 Modules: Native to JavaScript.
2. CommonJS: This system was born with server-side JavaScript in mind, it is used in Node. Modules are loaded synchronously, and processed in the order the JavaScript runtime finds them. Only supports objects as modules. You can use it client-side with Browserify.
3. Asynchronous Module Definition (AMD): Takes a browser-first approach. Modules and dependencies can be asynchronously loaded. Modules can be different types (objects, functions, strings, and so on). RequireJS is the most popular client-side implementation.
4. Universal Module Definition (UMD): Bid to provide "universal" pattern that supports both CommonJS and AMD styles.
5. Module pattern: Some form of using closures to create a local scope for related variables and functions.
6. Don't modularise code. Have one file with everything in it.

Bundlers

Module bundling is the process of combining a group of modules (and their dependencies) into a single file (or group of files) in the correct order. Bundlers may handle other assets such as CSS and images also.

A lot of different bundlers exist now, arguably, these are the most popular ones:

1. Webpack: Webpack is used to compile JavaScript modules, but it can also transform front-end assets like HTML, CSS, and images if the corresponding loaders are included.
2. Parcel: A web application bundler, differentiated by its developer experience. It offers blazing fast performance utilizing multicore processing, and requires zero configuration.
3. RequireJS: Optimized for in-browser use, but it can be used in other JavaScript environments. Supports CommonJS-style modules.
4. Rollup: Rollup allows you to write your code as ES6 modules, and will then compile it back down to existing supported formats such as CommonJS modules, AMD modules, and IIFE-style scripts.
5. Browserify: Allows developers to CommonJS-style modules that compile for use in the browser.
6. FuseBox: Alternative to Webpack with first-class TypeScript support. Can replace Babel.

Choosing the right bundler in 2020.

Transpilers

Transpilers are tools that read source code written in one programming language, and produce the equivalent code in another language. Transpilers are used to convert from CoffeeScript and Typescript to JavaScript, and from a recent version of JavaScript to an older version.

Popular transpilers are:

1. Babel: Babel is mainly used to convert ECMAScript 2015+ code into a backwards compatible version of JavaScript. However, it now has a lot of plugins to extend Babel for specific libraries, tools for things like linting, optimizations for browsers, and minification.
2. Bublé: Bublé is used to convert ECMAScript 2015+ code into a backwards compatible version of JavaScript. Bublé is heavily inspired by Babel, but limits itself to ES features that can be compiled to compact, performant ES5 (plus JSX), and it's comparatively tiny and much faster
3. Traceur: Traceur is used to convert ECMAScript 2015+ code into a backwards compatible version of JavaScript. Supports experimental features.
4. Typescript: TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
5. CoffeeScript: CoffeeScript is a little language that attempts to expose the good parts of JavaScript in a simple way. Transpiles into a version of JavaScript of your chosing.

Task Runners

Task runners are used to automatically perform frequent tasks such as minification, compilation, unit testing, and linting.

1. Grunt
2. Gulp

Photo by Vanessa Bucceri on Unsplash

---

Thank you for reading! Feel free to subscribe to my RSS feed, and share this article with others on social media. 💌

You can show your appreciation by buying me a coffee on ko-fi. 🙂

Comments

[Loralighte]

I have the index.html file in the main folder directory, I also have pages (if applicable or needed), _assets which contains my images, CSS, and if in use SASS containing folders (if using sass, I also include a sass.sh script so I can have a quick SASS compile (and in the SASS folder, a mobile and desktop folder). Back on the main folder, _client contains JavaScript code I need, and sometimes other things like Python and V lang.

[Rob OLeary]

[Sebastian Nitu]

I organize everything in a src folder that would container css, js, svg and any other directories of files that need to be "processed" in some way. All processed files go into the dist root directory.

My JavaScript, I write in ES6 and use rollup to transpile (babel plugin) and bundle the final format in a minified iife file.

As for styles, I use Sass and write in BEM methodology. That way each .scss file would be it's own component with maybe a single _global.scss file for just general styles. It's pretty rare that I'll need random general styles tho.

For task runners, I just use NPM scripts. I've been using Gulp for a few years but dropped it recently in favor of NPM cause I can just write most of my tasks using packages directly without the added layer of a task runner. So for example, my Sass script looks like this:

"styles:compile": "sass src/css/app.scss dist/styles.css --load-path node_modules",

Last thing I'll add is I take a slightly different approach if I'm writing a component I plan to reuse or include in my component library. That's when I use this concept:

Here's an example of that concept in my component library where I use Lerna to manage.