7 ms·

New-less JavaScript (2013)

37 points by voltagex_ 12y ago

rtpg 12y ago
I think a good complement tothis concept is that of "this"-less Javascript, relegating it only to things like mixins. So many headaches are to be had if you're not careful and using some decent functional things.
- AnkhMorporkian 12y ago
  I don't think there's anything inherently evil, bad, or even particularly confusing about this. As long as you understand how it's being attached to a running function there's very little confusion to be had. The problem is that most of the resources for learning completely gloss over this incredibly important aspect of the language.
  - insin 12y ago
    ...and too few of the posts complaining about it mention strict mode or ES6 fat arrow syntax.
- jsprogrammer 12y ago
  Agreed, `new` and `this` are pretty much useless boilerplate noise. Gimme a closure and watch me wipe out a quarter of the text in your source and never even have to think about using a`bind`.
  - bttmly 12y ago
    Yes, absolutely. In fact, this post is really just providing a trick for not having to always write `new`. Using closures for object construction is the real 'new-less' JavaScript. As a nice parallel, the trick explained in the post lets you construct objects using `new` without typing it, whereas object factories that use closures allow you to use `new` without requiring it.
- jfirebaugh 12y ago
  (author here) Absolutely. My preference for new modules is to use both newless and "this"-less Javascript. Newless via the technique outlined in this post (or encapsulated in a module: https://github.com/Mr0grog/newless https://github.com/Mr0grog/newless), and this-less via the module pattern (see link in post). This is the pattern followed by D3. It's easy to follow internally, gives you true private data and methods, and (IMHO) is a nicer interface for API consumers -- no `new`, `delete`, or `bind`'s necessary.
- aikah 12y ago
  With ES6 classes everywhere soon , I doubt you'll see less "new". On the contrary, you'll see more java-ish code and less Doug Crockford like code. By the way, he aint in TC39 anymore. So expect even more java-ish features in ES.
- methyl 12y ago
  The problem with module pattern which enables you to use "this"-less Javascript is increased memory usage. Of course you can use other techniques for elements which you instaniate in thousands, but then you are mixing one pattern with another and it will begin hard to follow which should be which. I prefer consistency here.
  - jsprogrammer 12y ago
    In theory, an optimizing VM/JIT should be able to handle this for you. I'm not sure if existing implementations currently do any optimizations though.
1day1day 12y ago
"JavaScript borrowed the new and delete keywords from its less-dynamic predecessor languages. They feel a bit out of place in a garbage collected language and are a source of confusion for newbies " They are? Delete maybe, due to language symantics - but not new. I think it's unfair to bundle them together in terms of newbie confusion. Also every time I see one of these type of blog post, discussions in a book the work arounds are even worse. JS is easy to understand, by the time you need 'new' it is not that difficult an extension of your current knowledge. As far as 'delete' even an advanced JS developer could go a year without calling it
- pjmlp 12y ago
  Fully agree. The author probably never used Smalltalk, just to cite one of the oldest dynamic languages. btn := Button new.
- shangxiao 12y ago
  'new' is a source of confusion for newbies and experienced devs alike, sufficiently enough for them to ask questions on SO: http://stackoverflow.com/questions/9468055/what-does-new-in-javascript-do-anyway http://stackoverflow.com/questions/9468055/what-does-new-in-... Even I have to refresh my memory on these ambiguous parts of the language from time to time.
simula67 12y ago
I feel like being bullied for having to learn Javascript to do web programming. I wish there was a push towards supporting arbitrary languages for doing web development.
- ChrisAntaki 12y ago
  Well, that's possible with compile-to-JavaScript languages. Also you have the option of plugins like Unity, if you're going for something graphically adventurous. That being said, JavaScript is a powerful tool, if wielded correctly. It's so flexible. In a lot of ways, it's like a pizza. One man orders a pizza with anchovies, another with green peppers. And on and on. Eventually it's like they've got two completely different dinners.
  - simula67 12y ago
    > Well, that's possible with compile-to-JavaScript languages. I have tried to read code that was translated to Javascript using some source-to-source compilers and they are very hard to understand. On the other hand for a language like C, it is very easy to understand the output ( assembly ). Don't get me wrong, understanding the intricacies of assembly for each processor architecture is a difficult process, but the rules that define assembly language itself are not so, there is an opcode and some operands and each instruction performs an action on the operands or stored state in various registers. Javascript ( at least for me ) is too high-level to attempt to read a machine translated output. Programmers need to know at least one level below the abstraction to which they are programming to.
    - jbergens 12y ago
      I would say the output of most of the compile-to-js languages are easy or at least non-hard to read. It is usually the minification that causes problems and you don't have to do that in a development environment where you usually attach your debugger. It's usually also hard to debug a running application written in a static and compiled language (unless you have symbol tables and similar).
  - 12y ago
EugeneOZ 12y ago
It's a movement in wrong direction. It's artifact that we can call class name without "new" and method name, because before ES6 there wasn't such thing as classes. Now we should just deprecate this artifact.
Rygu 12y ago
I use `delete object[key]` all the time to unset a property. I do think in the JS world the use of `new` is inconsistent, but avoiding the keyword does not rid of that fact. Your new-less libraries may be consistent with each other, but not the rest of the JS world that do it their own way. (http://xkcd.com/927/ http://xkcd.com/927/) This seems like a problem the language should solve incrementally. Especially with ES6 classes and modules!
- maga 12y ago
  `delete` is harmful, consider setting property to `undefined` or `null` instead.
  - kalms 12y ago
    Why is it harmful to delete a property that disappears forever?
    - drinchev 12y ago
      Because garbage collectors doesn't care if it is simply deleted. Setting it to undefined or null is better for speed http://bertanguven.com/preventing-memory-leaks-in-javascript-null-vs-delete/ http://bertanguven.com/preventing-memory-leaks-in-javascript...
      - zimbatm 12y ago
        This article is just badly written. It doesn't provide or make reference to a precise documentation of the issue. It's not clear whenever it applies to `delete x` or also `delete obj[x]`. It doesn't provide a reproductible use case or list of browsers that are affected. It mentions issues with scope but doesn't go in detail of which ones are triggering the issue. For what it's worth it might apply only to IE6. `delete obj[x]` removes not only the reference to the value but also the key which prevents other forms of memory leak.
        drinchev 12y ago
leichtgewicht 12y ago
How is this news? It says 2013 in the title ...
drinchev 12y ago
One of the greatest things about preprocessing languages is that they usually use optimized and hard-tested features of the specific language. Let's examine CoffeeScript ( which is one of the most popular ) : class Foo constructor: -> return 'bar'; foo = new Foo(); will compile to : var Foo, foo; Foo = (function() { function Foo() { return 'bar'; } return Foo; })(); foo = new Foo(); Which IMHO, follows the very best practices of javascript. Since JS is such a flexible language if you don't have any coding standards, your code could become hell and unmaintainable very quickly. I would advise not to use the proposed "New-less JS", because it breaks the general coding style guides that a lot of libraries use and yes it would be possible to write it that way, but keep in mind that your code would be one step less readable from random developers.
- cromwellian 12y ago
  Is that really optimized/optimal? I'd be curious to see jsperf benchmarks of this method of constructor vs the straighforward approach. The JS VMs tend to kind of finnicky and optimized towards certain types of idiomatic Javascript and it's my guess that the further off the common path you stray, the more likely you are to hit performance gotchas. Your best bet is to transpile code that looks much like the benchmark suites they run. :)
  - drinchev 12y ago
    I also agree with what you are saying. JS in terms of usage is so big that I guess developers behind JS compilers will have to optimize for "the most popular way of solving that problem". In any case, why I mentioned preprocessors is that there is a lot of history behind every feature. As of this there are a couple of github issues [1] that explain why this approach has been used. For the performance. Seems that "new" is way faster. [2] [1] : https://github.com/jashkenas/coffeescript/issues/912 https://github.com/jashkenas/coffeescript/issues/912 [2] : https://jsperf.com/obj-create-vs-new/4 https://jsperf.com/obj-create-vs-new/4
    - deleted 12y ago
      [deleted]
zimbatm 12y ago
The best reason to have new-less constructors is because it's now possible to use them as higher-order functions. [1,2,3].map(User)
- drinchev 12y ago
  Or the alternative : [1,2,3].map( function(i) { return new User(i); } ); might seem more reasonable in the JS world.
  - agumonkey 12y ago
    It's a valuable but unnecessary intermediate step if you go into functional idioms (map, fold, closures) fully. raganwald books cover this way of using javascript https://leanpub.com/u/raganwald https://leanpub.com/u/raganwald
- insin 12y ago
  As long as the constructor doesn't take multiple arguments [1], otherwise: [1, 2, 3].map(id => User(id)) [1] http://speakingjs.com/es5/ch15.html#_pitfall_unexpected_optional_parameters http://speakingjs.com/es5/ch15.html#_pitfall_unexpected_opti...
  - zimbatm 12y ago
    Why JavaScript, why !
  - elclanrs 12y ago
    I find it useful to have `unary` and `apply` around: [1,2,3].map(unary(User)) [[1,2],[3,4],[5,6]].map(apply(User))
jbergens 12y ago
The library StampIt uses factory methods instead of new to allow some extra features. Works a lot like .extend() in other libraries but with some extra options. https://github.com/ericelliott/stampit https://github.com/ericelliott/stampit
z3t4 12y ago
The nice thing about JS is that it has so many "religions". But some people think there should only be ONE religion. While One religion would be easier for newbies, destroying all other religions would kill the language. So can we just agree that many religions are nice. It's OK to try and convert people, but it's Not OK to force someone by changing the language itself. With that said, I'm a bit worried about more and more religions entering the JS language. Like classes and block scope (ES6). And how some, both good and bad new features are forever changing the language.

37 points by voltagex_ 12y ago

rtpg 12y ago

I think a good complement tothis concept is that of "this"-less Javascript, relegating it only to things like mixins. So many headaches are to be had if you're not careful and using some decent functional things.

AnkhMorporkian 12y ago
I don't think there's anything inherently evil, bad, or even particularly confusing about this. As long as you understand how it's being attached to a running function there's very little confusion to be had. The problem is that most of the resources for learning completely gloss over this incredibly important aspect of the language.
- insin 12y ago
  ...and too few of the posts complaining about it mention strict mode or ES6 fat arrow syntax.
jsprogrammer 12y ago
Agreed, `new` and `this` are pretty much useless boilerplate noise. Gimme a closure and watch me wipe out a quarter of the text in your source and never even have to think about using a`bind`.
- bttmly 12y ago
  Yes, absolutely. In fact, this post is really just providing a trick for not having to always write `new`. Using closures for object construction is the real 'new-less' JavaScript. As a nice parallel, the trick explained in the post lets you construct objects using `new` without typing it, whereas object factories that use closures allow you to use `new` without requiring it.
jfirebaugh 12y ago
(author here) Absolutely. My preference for new modules is to use both newless and "this"-less Javascript. Newless via the technique outlined in this post (or encapsulated in a module: https://github.com/Mr0grog/newless https://github.com/Mr0grog/newless), and this-less via the module pattern (see link in post). This is the pattern followed by D3. It's easy to follow internally, gives you true private data and methods, and (IMHO) is a nicer interface for API consumers -- no `new`, `delete`, or `bind`'s necessary.
aikah 12y ago
With ES6 classes everywhere soon , I doubt you'll see less "new". On the contrary, you'll see more java-ish code and less Doug Crockford like code. By the way, he aint in TC39 anymore. So expect even more java-ish features in ES.
methyl 12y ago
The problem with module pattern which enables you to use "this"-less Javascript is increased memory usage. Of course you can use other techniques for elements which you instaniate in thousands, but then you are mixing one pattern with another and it will begin hard to follow which should be which. I prefer consistency here.
- jsprogrammer 12y ago
  In theory, an optimizing VM/JIT should be able to handle this for you. I'm not sure if existing implementations currently do any optimizations though.

1day1day 12y ago

"JavaScript borrowed the new and delete keywords from its less-dynamic predecessor languages. They feel a bit out of place in a garbage collected language and are a source of confusion for newbies " They are? Delete maybe, due to language symantics - but not new. I think it's unfair to bundle them together in terms of newbie confusion. Also every time I see one of these type of blog post, discussions in a book the work arounds are even worse. JS is easy to understand, by the time you need 'new' it is not that difficult an extension of your current knowledge. As far as 'delete' even an advanced JS developer could go a year without calling it

pjmlp 12y ago
Fully agree. The author probably never used Smalltalk, just to cite one of the oldest dynamic languages. btn := Button new.
shangxiao 12y ago
'new' is a source of confusion for newbies and experienced devs alike, sufficiently enough for them to ask questions on SO: http://stackoverflow.com/questions/9468055/what-does-new-in-javascript-do-anyway http://stackoverflow.com/questions/9468055/what-does-new-in-... Even I have to refresh my memory on these ambiguous parts of the language from time to time.

simula67 12y ago

I feel like being bullied for having to learn Javascript to do web programming. I wish there was a push towards supporting arbitrary languages for doing web development.

ChrisAntaki 12y ago
Well, that's possible with compile-to-JavaScript languages. Also you have the option of plugins like Unity, if you're going for something graphically adventurous. That being said, JavaScript is a powerful tool, if wielded correctly. It's so flexible. In a lot of ways, it's like a pizza. One man orders a pizza with anchovies, another with green peppers. And on and on. Eventually it's like they've got two completely different dinners.
- simula67 12y ago
  > Well, that's possible with compile-to-JavaScript languages. I have tried to read code that was translated to Javascript using some source-to-source compilers and they are very hard to understand. On the other hand for a language like C, it is very easy to understand the output ( assembly ). Don't get me wrong, understanding the intricacies of assembly for each processor architecture is a difficult process, but the rules that define assembly language itself are not so, there is an opcode and some operands and each instruction performs an action on the operands or stored state in various registers. Javascript ( at least for me ) is too high-level to attempt to read a machine translated output. Programmers need to know at least one level below the abstraction to which they are programming to.
  - jbergens 12y ago
    I would say the output of most of the compile-to-js languages are easy or at least non-hard to read. It is usually the minification that causes problems and you don't have to do that in a development environment where you usually attach your debugger. It's usually also hard to debug a running application written in a static and compiled language (unless you have symbol tables and similar).
- 12y ago

EugeneOZ 12y ago

It's a movement in wrong direction. It's artifact that we can call class name without "new" and method name, because before ES6 there wasn't such thing as classes. Now we should just deprecate this artifact.

Rygu 12y ago

I use `delete object[key]` all the time to unset a property. I do think in the JS world the use of `new` is inconsistent, but avoiding the keyword does not rid of that fact. Your new-less libraries may be consistent with each other, but not the rest of the JS world that do it their own way. (http://xkcd.com/927/ http://xkcd.com/927/) This seems like a problem the language should solve incrementally. Especially with ES6 classes and modules!

maga 12y ago
`delete` is harmful, consider setting property to `undefined` or `null` instead.
- kalms 12y ago
  Why is it harmful to delete a property that disappears forever?
  - drinchev 12y ago
    Because garbage collectors doesn't care if it is simply deleted. Setting it to undefined or null is better for speed http://bertanguven.com/preventing-memory-leaks-in-javascript-null-vs-delete/ http://bertanguven.com/preventing-memory-leaks-in-javascript...
    - zimbatm 12y ago
      This article is just badly written. It doesn't provide or make reference to a precise documentation of the issue. It's not clear whenever it applies to `delete x` or also `delete obj[x]`. It doesn't provide a reproductible use case or list of browsers that are affected. It mentions issues with scope but doesn't go in detail of which ones are triggering the issue. For what it's worth it might apply only to IE6. `delete obj[x]` removes not only the reference to the value but also the key which prevents other forms of memory leak.
      - drinchev 12y ago

leichtgewicht 12y ago

How is this news? It says 2013 in the title ...

drinchev 12y ago

One of the greatest things about preprocessing languages is that they usually use optimized and hard-tested features of the specific language. Let's examine CoffeeScript ( which is one of the most popular ) : class Foo constructor: -> return 'bar'; foo = new Foo(); will compile to : var Foo, foo; Foo = (function() { function Foo() { return 'bar'; } return Foo; })(); foo = new Foo(); Which IMHO, follows the very best practices of javascript. Since JS is such a flexible language if you don't have any coding standards, your code could become hell and unmaintainable very quickly. I would advise not to use the proposed "New-less JS", because it breaks the general coding style guides that a lot of libraries use and yes it would be possible to write it that way, but keep in mind that your code would be one step less readable from random developers.

cromwellian 12y ago
Is that really optimized/optimal? I'd be curious to see jsperf benchmarks of this method of constructor vs the straighforward approach. The JS VMs tend to kind of finnicky and optimized towards certain types of idiomatic Javascript and it's my guess that the further off the common path you stray, the more likely you are to hit performance gotchas. Your best bet is to transpile code that looks much like the benchmark suites they run. :)
- drinchev 12y ago
  I also agree with what you are saying. JS in terms of usage is so big that I guess developers behind JS compilers will have to optimize for "the most popular way of solving that problem". In any case, why I mentioned preprocessors is that there is a lot of history behind every feature. As of this there are a couple of github issues [1] that explain why this approach has been used. For the performance. Seems that "new" is way faster. [2] [1] : https://github.com/jashkenas/coffeescript/issues/912 https://github.com/jashkenas/coffeescript/issues/912 [2] : https://jsperf.com/obj-create-vs-new/4 https://jsperf.com/obj-create-vs-new/4
  - deleted 12y ago
    [deleted]

zimbatm 12y ago

The best reason to have new-less constructors is because it's now possible to use them as higher-order functions. [1,2,3].map(User)

drinchev 12y ago
Or the alternative : [1,2,3].map( function(i) { return new User(i); } ); might seem more reasonable in the JS world.
- agumonkey 12y ago
  It's a valuable but unnecessary intermediate step if you go into functional idioms (map, fold, closures) fully. raganwald books cover this way of using javascript https://leanpub.com/u/raganwald https://leanpub.com/u/raganwald
insin 12y ago
As long as the constructor doesn't take multiple arguments [1], otherwise: [1, 2, 3].map(id => User(id)) [1] http://speakingjs.com/es5/ch15.html#_pitfall_unexpected_optional_parameters http://speakingjs.com/es5/ch15.html#_pitfall_unexpected_opti...
- zimbatm 12y ago
  Why JavaScript, why !
- elclanrs 12y ago
  I find it useful to have `unary` and `apply` around: [1,2,3].map(unary(User)) [[1,2],[3,4],[5,6]].map(apply(User))

jbergens 12y ago

The library StampIt uses factory methods instead of new to allow some extra features. Works a lot like .extend() in other libraries but with some extra options. https://github.com/ericelliott/stampit https://github.com/ericelliott/stampit

z3t4 12y ago

The nice thing about JS is that it has so many "religions". But some people think there should only be ONE religion. While One religion would be easier for newbies, destroying all other religions would kill the language. So can we just agree that many religions are nice. It's OK to try and convert people, but it's Not OK to force someone by changing the language itself. With that said, I'm a bit worried about more and more religions entering the JS language. Like classes and block scope (ES6). And how some, both good and bad new features are forever changing the language.