Preparing Yourself for Modern JavaScript Development • Hacker News Board

Re: Preparing Yourself for Modern JavaScript Development

#51

Post by kmontrose » Sat, Jul 07, 2012, 3:05 AM UTC

TazeTSchnitzel wrote: post #44

kmontrose wrote: post #42

Earlier quoted context omitted.

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.

Nonsense, a VM is what it's defined to be. If you wanted the x86 (or ARM, or PPC, etc.) instruction set to be your bytecode, you've got it.

That article starts from the assumption that any in browser VM will resemble the JVM; which is a faulty assumption. In fact, any in browser VM would have to be very different from the JVM since Rule 0 for any such VM would be "acceptable Javascript performance".

From that article:

> Meanwhile, JVMs don't do these optimizations. Since all types are statically

> known, the compiler knows exactly how much storage they need and what

> operations they support. It can then generate appropriate tight code for those

> types. This is fast if your language is statically typed, but if you're trying to

> compile a dynamically typed language to the JVM, it won't be able to run as fast as a

> VM that can assume dynamic typing all the way down and optimize specifically

> for that.

A whole wasted paragraph. Of course a browser VM wouldn't be statically typed, that'd make compiling/running Javascript a bear. One would hope there'd be some system of type-hinting, because eliminating dynamic dispatch is really low hanging fruit in terms of optimization, but JVM/CLR-style static typing? Madness.

Re: Preparing Yourself for Modern JavaScript Development

#52

Post by cfjedimaster » Sat, Jul 07, 2012, 3:29 AM UTC

combataircraft wrote: post #35

wilmoore wrote: post #33

Earlier quoted context omitted.

> it forces coders to cover their code with awkward code and maintain it manually Friendly request for proof via examples. A gist would be fair.

here; http://requirejs.org/docs/ you can see all the smelling shit of requirejs there.

That's not really an answer. What _about_ their way of doing things do you consider to be wrong and why?

Re: Preparing Yourself for Modern JavaScript Development

#53

Post by ricardobeat » Sat, Jul 07, 2012, 4:01 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)

why private methods?

Re: Preparing Yourself for Modern JavaScript Development

#54

Post by georgemcbay » Sat, Jul 07, 2012, 4:37 AM UTC

TazeTSchnitzel wrote: post #37

ufo wrote: post #25

Earlier quoted context omitted.

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

`let` is drafted for ECMAScript 6.

...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.

Re: Preparing Yourself for Modern JavaScript Development

#55

Post by wilmoore » Sat, Jul 07, 2012, 5:16 AM UTC

combataircraft wrote: post #35

wilmoore wrote: post #33

Earlier quoted context omitted.

> it forces coders to cover their code with awkward code and maintain it manually Friendly request for proof via examples. A gist would be fair.

here; http://requirejs.org/docs/ you can see all the smelling shit of requirejs there.

Can you expound please?

Re: Preparing Yourself for Modern JavaScript Development

#56

Post by aymeric » Sat, Jul 07, 2012, 5:52 AM UTC

ricardobeat wrote: post #53

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)

why private methods?

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

Re: Preparing Yourself for Modern JavaScript Development

#57

Post by tomjen3 » Sat, Jul 07, 2012, 6:05 AM UTC

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.

Dart isn't relevant, since google isn't pushing it nearly hard enough.

Re: Preparing Yourself for Modern JavaScript Development

#58

Post by kvnn » Sat, Jul 07, 2012, 6:14 AM UTC

combataircraft wrote: post #21

ender7 wrote: post #7

This is a nice, gentle introduction, but if you're going to start using modules you might as well go slightly farther and use something like RequireJS ( http://requirejs.org/ ) or Browserify ( https://github.com/substack/node-browserify ).

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.

Re: Preparing Yourself for Modern JavaScript Development

#59

Post by TazeTSchnitzel » Sat, Jul 07, 2012, 8:53 AM UTC

georgemcbay wrote: post #54

TazeTSchnitzel wrote: post #37

Earlier quoted context omitted.

`let` is drafted for ECMAScript 6.

...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.

Re: Preparing Yourself for Modern JavaScript Development

#60

Post by andybak » Sat, Jul 07, 2012, 9:01 AM UTC

TazeTSchnitzel wrote: post #13

jashkenas wrote: post #10

Earlier quoted context omitted.

That's unfortunate. Properly using prototypes and "this" is the only way to do high-performance JavaScript with objects. Get cozy with them -- they're useful.

It isn't the only way, it's just that browser JS engines tend to be optimised for them.

I believe your statement is therefore equivalent to the preceding one.