Please tell me which option is better ?
Option 1: All these methods will be in Track module
getTrendingTracks
getMyFavoriteTracks
likeTrack
unlikeTrack
getMyPlayedTracks
playTrack
getArtistTracks
Option 2: These methods will be in separate modules
Track module
getTrendingTracks
Like module
getMyFavoriteTracks
likeTrack
unlikeTrack
ListeningHistory module
getMyPlayedTracks
playTrack
Artist module
getArtistTracks
It depends on the size and the future development of the application.
If the project is small and you don't expect to have a lot of new functionality option 1 is a good choice. It will keep all things close to one another and you will be able to find and modify them easily.
For projects with a lot of functionality and longer lifespans option 2 is better. This way you will be able to create smaller and more cohesive modules. These modules will depend on other modules, so you can create a module dependency map. This way you can manage the dependencies in your application better so you don't end up with spaghetti code.
When you want to add new functionality you will have to do one of several things:
Add a new module. This is the coolest thing in options 2. You just add a completely new thing to get new functionality.
Extend an already existing module. Having smaller modules makes this a lot easier.
Extend a small number of modules. Having smaller cohesive modules makes this a lot easier too
I highly recommend taking a look at Unreal Engine. It has a very good modular architecture. It has a huge codebase, so in order for it to be manageable, they split the Engine into modules. You can check it here
Related
I've written PWA application, application isn't big, but now my app.js has 800 lines of the code. It has many methods. How to move these methods to another files divided thematically?
require doesn't work
You have a few options depending on what browsers you support.
You may be able to use native support for modules. You can find more information about this in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules This would be one of the simpler solutions as it does not require any additional tooling but at this time the support outside chrome is not very good.
A second alternative is to break up your code into multiple JS files and just load them all separately. This can have performance implications but if your files are small and few it wont cause too many problems. Just ensure that the code produced in these files put themselves onto a name object to avoid conflicts.
Ex file
(function() {
window.mycode = {};
window.mycode.func = function() {...};
})();
A third option is to use an existing module loader in the browser such as https://requirejs.org/
The fourth option, which is probably the most common, is to integrate a build step into your code that uses npm and a module loader such as webpack or browserify. This also lets you integrate babel which is really common among large javascript projects. The downside is it adds a step to your deployment that needs to be run and you need to learn how to use tools like webpack(which is surprisingly complicated). However, if you do javascript dev you will need to be familiar with them eventually.
I really like the way NodeJS (and it's browser-side counterparts) handle modules:
var $ = require('jquery');
var config = require('./config.json');
module.exports = function(){};
module.exports = {...}
I am actually rather disappointed by the ES2015 'import' spec which is very similar to the majority of languages.
Out of curiosity, I decided to look for other languages which implement or even support a similar export/import style, but to no avail.
Perhaps I'm missing something, or more likely, my Google Foo isn't up to scratch, but it would be really interesting to see which other languages work in a similar way.
Has anyone come across similar systems?
Or maybe someone can even provide reasons that it isn't used all that often.
It is nearly impossible to properly compare these features. One can only compare their implementation in specific languages. I collected my experience mostly with the language Java and nodejs.
I observed these differences:
You can use require for more than just making other modules available to your module. For example, you can use it to parse a JSON file.
You can use require everywhere in your code, while import is only available at the top of a file.
require actually executes the required module (if it was not yet executed), while import has a more declarative nature. This might not be true for all languages, but it is a tendency.
require can load private dependencies from sub directories, while import often uses one global namespace for all the code. Again, this is also not true in general, but merely a tendency.
Responsibilities
As you can see, the require method has multiple responsibilities: declaring module dependencies and reading data. This is better separated with the import approach, since import is supposed to only handle module dependencies. I guess, what you like about being able to use the require method for reading JSON is, that it provides a really easy interface to the programmer. I agree that it is nice to have this kind of easy JSON reading interface, however there is no need to mix it with the module dependency mechanism. There can just be another method, for example readJson(). This would separate the concerns, so the require method would only be needed for declaring module dependencies.
Location in the Code
Now, that we only use require for module dependencies, it is a bad practice to use it anywhere else than at the top of your module. It just makes it hard to see the module dependencies when you use it everywhere in your code. This is why you can use the import statement only on top of your code.
I don't see the point where import creates a global variable. It merely creates a consistent identifier for each dependency, which is limited to the current file. As I said above, I recommend doing the same with the require method by using it only at the top of the file. It really helps to increase the readability of the code.
How it works
Executing code when loading a module can also be a problem, especially in big programs. You might run into a loop where one module transitively requires itself. This can be really hard to resolve. To my knowledge, nodejs handles this situation like so: When A requires B and B requires A and you start by requiring A, then:
the module system remembers that it currently loads A
it executes the code in A
it remembers that is currently loads B
it executes the code in B
it tries to load A, but A is already loading
A is not yet finished loading
it returns the half loaded A to B
B does not expect A to be half loaded
This might be a problem. Now, one can argue that cyclic dependencies should really be avoided and I agree with this. However, cyclic dependencies should only be avoided between separate components of a program. Classes in a component often have cyclic dependencies. Now, the module system can be used for both abstraction layers: Classes and Components. This might be an issue.
Next, the require approach often leads to singleton modules, which cannot be used multiple times in the same program, because they store global state. However, this is not really the fault of the system but the programmers fault how uses the system in the wrong way. Still, my observation is that the require approach misleads especially new programmers to do this.
Dependency Management
The dependency management that underlays the different approaches is indeed an interesting point. For example Java still misses a proper module system in the current version. Again, it is announced for the next version, but who knows whether this will ever become true. Currently, you can only get modules using OSGi, which is far from easy to use.
The dependency management underlaying nodejs is very powerful. However, it is also not perfect. For example non-private dependencies, which are dependencies that are exposed via the modules API, are always a problem. However, this is a common problem for dependency management so it is not limited to nodejs.
Conclusion
I guess both are not that bad, since each is used successfully. However, in my opinion, import has some objective advantages over require, like the separation of responsibilities. It follows that import can be restricted to the top of the code, which means there is only one place to search for module dependencies. Also, import might be a better fit for compiled languages, since these do not need to execute code to load code.
From a performance/maintenance point of view, is it better to write my custom modules with netsuite all as one big JS, or multiple segmented script files.
If you compare it with a server side javascript language, say - Node.js the most popular, every module is written into separate file.
I generally take the approach of Object oriented javascript and put each class in a separate file which helps to organise the code.
One of the approach you can take is in development keep separate files and finally merge all files using js minifier tool like Google closure compiler when you deploy your code for production usage which can give you best of both worlds, if you are really bothered about every nano/mini seconds of performance.
If you see SuiteScript 2.0 architecture, it encourages module architecture which is easier to manage as load only those modules that you need, and it is easier to maintain multiple code files i.e. one per module considering future enhancements, bug fixes and code reuse.
Performance can never be judge by the line count of your module. We generally maintain modules for maintaining the readability and simplicity of the code. It is a good practice to put all generic functionalities in to an Utility script and use it as a library across all the modules. Again it depends on your code logic and programming style. So if you want to create multiple segments of your js file for more readability I dont think its a bad idea.
I'm working on my 1st Node.js module, and having to do common utility stuff like check types, looping etc.
The native JS for some of this stuff is pretty ugly. Underscore.js makes it more readable and adds a lot of new features too. But if I don't need the new stuff, should I use Underscore or just do it the hard way?
Thanks!
In node.is you can rely on having some ES5 stuff, array iteration functions and utility functions like isArray. In my node modules I never used underscore and had, due to array iteration functions like map, forEach never the need to use underscore or lodash.
I would not avoid a underscore dependency in case I'd really need it. The node.js platform relies on small modules depending on a couple of small modules itself. So why not depend on underscore.
I see no reason to avoid using a module that makes your life easier. And, it just so happens, that underscore.js is the most depended upon package in the npm registry (as of the time of this answer, according to https://npmjs.org/). So yea, no reason to avoid it.
I've never used underscore nor async on real projects. Once you know how to code good javascript it's not necessary to use any helper library. For example, functions that should execute in serie and are asynchronous it's pretty easy to do with a simple "recursive while loop", you don't need to load any library.
But at the end this is a personal preference. Use external libraries if you feel comfortable with them.
Advice: Don't look at the github starts or npm installations to decide which module to use. Being popular doesn't mean being good. I've tried a lot of popular modules and about a 40% of them are just bad/bugged/not really useful. There are a lot of modules that are not popular that are really good. Being popular helps to take a decision but you should not install and use a module just because it's popular.
Underscore does the right thing, which is check for all the native es5 methods first, meaning you won't have much in the way of performance loss on native methods getting replaced with slower non-native versions that basically do the same thing (code here):
var
nativeForEach = ArrayProto.forEach,
nativeMap = ArrayProto.map,
nativeReduce = ArrayProto.reduce,
nativeReduceRight = ArrayProto.reduceRight,
nativeFilter = ArrayProto.filter,
nativeEvery = ArrayProto.every,
nativeSome = ArrayProto.some,
nativeIndexOf = ArrayProto.indexOf,
nativeLastIndexOf = ArrayProto.lastIndexOf,
nativeIsArray = Array.isArray,
nativeKeys = Object.keys,
nativeBind = FuncProto.bind;
Note: prototypes assigned to "Proto" vars earlier.
That said, I'm pretty sure V8 has most if not all of these. Being of client-side dev origins I'd be delighted simply to use the raw naked thing without having to think about how or what library is best for dragging IE kicking and screaming out of the stone age this time, providing the built-in methods aren't as ugly as the DOM API and I would say these aren't.
If underscore does more for you than the above then by all means use it. If it doesn't, I'd consider it a waste of space. All it really does on the browser is give you fallback methods for the older browsers which aren't a going concern in Node. It's light though. I wouldn't object either way if you were on my team and didn't want to write your own versions of something uniquely handled by underscore but would prefer the direct native method names/args, etc. in my own code on the principle of disliking dependencies anywhere I don't need them.
I use underscore in modules that are shared with the browser, not to depend on ES5. Also Underscore has quite a few very useful methods that are not available in ES5, so it would make sense to read their manual page.
Often when beginning a new project, I start out with what I believe to be the best of intentions in terms of how to structure the codebase. I love the idea of numerous small modules that do one thing well, are de-coupled from other parts of the codebase, and could potentially be reused by myself in other (similar) projects or open sourced for others to take advantage of.
However, come crunch week when I'm actually trying to get something into production, there's been more than one occasion where the complexity of managing all these different modules has proved too much of an overhead (despite good documentation and deploy methodology). On those times I've simply changed tack and bundled all the modules into one repository and managed it all as one codebase, meaning I can track everything together through different branches, deploying to staging and test environments, etc...
What are the advantages and disadvantages of these different approaches, and how do you manage working in one way or the other?
Advantages of one monolithic codebase:
Easy to deploy
Easy to rollback
Easy to branch/manage all changes together
No (or less) potentially complex dependencies to document and manage
Advantages of modular dependencies:
Reusability
Clean architecture (one module does one thing well)
I do not see the opposites as much as you do. Taking a .NET experience as an example, I can ensure parts of my code are geared towards well-defined responsibilities, I can structure my codebase into namespaces, ensuring that the touching points of the namespaces are well defined and that classes within the same namespace really do belong together.
However, all this can happen within a single unit of deployment, single project, branch, what have you. If you stick to that, units of code that may become reusable in the context of the projects you do will crystallize and that would be the point where you may decide to introduce a new unit of code, with its own deployment artefact, source control branch, etc.
Here is a talk from Google explaining (a little bit) how they handle their gigantic monolithic code repository. And why they have one.
By the way, I don't think it has to be opposed to a well defined set of dependencies. I would even say that to handle a monolithic codebase, you have to be super careful with the dependency graph and the responsibilities. Because with this kind of organisation, it is easy to add a lot of more or less useful deps…