Sign in to follow this  

General question: how to keep JavaScript organized

This topic is 1105 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a question that is both game-related and useful for other web-based projects (though in the examples I below try to keep it focused on games).  To put it simply, what are the best strategies for keeping JavaScript organized?

 

Let me clarify: in most of the languages I know (C#, Java, PHP, AutoHotkey, even my limited knowledge of C++) we have classes.  And while I know not everyone is a big fan of object-oriented programming, I personally find it makes things a heck of a lot easier to understand and maintain.  Each class is usually in a separate file, and once created it's easy to use them (i.e. Player.SwingSword(), Wizard.TeleportTo(x,y), etc.). You know which objects are doing what, and you can use the same class in different games.  Even the HTML DOM seems to fall into this category (it is the document "object" model, after all).

 

But JavaScript is totally different.  You can do it in an object-oriented way, but those objects come in the form of functions.  It also has some great event handlers (even touch event handlers for mobile devices), but those also look like functions.  And you can also just create functions independent of any kind of object or event.  So with all these functions floating around, things seem to get confusing fast.  Regardless of whether I'm using OOP or not, creating a game or not, my scripts always end up with a long list of functions that just keeps growing and growing.There's got to be a better way.

 

So what do you guys do to help keep your JavaScript in order?  And please, don't even go there with things like JQuery, Node.js, Ajax and other libraries/APIs.  I have no problem reading up on APIs in class-based languages, but before I can even touch that in JavaScript I've got to get a handle on managing my own code.  Before yesterday (when I was assigned a JavaScript project at work) I didn't even like to use JavaScript at all for this same reason.  I get that it can do amazing things with the web, and I'd like to learn to use it better, but at this point I'm just not there yet.  If I can get this figured out, then I'll be able to move forward into the deeper stuff, but for now I'm just trying to get the hang of ordinary JavaScript.

Share this post


Link to post
Share on other sites

Use a module system.

 

Javascript is already OOP, everything is an object (strings, arrays, numbers, functions). Javascript also has classes, with inheritance and all that jazz, the inheritance is based on prototypes however and is not so called 'classical' inheritance. It is, however, more or less the same thing. (ES6 is even bringing the reserved keyword class into use). You are completely wrong, JavaScript is not 'totally' different. If you want a language that is, go learn something like Lisp or Haskell to see what 'totally different' actually looks like.

 

There are plenty of module libraries to make things simple (requirejs, commonjs etc), or you can write modules on your own without a library wrapper. (research the module pattern).

 

OOP languages have never been very organized, this is a myth - there is absolutely nothing stopping you from writing sphagetti code in one (nested classes, static functions, function/method sphaghetti). They do, however, tend to have really nice embedded module systems (usually called packages).

 

I personally love the ability to stick all the code in one file. I just re-factor it out every so often, whichever language I'm using (if your language can't do that, its probably junk). Usually my max is 1k lines of code, for more compact languages its 100 lines.

 

The reason you hate JS for being unorganized is probably because you've only ever seen JS written by people who didn't know JavaScript (reading poorly written C++, Java, or PHP is pretty painful as well), or you've seen some compiled JS which is intentionally horrible to read. Libraries like jQuery that use module systems are pretty well organized.

Edited by bassy

Share this post


Link to post
Share on other sites

Hi bassy,

 

You make some very interesting points.  I've never heard of JavaScript "modules" but I looked them up.  Turns out it can be used in ways that are a lot more similar to the other languages I know.  In particular this link:

 

http://briancray.com/posts/javascript-module-pattern

 

This person set up a bit of JavaScript that may as well be a class, in a way that was much cleaner and more straightforward than my usual "function spaghetti" (btw that was awesome lol).  I will definitely continue to research this.  I'm not sure what a "function expression" is yet, and I never did really get the whole "prototype" thing either, but this is a huge step in the right direction.

 

By the way, fyi I don't *hate* JavaScript, I just don't fully understand it (which makes it harder than usual).  You're right: technically, it's not "totally" different; but it's different enough that some of the concepts don't make sense to me, which makes it a pain to use.  You were also right that all I've seen is lousy examples from tutorial sites and intentionally messed-up source code (no whitespace so less to load).  In fact, speaking of which, do you know of some good sites to learn it?

 

But anyway, thanks for the pointer.  I think this was the answer I was looking for.

Share this post


Link to post
Share on other sites


This person set up a bit of JavaScript that may as well be a class

 

