JavaScript is an elegant and truly flexible language - very well suited to the roll we have given it in remote (and until recently) pretty simplistic client environments.
I suggest that your issues are not with JavaScript per se but with managing the flow of data and functionality between the server and the client. I am not suggesting that will become easy but, with experience, you will find workmanlike solutions.
> JavaScript is an elegant and truly flexible language
To me it looks like it has a beautiful prototype-OO language trapped inside it somewhere. The point is more I'd rather get the work done with the tools I like than be forced to learn it.
> very well suited to the roll we have given it in remote (and until recently) pretty simplistic client environments
I find strange that what suits the environment is a language instead of a bytecode interpreter of some sort. Lua seems to have pretty compact implementations for example.
> I suggest that your issues are not with JavaScript per se but with managing the flow of data and functionality between the server and the client. I am not suggesting that will become easy but, with experience, you will find workmanlike solutions.
I have issues with that I know but what I always feel is that I am struggling with that plus figuring out how to properly iterate an array or implement a dictionary (both things I've found to be ugly and/or non-trivial in Javascript)
>I'd rather get the work done with the tools I like
Well you can - within your own computing environment but when you want to reach out and run code on your user's computer then you have to take the tools available. In this instance we have a (broadly) common language that runs on Windows, Mac, Linux and then some - thats pretty amazing.
<language instead of a bytecode interpreter
It would be trite to point out that what you have "under the hood" in JavaScript implementations is a pretty good JIT bytecode interpreter. JavaScript code represents a fully portable version of the code that will run in the user chosen browser on the user chosen hardware platform.
<properly iterate an array
Just picking on of your points here - It may be that you can solve each obstacle just the once and retain that solution into the future. As an example try https://developer.mozilla.org/en/JavaScript/Reference/Global... for how to add "forEach" functionality to an array - an array which (of course) can contain objects of any type. I just love the ability to work with arrays (collections) of objects representing server side classes.
>In this instance we have a (broadly) common language that runs on Windows, Mac, Linux and then some - thats pretty amazing.
We have enough VM's that can do the same, it's not really a technical issue, which is what frustrates me.
>It would be trite to point out that what you have "under the hood" in JavaScript implementations is a pretty good JIT bytecode interpreter.
Yep, and I'd rather be able to target that.
> JavaScript code represents a fully portable version of the code that will run in the user chosen browser on the user chosen hardware platform.
It isn't fully portable really. Much less than any standardized bytecode anyway. One thing I've also struggled with is that I not only have to figure out Javascript I have to figure out each browser's take on it. I've had the same code fail subtly on Chrome while working fine on Firefox.
> for how to add "forEach" functionality to an array
I implemented this kind of thing in my own code and it works although the "block" syntax is a bit ugly ("function() {}").
> I just love the ability to work with arrays (collections) of objects representing server side classes.
I'm not sure what you mean here. One bit that has frustrated me is replicating in Javascript code what I already have for the same concepts/models in Rails. Although some of that is surely bad separation between client and server on my part.
You are probably aware of these anyway but - just in case...
jQuery (and other frameworks) deal with almost all browser compatibility issues when it comes to the UI.
JSON is a great format for passing class properties from server to client and back again making it reasonably straightforward to connect (via AJAX) JavaScript objects with server side classes.
I think the problem he's highlighting is with the browser executing a specific language. If it used a bytecode system, like JVM, CLR, or similar, you could still use Javascript--just compiled down to the appropriate bytecode. But others could use Ruby, or Python, or Java, or C#, or any other language that can be compiled to the appropriate bytecode.
Many people have laughed after Joel Spolski for Wasabi. Well, Joel had the right idea: just use whatever in-house language you want, just be careful to translate it in a language/platform your customers are more likely to have installed already,
Because I'd probably still prefer to write Javascript than Java. But a GWT approach is one possible solution and there are some Ruby projects that do similar things. None are production ready though. For reference:
First of all - shipping binary code to browsers. Please. No. Flash is bad enough. Say good bye to all the grease monkey style hacks and remixes and lots of other interesting things about the web.
Secondly - either you are a programmer or not. I can't actually tell from your article if you want to be or not. However if you want to be a good programmer then you need to learn other languages - you might not be an expert in those other languages but being able to navigate your way round them - it is good for your programmers brain. Eric Raymonds famous article actually recommends you should try and learn a new language every year http://www.catb.org/esr/faqs/hacker-howto.html
And thirdly - Javascript is actually a real cool language masquerading as a very dull mainstream one. I resisted doing too much in it for years but as I needed to do more and more
I found out that its very powerful and flexible. Also if you use something like jquery you get a lot of Ruby style bits and pieces.
And lastly - it might be a cliche but that doesn't mean its not true (to use another cliche in defence of the one I am about to use) - If all you have is a hammer then every thing looks like a nail. Ruby might be a pretty good language - but there is a reason there are so many other languages and its not because all the other people are idiots who weren't smart enough to come up with Ruby.
>First of all - shipping binary code to browsers. Please. No. Flash is bad enough. Say good bye to all the grease monkey style hacks and remixes and lots of other interesting things about the web.
Monkey patching bytecode may very well be harder but is that really used? Greasemonkey is marginal at best. What other things do you have in mind?
>Secondly - either you are a programmer or not. I can't actually tell from your article if you want to be or not. However if you want to be a good programmer then you need to learn other languages - you might not be an expert in those other languages but being able to navigate your way round them - it is good for your programmers brain.
I've learned plenty of languages and do appreciate some of the points of Javascript. I just don't see why everyone seems to defend it as the one-true-language for the client side. For everything else people make plenty of diverse choices yet somehow on the one platform that for historical reasons is stuck with a single language saying you'd rather use another implies somehow that you don't get it.
>And thirdly - Javascript is actually a real cool language masquerading as a very dull mainstream one. I resisted doing too much in it for years but as I needed to do more and more I found out that its very powerful and flexible. Also if you use something like jquery you get a lot of Ruby style bits and pieces.
I am using jQuery and it does have some goodies. The point isn't that with effort I couldn't make myself more comfortable with it. The point is that I don't see much that Javascript gives me that Ruby doesn't. So the fact I am forced to use Javascript is a net-negative for me.
>If all you have is a hammer then every thing looks like a nail. Ruby might be a pretty good language - but there is a reason there are so many other languages and its not because all the other people are idiots who weren't smart enough to come up with Ruby.
Certainly. And I do use other languages. The reason I'd like to be able to use Ruby for both codebases is that that would allow me to do interesting stuff I can't right now.
In fact the same criticism can be made of Javascript, that because it's the only hammer available everything looks like a nail. I'm proposing more languages, not less.
That most of the web (and obviously Flash is the exception to this) is text based is not an accident. Browsers and people are not the only thing reading the web - there are crawlers and other tools doing this, that and the other. Search engine crawlers for example go into the javascript and extract links.
Also I really don't think you have thought it through as a developer - its bad enough debugging stuff in browser without it being compiled and only having basically machine code to look at.
I don't think its the one true language for anyone to be honest - but expecting the browser to ship with several languages in it doesn't appeal to anyone either (and I know you just want a few byte code runtimes in but I cannot see how that would work while still maintaining all the richness and complexity of the web as it stands)
anyway - I think if there was any appetite to do anything about this problem it would have been done by now. There were people grumbling about it 10 years ago and I've seen a number of projects to add languages come and go.
> That most of the web (and obviously Flash is the exception to this) is text based is not an accident. Browsers and people are not the only thing reading the web - there are crawlers and other tools doing this, that and the other. Search engine crawlers for example go into the javascript and extract links.
I can see how that is important for the strings in the code but I'm not aware of many use cases for crawling the actual javascript code.
>Also I really don't think you have thought it through as a developer - its bad enough debugging stuff in browser without it being compiled and only having basically machine code to look at.
If I want to debug javascript I need Firebug or Chrome's tools and those can very well have support for a standard debugger.
>but expecting the browser to ship with several languages in it doesn't appeal to anyone either (and I know you just want a few byte code runtimes
I just want one standard bytecode runtime. I can ship and have the user cache whatever runtime I need.
> but I cannot see how that would work while still maintaining all the richness and complexity of the web as it stands)
I still don't see what web richness is there to be had inside the <script> tag. Seems to me all the uses of it that aren't simply execution are marginal at best.
>anyway - I think if there was any appetite to do anything about this problem it would have been done by now. There were people grumbling about it 10 years ago and I've seen a number of projects to add languages come and go.
It seems to have been enough of a problem for google to have built GWT. I wonder why they haven't shipped a Dalvik VM in Chrome and have their GWT apps target the VM on Android and Chrome and Javascript for everyone else. Is V8 execution these days comparable to a good JVM/CLR?
I suspect this is becoming a bit fruitless because it seems like your tack is - "I can't imagine anything other than the way I want to use the web"
But let me just mention one other view:
The browser, despite the inconsistencies between different brands, is very accessible. Anyone with the ability to peck away at a keyboard and read some basic instructions can make a web page - and with only a little more effort add some quite rich functionality even if only by cutting and pasting some javascript.
Now imagine if instead you needed a compiler and an SDK (see footnote), if you couldn't just shove a bit of code in the page but instead it needed to be compiled and included separately.
Would the web be what it is today?
Look at Java and Flash - why aren't they the dominant forces on the web because they are taking very much the approach you advocate.
footnote: and who would make these? Would you have one for every browser, for every language. Who would maintain them? In fact the more thought I give to it the more impressed I am that there is anything like one single common language available in all browsers
The problem with more languages is that you fragment the community. Maybe it'd indeed be nice to use Ruby instead of Javascript for a project or two. But I don't think something like jQuery would be simple to port over and maintain (especially considering that the mobile landscape is even more nightmarish than desktop cross browser support). And what about plugins?
And what happens when you get the odd client that wants you to do some work for them and it so happens they are using I don't know, PHP or Java on the client-side? (or CL or Scheme, if that's your cup of coffee)
The server-side is a good example of the fragmentation I mentioned. There are classes of projects that are hopelessly redundant (e.g. minimalist MVC frameworks), and classes of projects that only exist/work in some languages for various reasons (e.g. async MySQL APIs).
In an ideal world, I'd prefer if there weren't so many languages that do essentially the same thing with different syntaxes, but then again, standardization in itself is its own little can of worms (the short story being that it involves a lot of politics).
"First of all - shipping binary code to browsers. Please. No. Flash is bad enough. Say good bye to all the grease monkey style hacks and remixes and lots of other interesting things about the web"
I don't see how browsers interpreting compiled bytecode would prevent greasemonkey-style hacks.
He's not talking about binary code. He's talking about bytecode with the same security restrictions Javascript has, with the only difference being that a bytecode language is optimized for being a target of compilers, otherwise you have to be Google to make a functional compiler targeting Javascript.
Flash is bad enough
He's not talking about Java Applets or Flash either, he's talking about shipping a bytecode interpreter/compiler instead of a Javascript interpreter/compiler.
if you want to be a good programmer then you need to learn other
languages
I'm increasingly frustrated by having to learn programming languages, not for productivity, not because I'm learning useful new things, but because a certain platform requires it.
Eric Raymonds famous article actually recommends you should try and
learn a new language every year
I would take Eric's advice with a grain of salt: far more useful is to learn new algorithms, data structures, some design skills or do some math learning / exercises every year. Or how about sharping those marketing skills by reading some books / travelling / investing in some offshore relationships?
Learning a language that's similar to what you already know is a waist of time. And if you properly learn C++, Haskell and Lisp you're pretty much done with everything there is to know about programming languages.
Javascript is actually a real cool language masquerading as a very dull
mainstream one
IMHO, programming languages cannot be separated from their mainstream implementation, as many people seem to suggest. No matter how cool Javascript is, you're going to feel the pain related to browser issues.
If all you have is a hammer then every thing looks like a nail
Except that most programming languages are hammers of various sizes with a steeper learning curve than a library that could give you the same productivity.
I'm afraid all this seems like pedantic nit-picking to me - attacking the letter of what I said rather than what I was trying to say.
However I did want to comment on my favourite line in this: " if you properly learn C++, Haskell and Lisp "
Yes. If you properly learn them I would fully agree.
I have in my time made my living as both a C++ programmer and a Lisp programmer and was pretty good at both - but not even close to having properly learned either.
Learning them properly would be a life times experience and I suspect you would be a pretty decent programmer at the end of it.
And lets be clear: we are talking about IronPython working and manipulating the browser's DOM here, not the in-a-box model of Flash.
Unfortunately, problems with Silverlight: proprietary, not cross-platform enough, not popular enough, Gestalt is loading slowly because it has to download stuff, the IronPython interpreter not fast enough.
Some of these are solvable, but if it isn't a standard implemented by everybody, then it's useless.
I think this is an important question to ask. I don't think the OP is asking it for quite the right reasons, but I still think it's important.
As web developers, we're all about 'openness', 'choice' and other warm fuzzy concepts. So why is it OK that JavaScript is the only client side option?
the script element has 'language' and 'type' attributes, clearly indicating the possibility of other types of script (indeed, microsoft used to support VBScript in web pages, don't know if they still do).
To address some of your points:
1) Implementation isn't important. Sure, don't ship binaries to browsers. That's just a detail, the main point is why can't we ship anything other than JS?
3) JS is a cool language. So what? JPG is a cool format, doesn't mean there's no room for PNG too.
4) If all you have is JavaScript then everything looks like a JS problem.
TL;DR: I don't actually understand how JavaScript works, but I thought writing a nonsense article demonstrating my willingness to bash it nonetheless with an aggressive headline and post it on HN myself would bring me some desperately needed attention.
The OP deliberately wrote a rant about something he doesn't understand with an attention-grabbing headline and I called him out on it. I don't think that's unkind. I would have assumed good faith were it not for him explicitly stating he actually doesn't want to learn JavaScript but still wants to bash it.
You seem to be focusing of if I know Javascript or not. I don't know enough and I am learning. So it's not that I don't care. It's that I don't understand why Javascript being the only option on the client side is OK somehow. I've changed the title to be less aggressive.
If I do or do not know Javascript is actually tangential to my point. What I find strange is that the browser environment forces a language on developers and that is seen as OK. When apple was adding language/framework restrictions to the AppStore people were screaming bloody murder but somehow the browser status quo is fine.
That being said the title was probably too agressive. The original was not very descriptive and it was what I came up with on the spot.
The AppStore restrictions are top-down decisions for commercial reasons.
Whereas the web ecosystem has evolved this way.
You can write code that compiles to bytecode to run on a browser -- applets, Flash, Silverlight -- but for various evolutionary reasons, none of them have become dominant over JS.
It's like being cross about how few air-breathing fish there are, and writing to HN to complain.
>The AppStore restrictions are top-down decisions for commercial reasons.
>Whereas the web ecosystem has evolved this way.
>It's like being cross about how few air-breathing fish there are, and writing to HN to complain.
It was a rant about how things turned out. I'm not expecting anyone to go out and build something I'd like better. But it does surprise that most people think it's OK that an increasingly more important environment is limited to a single language. I was attacking Javascript as a single choice more than Javascript as a language, but I should have probably have made that more explicit as there were plenty of comments about how this was just me not knowing enough Javascript.
>You can write code that compiles to bytecode to run on a browser -- applets, Flash, Silverlight -- but for various evolutionary reasons, none of them have become dominant over JS.
All of those are ways to run code inside a box inside a webpage. None really replace Javascript as a DOM manipulator with a bytecode. I don't think there has ever been any portable option besides Javascript (or emitting Javascript from something else) to do scripting on a page that isn't constrained inside Flash/Applet.
I do see what you mean about the lack of choice, although I'd rather have all browsers implement one language consistently and and well, rather than a number of languages flakily and non-universally.
The compiling-to-JS idea has a lot of potential I reckon. I've done a couple of GWT projects and the results work very well, much better than if I'd written the JS myself, and not noticeably slow. And debugging the app in Eclipse is so much nicer than using a JS debugger.
I hated JS for years, but started to love it in the last couple of months. In my experience, as long as you're not prejudiced and dont judge JS for its flaws, it will treat you very well.
I have actually, that's the book I took with me. It made me understand the language more and just highlighted how it has an interesting model behind it (e.g., prototype and async) and a pretty bad syntax in front of it (e.g., constructor stuff).
38 comments
[ 3.6 ms ] story [ 93.7 ms ] threadJavaScript is an elegant and truly flexible language - very well suited to the roll we have given it in remote (and until recently) pretty simplistic client environments.
I suggest that your issues are not with JavaScript per se but with managing the flow of data and functionality between the server and the client. I am not suggesting that will become easy but, with experience, you will find workmanlike solutions.
It's starting with a bit of rage though :)
> JavaScript is an elegant and truly flexible language
To me it looks like it has a beautiful prototype-OO language trapped inside it somewhere. The point is more I'd rather get the work done with the tools I like than be forced to learn it.
> very well suited to the roll we have given it in remote (and until recently) pretty simplistic client environments
I find strange that what suits the environment is a language instead of a bytecode interpreter of some sort. Lua seems to have pretty compact implementations for example.
> I suggest that your issues are not with JavaScript per se but with managing the flow of data and functionality between the server and the client. I am not suggesting that will become easy but, with experience, you will find workmanlike solutions.
I have issues with that I know but what I always feel is that I am struggling with that plus figuring out how to properly iterate an array or implement a dictionary (both things I've found to be ugly and/or non-trivial in Javascript)
>I'd rather get the work done with the tools I like Well you can - within your own computing environment but when you want to reach out and run code on your user's computer then you have to take the tools available. In this instance we have a (broadly) common language that runs on Windows, Mac, Linux and then some - thats pretty amazing.
<language instead of a bytecode interpreter It would be trite to point out that what you have "under the hood" in JavaScript implementations is a pretty good JIT bytecode interpreter. JavaScript code represents a fully portable version of the code that will run in the user chosen browser on the user chosen hardware platform.
<properly iterate an array Just picking on of your points here - It may be that you can solve each obstacle just the once and retain that solution into the future. As an example try https://developer.mozilla.org/en/JavaScript/Reference/Global... for how to add "forEach" functionality to an array - an array which (of course) can contain objects of any type. I just love the ability to work with arrays (collections) of objects representing server side classes.
>In this instance we have a (broadly) common language that runs on Windows, Mac, Linux and then some - thats pretty amazing.
We have enough VM's that can do the same, it's not really a technical issue, which is what frustrates me.
>It would be trite to point out that what you have "under the hood" in JavaScript implementations is a pretty good JIT bytecode interpreter.
Yep, and I'd rather be able to target that.
> JavaScript code represents a fully portable version of the code that will run in the user chosen browser on the user chosen hardware platform.
It isn't fully portable really. Much less than any standardized bytecode anyway. One thing I've also struggled with is that I not only have to figure out Javascript I have to figure out each browser's take on it. I've had the same code fail subtly on Chrome while working fine on Firefox.
> for how to add "forEach" functionality to an array
I implemented this kind of thing in my own code and it works although the "block" syntax is a bit ugly ("function() {}").
> I just love the ability to work with arrays (collections) of objects representing server side classes.
I'm not sure what you mean here. One bit that has frustrated me is replicating in Javascript code what I already have for the same concepts/models in Rails. Although some of that is surely bad separation between client and server on my part.
jQuery (and other frameworks) deal with almost all browser compatibility issues when it comes to the UI.
JSON is a great format for passing class properties from server to client and back again making it reasonably straightforward to connect (via AJAX) JavaScript objects with server side classes.
I'd bet most browsers have a JVM installed as well, so there's that...
[1]http://jashkenas.github.com/coffee-script/
Many people have laughed after Joel Spolski for Wasabi. Well, Joel had the right idea: just use whatever in-house language you want, just be careful to translate it in a language/platform your customers are more likely to have installed already,
http://hotruby.yukoba.jp/ - Implements the YARV (ruby 1.9) bytecode in Javascript (most promising one in my view) http://github.com/mneumann/rubyjs - Compiles a subset of Ruby code to Javascript
However sometimes it's important to get function over form?
First of all - shipping binary code to browsers. Please. No. Flash is bad enough. Say good bye to all the grease monkey style hacks and remixes and lots of other interesting things about the web.
Secondly - either you are a programmer or not. I can't actually tell from your article if you want to be or not. However if you want to be a good programmer then you need to learn other languages - you might not be an expert in those other languages but being able to navigate your way round them - it is good for your programmers brain. Eric Raymonds famous article actually recommends you should try and learn a new language every year http://www.catb.org/esr/faqs/hacker-howto.html
And thirdly - Javascript is actually a real cool language masquerading as a very dull mainstream one. I resisted doing too much in it for years but as I needed to do more and more I found out that its very powerful and flexible. Also if you use something like jquery you get a lot of Ruby style bits and pieces.
And lastly - it might be a cliche but that doesn't mean its not true (to use another cliche in defence of the one I am about to use) - If all you have is a hammer then every thing looks like a nail. Ruby might be a pretty good language - but there is a reason there are so many other languages and its not because all the other people are idiots who weren't smart enough to come up with Ruby.
Monkey patching bytecode may very well be harder but is that really used? Greasemonkey is marginal at best. What other things do you have in mind?
>Secondly - either you are a programmer or not. I can't actually tell from your article if you want to be or not. However if you want to be a good programmer then you need to learn other languages - you might not be an expert in those other languages but being able to navigate your way round them - it is good for your programmers brain.
I've learned plenty of languages and do appreciate some of the points of Javascript. I just don't see why everyone seems to defend it as the one-true-language for the client side. For everything else people make plenty of diverse choices yet somehow on the one platform that for historical reasons is stuck with a single language saying you'd rather use another implies somehow that you don't get it.
>And thirdly - Javascript is actually a real cool language masquerading as a very dull mainstream one. I resisted doing too much in it for years but as I needed to do more and more I found out that its very powerful and flexible. Also if you use something like jquery you get a lot of Ruby style bits and pieces.
I am using jQuery and it does have some goodies. The point isn't that with effort I couldn't make myself more comfortable with it. The point is that I don't see much that Javascript gives me that Ruby doesn't. So the fact I am forced to use Javascript is a net-negative for me.
>If all you have is a hammer then every thing looks like a nail. Ruby might be a pretty good language - but there is a reason there are so many other languages and its not because all the other people are idiots who weren't smart enough to come up with Ruby.
Certainly. And I do use other languages. The reason I'd like to be able to use Ruby for both codebases is that that would allow me to do interesting stuff I can't right now.
In fact the same criticism can be made of Javascript, that because it's the only hammer available everything looks like a nail. I'm proposing more languages, not less.
Also I really don't think you have thought it through as a developer - its bad enough debugging stuff in browser without it being compiled and only having basically machine code to look at.
I don't think its the one true language for anyone to be honest - but expecting the browser to ship with several languages in it doesn't appeal to anyone either (and I know you just want a few byte code runtimes in but I cannot see how that would work while still maintaining all the richness and complexity of the web as it stands)
anyway - I think if there was any appetite to do anything about this problem it would have been done by now. There were people grumbling about it 10 years ago and I've seen a number of projects to add languages come and go.
I can see how that is important for the strings in the code but I'm not aware of many use cases for crawling the actual javascript code.
>Also I really don't think you have thought it through as a developer - its bad enough debugging stuff in browser without it being compiled and only having basically machine code to look at.
If I want to debug javascript I need Firebug or Chrome's tools and those can very well have support for a standard debugger.
>but expecting the browser to ship with several languages in it doesn't appeal to anyone either (and I know you just want a few byte code runtimes
I just want one standard bytecode runtime. I can ship and have the user cache whatever runtime I need.
> but I cannot see how that would work while still maintaining all the richness and complexity of the web as it stands)
I still don't see what web richness is there to be had inside the <script> tag. Seems to me all the uses of it that aren't simply execution are marginal at best.
>anyway - I think if there was any appetite to do anything about this problem it would have been done by now. There were people grumbling about it 10 years ago and I've seen a number of projects to add languages come and go.
It seems to have been enough of a problem for google to have built GWT. I wonder why they haven't shipped a Dalvik VM in Chrome and have their GWT apps target the VM on Android and Chrome and Javascript for everyone else. Is V8 execution these days comparable to a good JVM/CLR?
But let me just mention one other view:
The browser, despite the inconsistencies between different brands, is very accessible. Anyone with the ability to peck away at a keyboard and read some basic instructions can make a web page - and with only a little more effort add some quite rich functionality even if only by cutting and pasting some javascript.
Now imagine if instead you needed a compiler and an SDK (see footnote), if you couldn't just shove a bit of code in the page but instead it needed to be compiled and included separately.
Would the web be what it is today?
Look at Java and Flash - why aren't they the dominant forces on the web because they are taking very much the approach you advocate.
footnote: and who would make these? Would you have one for every browser, for every language. Who would maintain them? In fact the more thought I give to it the more impressed I am that there is anything like one single common language available in all browsers
And what happens when you get the odd client that wants you to do some work for them and it so happens they are using I don't know, PHP or Java on the client-side? (or CL or Scheme, if that's your cup of coffee)
In an ideal world, I'd prefer if there weren't so many languages that do essentially the same thing with different syntaxes, but then again, standardization in itself is its own little can of worms (the short story being that it involves a lot of politics).
I don't see how browsers interpreting compiled bytecode would prevent greasemonkey-style hacks.
Learning a language that's similar to what you already know is a waist of time. And if you properly learn C++, Haskell and Lisp you're pretty much done with everything there is to know about programming languages.
IMHO, programming languages cannot be separated from their mainstream implementation, as many people seem to suggest. No matter how cool Javascript is, you're going to feel the pain related to browser issues. Except that most programming languages are hammers of various sizes with a steeper learning curve than a library that could give you the same productivity.Case in point for Java programmers: http://www.playframework.org/
However I did want to comment on my favourite line in this: " if you properly learn C++, Haskell and Lisp "
Yes. If you properly learn them I would fully agree.
I have in my time made my living as both a C++ programmer and a Lisp programmer and was pretty good at both - but not even close to having properly learned either.
Learning them properly would be a life times experience and I suspect you would be a pretty decent programmer at the end of it.
To some extent, people can have this right now. Here's what you can do with Silverlight + the Gestalt script (yay, Python): http://ironpython.net/browser/gettingstarted.html
And lets be clear: we are talking about IronPython working and manipulating the browser's DOM here, not the in-a-box model of Flash.
Unfortunately, problems with Silverlight: proprietary, not cross-platform enough, not popular enough, Gestalt is loading slowly because it has to download stuff, the IronPython interpreter not fast enough.
Some of these are solvable, but if it isn't a standard implemented by everybody, then it's useless.
As web developers, we're all about 'openness', 'choice' and other warm fuzzy concepts. So why is it OK that JavaScript is the only client side option?
the script element has 'language' and 'type' attributes, clearly indicating the possibility of other types of script (indeed, microsoft used to support VBScript in web pages, don't know if they still do).
To address some of your points:
1) Implementation isn't important. Sure, don't ship binaries to browsers. That's just a detail, the main point is why can't we ship anything other than JS?
3) JS is a cool language. So what? JPG is a cool format, doesn't mean there's no room for PNG too.
4) If all you have is JavaScript then everything looks like a JS problem.
That being said the title was probably too agressive. The original was not very descriptive and it was what I came up with on the spot.
Whereas the web ecosystem has evolved this way.
You can write code that compiles to bytecode to run on a browser -- applets, Flash, Silverlight -- but for various evolutionary reasons, none of them have become dominant over JS.
It's like being cross about how few air-breathing fish there are, and writing to HN to complain.
It was a rant about how things turned out. I'm not expecting anyone to go out and build something I'd like better. But it does surprise that most people think it's OK that an increasingly more important environment is limited to a single language. I was attacking Javascript as a single choice more than Javascript as a language, but I should have probably have made that more explicit as there were plenty of comments about how this was just me not knowing enough Javascript.
>You can write code that compiles to bytecode to run on a browser -- applets, Flash, Silverlight -- but for various evolutionary reasons, none of them have become dominant over JS.
All of those are ways to run code inside a box inside a webpage. None really replace Javascript as a DOM manipulator with a bytecode. I don't think there has ever been any portable option besides Javascript (or emitting Javascript from something else) to do scripting on a page that isn't constrained inside Flash/Applet.
The compiling-to-JS idea has a lot of potential I reckon. I've done a couple of GWT projects and the results work very well, much better than if I'd written the JS myself, and not noticeably slow. And debugging the app in Eclipse is so much nicer than using a JS debugger.
When I got into web dev, I got several gigs doing IE-specific sites in VBScript.
Think how much worse it could have been if JS hadn't won.
1) invent a type that the browser current doesn't understand like: application/ruby-script
2) write a parser for it in JavaScript
3) Profit??
It would look like this:
<script type="application/ruby-script">
//your browser will ignore this but your parser won't
//sorry I don't do ruby to come up with an example
</script>
<script src="yourawsomerubyparser.js">