Hacker News Reader

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

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.

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.

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.

    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.

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

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.

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

Oops :D

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?

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/

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.

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?

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.

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?

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.

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.

Excellent point. Thats the same experience I had when moved to the flash platform, some years back.

Now that I am coming back to html-javascript, i can help but feel frustrated by the mess that is html app development.

My dream for the web platform, would be that the committees would create some kind of underlying bytecode and basic graphic primitives. On top of which different programming languages and graphic Apis could be implemented. Then, to develop hyperlinked documents, you can use an hyperlinked document oriented API. To develop complex UI, you can use a complex UI oriented API.

Maybe the web is now near that goal. Javascript could be the bytecode. And the DOM (wich I hate with passion) could be replaced by a GUI toolkit build on top of the html canvas. I would love to work on that, if I had time available.

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.

I'd say each of the annoyances has a historical reason for being there, but not a real reason as in "this is just the best way to do it". You make it sound like it's a cohesive platform that was designed to fulfill particular goals from the start, but it definitely wasn't.

I agree with you about the value of the web platform. It has a lot of advantages, especially from a business perspective, but it doesn't mean that it's a good platform.

This isn't the case for the desktop apps I care about at all. Ableton Live, Photoshop, XCode, MetaSynth, dozens of plugins for same, any number of video editors, look and feel nothing at all like a web app. Web-based versions of these will not be competitive any time in the forseeable future.

Your concerns about Apple's policies are legitimate but orthogonal.

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

I don't know, why don't you ask an iOS developer?

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

My straw man development team claims to have no problems with deployment.

iOS? Cross-platform compatibility? It looks like you posted this in response to someone else's comment.

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

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.

You mean "the kind of web app" or "the kind of desktop app"? Native desktop apps are usually very tedious to develop, even with high-level tools like Visual Basic. Even for simple CRUD apps, the amount of layouting you need to do, input validation etc; all of those rote tasks are much more automated in web frameworks than they ever were in desktop development tools. The kind of things you can do with a few lines of jQuery in terms of UI manipulation are miles beyond what was even reasonably possible (meaning, wouldn't take weeks of work) in desktop applications.

Sure, CRUD apps should almost always be web apps. If you want a richer UI or need to do any serious local computation the web stack is a poor choice.

The entire reason I've gone back to native apps after 10+ years of web dev is that I find the kinds of apps well suited for the web to generally be very boring.

No, what I meant was - what side of the argument are you on, 'desktop apps are harder' or 'web apps are harder' ? ('harder' can be 'more difficult' or 'more tedious' - I'm not making any moral judgements here, my point was that web apps can be made faster and with less knowledge of details that nobody should really know in the first place).

I guess it depends on what desktop stack you're using. It's certainly far easier to toss together a CRUD app with Rails than it is with MFC. "4GL" environments like Powerbuilder make this pretty easy on the desktop too but people don't seem to use them much anymore.

It's certainly a lot easier to build a multi-user app as a web app.

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.

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.

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

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

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!

Easier said than done :(

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.

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.

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

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

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.

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!

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.

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.

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.

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

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

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

Ask HN: Why not fix JavaScript?