12

I've recently been shown some JavaScript plugins written for OBIEE Mobile App Developer, as well as some custom libraries for various projects.

Coming from an OOP background, I am a little confused about the structure of these projects. I am seeing files that are thousands of lines long. I am used to splitting things into files and classes but I understand that this is a different framework - for one, file size is an issue - but there must be a better way to do it all?

The length of the scripts affects not only readibility and maintanability but also a person's general understanding of how the program works.

How are large applications structured? Any general OOP design patterns for this?

turnip
  • 1,657
  • 2
  • 15
  • 21
  • related (possibly a duplicate): [Are there any OO-principles that are practically applicable for Javascript?](http://programmers.stackexchange.com/questions/180585/are-there-any-oo-principles-that-are-practically-applicable-for-javascript) – gnat Jul 13 '16 at 10:25
  • To reduce file sizes in production you can use tools for files minification and unification. But all the other can be same to OOP you are regular to use. I am using javascript for 12 years and always try to stick to OOP it makes your life a little bit easier. Read about grunt and gulp they can help you. – genichm Jul 13 '16 at 10:41
  • Agreed. You can still split your project into small modules however you like. Then use something like Gulp/Grunt/Webpack to concat and minify files into one or a few files for the client. – neilsimp1 Jul 13 '16 at 13:12
  • 3
    Yes, there is a general OOP design pattern. It's called Typescript. Or ES6, if you prefer. Typescript and ES6 are specifically designed to cater to large Javascript programs. – Robert Harvey Jul 15 '16 at 15:12
  • 1
    This video by NCZ is very relevant: https://youtu.be/b5pFv9NB9fs you can look for the mediator, component, and module-loading patterns he talks about in many major frameworks – TehShrike Jul 15 '16 at 20:00

6 Answers6

8

If you are not familiar with JavaScript patterns, I can tell you a lot of large applications and libraries are using Revealing Module Pattern, but there are many other patterns you can use depending to your needs.

The Revealing Module Pattern though should give you a nice way to split large files and logically organise them; However when you are working with any design patterns in JavaScript, be aware that this can become very confusing. Try to use this, new, prototype, .call() and .apply() wisely.

While working on large projects, these can be useful also:

  • If possible, switch to TypeScript or ES6.
  • Write Modular code. There are various ways and third-party libraries, but any of them is better than nothing.
  • Use a Task Runner/Build System to automate tasks.
  • Read about Design Patterns. This could be a good start. As I said above, the Revealing Module Pattern is very useful, specially if you think you need time to master all the popular patterns.
  • Write Unit Tests. Working with a dynamic language can be more challenging. Testing the crucial parts of your application can save a lot of time.
  • Use an IDE or Text Editor that can actually help you with both writing code and catching bugs. WebStorm is a good choice. Sublime Text too.
  • If your IDE doesn't offer a debugger, try to master your favorite web browser's debugger.
  • Use libraries. Depending on the nature of project, try to employ the best third-party code you can find. If you are writing a web application, have a look at Angular, React and the good-old backbone.js. If you are writing a Node.js application, then take your time to search in NPM repository. You will be surprised how many packeges are already doing what you were just about to do.
  • Even if you are the only person who's working on the project, still use a version control system like Git and follow a Coding Standard that is not too strict and opinionated but still provides a good guide line that your team-mates would be also happy to follow.
  • Even if you opt for TypeScript or ES6, still understanding JavaScript's class-less OOP, the Prototypal OOP can be useful, specially while debuging.
53777A
  • 1,706
  • 13
  • 18
1

I am a C++ developer and have begun doing web development lately. I am porting a large desktop app to the web environment. I structure my JavaScript code exactly like I structured C++ code, using same patterns. I have about 25-30 files in all but I will eventually reduce them to 3-5 by clubbing as appropriate and minify them all.

For me, it is just the language that has changed, for better or for worse, but not the paradigm. JavaScript, for all its faults and frustrations, is a nice blend of functional and OOP style. Things have worked well so far.

Lastly, one thing that I realized early on was that JavaScript allows to write a lot more concise code than C++, so sometimes having large number of LOC coming from non JS language could be due to sticking to old way of doing things. Once this thing is addressed, I don't see anything that should really be different. Design and algorithms are after all language agnostic.

vin
  • 374
  • 1
  • 12
0

It varies widely from project to project, of course, but the generally accepted practice is that, for things that are meant to function as libraries or modules, to put them into a single large file and use encapsulation to prevent its internal ("private") interface from leaking to the outside. It is also helpful for developers wishing to use the library/module - one file to add to the application config or header snippet instead of a whole hierarchy of folders and files to copy and paste. It also reflects the fact that, with minimization and bundling, in a production site it would most likely all be combined into one file to reduce the number of HTTP requests.

Your own application code doesn't need to follow this practice, and it probably shouldn't. Since your app is the only one using it, you only have to add the files once and can probably count on the platform to handle minimization and bundling for you.

Frank Wolfmann
  • 9
  • 1
0

When working on the code, the different components are typically split up into modules, each one typically implementing a single class, and each one living in a separate file. During production, these files are then bundled together into a single file (hence the thousands of lines of code you're seeing) using something like Browserify (http://browserify.org/) or RequireJS to reduce the number of HTTP requests, but also to ensure that dependencies are loaded in the correct order

As far as how the classes for these modules are implemented, it's a little bit different from OOP in the underlying mechanics, but not that different on the surface. ES6 even introduced the class keyword, so it should look pretty familiar. This article on MDN is useful to start: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

vladvlad
  • 9
  • 1
0

I use (Petri’s) Net Elements and Annotations to organize or “to structure” software for my PDF form applications – JavaScript programs that use the Acrobat/JavaScript API. Perhaps it may be useful in your situation.

A diagram is used to establish the input-output relations of net elements and two form views of the annotations. Based on the diagram and form views it is possible to systematically create JavaScript programs for PDF form applications. Thus “reading” the source code is reduced to verifying that it matches the specifications: the diagram and two form views.

The implementation of my software uses constructors and prototypes. If performance becomes an issue then replacing prototypes with instance members may improve the performance at the expense of more memory use. Arrays are also used. If performance becomes an issue then direct references are used.

Some of the properties are created using eval; for objects with very many properties this would reduce the amount of code in the source file – and reduce the amount of typing by the programmer.

John Frederick Chionglo
  • 9
  • 1
0

It's still possible and recommended to write JavaScript in the OOP way that you are used to. Here is a good book that has goes through the most important design patterns in JavaScript.

https://addyosmani.com/resources/essentialjsdesignpatterns/book/

There are many JavaScript frameworks out there too where the main goal is to be able to split the code out into different files and modules. If the particular framework you're working in requires you to have all your code in one file then you should definitely look to switch.

user2802557
  • 153
  • 2