Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
This sounds really stupid to me, but I don't really have an answer for this.
What's the point of using ES6 modules or CommonJS (in browsers using browserifiy), if you can just connect multiple js files to the html via the script tag so they act as modules (sharing the same scope)?
In decent sized web applications, you have to take in count that more than one developer is working on the project, so separation of concerns is one of the key elements to develop a maintainable application, lets pains the next fake scenario:
You have a file within your web application called library.js.
ES2015 module syntax
export function calculatesquareArea(object) {
// code that calculates area
}
export function calculateVolume(object){
// code that calculates volume
}
And now we import this module into our code by doing something like this:
import { calculatesquareArea } from 'library'
// We log the output of the execution of calculatesquareArea
console.log( calculateSquareArea(object))
You can notice right away that in my module I have 2 functions but I've decided to only import one because at that time I've only needed to use that. Maybe this is a silly example but you can picture code reuse with the modularity nature of CommonJS or ES6 modules.
There is a more elaborate article on the key differences between CommonJS and ES2015 modules here
Hope this helped a little bit.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Currently, whenever I want to use a module in node.js standard library that is not part of the global objects e.g. readFileSync(), I require/import the module which that functionality belongs to, in this example, that's the fs module. A list of the global objects is here for reference: (https://nodejs.org/api/globals.html).
Is there a way to require/import all the node.js standard library, i.e. to have all of the node.js standard library available throughout my program?
No, you can't require all node modules at once. There are tens of thousands of possible modules, some built-into node.js and some available only if you install them into your project. In the interest of modularity, you import into each module the modules that you need inside that module. This is purposely done this way to make modules be modular so that they declare exactly what they need to import and only what they need to import.
This is a bit different way of thinking than some other environments, but once you get used to it, it works quite well and makes code reuse a lot cleaner and easier. The start of each module file should import that external modules that you need to use within that module.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
A coworker of mine recently setup testing in a new project (a JS library) where a transform step hooks in to the babel config for Webpack in the production config.
For reference, this is the setting used with Jest: https://jestjs.io/docs/en/configuration.html#transform-object-string-string
The production build targets ES5, while our CI is on Node 10 and up. This means that, for all of our tests, the source code is getting transformed by all the unnecessary Babel transforms. Mind you, our source code is regular ES2016 Javascript, nothing too fancy. The only transform required might be the ES6 import syntax.
My gut reaction was that this was quite wasteful and unnecessarily couples the tests to the production build config. But my coworker's justification was that he wants to make sure that the tests run against the same artifacts that users will be using.
That makes a lot of sense to me, but I am not sure what the right answer is. What are the pros and cons of each approach? What are the dangers of running your tests against the production build transforms?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
This is more of a question regarding the architecture of an application, let's say you have a module something.js with some kind of special configuration constants mind you that these constants are hardcoded they are not imported from env or some file.
Would it be better to put everything related to this module as a global constant or is it better to import all configuration constants from config.js for example.
I'm interested in knowing the pros and cons from an architecture point of view.
If it's something high-level or broad, like a debug option that turns on debug output across your app, I would be inclined to put it in a common config file. On the other hand, if it's something specific or narrowly scoped, like how many characters a particular piece of text can be before it's truncated, I would be inclined to keep it in the only file that references it.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I know a lot of people use the word "compile" quite loosely and interchangeably but I was hoping someone could explain to me like I'm 5 if it's technically incorrect to call a JS module bundler (eg. Webpack) a compiler or a build tool? I often hear things like "you have to compile your JS in order to update your bundle".
Thanks in advance.
It's definitely a build tool, and one which can be automated. One of the main use cases is to bundle various javascript sources into one or several bundle(s) of javascript, which is generally referred to as 'transpiling'. Transpiling basically means the output is the same language as the input, ie javascript in javascript out. Compiling is generally the act of turning source code into machine language, or IL. Webpack can of course also bundle other things, which is why on their own webpage they refer to it as a bundler.
In a colloquial sense, people often mean 'compile' to be the same as 'build', in the sense that you run your build tool.
Webpack it is a build tool.
Maybe you heard some like "some node package could not compiled for your OS" like
node-sass module. This module compliled from source code
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Note: By regular js I refer to the ES5 version of js.
I am currently setting up the foundation to a project. The tech stack that I currently have choosen to go with is Node.js for the back-end w/ Angular2 for the front-end/client-side and I am using Gulp as my build tool. In addition I have chosen to use Typescript for Angular.
I have already set up the gulpfile to do everything necessary for an optimal Typescript build. In fact the way I set everything up gulp can handle all the Typescript in the application, which led me to the realization it might be useful to write the whole application in Typescript vs regular (Node.js - Server) js. Although, when looking for pros and cons of doing so I have been unable to find any real references and instances where people recommend doing so or if it is better to just write the server side of the application without utilizing TS.
In short my question: Is it optimal to write the back and front end utilizing the Javascript superset Typescript? Are there any real Pros or Cons? I would appreciate any 'real' experiences. For example if there where any hurdles/workarounds that occurred or what made TS in server and client optimal in your case?
Thank you in advance, have a great day!
Is it optimal to write the back and front end utilizing the Javascript superset Typescript?
I would say yes : https://medium.com/#basarat/typescript-won-a4e0dfde4b08
But of course it is my opinion. The key choice is if you want statically analyzable code. It does help with tooling at the very least. More on why typescript https://basarat.gitbooks.io/typescript/content/docs/why-typescript.html.