Ask HN: Why not fix JavaScript?

https://news.ycombinator.com/item?id=2458088

by gary4gar • 15 years ago

33 46 15 years ago

news.ycombinator.com

Hello Hackers,

I have been learning JavaScript and have observed:

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.

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 & Coffee-script.

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 & disadvantages.

==My Question==

Why not fix the problem(Javascript Standard & 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?

And If there are some improvements coming into JavaScript language, how long we will have to wait till they hit mainstream?

madhouse• 15 years ago

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.

Jarred• 15 years ago

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?

phoboslab2• 15 years ago

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• 15 years ago

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.

BerislavLopac• 15 years ago

Actually, you don't even need CSS, all you need is HTML. So it comes down to two (any server-side language, basically, plus HTML), one of which is not even a programming language.

bad_user4• 15 years ago

Why is web development much more of a hassle than on the desktop?

Have you seriously tried developing for the desktop? What desktop? The one that has 90% market share and a dozen of GUI-toolkits available, including 3 official ones? Or was your app cross-platform? What GUI-toolkit have you used?

scrod2• 15 years ago

Probably because the web isn't actually an application platform at all, but is still fundamentally a medium for displaying static hyperlinked content on top of which has been piled an increasingly absurd series of hacks (forms + CGI, Cookies, Plugins, JavaScript, XMLHttpRequest, etc.), each in order to solve a different, unrelated problem. And so we then have to write "web frameworks" to smear the incongruities of these various functionality-hooks into an end-to-end system just to enable tolerable development methodologies.

If you want to make developing applications easier, then it will always be better to start with a platform that has actually been architected toward those ends from the beginning.

cageface5• 15 years ago

I can't find the words to express how much happier I am with to be working again on a platform (iOS) that was designed from the ground up to build rich UIs. HTML apps are such a grotesque heap of hacks in comparison.

bad_user4• 15 years ago

It is funny how people complain about web apps, but then the more complex a desktop app it is, the more the UI starts resembling a web application running on top of an embedded web browser.

Also, quick questions -- what other platform has a nearly 100% market penetration rate and how does that compare to the iPhone's Cocoa?

AND, with the iPhone's Cocoa you're not even allowed to distribute or update your app, without going through iTunes, both of which have been problems far worse than whatever any regular web stack has caused me.

Bitching about how web development sucks is NOT seeing the forest from the trees, because if you think about what web development enables, there is absolutely NO other alternative, and each of those little annoyances have a good reason for being there. And even though we could do with less cross-browser compatibility issues, I think I don't have to mention the shithole you're entering when doing cross-platform desktop UIs.

roel_v3• 15 years ago

"and why should developing on the web be so much more of a hassle than on the desktop?"

I guess with this you're implying that writing web software is harder than writing desktop apps, and to that I say 'LOL'. Even when one restricts himself to one platform (the easiest to develop for when you make some sacrifices - Windows), it's still a lot more work to get a 'real' application developed there than on the web. You need to include the whole cycle - running on various versions of the OS, application installation and updates, data backup etc. Believe me, the front end of web apps (and even the simple part of the backend, i.e. the parts without high scaling etc) are quite easy and high-level compared to the alternatives on the desktop.

cageface5• 15 years ago

Believe me, the front end of web apps (and even the simple part of the backend, i.e. the parts without high scaling etc) are quite easy and high-level compared to the alternatives on the desktop.

I've done plenty of work on both sides and this is only true if you're developing the kind of app that looks and acts like a fancy web page.

phoboslab2• 15 years ago

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

wh-uws• 15 years ago

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.

olegp• 15 years ago

Further to this, a lot of the problems one has with the DOM and browser differences are a non issue on the server where you tend to work with much more mature engines, such as Rhino or V8.

Our only minor gripe at Akshell (http://www.akshell.com), which incidentally the original poster should check out, is the hype around asynchronous I/O on the server.

It appears to be a case of premature optimization and tends to throw off new developers just starting out with the language. Since ease of development is our top priority, Akshell defaults to a synchronous model.

grimlck• 15 years ago

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.

phamilton2• 15 years ago

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_user4• 15 years ago

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 ;)

mburns• 15 years ago

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

olavk2• 15 years ago

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).

ggeorgovassilis2• 15 years ago

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• 15 years ago

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

ggeorgovassilis2• 15 years ago

Oops :D

aberkowitz• 15 years ago

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

dorkitude• 15 years ago

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).

pschlump• 15 years ago

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.

phamilton2• 15 years ago

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.

gary4gar2• 15 years ago

I would argue that Python & Ruby are pretty good general purpose programming languages & yet are easier to learn.

Hence, I don't buy your hypothesis that language has to be "hard" to learn; in-order to be useful.

yesbabyyes2• 15 years ago

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!

gary4gar2• 15 years ago

Easier said than done :(

yesbabyyes2• 15 years ago

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.

dualogy• 15 years ago

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 =)

neilk• 15 years ago

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_user4• 15 years ago

    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.

mrspeaker• 15 years ago

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

Yes. All of them!

edtechdev• 15 years ago

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.

X4• 15 years ago

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• 15 years ago

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.

Ask HN: Why not fix JavaScript?

Related Stories