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

The Future of JavaScript

blog.chromium.org

Post reply on HN
Print view View original

101–110 of 115 posts

Re: The Future of JavaScript

#101

Post by batista »

erichocean wrote: post #74
substack wrote: post #61

I really dislike what they're doing with modules because it's such a step back from the commonjs-inspired require() that node uses. In node, require() just returns a value. That value is usually an object but often it's just a function. Why should a module that encapsulates exactly one function return anything else but that one function? In ES.next, you've got to use pythonesque `import y from Bar` statements which i…

Totalyl agree. The lack of a module system in JavaScript has been an enormous benefit to the developer community, because it has allowed us to develop idioms that make sense in the context of JavaScript . Adopting a hard-coded, python-esque module system is a step backwards from what we have now, and I doubt will be used much, if at all -- why give up features that already exist (and will continue to work)? sigh

Sure, the top JS language designers in the ES6 group haven't thought of these issues...

Re: The Future of JavaScript

#102

Post by batista »

gjm11 wrote: post #66
mcantelon wrote: post #65

Earlier quoted context omitted.

Attempts to create big iterations on successful languages seem to consistently fail to win adoption.

C++ seems like a pretty obvious counterexample, even though it didn't call itself "C". Others: Fortran 90. Common Lisp. Visual Basic. [EDITED to add: Perl 5.] ANSI C was quite a big change from K&R, even.

