
Ask HN: Why not fix JavaScript? - gary4gar
Hello Hackers,<p>I have been learning JavaScript and have observed:<p>1) Most programmers program using javascript libraries(e.g jQuery), whose syntax is not even vaguely similar to pure javascript which often gives so called jQuery programmers a shock when they attempt to do things in Javascript. I would agrue that less than 1% of so called web programmers can do pure javascript programming.<p>2) Some Popular web frameworks have resorted to choosing altogether different language that "compiles into Javascript". If its not clear I am talking about Ruby on Rails &#38; Coffee-script.<p>In-short,
JavaScript does have not-so-good parts and people are using workarounds to get those bad things to behave nicely.  so as a new Developer looking to learn JavaScript. I face this dilemma of choosing between a) Pure Js b)JS libraries C) language that "compiles into Javascript". And what I have observed there is no right choice, each has its own advantages &#38; disadvantages.<p>==My Question==<p>Why not fix the problem(Javascript Standard &#38; its implementations), instead of replying on hackery workarounds that further fragments web-development ecosystem? Aren't workaround are going to hurt us in longer term?<p>And If there are some improvements coming into JavaScript language, how long we will have to wait till they hit mainstream?
======
phoboslab
JavaScript - without a doubt - has it's quirks, but it's a very nice and
elegant language if you can restrict yourself to a subset of its features. The
ECMAScript 5 standard and the Strict Mode[1] fix some of JavaScript's design
problems. It's already implemented in Firefox 4 and should arrive soon-ish in
Chrome (v8) and Safari (JavaScriptCore).

Also, jQuery doesn't "fix" JavaScript, it "fixes" the DOM. I.e. jQuery and
many other libraries, have little to no use for programming games (shameless
plug: e.g. with Impact[2]) or server side stuff. And some of jQuery's ideas
have already been implemented natively in browsers[3].

JavaScript is extremely flexible and allows implementations of other languages
like Coffescript with relative ease. I don't see a problem with
"fragmentation"; it drives innovation.

[1] <https://developer.mozilla.org/en/JavaScript/Strict_mode>

[2] <http://impactjs.com/>

[3]
[https://developer.mozilla.org/en/DOM/document.querySelectorA...](https://developer.mozilla.org/en/DOM/document.querySelectorAll)

~~~
wh-uws
Yeah a lot of people conflate JavaScript with the DOM because the only place
most people see js is in a browser where one of its major purposes is
manipulating the DOM. Admittedly the DOM has had a checkered past.

But js's story is much bigger than that.

Also I would argue that jQuery just uses a different set of the language's
syntax than many programmers would ever encounter just coming from the c-style
languages.

It forces you to use closures before many programmers actually know what one
is. Some never do or never need to.

------
neilk
I think your unstated assumption is that everything you describe shows that
JavaScript is broken. I feel your pain, but a lot of your complaints show just
how successful JavaScript really is.

It has libraries to abstract away differences in the underlying platforms --
obscures the miracle that it basically works on different platforms, even
written by bitter competitors. What was the last language to do that? C? Perl?

It allows the programmer to create new abstractions like jQuery -- again, this
is because of the _good_ parts. It's highly dynamic. Even if JavaScript had
all of jQuery from day one, people would still be writing frameworks to reach
the next level of abstraction.

As for languages that treat JavaScript as assembly; well, it depends.
Sometimes the motivation is to write better applications -- like, people want
to define server-client communication at a higher level, or use similar
representations of the same concepts on server and client. But that's more of
a flaw of the browser (or server) platform, not JavaScript the language. It
wouldn't be fixed if we suddenly had python in the browser as a viable
scripting language.

The last category are people who treat JS as assembly because it's missing
features, as a language, like types, or asynchronous communication, or
internationalization. Now these really do show where the flaws in the language
are, in my opinion. Some of this is being addressed in newer versions of the
language.

~~~
bad_user

        people who treat JS as assembly because it's
        missing features, as a language
    

Not all features are equal, and what some people might call a "feature",
others might call a "flaw". Treating Javascript as assembly is perfectly
acceptable.

------
dualogy
Your dilemma is analysis paralysis. jQuery is widely popular because of what
it accomplishes, not just its syntax. And its syntax is totally "pure"
JavaScript. How could anyone understand jQuery code that couldn't grok "pure"
JS? jQuery is pure JS and does not radically alter the syntax.

The other camp, CoffeeScript (which I use and love) or "Objective-J"... yes
they are different languages that compile to JavaScript but why does it bother
you? Check out if you like or need them -- if not, stick to JS with or without
libraries.

Now get busy =)

