You must learn JavaScript
thenerdary.net
thenerdary.net
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.
You need to change that sentence then...
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.
No thanks, not willing to pay that overhead. I'd put $50 on the bet, though :)
Edit: or was that sarcasm?
I wouldn't be surprised if this has been done too, but if it has it's not as popular as Lua.
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.
Aren't there already a lot of Javascript games out there though?
Of course, DOM is utterly irrelevant here, just wanted to point out its use in games.
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).
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.
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.
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.
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?!
(I don't think I'd do this myself, even though I like Python quite a lot.)
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.
/pedantry
Not to mention RubySpec, which all major implementations are working to conform to. Even though that's built off of "What MRI/YARV do"...
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.
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.
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):
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.
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.
Flash blockers are extremely popular these days.
We've had that already, and it didn't go too well:
<applet>
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.
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.
* 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.
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!
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.
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.
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 highly doubt this will be prevalent technology 'in about a year'
Gestalt is not a viable solution in my opinion, as it rides on top of Silverlight.
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.
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.
http://www.codinghorror.com/blog/2007/07/the-principle-of-le...
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.
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/
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.
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.
http://www.theprotectornetwork.com/
http://evolve108.com/#/section=home
For comparison, here are some websites put together by companies that ycombinator has funded, and which, I believe, are html/javascript without the middleman.
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.
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.
"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?
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".
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.
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.
There's a reason why it's tied with RoR as the top language on Github: https://github.com/languages
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.
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)