How to easily modularize Javascript like C/C++ - javascript

I have a large project entirely built in JavaScript, I have an ordered and "inside modularized" 5k lines .js file that's the engine of whole site.
Now I have to make other site (extension of this one) in which I'll have to repeat a lot of code, my question is, I've seen lot of possibilities using Browserify, CommonJS, etc. But that's not what I'm searching, I'm searching modularize JavaScript just like C/C++, making #includes with the files of the functions or functionalities and reuse code like that. I'm already doing this including other JS files in HTML, but that JS files are only variables and some arrays, not functionality of the site.
I use jQuery too, in that large 5k lines .js file I have almost all inside the jQuery document.ready event, that's bringing trouble too, because I'll have to make a document.ready event for every file?
I need some orientation please

CommonJS will let you require() modules, this is the foundation for the NodeJS module system. Browserify simplifies this implementation for use in browsers and even allows you to require Node modules (as long as they don't depend on binaries, the file system and other features a browser doesn't support).
var lib = require('someLibrary');
ECMAScript6 (aka: ES6) brings imports to javascript. While browsers don't fully support ES6 yet, you can use Babel to "transpile" ES6 to ES5. This ES5 will take advantage of CommonJS to replicate the importing behaviour.
import { SomeClass, someFunction, someValue } from 'some/library';
In all cases, your javascript will require some kind of pre-processing to transpile it into javscript a browser can understand. This usually means taking all your separate source files and bundling them into a single minified bundle file. This reduces the number of requests the browser has to make.
To handle all this transpiling and bundling, several popular build systems exist including Grunt, Gulp and Webpack. Grunt is older and typically slower because of it's configuration-based design. Gulp is simpler and faster because it relies on NodeJS streams. Webpack is the newest and most powerful, but at the cost of complexity. For what you're hoping to do, I'd recommend looking at Webpack since it can modularize not only your javascript but your stylesheets and other web assets.
http://webpack.github.io/docs/tutorials/getting-started/

Use webpack to bundle your code http://webpack.github.io/docs/tutorials/getting-started/

Related

ParcelJS module loading vs Webpack

I am trying to deepen my understanding of modules in JavaScript beyond just using CommonJS, AMD and ES Modules.
This has lead to me look more into webpack to understand how it actually makes modules work in the browser without relying on the still relatively new ES Modules. From what I understand, Webpack bundles the JS, converting import and require statements to its own statements and ships it with a runtime and manifest which allows it to execute them. So Webpack has gotten past the lack of module support by basically implementing its own?
I have tried to compare this to a different bundler — Parcel, but I can’t seem to find any information about how it handles modules.
Does anyone know if my understanding of Webpack is correct, and how that compares to how Parcel does it?
Appreciate any help in advance.
Thanks
The implementation of the ES6 import/export syntax has rendered many traditional module loaders such as RequireJS / AMD and rollup somewhat obsolete. However, asset bundlers like Webpack and Parcel still find their place in modern web development.
An assets bundler packs multiple files into a smaller set of files (including JS, images, fonts, LESS, SCSS etc.), thereby reducing the number of requests to the server and communication overhead. The bundling process typically involves script minification, dead code removal and dependencies management. This also allows more modular front-end web development.
In some ways, Parcel, being newer, is more advanced than Webpack. Parcel supports many different languages and file types out of the box, from web technologies like HTML, CSS, and JavaScript, to lower level languages like Rust, and anything that compiles to WebAssembly (WASM), to assets like images, fonts, videos, and more. You can build multiple targets at once and live-update them as you make changes. Parcel compiles all of your files in isolation in parallel inside workers, caching all of them as it goes along. No explicit configuration is needed for code splitting using dynamic import() statements.
Both Webpack and Parcel provide you a development server to test your project on a browser. Unlike Webpack, the entry point of Parcel is an HTML file instead of a JS file. You should not declare type=”module” within the < script> tags.
Another asset bundler is Browserify. It is a simpler tool which merely bundles your files. It is not as rich in features as Webpack and Parcel.

Can I build a production JavaScript web application without a bundler?

I've recently gone down the rabbit hole of learning about modular programming with JavaScript, including some history of JS module systems, bundlers and ES2015 Modules. I now understand some of the pains that bundlers help/ed alleviate, such as:
network latency (more effective caching of a single bundle, HTTP/1.0 connections),
performance constraints on the size of application modules (minification, tree-shaking),
ES2015 not supporting some features (bare imports),
and backwards compatibility with older module systems (transpilation of ES2015 Modules syntax).
However I'd like to know if it is possible to create a production JS web application in 2020 that doesn't use a bundler like webpack or Parcel and uses ES2015 Modules? A caveat being that a source-to-source compiler like Babel could still be used provided it preserves ES2015 Modules syntax. I'm not saying I would like to do this but for the sake of argument, what would be the downsides?
Client-side code does not have to be bundled when run in a modern browser, but if you're going to design your code into tons of small modules (for the sake of development efficiency and reuse), then it will be very inefficient to load if you don't use a bundler that can reduce the number of separate files that need to be loaded.
A bundler will be desirable if you design your client JS files for best modular development and thus don't design your client JS files for efficient delivery as the bundler can bundle things together for efficient delivery in a build process.
"Part of the JS SDK" is a matter of terminology and opinion, not facts so I won't really comment on that assertion.
It is certainly possible to design client-side JS files from the beginning for efficient client-side delivery and not use a bundler (like we used to do), but you will not be able to also design the layout of the files for modular development. A bundler allows you achieve both goals which is probably why they are so popular.
However I'd like to know if it is possible to create a production JS web application in 2020 that doesn't use a bundler like webpack or Parcel and uses ES2015 Modules?
Yes, it's possible without a bundler if you run in a browser that supports import and export.
I'm not saying I would like to do this but for the sake of argument, what would be the downsides?
As explained above, you would either give up efficient client-side loading or you would give up ideal modular design as the two have conflicting design parameters.

