
You must learn JavaScript  - platypus
http://thenerdary.net/articles/entry/you_must_learn_javascript
======
aplusbi
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.

Edited to remove snarkiness.

~~~
ericflo
Want to make a bet that we'll see JavaScript used to script a game within the
next 5 years? I'd bet money that we will.

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

Edit: or was that sarcasm?

~~~
tlrobinson
He's probably talking about embedding a JavaScript engine within a game to
script the lower-level (usually C/C++) game engine, a role that is currently
often filled by Lua:
[http://en.wikipedia.org/wiki/Lua_(programming_language)#Vide...](http://en.wikipedia.org/wiki/Lua_\(programming_language\)#Video_games)

I wouldn't be surprised if this has been done too, but if it has it's not as
popular as Lua.

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

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

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

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

~~~
beauSD
IE developer toolbar really helps with JavaScript and CSS debugging. It
believe it is built into IE 8.
[http://www.microsoft.com/downloads/en/details.aspx?FamilyID=...](http://www.microsoft.com/downloads/en/details.aspx?FamilyID=95e06cbe-4940-4218-b75d-b8856fced535)

~~~
euroclydon
It's pretty poor: You can't even inspect the global scope without being
stopped on a breakpoint.

~~~
kls
Yep, I have to agree the only way to half way decently debug IE is with VS and
that is still not as pleasurable as Firebug or Chrome's debugger.

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

~~~
amackera
Everyone knows the best language is Modula-2...

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

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

------
chrisaycock
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:

<script language="Python" version="2.5+"
downloadfrom="<http://www.python.org/dompython> ">

Is this just too much to ask?!

~~~
jashkenas
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):

<http://thelincolnshirepoacher.com/>

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

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

~~~
kiddo
Why does it make sense to have the client do as much as possible so the server
does as little as possible?

~~~
didip
I could think of a couple reasons:

* bandwidth bill.

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

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

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

------
moron4hire
"Do not pass go. Do not collect 200 dollars."

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.

~~~
akavlie
"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)

~~~
freakwit
<http://visitmix.com/labs/gestalt/>

and a demo in ie9 -
[http://blogs.msdn.com/b/nickhodge/archive/2010/06/29/having-...](http://blogs.msdn.com/b/nickhodge/archive/2010/06/29/having-
fun-with-html5-script-python-amp-svg.aspx)

~~~
akavlie
Yeah, I don't see any signs of impending mainstream (cross-browser) acceptance
of NativeClient any time soon.

Gestalt is not a viable solution in my opinion, as it rides on top of
Silverlight.

------
mikebike
I'm surprised nobody's mentioned Atwood's Law: any application that can be
written in JavaScript, will eventually be written in JavaScript.

[http://www.codinghorror.com/blog/2007/07/the-principle-of-
le...](http://www.codinghorror.com/blog/2007/07/the-principle-of-least-
power.html)

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

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

~~~
asnyder
_...references to assembly and C are straw men._

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:

NOLOH: The Comprehensive Framework -
<http://www.phparch.com/magazine/2010/may/>

Lightweight, On-demand, and Beyond -
<http://www.phparch.com/magazine/2010/november/>

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

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

~~~
spc476
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/>

~~~
asnyder
I'm sorry, I wish php|architect would expose their articles without a pay
wall, or subscription. They have an exclusivity period of 3 months.

------
dkarl
This is "you must learn JavaScript in the browser," isn't it? JavaScript I
don't mind. Programming in the browser, ugh.

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

------
beambot
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?

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

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

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

------
sayemm
I second this. Learning JS really opened my eyes to the web and made me
appreciate it more.

There's a reason why it's tied with RoR as the top language on Github:
<https://github.com/languages>

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

------
Sakes
_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)

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

------
dstein
End-to-end web programming in JavaScript using NodeJS is breathtaking to see
in action.

------
brudgers
The truth value of "You must learn JavaScript" is true if and only if "You
must learn HTML" is true.

------
axod
Also make sure you learn js. Don't end up learning something like jquery.

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

------
pshirishreddy
Also, I have just bought the book "JavaScript : The Good Parts" from
www.flipkart.com(India) to read it, but really getting no time to read.

