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

JavaScript is Dead. Long Live JavaScript

peter.michaux.ca

Post reply on HN
Print view View original

41–50 of 69 posts

Re: JavaScript is Dead. Long Live JavaScript

#41

Post by clintjhill »

grimlck wrote: post #24
clintjhill wrote: post #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 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 pro…

Good questions/points.

I would only respond with that in particular, GWT is more than a compiler - it is as much a JRE as anything. So there is more to it. I personally don't see Google doing much public interaction with the development of the GWT compiler. If it's left to Google and its own time then my point remains.

JavaScript on the other hand really doesn't have a single organization leading it's development. Maybe this is an argument to be made about its perceived slow progress. Language design by committee is pretty slow.

More choice is good. Always. But right tool for the job should always win.

Re: JavaScript is Dead. Long Live JavaScript

#42

Post by petermichaux »

EGreg wrote: post #40
petermichaux wrote: post #28

Earlier quoted context omitted.

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?

Yeah, some features can be pushed into the language, but I like languages which have few rules. Like C and like CHESS :) My favorite languages are C, Java and Python though. So go figure...

If you like minimalistic languages, have you checked out Scheme? Because of its macros, the core language can stay small and the users can expand its syntax.

Re: JavaScript is Dead. Long Live JavaScript

#43

Post by nxn »

azakai wrote: post #36
nxn wrote: post #32

Earlier quoted context omitted.

>> 1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer. http://shootout.alioth.debian.org/u32/benchmark.php?test=all... >> 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on Mono (or the JVM for that matter), and compare them to native implementations of dynamic languages, in particular JavaScript and Lua. The native implementations bea…

1. The Alioth results are not necessarily final - they compare a single JS engine, and we have several fast ones now (SpiderMonkey with type inference can be significantly faster on some benchmarks, for example). Even so, the median speed there is 2X, which is fairly close. Admittably there are some bad cases though, in particular pidigits (badly written benchmark code? bug in v8?). 2. It is true that JS on Mono has…

In my opinion it makes no difference that we have several fast engines where some are faster at some things than others. When executing in the browser you don't get to pick and chose how and where your application will be executed. If you run into performance problems on one of the engines you can: A) dismiss a subset of your users and their performance problems, telling them to use a browser with a faster engine (they wont), B) only allow certain functionality based on a user agent string, or C) limit your applications scope to one that runs suitably in the slowest of the engines you're willing to support. In essence, if the application runs great in browser A but chokes in browser B, are you willing to say bye bye to your A users to take advantage of performance gains on B? I've been in this situation, and in my experience I've always had to look away from the faster browser rather than the user.

Outside the browser you probably have a little more freedom, but it's not like you get to pick and chose in the style of "Oh, I'll execute this function in V8 since it does this faster, and that function in SpiderMonkey since it's faster there". For this reason, I don't think the fact Alioth only has measures for one engine would make a significant difference in the overall comparison. You'd be, for the most part, gaining performance in one place by sacrificing in another.

Anyway, in my personal experience, I've ran into performance problems in JS a lot more often than with C#. I also have to go through a lot more tedious practices to ensure my JS code runs as fast as it can, where as in C# Some.lookup.with.lots.of.dots.does.not.scare.me(). That's why your claim sort of surprised me. Then again, the last serious JS performance problem I had was 6 months ago (before FF4), so maybe a lot has happened in those 6 months.

By the way, I'm not too informed on how type inference is done in SpiderMonkey, so I may be completely wrong in mentioning this, but it sounds like they're trying to speed up a dynamic language by mimicking static typing. If that's how far they're going to improve performance, maybe soon enough JavaScript will in fact sit better in the Mono/.NET/JVM?

Re: JavaScript is Dead. Long Live JavaScript

#44

Post by jacabado »

masklinn wrote: post #6

> If your application uses the let idiom, wouldn’t it be nice to have new syntax for it? Mozilla introduced this back in Firefox 2, and you can replace var with it, so TFAA's for (var i=0, ilen=elements.length; i becomes: for (let i=0, ilen=elements.length; i Of course, since this does not quite seem to be a tight loop you should be using Array.prototype.forEach instead: elements.forEach(function (element, i) { LIB_a…

Your example shows how the author's conclusions are wrong. IMHO the biggest milestones of Javascript life have been his libraries and the creative uses we have seen around them. From XMLHttpRequest to jQuery (and Prototype, Mootools, etc) and now Node.JS there have been highly disruptive innovations over this basically flawed language.

