Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Preparing Yourself for Modern JavaScript Development

codethinked.com

Post reply on HN
Print view View original

41–50 of 75 posts

Re: Preparing Yourself for Modern JavaScript Development

#41

Post by grannyg00se »

ufo wrote: post #25
azakai wrote: post #23

Earlier quoted context omitted.

> I always find it odd that the same developers who deride PHP look at things like IIFE and think "wow, JS is a cool, modern language!" I don't deride PHP (I don't know it), but I see nothing wrong with IIFE. Yes, it could benefit from some syntactic sugar, but otherwise it is just using one of the best features of JavaScript, function support (first-class functions, anonymous functions, etc.). It makes perfect sense…

IIFEs are cumbersome and non-intuitive. Better languages have block scope or a "let" statement instead.

Javascript [does/will]* have a "let" statement.

*depending on which version of ECMAscript is being used.

Re: Preparing Yourself for Modern JavaScript Development

#42

Post by kmontrose »

TazeTSchnitzel wrote: post #38
tomjen3 wrote: post #28

Earlier quoted context omitted.

Oh definitely. Or rather we need a vm designed to write code that can be optimized to run fast (personal dream, allow me to optionally include typing information. I already type my JS, might as well make it run better). This means that the vm would be lowlevel enough that performance would start to approach that of native code, with complete freedom for the programmer to write the code for it in any language he desir…

You'll be disappointed to know that Dart doesn't use bytecode.

There's a wholly unconvincing argument as to why Dart isn't pushing a VM as well, http://www.dartlang.org/articles/why-not-bytecode/ . Might as well be titled "Why not the JVM?" in my opinion.

Re: Preparing Yourself for Modern JavaScript Development

#43

Post by insin »

MatthewPhillips wrote: post #36

> Spy.prototype = new Person(); Don't do it that way. If the Person constructor assigns any data, for example an array, that data will be shared with all instances of Spy. Most likely you don't want that. Instead call the Person constructor within the Spy constructor: function Spy() { Person.apply(this, arguments); } Spy.prototype = Person.prototype; Spy.prototype.constructor = Spy;

Person will also have anything you add to Spy's prototype if you do that.

Attaching the "parent" prototype you want to have in the "child" prototype chain to a dummy constructor and new-ing that will do the trick for widest compatibility, although Object.create in ES5 and __proto__ (standardised) in ES6 both give you more direct access to the prototype chain:

  function inherits(child, parent) {
    var dummy = function() {}
    dummy.prototype = parent.prototype
    child.prototype = new dummy()
    child.prototype.constructor = child
  }

  function Spy() {
    Person.apply(this, arguments)
  }
  inherits(Spy, Person)

Re: Preparing Yourself for Modern JavaScript Development

#44

Post by TazeTSchnitzel »

kmontrose wrote: post #42
TazeTSchnitzel wrote: post #38

Earlier quoted context omitted.

You'll be disappointed to know that Dart doesn't use bytecode.

There's a wholly unconvincing argument as to why Dart isn't pushing a VM as well, http://www.dartlang.org/articles/why-not-bytecode/ . Might as well be titled "Why not the JVM?" in my opinion.

It isn't unconvincing. They make the case that bytecode is not assembly in reality, and constrains what you can do in languages compiled to it.

Re: Preparing Yourself for Modern JavaScript Development

#45

Post by jamiemill »

aymeric wrote: post #34

What is the difference between using the prototype technique shown in the article and this? var Person = function (){ this.Save = function() { … }; }; var person = new Person(); person.Save();

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 instances from the past and the future. So for example if you add a method to String.prototype, all current and future strings get it.

Re: Preparing Yourself for Modern JavaScript Development

#46

Post by bazzargh »

ufo wrote: post #18
bazzargh wrote: post #4

I'd be interested if one of these articles on modularity also addressed testability. For example, the IIFE pattern in the article: (function(window, $, undefined){ //do some work }(window, jQuery)); If instead of immediately executing this function, we kept a reference to the function, then reference it, the function can be supplied with mocks for testing. Obviously there's an issue that you'd pollute the global name…

I don't think you need to go through all the trouble. Some thing like the following should be enough: oldJQuery = jQuery; jQuery = mock; //Run module jQuery = oldJQuery; Remember that IIFE's are basically equivalent to variable definition and assignment. The only reason we even have to go through the trouble of using them is due to JS not having block scope.

Yeah, I'm aware I can do that, but it gets a bit painful for code that is stateful & executes on load (like IIFE does). You end up having to write a separate test script to run in a separate process for each test case...way slower than if you can isolate the module and 'restart' it in a closure for each test.

A different approach that might work for me would be to subvert require.js, so that it pulls in mocks. I see there's other people thinking along the same lines: https://github.com/tigbro/requirejs-factory-plugin

Re: Preparing Yourself for Modern JavaScript Development

#49

Post by silentbicycle »

ufo wrote: post #16
wickedchicken wrote: post #3

I always find it odd that the same developers who deride PHP look at things like IIFE and think "wow, JS is a cool, modern language!" Thanks for the article though, if I ever need to write some JS this will help keep me a little more sane.

The first time I saw something like IIFEs was in one of the SICP lectures, where they show that variable definitions with let or define can be seen as syntactic sugar over immediately invoked lambdas. And even those Scheme uber-nerds considered it big hack, more useful in theory then in practice.

It's useful as a de-sugaring step during compilation, not something people generally do by hand.

Re: Preparing Yourself for Modern JavaScript Development

#50

Post by aymeric »

jamiemill wrote: post #45
aymeric wrote: post #34

What is the difference between using the prototype technique shown in the article and this? var Person = function (){ this.Save = function() { … }; }; var person = new Person(); person.Save();

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)
Post reply on HN