5 Myths About Javascript

1. JavaScript is ECMAScript.

ActionScript and JScript are other languages that implement the ECMAScript.  JavaScript was submitted to ECMA for standardization but due to trademark issues with the name Javascript the standard became called ECMAScript. Every browser has a JavaScript interpreter.

2. JavaScript just for the front end.

With the advent of nodejs and io.js (and others) this is no longer true. JavaScript can now be used to build full fledged RESTful and socket based API’s. Take a look at loopback.io and hapi.js for two (of many) API libraries.

3. JavaScript is simple.

There was a period of time that JavaScript was for front end DOM manipulation and that was about it. Over time the language has matured into a wonderful and powerful functional programming language that can emulate multiple types of inheritance paradigms.

4. JavaScript is not scalable

If this were the case we would not see companies like Google and Facebook spending so much time using it. These guys know scalable and almost everything you use on both of those sites rely on the fact that it is scalable, modular and extensible.

5. JavaScript is boring

No way! You can do so much with it that boring should never enter your mind. Even if you think you have mastered the language, if you explore a bit more you will find the weird stuff left over to maintain backwards compatibility. Check out wtfjs.com for more.




Out of Scope! Out of Time!


Dreams are great. Dream big, that’s what they always say. As a programmer you must retune this concept to dream within a reasonable scope. In this post I will go over my original concept for my second solo week project and then what actually ended up getting created.

Pre-Dream-Crush Wishlist

  1. Authenticate a User
    1. redirect based on user type
      1. if player show player dashboard
      2. if storyteller show storyteller dashboard
    2. allow many authentication methods
      1. github
      2. facebook
      3. username/password
  2. Create a Game Container
    1. Game state aware dashboards
      1. if game activated show game active dashboard
      2. if game is not activated show lobby style dashboard
  3. Integrated Chat
    1. allow for slash commands
      1. /init rolls initiative (based on character sheet)
        1. Show users profile picture in order on the side of the chatroom
      2. /roll <NUM> rolls the <NUM> of six sided dice
  4. Character Management
    1. Rules based character creation
    2. Import of xml files with weapon info
    3. Chat aware leveling system
    4. Save a history so you can ‘replay’ at times in the past
  5. Game Management
    1. Create a game
      1. Manage individual game sessions
        1. Scheduling and invites
        2. Calendar for in world and real world
      2. Asset Management
        1. Sound board
        2. Graphics
          1. Fog of War
        3. Maps with player/npc tokens
      3. NPC Management
        1. Scale to player level
        2. Combat Helper
        3. Name Generator
        4. NPC Generator by type
  6. Much Much More!


What did I end up with? A combat assistant. I use it, it works but oh man is it not what I had in my original vision.

So what did I learn? Iterative thinking should be core to project conceptualization. If I had only thought of my program as a combat assistant I would have been very happy with my results. However because I had such grandiose visions of the first iteration I felt I let myself down.

It’s all about the MVP baby! Change that mindset. It’s awesome I had so many ideas, but if only I thought about them as user stories in the backlog and the MVP as my main goal my personal satisfaction would have been much higher in the end.