Ask HN: Why not fix JavaScript?
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?
46 comments
[ 3.5 ms ] story [ 92.6 ms ] threadAt which point, the fixed language becomes irrelevant, as it cannot replace the older one.
[1] http://nodejs.org/
[2] http://couchdb.apache.org/
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 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?
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?
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.
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.
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 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.
Your concerns about Apple's policies are legitimate but orthogonal.
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.
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.
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.
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.
It's certainly a lot easier to build a multi-user app as a web app.
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...
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.
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.
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.
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 ;)
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.
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.
Hence, I don't buy your hypothesis that language has to be "hard" to learn; in-order to be useful.
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.
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 =)
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.
Yes. All of them!
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.
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!!
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.