Not to mention: C11x (or whatever it's called), which has huge support from vendors and C++ guys, C# 4.0 that is miles ahead of C# 1.0,

Re: The Future of JavaScript

#103

Post by batista »

It would be nice if there was some mechanism --at least for dynamic languages-- where when a feature X (say, the new "let" keyword) is introduced in the compiler, you can add some code that adds support for it at runtime. Maybe with some kind of name-mangling to avoid name clashes with existing variable names, etc.

Of course it would incur a performance penalty, and for some stuff it might also be infeasible, but there could be some low level package just for this purpose, that provided options to add new keywords, bytecodes, etc.

The end result would be something like (in mock-pyjs glory):

if __language__.has_not("let") import __Future__.Let".

This would enable faster iterations of the main language, while keeping backwards compatibility. Anyone knows if anything like this exists?

(Well, you can do sort of this kind of thing in Lisp. But has it ever been attempted in a C-like syntax?)

P.S My understanding is that Python does not do this, it just makes the __future__ imported modules optional in the previous version of the compiler, but they are still implemented in plain C along with the rest of CPython, no?

Re: The Future of JavaScript

#104

Post by JoshTriplett »

batista wrote: post #103

It would be nice if there was some mechanism --at least for dynamic languages-- where when a feature X (say, the new "let" keyword) is introduced in the compiler, you can add some code that adds support for it at runtime. Maybe with some kind of name-mangling to avoid name clashes with existing variable names, etc. Of course it would incur a performance penalty, and for some stuff it might also be infeasible, but the…

Personally, I'd love to see an implementation of ES.next as a static compiler. Much like CoffeeScript provides a JavaScript-like language that compiles to JavaScript, an ES.next compiler could compile ES.next JavaScript to cross-browser JavaScript.

Re: The Future of JavaScript

#105

Post by vectorjohn »

rdtsc wrote: post #99
vectorjohn wrote: post #81

Earlier quoted context omitted.

Wrong. What makes JavaScript popular is how good it is. You can't explain its mass popularity growth in non browser setting (node js ) with its ubiquity. It is a great language, and perhaps ubiquity was needed to get a lot of people to try out new concepts.

> What makes JavaScript popular is how good it is. If you are trying to be sarcastic, you are not doing it right.

Hah, no reason to get defensive. Javascript is a great language. If you don't like it, you are free to feel that way. But there is a huge number of people who like it. Personally, it is my favorite programming language. It just feels right.

And I've only been using it for a few years. It really isn't hard to get past the bad parts.

Re: The Future of JavaScript

#106

Post by vectorjohn »

tomjen3 wrote: post #84
vectorjohn wrote: post #81

Earlier quoted context omitted.

Wrong. What makes JavaScript popular is how good it is. You can't explain its mass popularity growth in non browser setting (node js ) with its ubiquity. It is a great language, and perhaps ubiquity was needed to get a lot of people to try out new concepts.

Have you used Javascript? I mean to do real-web apps, not to enhance some webpages with a bit of JQuery (as useful as that is). Var is broken in js because it does not obey sensible semantics for(var i.... does what you think it does. In every language except javascript it would declare i only inside the loop. In js it declares i in whatever function scope the loop is inside. A = function(){ console.log(this); } A.pr…

Your argument makes it pretty clear it is you that have not used Javascript very much.

setTimeout( 100, imp.q) // DOESN'T DO ANYTHING, 100 is not a function

And if you thought about it for more than a few seconds, you would realize that the behavior of "this" makes sense and is less magical than in other languages. Since "imp.q" is not a function call, it is a reference to a function, you are simply passing in a function. Since javascript "classes" are just objects with function references, you can't somehow decide what object "this" should point at unless it is explicit. In the case of "foo.bar()", it is explicitly "foo". In the case of setTimeout( foo.bar, 100), all setTimeout gets is a function pointer with no notion of what this should be.

Anyway, the rest of your gripes just sound like you don't like untyped languages, which is personal preference and I guess I don't share your preference.

Re: The Future of JavaScript

#107

Post by tomjen3 »

vectorjohn wrote: post #106
tomjen3 wrote: post #84

Earlier quoted context omitted.

Have you used Javascript? I mean to do real-web apps, not to enhance some webpages with a bit of JQuery (as useful as that is). Var is broken in js because it does not obey sensible semantics for(var i.... does what you think it does. In every language except javascript it would declare i only inside the loop. In js it declares i in whatever function scope the loop is inside. A = function(){ console.log(this); } A.pr…

Your argument makes it pretty clear it is you that have not used Javascript very much. setTimeout( 100, imp.q) // DOESN'T DO ANYTHING, 100 is not a function And if you thought about it for more than a few seconds, you would realize that the behavior of "this" makes sense and is less magical than in other languages. Since "imp.q" is not a function call, it is a reference to a function, you are simply passing in a func…

I haven't used setTimeout much, but I do use js everyday (it is my fulltime job).

And it may be nice to have 'just objects with function references' when you are writting a few lines of code to validate emails or something like than. When you start pushing 2k lines of code and more than two developers you need much more structure than than that. Anyhow C++, Scala and C# all have reasonable understanding of this. If all you have are function points, don't have this.

Re: The Future of JavaScript

#108

Post by DomenicDenicola »

batista wrote: post #96
vectorjohn wrote: post #80

Earlier quoted context omitted.

It would be easier to just learn the language. JavaScript I not c. JavaScript is not Java. JavaScript is not python. If it was one of those languages it would be named that and there would be no JavaScript books, just dom and browser books. But it is not those languages. It is different. If people don't learn the language they cannot be expected to write code. People always bring up var for some reason. Why var? Why…

It would be easier to just learn the language. Can you conceive the existence of a language that has got some parts wrong, and maybe awfully wrong? Well, my point, and that of a lot of others, including Cockford and Eich, is that Javascript is such a language. And that the fucked-up scope it has, is one of such parts. JavaScript I not c. JavaScript is not Java. JavaScript is not python. If it was one of those languag…

> Brendan Eich is a JS guru and implementer. Douglas Cockford invented the damn language!

Er, not quite sir. Brendan Eich invented the language. He is indeed a guru and an implementer; in fact the original implementer.

Crockford is a guru, and more importantly a pundit.

Re: The Future of JavaScript

#109

Post by medikoo »

samth wrote: post #92
substack wrote: post #61

I really dislike what they're doing with modules because it's such a step back from the commonjs-inspired require() that node uses. In node, require() just returns a value. That value is usually an object but often it's just a function. Why should a module that encapsulates exactly one function return anything else but that one function? In ES.next, you've got to use pythonesque `import y from Bar` statements which i…

I'll try to separate out the different issues you're raising here, and respond to each individually. 1. What if I want to have my module be a function, the way that $ in jQuery is both a function and a namespace for the rest of the functionality? This is an important use case, and so we're going to support it in ES6 modules. You'll be able to say: module $ at "http://jquery.com/jquery.min.js"; $(...) $.ajax(...) 2. M…

I'll just add that I totally I agree with samth

I'm strong user of Node.js style modules (also for client side) and I see modules as proposed for Harmony as big step forward. It's basically same concept but with dedicated syntax (well put syntax) and some extra powerful features.

I've once setup some comparison how today modules written for Node.js (like modules that are functions) will look in harmony. I didn't spot any issues. See slides 86-87 at http://www.slideshare.net/medikoo/javascript-modules-done-ri...

Re: The Future of JavaScript

#110

Post by samth »

samth wrote: post #92
substack wrote: post #61

I really dislike what they're doing with modules because it's such a step back from the commonjs-inspired require() that node uses. In node, require() just returns a value. That value is usually an object but often it's just a function. Why should a module that encapsulates exactly one function return anything else but that one function? In ES.next, you've got to use pythonesque `import y from Bar` statements which i…

I'll try to separate out the different issues you're raising here, and respond to each individually. 1. What if I want to have my module be a function, the way that $ in jQuery is both a function and a namespace for the rest of the functionality? This is an important use case, and so we're going to support it in ES6 modules. You'll be able to say: module $ at "http://jquery.com/jquery.min.js"; $(...) $.ajax(...) 2. M…

Since it came up on twitter, here's how you'd implement the `$` module I describe above:

    export function ajax(...) { ... };
    
    // NB: not how jQuery actually works ;)
    export this(query) { return document.find(query); };
The `export this` syntax specifies how the module instance object behaves when called as a function.
Post reply on HN