It is not 'may as well be' - you need to change the way you think. It IS a class, just packaged differently. Remember, a class is nothing more than some bundled properties with attached methods that you can clone around places. The syntax you are used to is technically termed 'syntactical sugar' - i.e. it is a particular way of saying something.

 

As for sites, stop using the internet to learn JS. Go find a book or a course - you'll learn more, faster. After you've done that, there are plenty of good references online, e.g. MDN.

Share this post


Link to post
Share on other sites

Re the above comments, I've identified three distinct meanings for the word "class." The one used above is the OOP class, which is a software module (commonly a file) that contains constructor code, property definitions, method code and so on. This is called a "class" in OOP languages like C++ and its progeny (such as Java). Many languages follow this model. For examples, Basic, Fortran and Cobol in their more recent versions.

 

A "class" is also a set of objects that have many or all properties in common (think Professor Boring's Comp Sci class). In software this is usually the set of objects descended from a single constructor.

 

See my _JavaScript Inheritance and Object Programming_ if you really need the third definition. It's the sort of thing one puts in a book for completeness.

 

When you write JavaScript you can organize your object definitions in OOP-style classes, but these are ususally short enough so that one-per-file becomes a nuisance. I myself look for 500 to 1000 line files and group object definition code accordingly. I also am a big fan of the classic (Fortran, 1957!) library pattern. I usually put all my library funcs in a single file. In can grow quite large put interdependencies are minimal.

 

But let me discourage you from writing JavaScript in a class-oriented, OOP way. Almost all my work is done by objects, but many of them are created _ex nihilo_ (literall, "from nothing") as JS object literals. I also use "capabilities" that cross multiple objects. See the "mixin" pattern for the more common way of doing the same thing.

 

Google me (or Amazon me) if you want to discuss this further.

Share this post


Link to post
Share on other sites

To clarify what MartinRinehart is trying to say when he makes this nonsensical sentence:

 

 


But let me discourage you from writing JavaScript in a class-oriented, OOP way. Almost all my work is done by objects

 

(nonsensical as it clearly contradicts itself)

 

Don't let idioms from previous languages rule your current language, i.e. you are better off not trying to Java-style create a class for everything that needs to run a 'capability' or more commonly known as a 'function'. The module pattern provides you with the flexibility to utilize 'mixin' and hierarchical inheritance on your prototype chains.

 

More specifically, there is no reason not to create a Person, and a Ninja, and a Baker, but there is no need for nonsense such as a StatsProvider and then ninja.setStatsProvider(someSubclassOfStatsProvider) when you can just ninja.getStats = function() {}

Edited by bassy

Share this post


Link to post
Share on other sites

With all due respect, bassy, if you took the trouble to read my book you would understand that there is no contradiction. And 'capabilities', as I use them, are not just functions.

 

In JS you can (and I think most well-written JS frequently does) create an object with an object literal: var person = { name: 'Martin Rinehart', sex: 'M', ... };

 

This is an object not created from a class software module. You use an OOP-style class software module when you wish to create lots of Person objects (a class of objects, 2nd definition). Then it becomes var person = new Person('Martin Rinehart', 'M', ... );

 

A 'capability' is something than an object can do.

 

In my windowing system example, many on-screen objects share the Movable capability (ability to be dragged by their title bars). The Movable capability adds the title bar, adds listeners for mouse down/move/up, and so on. It includes quite a few functions and additional properties. Called by my 'implements' method you make something a Movable screen object by: screen_object.implements( Movable, "Title Bar String" );

 

As with all good object software, all the details are encapsulated. Unlike OOP there is no software module that looks like a C++ or Java 'class'.

 

In Java, for example, you would get this result by defining an interface (in a class module) and implementing the interface in another class module that extended some base on-screen object class. In C++ you could create two base classes modules, one for being on-screen (a DOM cover) and another for being Movable. A third class could use multiple inheritance to create the desired Movable screen object. But those designs are really workarounds for the weakness of the OOP model: you cannot modify objects at run time, except to modify their properties' values.

 

In JavaScript the Movable capability (or any mixin) simply attaches additional properties as needed at run time and gives those properties appropriate values (where 'property' may be either data or code). JavaScript is so much richer it its power to manipulate objects that one can do most of one's work with objects, but without OOP-like classes. I'm surprised you haven't read Crockford's _Good Parts_. He entirely rejects the JS 'new' operator and never uses OOP classes for his object work.

Share this post


Link to post
Share on other sites
If you search for "right way to learn JavaScript", there's a lot of decent advice on how not to fall into the abundant traps that exist due to the immense about of bad JS that exists out there.

BTW, js's particular flavour of OO is the prototype paradigm -
http://en.m.wikipedia.org/wiki/Prototype-based_programming

Lastly, the kind of inheritance that C++/Java are renowned for shouldn't actually be very common in good C++ code. This over-use of inheritance is a remnant of the 90's when OOP was a new fad that everyone dived into without actually groking, resulting in lots of bad code, and then lots of people learning from that bad code... Much like JS :)
Writing C++ using composition over inheritance and lots of std::function instead of virtual would be a great eye opener if you're a C++ coder that wants to gain new perspectives on OOP.
Learning JS (properly) will be similarly eye opening.

