JavaScript isn't really important for non-web development. I used to program video games for hand held consoles and JavaScript was the last thing on my mind.
Okay, maybe I was working for the unmentioned 1% (and for what it's worth, the company I currently work for uses JavaScript). And really, it's not a bad idea to learn JavaScript - it's pretty ubiquitous and chances are you will work for a company that uses it at some point in your career. But honestly, I'm getting a little sick of all these articles that seem to forget that there is more to programming than web apps.
Don't know what you mean by this comment. There already are plenty of games written exclusively in Javascript. I've written a couple myself. Even if you exclude html5/websockets, it's entirely possible to write a server/client game, even a complex one, just with AJAX (Asynchronous JAVASCRIPT And Xml). And that's not even counting the tons of singleplayer games, hell look at the JS1k and JS10k contests, most if not all of the entries were games.
Yep, exactly. I expect that as node.js rises in popularity in general, JavaScript's use as an embedded game scripting language will rise (possibly at the expense of Lua and Python).
Actually now that I write this, I wonder about the possibility of JavaScript game scripting combined with something capability-aware like Caja for hosted game mods. Could be an interesting area to explore.
There is a robust implementation of JavaScript for the JVM (Rhino), part of which even ships with Java 6, so scripting a Java-based game seems a straightforward step. On .NET, JScript similarly seems to be an almost first-class citizen (though, unlike Rhino, I've never used it).
LUA and ActionScript (for UI work mostly) are well represented in games companies already, I would think JavaScript will get some exposure if someone goes the extra mile to open their UI in the way that Blizzard have done to addon development (LUA).
If you're writing games with Unity, there's a good chance you'll be using Javascript, as they have implemented Mono/Javascript (with their own extensions) as one of the engine's main languages.
Of course, DOM is utterly irrelevant here, just wanted to point out its use in games.
the very popular Unity3D engine supports JavaScript as a scripting language btw. Many people use that to develop iOS/Android games and even Browser/PC/Mac games.
Same here on regular consoles. We did use lua and once UnrealScript and the reduction in iteration time to seconds was worth any loss of speed in the short term (i.e. discover the game, then downcode what you need to later).
However, times have changed. The kind of games i'm interested in are ubiquitous in nature. I want to interact with it on the console, the iPhone, the PC, and on the web. I want to write tools that are cross platform. The browser is the ultimate cross platform.
Yeah, we actually did use Lua on some of our games. I'm not saying JavaScript is too slow for games, or can't be used for games, just that it wasn't very useful for console development at the time I was doing that. Plenty of games have been written in JavaScript, although almost all of them are web-based games (and I specifically said it's not that useful for non-web development).
I very reluctantly conceded this point a few years ago, but in a slightly different way. I've been doing JavaScript-as-a-kludge-for-whatever-server-side-framework-I-happen-to-discover-the-limitations-of for a while. I'm discovering that the complexity of every browser's quirks means I'm going to have to do more than just "learn it". And therein lies the problem.
JavaScript isn't an awful language (all languages have their pluses and minuses and developers are so touchy on this subject, I don't even want to broach it). It's the sheer number of platforms (browser/hardware/OS combinations) that make JavaScript painful to learn properly. Every browser on every device must perform adequately. It's not a matter of supporting Windows or MacOS, it's every variant of RIM device, i* device, every browser on Windows Mobile taking into account the performance/memory footprint (to a lesser extent anymore), and devices with browser variants running on Android.
For the sake of my current set of projects -- requiring reasonable compatibility across platforms, but not a universally good user experience on all, learning jQuery became a necessity. Though I'd prefer to not be framework dependent, I've found that understanding how to use jQuery has also improved my understanding of the various quirky implementations of JavaScript in general.
I have no doubt that future projects will require a good user experience on most platforms. Does anyone have any suggestions regarding good, comprehensive resources in this area? The blog post mentions several online resources for folks wishing to learn/understand the language (some of which I haven't used before), but I'm wondering if there are particularly excellent tools beyond that (IDEs, good debuggers beyond Firebug) or anything else out there that can assist in identifying code that won't work, or won't work well in cross platform scenarios (for free or not).
I have found that between firebug and chrome you can generally nail down most bugs. What one does not catch the other does. IE is a whole different beast you have to have visual studio to do any decent level of debugging and it is still painfull. That said sticking to a toolkit eliminates a good deal of the cross platform cross browser issues. 9 times out of 10 when we do have an issue it is css rather than javascript hat bites us. We use Dojo or jQuery for projects depending on size and both are good at smoothing out the inconsistancies as long as you color in the lines.
Adobe uses js for a lot of application scripting as well as web dev, and have a variety of tools you can try for free. IIRC their newish Flex Builder IDE has js syntax highlighting, debugging, and more, and they have some cross-browser testing tools in their labs too.
"If you asked me 3 years ago what language you should learn I would’ve said Ruby. If you asked me 6 years ago, it was PHP."
You should have concluded that you're not the best person to give advice on what programming language a person should learn. Anyway, the right answer is C++, and the rest will follow.
I agree that JavaScript is a very good thing to learn, but it seems odd that the article doesn't even mention server-side JS. Yes, jQuery is wonderful, but a large share of the things that are getting people excited in the JS community lately revolve around Node, Socket.io, and other attempts to break JavaScript out of its DOM playground.
Criticism aside, it's good to see articles like this. There are more subtleties to JS than a lot of people realize. Instead of getting frustrated and blaming the language when it doesn't behave like [insert favorite language here], one should take the time to study its fundamentals.
To be honest, that was implied. I only used client side as the beginning point because it's the one with the least amount of fuss to setup and the quickest reward. It was trying to be encouraging and encourage core JavaScript education.
You should know that the server side technologies are a big piece of the inspiration for writing this. I'm sorry I didn't convey that correctly.
While we're on the subject, why is JavaScript the only language available for the browser? I can run tons of languages from the command line since they all follow the shebang (#!) convention. Why can't I run Python or Ruby with the <script> tag?
It seems like any language that had appropriate DOM bindings should be able to run so long as the user's browser has the appropriate interpreter. (Kind of like a plugin, but for embedded interpreted languages.) For example:
Although you can compile the syntax of Python or Ruby into JavaScript fairly easily, the semantics don't match up very well.
You can run <script type="text/coffeescript"> today. All of the interactive bits on CoffeeScript.org are implemented with it -- and here's an example of a site that uses it for something a little more creative (View Source):
Not to mention that coffescript will work on any javascript runtime, not only browsers. It works on rhino, on node, for scripting Qt, and anywhere you can run js.
Lambdas in Python are so pitiful compared to javascript's closures that I think this would be a very bad choice, although you're welcome to disagree with me completely, since this is completely subjective.
This might not be a bad idea for a future project like a hypothetic HTML6, but I still think it's a bad idea _in general_. The web has consistently been about standards, and enabling developers to write code once that runs on many platforms (although the realities of browsers' quirks means that you will need to endlessly tweak your code to work on a given platform). Were we to allow developers to write in any suitable language, there would be much much more work on the part of end users and browser developers to make sure that their system is up to date with the latest language X plugin so that websites that use language X as a scripting language function well/correctly.
In short, this is a bad idea because it would fracture the web, when really we should be embracing standards that make the web simpler and easier for everyone to use.
JavaScript is not the only language available for the browser. ActionScript (Flash) is also available in many browsers, albeit fewer every day. Also, most browsers have a Java run-time for "applets."
Anyone sufficiently motivated and competent could write a browser plugin that holds a run-time for Python, Ruby, C#, whatever. The problem is getting people to install it or to get the browser makers to include it as a default. By historical fluke JavaScript got baked in to browsers early on.
The number of Flash-enabled browsers is not getting "fewer every day"; it's growing. The ratio, however, is probably falling, given the rise of mobile and decent alternatives for things like video.
If you want it to be secure and compatible, you'd have to download implementation of the language in form of bytecode for a virtual machine.
We've had that already, and it didn't go too well:
<applet>
Also, until all current browsers (including IE9) die, any such script will be unusable or will have awful performance nad slow start caused by compatibility shim.
We're stuck with JS, because it happened to be first one that's good enough. Cost/benefit of having multiple built-in run-times (that won't be more mature and interoperable anytime soon) or adding a VM is too large.
Wouldn't it be a bit of a security risk for browsers to let web sites specify what languages can run? Get rid of the downloadfrom attribute and select from a list of options acceptable to the browser. But then you have the challenge getting your favorite language accepted by all the browsers
Maybe the next standard should require support for an additional language. The competition would benefit everybody. Even if we just put all the language names in a hat and pick one, we'd be on a better path than we are now.
If the other languages have the same constraints as JavaScript why would it be any less secure?
The real problem is getting the language deployed on a critical mass of browsers.
You can do it today by compiling to JavaScript. See: Objective-J, CoffeeScript, Gordon (Flash), GWT (Java), Pyjamas (Python), ParenScript (Lisp), HotRuby (Ruby), haXe, etc.
But of course JavaScript isn't exactly the best language to target, and it could be a lot faster if there were a secure low level VM we could target. Something like the JVM, LLVM, or NativeClient. Then the language runtime could simply be downloaded the first time a page requiring the language is loaded.
That's not really Python or Ruby in the browser, that's IronPython or IronRuby running in the Silverlight's CLR via the plugin. Yes your Silverlight app can get out to the DOM and vice versa, but it's not really what Silverlight was meant for.
If you want to be pedantic and get into a debate nothing is really ruby as the language lacks a spec the best definition of Ruby we have is acts kinda like MRI 1.8.
Also, most browsers don't run really run Javascript, they run ECMAscript or JScript. It's really jQuery converted to bytecode/assembly/C on SpiderMonkey/JagerMonkey/V8/Nitro. Sure you can create a high performance web server, but that's not really what V8 was meant for.
Since 2005 JavaScript has become the underground Lingua Franca of Internet.
And now the underground is reaching the surface, JavaScript isn't that slow anymore.
At this point, I see no solution to escape it. I agree, unfortunately, you must use JavaScript. Or die in obscurity (that later one is a little bit an exageration).
It simply "makes sense" to have the client do as much of the job as possible so that the server does as little as possible.
* rich interactions without back-and-forth server trips.
* What's on client-side can technically be saved on client-side. Thus, making distributed setup possible. And that contributes to lower bandwidth bill.
* client hardware is no longer wimpy, why not use all those CPU cycles on users' laptop/iphone/ipad/android/etc.
Back in the heyday of Netscape, I did JavaScript client-side development as part of web development. It was often frustrating work.
Recently I began reading Crockford's "JavaScript: The Good Parts". I must admit that, as I make my way through the book, I find myself shaking my head in amazement at the idiosyncracies and weaknesses remaining in the language. It was a clumsy language then and remains one now. But it's the only show in town where the browser is concerned.
Crockford claims that, by restricting oneself to a subset of JavaScript (i.e., the "Good Parts" of the title), one can do what is necessary. He writes also about the bad and awful parts of JavaScript. I am thankful that Crockford had the skill to discern signal where I saw noise, and the patience to carry out and publish his reorganization.
But reading about JavaScript is still good for laughs!
It's true that it's easy to write very bad JavaScript when you're first starting out, but I rarely run into those problems any more now that I've learned which corners of the language to avoid.
I don't always agree with Crockford's decisions on what's good and bad, but overall he's right, and that's why it's important to use a book like "The Good Parts" when you're learning it. That said, I always recommend "JavaScript: The Definitive Guide" as well.
This isn't a game, there are no hard and fast rules. You can be successful in this world as a highschool dropout and you can live in abject poverty with a PhD in economics.
Learn JavaScript, or don't. In about a year, you'll be able to do Python and Ruby in the browser. I'm pretty sure there are JavaScript libraries that will do a conversion for you right now, but Mozilla is pushing to have native support for it anyway. I mean, what was the point of having the DOM if you weren't ever going to access it from anything but JavaScript? You can do C# and VB in the browser right now, too (SilverLight).
But really, learn every language. There is no "killer language" to learn. You should be learning them all. And once you get 10 or so under your belt, the others come with little effort. Languages aren't special. They're mostly all the same.
edit: and if you thought 6 years ago that PHP was the hot language and 3 years ago Ruby was the hot language, you have only been paying attention to your little corner of the world and need to get out more.
That's a bit unfair. I actually program in Python, it's not a language war I'm fighting here. My point was to point out a language that would be a marketable skill which 3 years ago Rails was really kicking into high gear. This was not a matter of a "killer language". JavaScript has its quirks just like all of them. A tool is a tool is a tool is a tool.
You can be as pragmatic and all-language-embracing as you like, but you eventually have to come to a conclusion, damn it. It's my conclusion that JavaScript is a necessary tool in the tool belt of web developer.
That being said the irony of you using your little corner of the world to insult my little corner of the world was a bit disheartening. I assure you that the general populace of my corner are now sad and are taking down the "Welcome your little corner" banners and polka-dot party hats we were preparing for your arrival.
I think it's fair to speculate a language's future market share as this allows us to anticipate demand. I think most modern languages are "good languages", but the application of JS is skyrocketing. I use javascript as a storage medium , web server, in the browser, native mobile apps (appcelerator) and more.
"In about a year, you'll be able to do Python and Ruby in the browser."
No, in about a year you'll be able to do Python and Ruby in X% of browsers, where X is depressingly small.
Depending on what segment of users you're targeting you're stuck with JavaScript for probably between 2 and 8 years, and that's assuming Mozilla and other actually start putting other languages in the browser immediately.
That's languages that can be compiled to JavaScript and execute relatively efficiently. And Flash, Silverlight, Java, but those are only useful for a certain class of web app.
But JavaScript really isn't that bad. You should learn it.
The title here should probably be something along the lines of "You Should Develop For The Web." Javascript happens to be the focus because it is THE client-side language on the web.
By the way, when were Python and Ruby declared to be absolutely available in any given browser (chrome, safari, firefox, opera, ie9 at least) within a year? Either I've been underneath a rock, or this is absolutely crazy.
"In about a year, you'll be able to do Python and Ruby in the browser."
I've been hoping for something like this. But I don't see any indication that it's going to be a reality any time soon. Did you see this somewhere, or is it just wishful thinking?
Also, even if it comes to a browser, how long until it's in place on all mainstream browsers? (I'm looking at you, IE)
I vehemently disagree with the message of the post. It's unnecessary to suggest that anybody must learn anything, let alone JavaScript in the browser. Plenty of technologies exist that abstract away the need to know JavaScript and allow a developer to focus solely on their application rather than the underlying technologies that allow their application to run on a target platform (note, I'm a co-founder of one such technology, http://www.noloh.com).
Similarly, I wouldn't demand that anyone learn assembly or C. While it can be useful in certain situations to have that knowledge it's most definitely not necessary. It's perfectly acceptable to learn and use a higher level language, whether it's NOLOH or one of many other tools and languages that generate the necessary JavaScript or other underlying code. This has the benefits of freeing the developer up to concentrate on their application, while allowing the producers of such tools to worry about the numerous implementation details regarding the many different target platforms. This also has the benefit of allowing for easier porting to non JavaScript platforms.
Clearly if you're somewhat religious about having to know and being able to reproduce all the underlying architecture that runs your application then you must learn JavaScript, but for many others, using a language they know, or learning a higher level language can fully allow them to focus on their applications is ideal.
There also exists a middle ground, for example in the case of NOLOH, if the developer knows some of the basics of JavaScript they can create, or wrap existing 3rd party JavaScript widgets or modules, but extensive knowledge of JavaScript is not necessary, and the truth of the matter is that the vast majority of developers are not of that type, but rather looks to use an existing module created by someone of that type.
Thus, I would argue that if you're a developer of a particular type, either one that's religious, or one that plans to create certain types of client modules or wrap/integrate client modules with little to no API, then you must learn JavaScript, but for the vast majority I believe it's becoming increasingly less necessary.
C probably isn't a good counter-example. You really ought to learn it if you don't already know it. Coming from a managed-memory scripting language, the concepts you'll pick up along the way are foundational to becoming a well-rounded programmer.
I think its becoming increasingly less necessary to learn something else. I think javascript is, after a decade or so, finally coming into its own. I agree that one should use a library that lets someone else deal with the inevitable bullshit of browser compatibility. The question is then, "what language should I use"? I used GWT for example, since I know Java, and I assume there are people who will find noloh easy to pick up because they already know the language. However, javascript is a high level language, so references to assembly and C are straw men. Noloh and GWT add yet another layer of abstraction on top of an already complex system. They offer little advantage beyond familiarity, and prevent comprehension of the system as it really is.
Referencing C and assembly are not straw men, in the context of the web and the browser they serve equivalent purposes.
They offer little advantage beyond familiarity, and prevent comprehension of the system as it really is
Rather than respond with a long post, there are significant advantages to using something like NOLOH instead of JavaScript directly. Rather than going into it detail here, I will merely point to 2 issues of php|architect that go in-depth into the many significant advantages you gain, similarly the noloh.com website goes into some of the advantages in the 3 read-more home blocks:
Assembly and C are low level languages. Javascript is high level language. The claim appears to be based on the fact that it is the lowest level available in the browser as if this somehow makes it comparable to assembly language, the lowest language available on computers. It is a straw man argument. Saying that they server "equivalent" purposes is bollocks. Using your flawed logic, one could say that because javascript is also the highest level language supported natively by all browsers that it therefor serves the same purpose as HAL in 2001.
The fact that various companies have sprung up that can take a language and generate javascript from it doesn't make javascript comparable to assembly.
Normally one takes a high level language and compiles it to a lower level language. However, it is not the case that simply compiling one language into another automatically dictates that one is higher than the other. In this case, it is done because javascript is the only language available, and some people don't want to learn it. I suspect that most people are put off learning javascript because the first time they tried it it was a PITA. Especially, it didnt do the same thing in IE as it did in Chrome. So people wrote frameworks like GWT and NOLOH so they could use languages that were familiar to them. I understand why: its easier to solve one unknown at a time. Presented with two problems: a) I don't know javascript and b) browsers are shitty, people decided to tackle problem (b) and ignore problem (a) by writing libraries in their familiar language. Ironically they probably now know more about javascript than anyone else.
I'm opting to deal with problem (a) and solve problem (b) by using jQuery. YMMV.
As for the advantages of something like NOLOH, yes, sure there are many advantages to using what is essentially big enough to be called middleware. However I suggest that the advantages initially presented by its ease of use will be quickly outweighed by all the things it can't do, or that it demands you do "its way". Perhaps NOLOH is the worlds first middleware that doesnt have this problem, or perhaps its the 2010 version of MFC. The problem is, by the time you find out its the latter, its too late. The risk of that discovery is greater than the learning curve of javascript and modern frameworks. Unlike assembly language.
I'm too tired to properly respond to this. It's clear that you don't know what NOLOH is, or the advantages it provides. By it's nature, it's not equivalent to GWT, and provides significant advantages over doing web development in most other frameworks or languages. The fact that it abstracts away JavaScript is only one of it's features, and as mentioned previously you can still use JavaScript. Furthermore, if you read the "Lightweight, On-demand, and Beyond" article I linked you to you would've seen how it's not middleware in the traditional sense and actually produces lightweight and on-demand output for target devices that is significantly more optimized and targeted than one could ever hope to do manually. Either way it's irrelevant as this just sidetracks from the real topic of discussion in that it's not necessary to learn or use JavaScript and that in most development cases it's advantageous and faster not to.
There was no reason for you to bundle NOLOH negatively in your response without actually taking a hard look at it. From your initial statements it's clear that you don't fully substantiate your arguments, but rather phrase things for most impact, which just makes it very difficult to have a meaningful conversation.
Frankly, I'm sick of having these type of discussions on Hacker News, I expect a higher class of individual here, but over the years I've clearly forgotten to lower my expectations. I feel like I'm on Fox news dealing with an aggressive host who isn't listening to what I'm saying and just lists false associations for psychological deception.
I'm very comfortable with my history and experience and can't be bullied into thinking otherwise. Your reasoning of the history behind why people wrote frameworks is flawed, but frankly, it doesn't matter. It doesn't matter what I say, or what I link to, or what arguments I present. You have your viewpoint, which is okay. It's clear from the personality type you expose in your response that any further response would fall on deaf ears.
An aside, NOLOH has been around in some form since 2005, pre-AJAX craze, so we can definitely appreciate the evolution of the web.
I would have liked to have read both articles you linked to, but in fact, all I got were abstracts pointing to a magazine that costs $5.00 to read. Perhaps it might have been better to link to the actual website: http://www.noloh.com/
For comparison, here are some websites put together by companies that ycombinator has funded, and which, I believe, are html/javascript without the middleman.
Your proof is in the pudding makes no sense, and just reinforces my comments about fox news earlier.
There are plenty more NOLOH sites, those are sites where the users submitted their site via our submit site functionality and is no way representative of all of NOLOH sites. Furthermore, you selectively chose the sites you wanted to list.
Whether a company is using NOLOH or html/javascript directly has nothing to do with whether someone needs to learn JavaScript. At this point you're just being combative for argument's sake, which is what I didn't want to deal with.
Surely, most sites on the web are written directly in a combination of HTML/JavaScript and some server-side language, but that in no way means that's the best approach. With your logic one can say that there's no place for any tools, since the majority of sites will always be in the status quo, or previous norm.
The point of the article was if you are doing web you have to do JavaScript a conclusion I agree with. JavaScript and Browser based apps is the web of the future when talking about apps. Most new development of web applications are taking place not with struts or ASP or PHP but with JavaScript relegation the others to providing REST services to the browser based app.
Personally I could not be happier, I hated the old page POST model for anything other than web magazines. It was painful to gyrate back to the server for every state change. I agree with the authors conclusion JavaScript is rapidly becoming the default language of the web UI and not having experience in it will put you at a disadvantage if you plan to do web UI work.
The interesting part that I see is just as the role of the designer and developer defined over the last 15 years to become two independent roles we are now seeing the roles of UX developer and systems developer diverge. I know a good deal of people on each side of the fence who are happy about that fact.
I see Java and C# guy that are happy that their role stops at the REST service interface. And I see front end guys who are ecstatic about not having to worry about contorting objects into relational structures and integrating with queues and legacy systems. I see the new web apps as a maturing of the art.
I've spent considerable time becoming an "expert" in other non-web languages. I'm curious about others' experiences with projects like Parenscript ( http://common-lisp.net/project/parenscript/ ):
"Parenscript is a translator from an extended subset of Common Lisp to JavaScript. Parenscript code can run almost identically on both the browser (as JavaScript) and server (as Common Lisp)."
Does anyone have experience with such tools? How about suggestions for similar tools in Python / Ruby?
Knowing JavaScript well is probably one of the most challenging and rewarding things you can do as a programmer
Do others agree with this (the importance of learning JavaScript the language well)?
As someone just learning JS and jQuery and just starting out with web development, JavaScript seems like a rather boring language that is strangely ill-suited to manipulating the DOM.
If JavaScript was jquery then I could see myself thinking of it as a really cool language worth exploring beyond "how can I do x".
I don't think your question makes much sense - you aren't going to get very far if you can't or won't distinguish between a language and its common libraries.
One thing I will concede is that using vanilla javascript to manipulate the DOM is very, very painful, which is exactly why libraries like prototype and jquery exist - to help make this less tedious and to make your experience, as a developer, more pleasurable and faster (as well as for your code to be DRYer, but that's just an added bonus, I'd say).
When you say "if javascript (were) jquery...", I can't help but think you don't understand jQuery. It's a library for javascript. Would you say "If Ruby were Rails then ..." ? No, you wouldn't, because Ruby on Rails is built on top of the language, just as jQuery is built on top of javascript.
Sit down sometime and read the source of jQuery and you will very quickly see that javascript is a really cool language that you can do cool stuff in. If jQuery doesn't float your boat, then maybe you should look at underscore.js - there is a very good annotation for it linked off their website.
I understand the concept of a library. What I don't understand is: JavaScript was designed as a domain-specific language, yet performing the most common tasks that it was designed for (manipulating the DOM)is, as you say, "very, very painful".
If you consider a language's standard library to be part of the language, then it seems like poor language design not to build-in functionality that makes manipulating the DOM at least as easy as jQuery makes it.
Thanks for the response, I will certainly peruse the jQuery source.
if one agrees with the idea that js will be everywhere, why learn a skill that will be commodity? there will be lots of people you can hire to do it for you.
real world example. say my html is sloppy. but I'm really good at core components (python, django, machine learning bits). So I can just hire a less skilled person off oDesk and pay them $10 an hour to review my HTML code, while I spend time on more important things.
Frameworks are nice. They are helpful. If anyone scoffs at you for using a framework while you’re learning, don’t listen to them.
I'd take this a step further. If you are doing heavy javascript development always use a framework like mootools or jquery. They remove over 95% of the browser compatibility issues that you will run into. (I personally like mootools)
I know python, SQL and actionscript and learning JS now.I totally agree to knowing the importance of JavaScript. even if its just for the sheer joy to have the ability to write little addons for browsers, and customize the internet little for yourself (and potentially for others).
Totally agree. Started with assembly language, then C, C++, C#, Java. I'd been dreading doing anything in the browser, and was playing with GWT and other esoteric things. But I'm finally getting my head around javascript and its just a heck of a lot of reward for very little effort. Its fun!
Okay, maybe I was working for the unmentioned 1% (and for what it's worth, the company I currently work for uses JavaScript). And really, it's not a bad idea to learn JavaScript - it's pretty ubiquitous and chances are you will work for a company that uses it at some point in your career. But honestly, I'm getting a little sick of all these articles that seem to forget that there is more to programming than web apps.
Edited to remove snarkiness.