------
ggeorgovassilis
Hello gary4gar,

1) Libraries offer functionality, they don't change the nature of the
language. With this respect, jQuery & al. are not different from libraries you
use with java or .Net. This is the same thing as considering the browser API
(DOM etc) to be the JRE lib in Java and other libraries just extending the
functionality.

2) Or the Google Web Toolkit which uses the Browser's Javascript engine as a
form of bytecode interpreter. It is an efficient technique allowing for very
compact programmes.

Javascript won't be changed (too much) because it is not broken - it brings an
untyped system, closures and other goodies which just recently entered java,
not to mention the benefit that it speeds up development because it does not
require compilation. Adding libraries and frameworks is what happens just
alike to any other programming language which allows other users to bring in
new functionality and a different way of thinking.

~~~
njs12345
Minor nitpick - JavaScript is dynamically typed rather than untyped :)

~~~
ggeorgovassilis
Oops :D

------
Jarred
An even better question is "Why does it take at least four different languages
for database-backed web applications, and why should developing on the web be
so much more of a hassle than on the desktop?

~~~
phoboslab
You can use JavaScript client side in the browser (duh) as well as on the
server (e.g. with NodeJS[1]) and your database (e.g. with CouchDB[2]). The
only other languages you need are HTML and CSS. That makes 3, not 4 ;)

[1] <http://nodejs.org/>

[2] <http://couchdb.apache.org/>

~~~
flomo
Aside from recent developments like NodeJS, the lack of interest in JavaScript
as a server-side language is really weird. Both Microsoft and Netscape had
JavaScript server scripting back in the 1990s, but people instead glommed onto
ad-hoc languages written from scratch (PHP) or plucked others out of complete
obscurity (Ruby) and made them successful.

I can't help to think that history would have been completely different if
someone had created an Apache mod_js 10 years ago.

~~~
olavk
JavaScript is all we have on the client side, but on the server you can choose
the best tool for the job. Languages like Ruby and Python are basically
supersets of the semantics of JavaScript, but with many more features and
large standard libraries. And these languages evolve, while JavaScript have
been basically frozen for a decade. The server side language have well-tested
libraries for working with the file system, databases and so on.

JavaScript is a nice, minimal language, but a bunch of other languages are
just better when you are not constrained by the browser.

Besides, the benefit of having the same language on client and server might
not be so great. Sure it looks nicer, but the programming model on client and
server is quite different anyway.

Node.js is interesting. I suspect the users will soon want some syntactic
sugar for dealing with asynchronicity (something like the new "await" keyword
in C#). This is also neede on the client side, but much harder to get support
for. But if they extend JS on the server side, does it make sense to compile
down to vanilla JS rather that just forking the language?

------
madhouse
If you'd 'fix' javascript, you'd still have to wait for browsers to support
the new version, and they would have to support the old js until there are
pages out there that use it. Which means pretty much forever.

At which point, the fixed language becomes irrelevant, as it cannot replace
the older one.

------
grimlck
Is it a workaround that your CPU doesn't run C++ code directly and instead
runs assembly, and a compiler is needed to convert C++ to assembly?

The answer is obviously no, so how are 1) and 2) any different? I think they
are great things - they encourage competition and allow for much more rapid
progress than if there were a single monolithic framework and language that
everyone was forced to use. Trying to create a single perfect platform that
makes everyone happy is an impossible task.

~~~
phamilton
I think it would be interesting though, for browsers to implement a Javascript
VM which would allow compilations to byte code from any supported language,
rather than source to source translations. Similar to the many languages that
compile to run on a JVM (JRuby, Jython, Scala, etc.)

~~~
bad_user
Javascript is very dynamic, and it is a decent target from any source
language.

And although it would be really cool, I wouldn't want a browser bytecode,
because it would make Javascript harder to optimize, while also not improving
too much the lives of language developers.