Maybe we should give more attention to the basic process behind this, creating libraries aka Programming Motherfucker.

Re: JavaScript is Dead. Long Live JavaScript

#45

Post by bgrohman »

bgrohman wrote: post #16
Joeri wrote: 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.

Oops, meant to say "compiling new versions of javascript to old versions", not the other way around.

Re: JavaScript is Dead. Long Live JavaScript

#46

Post by azakai »

nxn wrote: post #43
azakai wrote: post #36

Earlier quoted context omitted.

1. The Alioth results are not necessarily final - they compare a single JS engine, and we have several fast ones now (SpiderMonkey with type inference can be significantly faster on some benchmarks, for example). Even so, the median speed there is 2X, which is fairly close. Admittably there are some bad cases though, in particular pidigits (badly written benchmark code? bug in v8?). 2. It is true that JS on Mono has…

In my opinion it makes no difference that we have several fast engines where some are faster at some things than others. When executing in the browser you don't get to pick and chose how and where your application will be executed. If you run into performance problems on one of the engines you can: A) dismiss a subset of your users and their performance problems, telling them to use a browser with a faster engine (th…

I agree with your point about multiple JS engines, indeed you can't pick and choose the best results. What I was trying to say is just that the best results we see are an indication of where things are going. But again, I agree, we are not there yet and right now, each user has just one JS engine, and problems on some benchmarks. Static languages have much more consistent performance.

About the last 6 months: Yes, a lot happened during that time, namely FF4's JaegerMonkey and Chrome's Crankshaft. Both are significant improvements.

About typing, yes, in a way that could let this code run faster inside the JVM or Mono. If you can figure out the types, you can generate fast statically typed code for those VMs. However, type analysis can be both static and dynamic, should integrate with the PICs and so forth. So even with that, I don't expect dynamic languages to be able to run very fast on static language VMs.

Re: JavaScript is Dead. Long Live JavaScript

#47

Post by nxn »

"In 1997, I collected a list of languages with compilers to JavaScript. There were JavaScript extension languages: the now-defunct ECMAScript 4, Narrative JavaScript, and Objective-J. There were pre-existing languages: Scheme, Common Lisp, Smalltalk, Ruby, Python, Java, C#, Haskell, etc. There were even brand new languages HaXe, Milescript, Links, Flapjax that were designed to address web programming needs."

Am I reading this right? Objective-J (2008), C# (2001), HaXe (2005), etc having compilers to javascript in 1997?

Re: JavaScript is Dead. Long Live JavaScript

#48

Post by Wilfred »

apl wrote: post #13
rhizome wrote: 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?

It is, though that's not very surprising. Here's a quick proof:

S-K combinators[1] are a Turing-complete subset of lambda calculus. Here's an implementation of them:

  k = (x) ->
    (y) -> x
  
  s = (x) ->
    (y) ->
      (z) -> x(z)(y(z))
1: http://en.wikipedia.org/wiki/SKI_combinator_calculus

Re: JavaScript is Dead. Long Live JavaScript

#49

Post by seanp2k »

I really hate when "X is dead; long live X!" is misused like this. The original phrase is "The king is dead; long live the king!", used when the OLD king died and the NEW king takes over.

Googling around, I see tons of misuse: Example of bad usage: "White Stripes are dead (long live white stripes)"

Example of proper usage: "Palm is dead; long live Palm!" (this would mean that Palm got acquired or reformed) "Paper is dead; long live paper!" (could be proper if used in an article about how paper for PRINTING is dead but paper lives on in other forms)

REF: http://en.wikipedia.org/wiki/The_King_is_dead._Long_live_the....

Re: JavaScript is Dead. Long Live JavaScript

#50

Post by Groxx »

nxn wrote: post #35

"Optional Parameters and Default Values" Since JavaScript will still invoke a function call even if the number of arguments don't match up, parameter defaults will not completely eliminate all the problems he lists. function(a = 1, b = "Smith", option = {}) { .. } Will still break upon trying to invoke it without parameter 'b' since param 'option' will just take its place while option will become an empty object. Fur…

I'm very much in agreement with objects-as-named-params. Default params just mitigate the problem, ambiguous function calling still rears its head as soon as you have multiple optional arguments of the same type.

As to the "option = option || {}", he was referring to the ultimate "option = {}" assignment if you passed a falsy value (0, "", false), which is different than if you didn't pass a value (undefined). Which is resolved by "option = option === undefined ? option : {}", which is even larger and kinda ugly.

Post reply on HN