A YouTube watcher of my channel regarding my Basics of Require JS Part 1 writes:
… main.js is a concatenated and minified version of all the js. Just wondering why do you still need requirejs if you concatenate and minify your js in a single file [via r.js].
Is there an advantage of using requirejs in this instance? Or can you just straight target main.js?
I’ve seen 2 clients now who put all of their JavaScript into a single, large file vs. using classes, modules, and packages; traditional computer science concepts that Require does its best to enable in JavaScript.
There is a development build: load a bunch of js files, sometimes on the fly.
Development vs. Production Build (or deployment)
There is a production build: a single, minified, js file, up front.
Production allows me to have a small file with a single http request which can possibly lead to a faster app. However, it’s next to impossible to debug. If there is a problem, I cannot set a breakpoint in the code, nor identify what line, nor what file the issue is in.
In development, I can (sometimes) identify what file and on what line the issue is. I can also change the variables value at runtime to test things, see their current values, and run other console statements at runtime or while the code is paused to verify. Using Chrome you an even edit the code while it’s running to test. Finally, require allows loading classes on the fly. For some mobile apps where you don’t want to load everything at once, this leads to a faster app.
Concurrent Development With a Team (also called RAD or Rapid Application Development)
Development is actually a rabbit hole of reasons, though. For example, when you are working on a team who are all working on the same code base, I can be inside of the deviceEditView.js while another developer is handling all the data in the getAffiliateCDNService.js. When we go to check into source control, it’s highly unlikely we’ll have conflicts or have to merge because they are 2 separate files. As long as you communicate, this scales pretty well for larger applications and teams.
Relevant Encapsulation and Organization
Additionally, it’s easier to find code that’s relevant. If it’s one big-ole file, it’s harder to find the function or “area of functionality” you’re looking for whereas if it’s in a class, you know that that particular class is for a specific piece of functionality. This becomes even more relevant as your application gets larger and you start to utilize packages to organize “all of your services” and “all of your models” and “all of your models that just deal with user authentication and management”.
Unit Testing and Continuos Integration via Mocks/Fixtures
Yet another example is when you’re dealing with unit testing / mocking. It’s easier to mock a use of a class vs. a whole chunk of code in a large file. For example, if you’re trying to run some unit tests against parts of your application offline (check out Zombie JS), then you can write mocks or fixtures; basically mock services so your app “thinks” it’s hitting a Ruby on Rails back-end but in reality, it’s just making a function call to a class that returns fake data it needs after a timer of 3 seconds. You can then use require or some Dependency Injection framework to full fill those dependencies with Mocks vs. Reals. Without using classes, or separate files, it becomes challenging to do that.
Compensating for Pathetic/Non-existent Tooling
Also, the currently tooling in the market, namely Chrome, struggles to debug 13,000 lines of code or more. When they are in smaller class files of 300 lines or less, it”s more responsive. It’s also easier to tell a fellow developer “check line 102 of the DeviceItemRenderer” vs. “12,456”.