You're mentioning the JVM, but there's a problem with that example. The JVM is
freakin' heavy, and optimizations are parts of that. Google had to come up
with their own bytecode for Android to lighten the pipeline for mobile phones,
and Rhino is a lot worse performance-wise than V8 -- there is not such thing
as a language-neutral VM / bytecode that's also efficient. Go ask the
developer of Lua-JIT about it ;)

------
yesbabyyes
Hi gary4gar, Brendan Eich is working on the next version and parts of it will
be inspired by CoffeeScript. That said, you will probably be well off learning
all three!

~~~
gary4gar
Easier said than done :(

~~~
yesbabyyes
Maybe but I find that both jQuery and CoffeeScript shine a good light on
JavaScript's functional side.

I really think you will learn to write better JS by studying it along with CS.
When you get the feel of it, I don't think you'll find jQuery that strange.

------
edtechdev
A 'simpler' solution would be to simply offer a complete alternative to
javascript in the browser. If they released a new, fixed version of
javascript, it would take at least a few years for the other browsers to catch
up, assuming they even do (IE won't).

They actually did work out how to 'fix' many of javascript's issues over 10
years ago with the Javascript 2 proposal, but it never happened.
<http://www.mozilla.org/js/language/js20-2000-07/index.html> If they had
simply added type annotations, for example, javascript would be an order of
magnitude faster today, and pretty much every language out there could easily
compile to javascript without losing any speed or features.

------
aberkowitz
How can you call it fragmentation when everything ultimately turns into valid
JavaScript?

------
X4
That's is simple. You're watching it from the wrong perspective dude. When
DSLs/Frameworks/Libraries/ spread around languages, it's a strong indicator
that the language is highly valueable, but not abstract enough to like it.

What I mean is that it's not easily understandable, fullstop. That's a simple
reason for, why people create jQuery,CofeeScript,SproutCore and many other
Abstraction Layers.

You will see that only the fittest will survive!

Your question is at the bottom of your post, irony.. Javascript's roots are
anchored at the bottom too, you cannot just unearth it and plant it into
another pot. But you can graft it :)

Evolution Baby!!

------
adrianoconnor
The answer is pretty simple: whatever 'fix' you come up with will only last
until somebody tries doing yet something else that you hadn't anticipated. At
that point, you'll be back to square one.

This is the magic of human ingenuity. It has nothing to do with standards and
best practices. That said, Javascript (as a standard) is obviously plenty good
enough to let us coerce it in to doing all of these thing (like jQuery,
Coffee-script, node.js and so on), that I'd say the people who have steered
Javascrip over the years have done a pretty good job, all considered.

------
mrspeaker
It's easy to say "just fix it" but it the history behind JavaScript is complex
and wacky - and one persons problem is another persons super-powerful closure.
If you really want to know the nuts & bolts then you have to watch the
Crockford on JavaScript series:
[http://developer.yahoo.com/yui/theater/video.php?v=crockonjs...](http://developer.yahoo.com/yui/theater/video.php?v=crockonjs-1)

Yes. All of them!

------
pschlump
There is no problem to fix - JavaScript is the 2nd best language. LISP is
better. KnR C is 3rd. No good language is easy to learn and understand.

~~~
phamilton
Unless a language's sole purpose to be easy to learn and understand. Then by
definition it's a great language.

Use the right tools for the right job. A jewelers file is pretty worthless if
you are building a house. Likewise a hammer isn't very useful in the finishing
touches of a diamond ring.

------
mburns
Microsoft threw a fit when Adobe proposed a significantly improved version of
Javascript (inspired by modern ActionScript, not surprisingly).

~~~
olavk
That is only partially true. Microsoft actually released JScript.net, which
was an implementation of the proposal on the .net platform. Later they changed
strategy and decided they didn't want to support the proposal, and JScript.net
is not supported anymore. But the fact remains that MS has delivered the only
other implementation of the (now rejected) proposal apart from ActionScript
(AFAIK).

------
dorkitude
Because it would take roughly 1 billion years for those standards to have
actual, web-wide meaning (thanks in no small part to the popularity of
Microsoft's so-called browsers).