Share this post


Link to post
Share on other sites

JavaScript is usually bound to HTML documents. Much like in C++ where you #include your headers, in HTML you <script> them. The browser reads the file top-down (again, much like C++).

 

It is a very bad idea to make the browser download a lot of files, so you usually bundle  and minify your JavaScript.

 

It is very rare to split your code like in Java where every class gets its own file. When you write a bit more complex code, you usually wrap it inside anonymous function which you immediately execute to avoid naming conflicts. Assigning the result of the function is kind of.. weird. You usually strive to put code together, you would only do that if you wanted to expose something as public API - and this is rare in JavaScript (unless you were writing a library).

 

If you really wanted the module systems where JS files themselves include other JS, you would use RequireJS. I haven't looked into their code, but the idea is trivial: you dynamically append a <script> into your <head> and wait until the browser downloads and parses the file (much like you would add an <img>). RequireJS is relatively popular, has tools to optimize your JS (understand: minify and bundle), and you are likely to find answers to your questions at StackOverflow, and also has surprisingly good documentation. 

 

You didn't say what your project is. Is it browser-based (then just include the <script>-s in the appropriate order), or is it embedded (node, chromium)? How you make script files reference each other depends on how JS is hosted. In any case, since everything in JS is an object, the so described "modules" are just functions where you expose public API by adding it to this (e.g. this.killGoblins = function() {..}), or, if you really needed classes, using the prototype syntax (var goblin = function() {}; goblin.prototype = { object literal };). In most cases, you don't really need classes, you use duck typing. In JS, you've got a lot of free functions just because you don't really need classes and objects most of the time.

 

How I organize my code depends very much on what I'm doing. Is it a web site? Then follow whatever the framework I'm using dictates. Is it a game? If I can do it in a single file, I would. If the code is bigger, then depend on the <script> order in my JS files (usually located in /js or similar). It may sound horrible to you, but I try to do the simples possible thing first. Plus, in JS, you rarely have to have explicit types.

 

If you want your code to be more organized and be closer to what you are used to from strongly-typed languages, take a look at TypeScript. I has modules, supports including (and then bundling) multiple files, etc.

Share this post


Link to post
Share on other sites

Very good, multi-lingual post, Hodgman. It looks like you've been doing this a while.

 

I use the term "object programming" the same way you use "object-oriented." To me, the latter signifies Stroustrup's simplification of object programming: all the SmallTalk he could fit into a C precompiler. It's not really programming with objects, but it's "oriented" toward using objects. An object programmer likes to create and manipulate an object's properties at run time. An object-oriented programmer is content just to change the properties' values.

 

Your usage is more common, of course.

Share this post


Link to post
Share on other sites
&amp;nbsp;

With all due respect, bassy, if you took the trouble to read my book you would understand that there is no contradiction. And 'capabilities', as I use them, are not just functions.

No, there is, you have written a book and so you feel entitled to your own definitions and views of things. No, I'm NOT going to buy your book, I don't think much of it at all. Sorry, no disrespect meant.

OOP is strictly a certain way of programming, i.e. the canonical definition:

'OOP is a programming language model organized around objects rather than "actions" and data rather than logic.'

However this definition is widely muddled by so called 'OOP languages' that use this as one of their marketing/selling points.

The fact of the matter is, Javascript is organized around objects, and data. You have the freedom to write everything in a purely functional manner with state logic tables, but hardly anyone actually does that. It IS OOP, you are contradicting yourself.

Now, I sincerely suggest, instead of trying to sell your book in here, if you have more to say on OOP or your personal opinions you PM me instead or find another forum of discussion, this is not helping the OP in any way.

Share this post


Link to post
Share on other sites

This topic is 1105 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this