Live data from Hacker News

JavaScript is Dead. Long Live JavaScript

peter.michaux.ca

21–30 of 69 posts

Re: JavaScript is Dead. Long Live JavaScript

#21
post #13
post #12

Earlier quoted context omitted.

I hope someone writes a decompiler for one of these supra-JS languages (not sure if CoffeeScript is Turing-complete) to run against existing Javascript codebases. It could well speed up adoption if a mass-tangle of JS can be boiled down to a more readable and understandable structure.

> not sure if CoffeeScript is Turing-complete Wait, why wouldn't it be?

Heck if I know, I'm not CS trained.

Point being, CoffeeScript and other compilers would get a big boost if someone came out with a way to convert existing JS codebases into these new, more readable, more maintainable (as the story goes) representations.

Re: JavaScript is Dead. Long Live JavaScript

#22
"Do you want to maintain a compiler? Does anyone on your team have the skills to do that? That ulcer is going to get pretty big while you prepare to explain to the CEO that you now need to rewrite the UI in JavaScript."

GWT could be really strong. But it's this single maintainer problem that I think prevents it's penetration into the market.

Sadly when I hear people talk about the "strengths" of GWT, debugging and IDE debuggers is what I hear most. If that is the core reason for using GWT it seems shortsighted.

And for me personally I find that using Java (static typed system) to compile down to JavaScript (dynamic function system) is too big a paradigm switch for developers to maintain. Other languages, specifically functional type languages are far better for maintaining language paradigms in compiler situations.

Re: JavaScript is Dead. Long Live JavaScript

#23
post #21
post #13

Earlier quoted context omitted.

> not sure if CoffeeScript is Turing-complete Wait, why wouldn't it be?

Heck if I know, I'm not CS trained. Point being, CoffeeScript and other compilers would get a big boost if someone came out with a way to convert existing JS codebases into these new, more readable, more maintainable (as the story goes) representations.

js2cs - https://github.com/mindynamics/js2cs

Though I've found doing the conversion manually is a better way to learn CoffeeScript. Plus, it is a point for optimization and refactoring since CoffeeScript allows for doing certain things more easily or in better ways. The automated conversion only does so much.

Re: JavaScript is Dead. Long Live JavaScript

#24

"Do you want to maintain a compiler? Does anyone on your team have the skills to do that? That ulcer is going to get pretty big while you prepare to explain to the CEO that you now need to rewrite the UI in JavaScript." GWT could be really strong. But it's this single maintainer problem that I think prevents it's penetration into the market. Sadly when I hear people talk about the "strengths" of GWT, debugging and ID…

Why isn't the 'single maintainer problem' a concern with other programming languages? What language DOESN'T have a single organization leading its development? Even worse, some projects (incl. coffeescript) seem to be controlled by just a handful of individuals who can easily be hit by a bus, hired away to do something else, lose interest, etc.

I think the only way to defend against that is to have an open source project, and to have a sufficiently large user base such that someone is sure to take over if the owners drop the project.

I think the strength of GWT is that for some languages/teams, a statically typed language is more appropriate than a dynamic language. And isn't more choice a good thing? Avoid the whole 'this is a hammer, everything else is a nail' approach?

I do agree that some teams choose GWT for inappropriate reasons though.

Re: JavaScript is Dead. Long Live JavaScript

#25

I like the prediction, but I think the biggest hurdle to compiled javascript will be mobile browser usage. The javascript interpreters in the mobile browsers right now are dog slow compared to their desktop cousins.

Android 2.2 and later uses Google's V8 JIT. iOS 4.3 and later uses Apple's Nitro JIT. Firefox 4 and Opera 11 also have JIT compilers enabled for ARM devices.

Mobile processors are still slower than desktop ones, of course, but JavaScript on mobile today is already faster than JavaScript on desktop just a few years ago. For example, the benchmarks on http://arewefastyet.com/ show V8 running only about 5x slower on an nVidia Tegra 250 ARM board than it does on an Intel Core 2 Duo Mac Mini.

