Preparing Yourself for Modern JavaScript Development • Hacker News Board

Re: Preparing Yourself for Modern JavaScript Development

#61

Post by jamiemill » Sat, Jul 07, 2012, 9:55 AM UTC

aymeric wrote: post #50

jamiemill wrote: post #45

Earlier quoted context omitted.

That's called a "privileged method". The advantage of those is that they can access any private variables from the constructor, and they keep those variables in scope for their lifetime. The disadvantage however, is that the method is re-created once for each instance when the constructor runs, so they are not as memory-efficient as the prototype style. Also, when you add methods to the prototype you affect all insta…

Should I be concerned about the additional memory my way of doing things takes? It seems more convenient, allows for private methods and a limited drawback in my view (memory is rarely a bottleneck)

Probably depends on your application. You may also see slower construction time if you are creating thousands of objects.

I think which to use depends on whether you believe private methods/variables are helpful or not. Some argue they are unnecessary and it's better to keep everything public. Some like to use a naming convention like an underscore prefix on private items, but declare them publicly.

You could also argue that private items are problematic if you start composing classes from other classes by extending. Then the new methods can't access the private state because they're in a different scope, whereas if they were on the prototype they could find it through `this`.

I've used both approaches but nowadays tend towards the prototype style as that seems to be the more accepted.

Re: Preparing Yourself for Modern JavaScript Development

#62

Post by ahoge » Sat, Jul 07, 2012, 12:23 PM UTC

stephenr wrote: post #22

thealphanerd wrote: post #9

Earlier quoted context omitted.

I've been working on following the good parts for my latest project. I've started to cringe any time people talk about the prototype or using "this"

I cringe when people claim to be writing more than the most basic JS and aren't using prototypes.

It's a style choice. You don't have to use classes and/or do anything with the prototype chain.

Re: Preparing Yourself for Modern JavaScript Development

#63

Post by esailija » Sat, Jul 07, 2012, 12:41 PM UTC

jamiemill wrote: post #61

aymeric wrote: post #50

Earlier quoted context omitted.

Should I be concerned about the additional memory my way of doing things takes? It seems more convenient, allows for private methods and a limited drawback in my view (memory is rarely a bottleneck)

Probably depends on your application. You may also see slower construction time if you are creating thousands of objects. I think which to use depends on whether you believe private methods/variables are helpful or not. Some argue they are unnecessary and it's better to keep everything public. Some like to use a naming convention like an underscore prefix on private items, but declare them publicly. You could also ar…

There are also other problems such as nesting functions inside other functions inside other functions which is IMO much harder to maintain than a clean flat list of functions defined in the prototype. Don't even get me started on using "self", "that" or "me" instead of the built-in keyword "this".

It could be just me but I cannot understand how that was/is/has been acceptable at all in the first place. Doesn't functions nested 11 levels deep (true story) ring any alarm bells for people?

Re: Preparing Yourself for Modern JavaScript Development

#64

Post by swah » Sat, Jul 07, 2012, 12:57 PM UTC

aymeric wrote: post #56

ricardobeat wrote: post #53

Earlier quoted context omitted.

why private methods?

var Person = function() { var privateMethod = function() {...}; };

Normally I use code like this to avoid polluting the global namespace -- you might as well throw your functions in there and they will be "private":

    (function(){ 

     })();

Re: Preparing Yourself for Modern JavaScript Development

#65

Post by drostie » Sat, Jul 07, 2012, 12:58 PM UTC

aymeric wrote: post #50

jamiemill wrote: post #45

Earlier quoted context omitted.

That's called a "privileged method". The advantage of those is that they can access any private variables from the constructor, and they keep those variables in scope for their lifetime. The disadvantage however, is that the method is re-created once for each instance when the constructor runs, so they are not as memory-efficient as the prototype style. Also, when you add methods to the prototype you affect all insta…

Should I be concerned about the additional memory my way of doing things takes? It seems more convenient, allows for private methods and a limited drawback in my view (memory is rarely a bottleneck)

