Summary

This article presents a small set of principles that I had forged for myself after entering the world of full-stack javascript development for videogames and virtual worlds projects. You will find a lot of disclaimers here because these principles are quite away from the mainstream practices of front-end developers, and also I am a lot biased by my commitment to Free Software philosophy. So, just read this as a curiosity rather than a manifesto or a claim that this should be a standardized approach or the right solution.

Disclaimer # 1: this is my personal opinion. It doesn't reflect the opinion of the companies I had or I am working for.

Disclaimer # 2: Most of these principles doesn't make sense for situations where the ratio between the number of developers and the number of active projects is greater than one. I had been involved most of the time in the opposite situation: a single developer by project or even worse, a single developer with more than one project under active development. If you are in the first scenario, lucky boy, just stick religiously to the development guidelines and good practices documented by your company (they have documented that, right?). But if you are in the solo arena (indie, freelancer, start-up?) perhaps you will find one or two principles of value for you.     

The principles

1. The OS is the IDE.
2. Stay away from the "new thing" fever
3. Reuse with libraries, not with frameworks.
4. Shell is your friend. Automate your art pipeline.

The OS is the IDE

An IDE is a program that consumes all your RAM trying to convince you that you can't develop without it. Fancy features, that 90% of the times are just wrapping calls to very simple command line instructions and tools already available in your OS. Things like syntax highlighting, advanced search features, monitoring of file changes, integration with git, are easily achievable with good old command line tools and lightweight programs. I worked many years with a long list of bulk IDEs, like Visual Studio, JBuilder, Eclipse, but you know what? you finally discover that the little checkbox hidden in some hard to find popup dialog was just adding a parameter to a command line call that you can assemble by yourself and run from a makefile or shell script. the UI of the IDEs changes over the time, but the underlying commands are the same. A bad side effect to get used to IDEs is for young developers that don't realize what is happening under the belt. I encourage you to learn what commands are part of your toolchain.  I finally decanted by VIM and a couple of terminal windows. and it just rocks. it doesn't matter if I am working in C++, javascript or python.

and yeah, by OS I mean Linux.

Stay away from the "new thing" fever

When I moved for C++ and Java to javascript I was completely astonished. I was used to JEE for backend development, and the complexity of its architecture always seemed to me too bloated. When I learn how you can create fullstack applications with the humble javascript, the language got my heart, but not before a long process or negation where I did my best to use tools to make javascript look like java (typescript transpilers? class-library wrappers?). Then I learned the fundamentals (prototypical inheritance, mixing and module patterns) and it just flow.

Soon, raising in javascript popularity also attracted people who considered that if we really were to do serious stuff in javascript, we should do it with serious frameworks. It was just like all Java Enterprise developers were trying to replicate JEE in Javascript. for me, that killed the main appeal of the language: simplicity.

Today, Javascript landscape is a savage land, where every month a new tool or framework replace the previous one, transforming one year apps suddenly in legacy projects (understanding legacy project as a project written in a technology for which is hard to find skilled developers. if you jumped three years ago in the angular.js movement, and wrote your project with angular 1.3, I wish you good look finding developers that feel comfortable with that, because Angular 2.0 one year later completely overwrite the framework, forcing you to rewrite your whole codebase. And the race is far away from stop... need a task manager? use Grunt. eh, wait.. that is too 2015. use Gulp. sorry. too 2016. Use Webpack.. some day I discover that people was using npm to launch shell scripts, and later I recognized that I can do all my task manager tasks with a tool that had been always there: 

Make.

yes, I use makefiles and shell scripts.  

Reuse with libraries, not with frameworks

Reusability is one of the golden goals of software development. "don't reinvent the wheel" is the mantra of framework supporters. I agree with that. But, know what? sometimes, when someone had created a popular framework the need to support more and more side cases transform a simple tool (a wheel) in something that looks more like an Autobot or a portal to another dimension. it barely maintains its round shape (yeah, thinking in angular.js again). At the end of the day, a framework is a highly-opinionated set of libraries that pretend to cover a lot of use cases. In order to keep reusable, the rules to configure and use it grows in length and complexity. You will discover yourself digging in stackoverflow to understand if a bug in your application is yours or comes from the framework. and don't even think in check the source code of the framework: it will be hundred of times more complex than your own code. say bye to productivity.    

Libraries, on the other hand, don't presume of you attaching to a single way to use them. libraries encapsulate functionality generic enough (think of Three.js, cannon.js, D3, Processing ) and you will have plenty of opportunities to mix them inside your project. usually easier to debug, inspect and learn from them. Libraries also offer you the adventage of replace them easily that when they came pre-bundled and tight-coupled to a framework.  

A final reason why frameworks tend to be complex: to avoid the label of "highly opinionated" they favored imperative configuration over "convention over configuration". the last one is ridiculously fast and productive if you work in internal projects, i.e when you are a framework user and not a framework developer. "convention over configuration" makes easier to roll your own scripts because you can make safe assumptions about the location of resources, output dirs, naming conventions and share them with your team.

disclaimer #3: large frameworks should be used for big projects, projects with long lifetimes and high rotation of developers. see disclaimer #2

Shell is your friend. Automate your art pipeline

A particularity of videogame naming conventions and standars of the art assets in order to be properly integrated into the project. Dev teams tend to produce large documents of technical specifications for the artists, who generally are not fond of study them in detail..  Playing with the saying of "a picture worst most than one hundred words" I would say that "a script worst most than one hundred words". Instead of writing spec documents, write scripts that actively validate the application of the specs automatically each time the artist submit a new asset.

That is easier that it sounds, if you start with the right mindset and choose the right tools. Opensource projects like Blender, Gimp and Inskcape (the tools I use in my projects) offer you mechanisms to run scripts directly inside the tools, and even better, you can run the tools in command line mode (headless) and that means that you can integrate the exporting of the asset in your toolchain. Mix that with git and continous integration techniques and you will never worry again about that artist that thinks that including emoticons in the name of hers assets is cute.

Note: An example of the headless scenario that I use is to execute from Make a Blender instance that opens a 3d model (.blend file), exports it using a custom python script, and store the output as json for reading in the assets folder of my web project. I expect to write another entry with details on that technique.

Conclusions

The cool thing about videogame programing in javascript is the flexibility and availability of tools and approaches that you can use. Keep it simple, and give yourself the opportunity to learn some "low level" tricks. Linux is plenty of resources and, even in the times of Unity3D-like IDEs,  the shell becomes an fun and productive environment once you get used to.