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

51–60 of 69 posts

Re: JavaScript is Dead. Long Live JavaScript

#51

Post by bzbarsky »

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…

Actually, the forEach version can end up faster than the let version... especially if you self-host forEach so that the JIT can do its job (e.g. inlining the LIB_addEventListener calls so there aren't actually any function invocations, etc).

Re: JavaScript is Dead. Long Live JavaScript

#52

Post by bzbarsky »

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…

His point is that if config.option is supposed to be an integer, not an object, then your proposed syntax falls down when trying to determine whether 0 was passed or whether nothing was passed.

Re: JavaScript is Dead. Long Live JavaScript

#53

Post by petermichaux »

nxn wrote: post #47

"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 rea…

You know how on January 10th, 2011 you were still writing 2010 by accident? I was off by a decade. Corrected.

Re: JavaScript is Dead. Long Live JavaScript

#54

Post by bzbarsky »

nxn wrote: post #32
azakai wrote: post #18

Earlier quoted context omitted.

1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer. 2. I don't think anyone but Microsoft would support .NET bytecode in the browser, simply because Microsoft controls .NET and has patents on it. It would take a lot more to reassure other browser vendors than Microsoft's existing CPs. 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on…

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

> which is already approaching a limit of how fast it can go

Do you have data to back this up? At least SpiderMonkey has projects in the works that give significant speedups on various workloads already, and lots of headroom left...

I would not be surprised to see another factor of 5 or so speedups on various code in the next few years in JS implementations.

Re: JavaScript is Dead. Long Live JavaScript

#57

Post by masklinn »

bzbarsky wrote: post #51
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…

Actually, the forEach version can end up faster than the let version... especially if you self-host forEach so that the JIT can do its job (e.g. inlining the LIB_addEventListener calls so there aren't actually any function invocations, etc).

> Actually, the forEach version can end up faster than the let version...

Theoretically maybe, but I've yet to see that. A regular `for(;;)` is generally 3-5 times faster than using `Array.prototype.forEach`.

Re. JIT, hand-rolling a foreach in javascript can be up to twice as fast as the native one, depending on the features you leave out.

Re: JavaScript is Dead. Long Live JavaScript

#58

Post by Stormbringer »

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…

So... what you're saying is that having better tooling is a bad thing?

Disclaimer: I've done GWT and I liked it.

I did not find any JavaJavascript paradigm shift problem at all. You simply forget about the Javascript and just write Java.

The big benefit of using GWT over writing 'native' javascript is that you get the same behaviour on all browsers.

The big benefit of using GWT over using other java based web frameworks is that GWT moves the client's state down to the client, where it belongs.

If you look at most other Java web frameworks like that (e.g. Struts and it's direct competitors), they expend enormous effort porting data to and from the client, and trying to hack around the limitations of the HTML post operation - namely that blank values aren't returned (checkboxes!!) and that everything is passed as text (numbers!!). So what these other frameworks do is they end up making you write all these model objects, and then try to simulate the client state. JSF is the worst of these as it takes it the furthest, they're not just emulating the model, but also the view as well with their overly-complex de-hydration and re-hydration of components.

If you tell the client state to bugger off back to the client where it belongs, you save a good 30-40% of your typical web framework effort right there.

Eliminating Javascript browser/version idiosyncrasies saves you another 20-30% of your effort (more if the UI is very dynamic, less if it isn't).

-----

I think you're posting on the basis of assumptions you've made based on what you've heard about GWT, rather than experience with it.

Re: JavaScript is Dead. Long Live JavaScript

#60

Post by aufreak3 »

kbd wrote: post #2

Great and thorough article. Here's a TLDR: * Javascript has some warts, and here are some examples. * 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. * To get around this problem, people are treating Javascript as a compilation target for other languages, the most prominent example being CoffeeScript. * Discu…

What if the standard could be changed from a language to a runtime specification? For example, a subset of LLVM assembler could play the role of a substrate (very much like what NaCl is doing) and leave the language part open. Runtimes with sufficiently rich capabilities can evolve over a much longer period than languages. This could liberate client-side coding from language specific-ness just like it doesn't matter what language you use on the server side.

That might sound a lot like Java, but it can can use some fresh thinking. I'm quite excited about NaCl on this front, for example.

Post reply on HN