Memory is seldom a constraint on the sorts of computers which run JS. The real WTF about that approach later on is just going to be that person.hasOwnProperty('Save') === true. As long as you can guarantee that you will never want to iterate over a person with a for/in loop, you should be pretty much fine.

Re: Preparing Yourself for Modern JavaScript Development

#66

Post by georgemcbay » Sat, Jul 07, 2012, 6:08 PM UTC

TazeTSchnitzel wrote: post #59

georgemcbay wrote: post #54

Earlier quoted context omitted.

...and ECMAScript 4 had block scope. Language design by committee is seriously flawed and until a feature is shipping in all the major browsers it isn't real.

ECMAScript 4 was cancelled.

That was exactly my point.

Re: Preparing Yourself for Modern JavaScript Development

#67

Post by combataircraft » Sat, Jul 07, 2012, 7:30 PM UTC

kvnn wrote: post #58

combataircraft wrote: post #21

Earlier quoted context omitted.

both RequireJS and Browserify are not good options. Browserify's implementation is awkward, incomplete and pollutes global scopa a lot. Check out OneJS: http://github.com/azer/onejs It's the only tool that lets you structure your client-side project as a CommonJS package and produces unobtrusive code mixable with anything in same global scope.

There is another comment on this thread, by a separate user that reads: "both RequireJS and Browserify are not even good options. Browserify's implementation is awkward, incomplete and pollutes global scope a lot. Check out OneJS" I think there may be an agenda behind these comments.

I'm the owner of both comments and wrote it for two times because I can't see the other one and have very strong opinions about this topic.

Re: Preparing Yourself for Modern JavaScript Development

#68

Post by ricardobeat » Sat, Jul 07, 2012, 8:40 PM UTC

aymeric wrote: post #56

ricardobeat wrote: post #53

Earlier quoted context omitted.

why private methods?

var Person = function() { var privateMethod = function() {...}; };

why: what's your reasoning for using them?

A more memory-efficient approach:

    var Person = (function(){
  
      function Person(x){
        this.x = x
      }
      
      function myPrivateMethod(x){
        //...
      }

      Person.prototype.something = function(){
        y = myPrivateMethod(this.x)
      }
    
      return Person 
    })()

Re: Preparing Yourself for Modern JavaScript Development

#69

Post by saurik » Sun, Jul 08, 2012, 1:45 AM UTC

combataircraft wrote: post #67

kvnn wrote: post #58

Earlier quoted context omitted.

There is another comment on this thread, by a separate user that reads: "both RequireJS and Browserify are not even good options. Browserify's implementation is awkward, incomplete and pollutes global scope a lot. Check out OneJS" I think there may be an agenda behind these comments.

I'm the owner of both comments and wrote it for two times because I can't see the other one and have very strong opinions about this topic.

(That other account has apparently been hell-banned, seemingly due to a downvotes during a political conversation about Kim Jong-il that you were involved in; you should probably stop using that account, as users can only see your posts if they turn on showdead. FWIW, thank you very much for this comment about OneJS, despite the flak you got for it due to the post from your hell-banned account.)

Re: Preparing Yourself for Modern JavaScript Development

#70

Post by saurik » Sun, Jul 08, 2012, 1:47 AM UTC

combataircraft wrote: post #27

iron_ball wrote: post #26

Earlier quoted context omitted.

What's specifically wrong with RequireJS? I haven't heard much discussion of it, and you only addressed Browserify in your comment.

I've been following the work on RequireJS for two years and think that it's an evil project that sabotages the rise of CommonJS, NodeJS and NPM by leading client-side Javascript coders to follow a non-standard, awkward way of JS development. From the very beginning, it forces coders to cover their code with awkward code and maintain it manually. It's completely insane. I even think that I'm wasting my time by talking…

Their (RequireJS's) website claims the following; I would be interested in an argued response/critique.

> CommonJS defines a module format. Unfortunately, it was defined without giving browsers equal footing to other JavaScript environments. Because of that, there are CommonJS spec proposals for Transport formats and an asynchronous require.