Re: JavaScript is Dead. Long Live JavaScript

#26
post #4

He calls inheritance in Javascript a wart. It's one of its major strengths, IMO: the fact that you can directly override methods for a single object. Class inheritance, as he'd like to see, is not all it's cracked up to be. Just look at Java with its anonymous inner classes, for one incredibly ugly construct... BTW an easy way to produce traditional class inheritance in Javascript is to have a single instance from th…

Yeah, javascript's prototypal inheritance is flexible enough to simulate classical inheritance. I wouldn't call that a wart. http://www.prototypejs.org/learn/class-inheritance http://dojotoolkit.org/reference-guide/dojo/declare.html Plus, I tend to prefer prototypal inheritance to classical inheritance. I do agree that the constructor pattern using the new keyword and the prototype object is a bit odd, but that's not…

The wart is that since classical inheritance isn't built into the language, we get:

1) Crummy syntax. 2) Everybody doing it a different way.

Re: JavaScript is Dead. Long Live JavaScript

#27
Why not just have a library in Javascript, for example:

  Q.each(arr, function(i) {
     this.rocks();
     arr.pop(); // watch out doing this in the loop
     arr.push('foo'); // watch out doing this in the loop
  });

  Q.each(obj, function(k) {
     this.rocks();
     delete obj[k]; // should be safe maybe
  });

  var p = Q.pipe(crazy stuff involving pipes and callbacks)
  doSql("SELECT * FROM users", p.fill('users'));

  getUsers = Q.getter(getUsers); // turns it into a really  smart getter

  getUsers = Q.batch(getUsers); // turns into into a batched getter
and lots of other stuff

Why must the language take care of everything for you when libraries can do it? That has been the case with C, C++ and other languages.

Re: JavaScript is Dead. Long Live JavaScript

#28
post #27

Why not just have a library in Javascript, for example: Q.each(arr, function(i) { this.rocks(); arr.pop(); // watch out doing this in the loop arr.push('foo'); // watch out doing this in the loop }); Q.each(obj, function(k) { this.rocks(); delete obj[k]; // should be safe maybe }); var p = Q.pipe(crazy stuff involving pipes and callbacks) doSql("SELECT * FROM users", p.fill('users')); getUsers = Q.getter(getUsers); /…

Features that can be added through libraries should be added that way. You cannot add new syntax which involves scoping of variables through libraries. How would you do destructuring assignments with a library and have it as succinct as it can be done with syntax?

Re: JavaScript is Dead. Long Live JavaScript

#29
post #9

Earlier quoted context omitted.

"It's going to take way too long to get these fixed to the point that we can actually start using new versions of Javascript because of slow browser adoption." Which isn't true, because you could compile newer versions of javascript to older versions. I see languages like coffeescript as interesting experiments in how the language can evolve, but eventually it needs to come back home to javascript and get deployed na…

Seeing how a handful of ideas in CoffeeScript have been rumored to be included in the next JS release, it seems like individual experimental language design might be the way to push for change.

Yes but many of the ideas in CoffeeScript were likely slated for ES.next before CoffeeScript. So it has been working in both directions.

Re: JavaScript is Dead. Long Live JavaScript

#30
post #9

Earlier quoted context omitted.

"It's going to take way too long to get these fixed to the point that we can actually start using new versions of Javascript because of slow browser adoption." Which isn't true, because you could compile newer versions of javascript to older versions. I see languages like coffeescript as interesting experiments in how the language can evolve, but eventually it needs to come back home to javascript and get deployed na…

Good point. I hadn't thought of compiling old versions of javascript to new versions - that keeps everyone writing in the same language and seems like a better solution to me.

There was an ES4-to-ES3 compiler. The Traceur compiler takes many of the Harmony ideas and compiles to ES3.
Post reply on HN