Modularity in Javascript

I know that if there are multiple JS files to be rendered by the browser, which apparently have identifiers inside, the global scope is polluted by this identifiers. I also know that one way to avoid this is using modules which(in my understanding) are just objects which have the aformentioned identifiers as members, thus sort of imitating C++ namespaces. I am also learning Node.js and there is a built in module system which eases this task so my question is: how to use modules in js files that are sent to the browser to be rendered?
Thanks.
Tools like browserify and WebPack are exactly what you are looking for (I personally prefer browserify over WebPack). Have a look at this answer, it explains a lot of your concerns.
In Node.JS, you can export a module using module.exports keyword, but you cannot just import those modules in your browser by just requiring them in a <script> tag. That's because, the browser doesn't understand the module system and everything works in the context of a global window object there, so module.exports simply becomes window.module.exports which I'm sure you'll not want. Hence you use tools like browserify that process the Node.JS scripts into something that your browser will understand.
This problem is usually solved by module bundlers or module loaders (e.g Webpack, Browserify, RequireJS). They are able to understand relations between your JS modules, skip unused modules and produce output that just works in your browser. All of that without the need to worry too much about global scope if you follow some conventions.
Some time ago, before ES6, two different approaches to this problem were widely used:
CommonJS:
var module = require('my-module');
widely known from Node.js
AMD:
define(['jquery'] , function ($) {
return function () {};
});
Which was suited for browser usage since it by design supported asynchronous loading of modules.
Then ES6 was introduced with native support for modules:
import * as lib from 'lib';
Main problem with new technology in web is that you often have variety of browsers to support which for a long time prevented developers from using new features. Nowadays, we have code transpilers and sophisticated code bundlers (e.g. Webpack). With their help you can use latest version of language, compile and bundle your code and at the end single "bundle.js" file is emitted which supports older browsers at the cost of slower execution times.

In ES6 will the module lead to multiple network calls as 2 modules cannot be defined in single file

In ES6 each module is defined in its own file.
Does that mean that we will have to do multiple network calls for each javascript module if we go the es6 way?
Is there anyway to concatenate the module files essentially create one minified javascript file for the app in es6?
We can transpile the es6 code to es5 and concatenate the same.
But, without transpiling to es5, does it mean that to use modules, we won't be able to concatenate and minify all javascript files into one?
Bundling is the way to go.
Modern web applications consist of many, often small, modules. Loading
those modules over HTTP impacts performance negatively, because a
separate request is needed for each. Therefore, bundling multiple
modules as a single file has a long tradition in the web development
world. Current approaches are complex and error-prone and only work
for JavaScript. Therefore, the W3C Technical Architecture Group is
working on a new approach: Arbitrarily nested directories are archived
as a single package file. Browsers access files in the package via a
new kind of URL:
url-for-package SEPARATOR path-inside-package
Source: http://www.2ality.com/2013/11/es6-modules-browsers.html

Ultimate JS module solution for UMD with dependencies?

I maintain and collaborate on some JavaScript modules written in CommonJS that are in need of high-quality UMD wrappers.
The dependencies are sourced from npm but have at least CommonJS and AMD support (or I can add it).
The CommonJS version goes on npm The UMD wrapped module will be pushed to bower
The wrapper must work in browsers (AMD + globals), and in Node.js (any and other CommonJS systems if possible). Any automation should preferably happen using Grunt (I'm pretty handy in grunt).
I've spend ages trawling Google en SO but it is a huge mess.
Some hopeful ones that don't quite cut it (or I am missing something, which is entirely possible):
browserify
gluejs
grunt-umd
I'm finding desperate constructs like this everywhere: http://rathercurio.us/building-umd-modules-with-dependencies-with-browserify , but I'm not really cool with such hackery.
Any good tips on this? I'll take any pointer or link or tip.
Edit: clarification: that last thing said, the ideal solution should not require us to assemble chunks of boilerplate template code by hand and create new bugs. I cool with configuring and specifying stuff though.
Your 1st and last stop should be urequire.org, the Universal Module Converter that does much more that just converting CommonJS and AMD javascript modules to UMD (or AMD or CommonJS or a standalone using rjs/almond).
It allows you to manipulate Module's code and dependencies while converting: inject, replace or remove code and dependencies, export to global objects (window) or your bundle, inject & optionally merge common code (like initializations), add runtime information, minify and much much more.
Most of that using simple but hugely powerful declarations & optionally callbacks for fine grained manipulation. It works with standalone config files (.js, .coffee, .json, .yml etc) and as-is as a gruntjs config
uRequire compiles from source modules written in javascript, coffeescript, livescriped, coco & icedcoffeescript without any plugins.
Forget boilerplate, code ceremony and repeating requires. The conversion templates are based on the well known UMDjs but can be customized via declarations to hide or provide functionality.
uRequire is opensource, MIT license and hosted on github and authored by me :-)

Categories

Resources