Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

While Multiple Files Using RequireJS vs. 1 Big One

DZone's Guide to

While Multiple Files Using RequireJS vs. 1 Big One

· Performance Zone
Free Resource

Download our Introduction to API Performance Testing and learn why testing your API is just as important as testing your website, and how to start today.

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″.



Find scaling and performance issues before your customers do with our Introduction to High-Capacity Load Testing guide.

Topics:

Published at DZone with permission of Jesse Warden, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}