Since javascript is a scripting language, updating it wouldn't be a big deal, it would mean restarting the server, but it would seem most online games go through some sort of restart when introducing new things anyways.
You really don't want this.
Yes, some items will need reboots, because they'll need new accompanying game logic. Minor updates, GM-driven quests, marketing-driven quests and bonus items (or pricing changes), etc. should absolutely not require a reboot.
Honestly, even code changes shouldn't require a reboot in this day and age. Incremental rollouts are quite possible, even in an MMO.
Items in my game are really hard to define in data, as they can have wildly different functions, if its a javascript object, I can define a 'use' function for all of them and don't need to worry about creating a complex item definitions in the database.
This is not a good reason to hard-code the data. Your need to hard-code the behavior of an item is irrelevant to your need to associate a name, or a cost, or a weight, or an icon, or anything else with the item. Hard-code what you need to; nothing else.
Even with item behavior you probably want to parameterize all that. You shouldn't need 10 different use() functions for similar but different features. A single heal() function could be used across most if not all healing items, for instance, allowing the item to define in data how much healing is applied.
Then you can allow items to have multiple functions. Instead of a complex heal_100hp_and_cast_lvl3_fireball() you can instead have heal(hp) and cast(spell, level) functions and then allow an item to require both of them. Even the heal(hp) function can be further parameterized to allow a single function to handle healing by explicit amount, by percentage of max HP, etc.
Put your mind to it and you'll see that you only need a relatively small set of individual functions to implement a very wide variety of both simple and complex items. That makes your code much simpler, decouples your behavior from your items, and even allows totally new complex items to be created and released without ever touching a single line of code.
If I used a database only, I would have to come up with some sort of way to define every possible item ever, and I don't think its likely I will imagine all of them.
You have to do that even without the database. Whether they're in your code or in your data, you have to keep around all items you release forever.
Players don't tend to like it when items they "own" just up and disappear because you decided to trim a few hundred thousand lines of code out of a bloated codebase.
Once an item is released, it exists forever. Do you want your code to keep growing forever until it's utterly unmaintainable or would you rather have a big database designed for handling terabytes of data hold on to some legacy data entries?
I could use a database for things like name, and description, but still have a hash of functions somewhere.
Yes. Do that. Combine that with database-supplied parameters for the functions.
Maybe having all these items hard coded could increase memory foot print of the web application as they would all always be loaded into memory?
Well, yes, but that's not a good reason to avoid it. There are good reasons (see above); that's just not one of them. :)
