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.
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.
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):
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.
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.
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.
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 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.
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.
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).
[+] [-] aplusbi|15 years ago|reply
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|15 years ago|reply
[+] [-] kennymeyers|15 years ago|reply
[+] [-] mambodog|15 years ago|reply
Of course, DOM is utterly irrelevant here, just wanted to point out its use in games.
[+] [-] kayoone|15 years ago|reply
[+] [-] DjDarkman|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] binaryfinery|15 years ago|reply
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.
[+] [-] reduxredacted|15 years ago|reply
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|15 years ago|reply
[+] [-] anigbrowl|15 years ago|reply
[+] [-] 3am|15 years ago|reply
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|15 years ago|reply
[+] [-] smokeyj|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] dschobel|15 years ago|reply
[+] [-] Mongoose|15 years ago|reply
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|15 years ago|reply
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.
[+] [-] jasonlotito|15 years ago|reply
[+] [-] chrisaycock|15 years ago|reply
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|15 years ago|reply
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/
[+] [-] tjarratt|15 years ago|reply
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.
[+] [-] adolph|15 years ago|reply
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.
[+] [-] pornel|15 years ago|reply
We've had that already, and it didn't go too well:
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.
[+] [-] stretchwithme|15 years ago|reply
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.
[+] [-] icey|15 years ago|reply
(I don't think I'd do this myself, even though I like Python quite a lot.)
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] jhrobert|15 years ago|reply
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.
[+] [-] giardini|15 years ago|reply
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|15 years ago|reply
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|15 years ago|reply
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.
[+] [-] kennymeyers|15 years ago|reply
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.
[+] [-] mikebike|15 years ago|reply
http://www.codinghorror.com/blog/2007/07/the-principle-of-le...
[+] [-] asnyder|15 years ago|reply
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.
[+] [-] bluesnowmonkey|15 years ago|reply
[+] [-] binaryfinery|15 years ago|reply
[+] [-] dkarl|15 years ago|reply
[+] [-] kls|15 years ago|reply
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|15 years ago|reply
"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|15 years ago|reply
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|15 years ago|reply
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.
[+] [-] spacemanaki|15 years ago|reply
[+] [-] sayemm|15 years ago|reply
There's a reason why it's tied with RoR as the top language on Github: https://github.com/languages
[+] [-] anmol|15 years ago|reply
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|15 years ago|reply
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|15 years ago|reply
[+] [-] dstein|15 years ago|reply
[+] [-] brudgers|15 years ago|reply
[+] [-] axod|15 years ago|reply