I think the "loose and flexible" aspect is why so many people think it's a joke. For the longest time, the only Javascript I learned was from online tutorials, and 90% of those were complete and utter crud, showing different ways of doing the same thing that were still acceptable because of how accommodating Javascript is with syntax errors. Because of the fact that no two tutorials were the same, I never wanted to touch Javascript.
Later I picked up an O'Reilly book about "the good bits" of Javascript and enjoyed it immensely, but the amount of parseable cruft out there doesn't help up-and-coming JS coders in the slightest.
We'd be better off without JavaScript embedded into Websites and PDF files. Granted, it adds functionality, but if you've ever tried to keep hundreds of Microsoft Windows PCs from being infected with malware, you'd understand. Things are simpler without it.
Just because one OS has security problems doesn't mean the world would be better off without this amazing functionality.
I think JavaScript embedded in websites is one of the most important abilities in the web today. It's critical to the way nearly all modern applications are written and it allows for extremely fast and rapid development of scalable powerful applications.
While Javascript is better than nothing, I'm one of the few proponents left of a strong, lightweight, maybe standardized, plugin model. I'd rather write with an appropriate language for the task at hand.
If my site would best be served by Lisp, or Haskell, or Java, or Javascript, or C#, or Python... let me decide. It just feels like we've entered this world that everything has to be Javascript, if its appropriate or not.
But then your site will only work with people who have installed the plugin that you depend on! That model doesn't seem like it would work very well to me, since there's no way every single browser will have support for 30 different scripting languages. There'd be a plugin-hell; it's much better if we all standardize on a language like we have.
The point you have is a valid one, but I feel like it shouldn't be.
For example, the fact that you say there'd be plugin-hell with 30 plugins is crazy. A good management system should be able to efficiently handle hundreds or even millions of components.
And what if we standardized support for the scripting languages? So, for example, the DOM calls looked like RESTFUL services returning JSON. And maybe there was a low-level, but efficient virtual machine that everyone could target (someone mentioned LLVM -- although I really don't care what it is all that much).
It just feels like the web is in this weird cycle where we continue to make suboptimal choices... largely because that's how it was done the first time.
If we're going to be doing that, wouldn't it maybe be better to compile to something that was actually designed as a compilation target (like the JVM/CLR - which are apparently the dread scourges JavaScript saved us from - or LLVM) rather than roping in an HLL not designed for the job?
The JVM wasn't originally createf for other languages as well. I agree it would be great if a vm such LLVM was builtin on all browsers. It is not, as specs that move the a better web development environment are not as aggressive as one would like, both in design and (even more prominently) in implementation.
The thought that developers should wait for browsers to catch up with their needs is what leads to such situation. But, if the JVM finally decided to host other languages, after they got a lot of attention, maybe so will browsers. But we need to justify it first. Not wait.
And leave the Web as a set of static pages like in the nineties? Web applications are desirable, if only because they're multi-platform. Javascript is what saved us from those slow and not so safe Java applets (and Flash, Silverlight, which would be everywhere without Ajax).
Anyway, malwares would have spread through downloaded executables (e-mail attachments, etc). Is Javascript even helpful to most malwares?
Yes, very much so. Adobe PDF reader's JavaScript ability is the reason it's dangerous to open PDF files anymore. They issue a new patch once a month it seems and are working on a sandbox as the problem cannot be contained. Without JavaScript embedded in the PDF files, this would be a much more manageable issue.
I didn't really appreciate JS when I had to use it for a school project. But, believe it or not, I gained an appreciation for it via CoffeeScript. Replacing the syntax with something more concise showed me that the underlying fundamentals of the language are pretty clean.
I had a similar experience learning to use mootools. It got rid of so many of the ticky-tack compatibility problems and just let me work on the problem.
I know it's been said many times, but Crockford's Javascript: The Good Parts is a wonderful approach that squeezes maximum value, maturity and robustness out of a mostly-good language with some spectacularly bad bits.
Going to chime in here. JavaScript: The Good Parts isn't just one of those crazy-useful technical books. It's also just good reading, if that makes sense.
It's also very short. A total breath of fresh air in an industry where so many publishers have a "bigger is better" mentality.
Yes, it's a great (re-)introduction, that doesn't try to cover every unusable corner of the specification and isn't apologetic about the bad parts.
This might sound weird or blasphemous, but programming in Javascript – whether it's in the browser or with node.js – feels a lot like C programming. Not in a way that it's close to the metal, but that you can do a lot with the whole system and there's not a lot of environment that you're dragging along with you (cf. Java/Python/Ruby). It's definitely not a polished marble statue, but it's a pretty handy chisel.
I wish there was a single curriculum that most JS developers were exposed to and can point to.
Every JS developer I meet has a different way of doing encapsulation and abstraction. This makes it terribly confusing for developers new to the environment who just want to know "the typical way" you do XYZ.
Javascript has 3 serious, fundamental problems. The first is that it's a prototypal language that's been forced into looking like a class-based OO language. This leads people to confusion and frustration, much the same as if you were making a burrito and someone replaced your ingredients with pita bread and hummus. If you try to work against the grain by imagining that JS is just another class-based language you will end up thinking that it's some crazy mutant language that doesn't make sense. If you go into it understanding the paradigm and how to make the best use of it you'll get much better results.
The second major problem with Javascript is that it was prematurely standardized due to excessive pressure to ship during development, and thus has a lot of little mis-features and defects in the core language that haven't been fixed due to concerns about breaking backward compatibility. Luckily it's generally possible to avoid these areas of the language without having to compromise your code so it's just a matter of keeping to good practices and of knowing what to avoid.
The third problem is that Javascript is primarily a web technology where it is married to the DOM, and historically browser DOMs have been a mess: non-standardized, buggy, sometimes slow.
Overall the result is a language with a few landmines that need to be tiptoed around but that is still very solid in its fundamentals. Compare that with many other languages that are more polished and yet fundamentally limited in significant ways (such as Java's lack of closures, for example).
The wonderful thing about JS is that because of its expressiveness, power, and advanced featureset, using the language properly becomes a potent self-reinforcing feedback loop, jQuery is one of the better examples of this.
Exactly right. I don't understand why there can't be a Javascript 2.0 that fixes its ridiculous misfeatures, and that you opt-in to with <script language="js2"> or something. So browsers would have to include two interpreters, but they're so bloated as it is I doubt it would be noticeable.
If you want to see what Javascript could have become without premature standardization, check out Lua (http://www.lua.org/). It doesn't get that much hype because it isn't married to the web, but it's popular in other niches, particularly the gaming industry. It's designed for scripting C / C++ applications, but also works well as a standalone language.
It's like a tasteful mix of Python and Javascript, but without any of the fat. It's very dynamic, has a small, extremely portable, and high-performance implementation (in a ~200k C library), has prototype-based objects, a JSON-like native datatype, and a better JIT (http://luajit.org/) than any JS implementation thus far.
It's my personal opinion that Javascript is the language of the future. One could argue it's actually the language of today with everything becoming a rich Web App. I'm not a hardcore CompSci language expert by any means - have just used dozens of languages over the years - and Javascript has become my favourite language by a large margin. The simplicity and flexibility of it is just so appealing. It's the GTD done of programming languages. I should also add that I don't have too much experience with functional languages just a little dabbling in Scheme and Lisp.
One of the things that I absolutely love about Javascript is that it doesn't need to be compiled. Most of people's time is actually spent debugging and not core coding. Therefore I highly highly value the "code-deploy-test" loop being as tight and friction free as possible. And with Javascript that loop doesn't get much tighter.
You too should try coffeescript— the compiler has a watcher built in that makes the compilation completely transparent. For me at least, the time saved vastly outweighs adding that one step to project setup.
I always commit both files (.coffee and .js) together, so I know for sure that the compiled version is up to date.
(With the disclaimer that the CoffeeScript syntax is still unstable, so it probably shouldn't be used for anything mission critical.)
Speaking of JavaScript, O'Reilly's Ebook Deal of the Day for today is the guide to Google's Closure JavaScript suite for $15. See http://oreilly.com/catalog/9781449381875/ and use the discount code DDSDF. (I am not affiliated w/ O'Reilly.)
You have been able to for a long time. On windows there's windows scripting host which includes JS support. On *nix there's no standard way of doing it but there are plenty of options for rolling your own though node.js is becoming a de facto standard.
This dude is late to the party. This seems to me like something that could have been written two or three years ago. Lots of developers have for a long time appreciated the powerful features and expressiveness of JavaScript.
37 comments
[ 2.8 ms ] story [ 115 ms ] threadLater I picked up an O'Reilly book about "the good bits" of Javascript and enjoyed it immensely, but the amount of parseable cruft out there doesn't help up-and-coming JS coders in the slightest.
I think JavaScript embedded in websites is one of the most important abilities in the web today. It's critical to the way nearly all modern applications are written and it allows for extremely fast and rapid development of scalable powerful applications.
Awesome, no?
If my site would best be served by Lisp, or Haskell, or Java, or Javascript, or C#, or Python... let me decide. It just feels like we've entered this world that everything has to be Javascript, if its appropriate or not.
For example, the fact that you say there'd be plugin-hell with 30 plugins is crazy. A good management system should be able to efficiently handle hundreds or even millions of components.
And what if we standardized support for the scripting languages? So, for example, the DOM calls looked like RESTFUL services returning JSON. And maybe there was a low-level, but efficient virtual machine that everyone could target (someone mentioned LLVM -- although I really don't care what it is all that much).
It just feels like the web is in this weird cycle where we continue to make suboptimal choices... largely because that's how it was done the first time.
http://fantom.org/
The thought that developers should wait for browsers to catch up with their needs is what leads to such situation. But, if the JVM finally decided to host other languages, after they got a lot of attention, maybe so will browsers. But we need to justify it first. Not wait.
Anyway, malwares would have spread through downloaded executables (e-mail attachments, etc). Is Javascript even helpful to most malwares?
Yes, very much so. Adobe PDF reader's JavaScript ability is the reason it's dangerous to open PDF files anymore. They issue a new patch once a month it seems and are working on a sandbox as the problem cannot be contained. Without JavaScript embedded in the PDF files, this would be a much more manageable issue.
It's also very short. A total breath of fresh air in an industry where so many publishers have a "bigger is better" mentality.
This might sound weird or blasphemous, but programming in Javascript – whether it's in the browser or with node.js – feels a lot like C programming. Not in a way that it's close to the metal, but that you can do a lot with the whole system and there's not a lot of environment that you're dragging along with you (cf. Java/Python/Ruby). It's definitely not a polished marble statue, but it's a pretty handy chisel.
I wish there was a single curriculum that most JS developers were exposed to and can point to.
Every JS developer I meet has a different way of doing encapsulation and abstraction. This makes it terribly confusing for developers new to the environment who just want to know "the typical way" you do XYZ.
The second major problem with Javascript is that it was prematurely standardized due to excessive pressure to ship during development, and thus has a lot of little mis-features and defects in the core language that haven't been fixed due to concerns about breaking backward compatibility. Luckily it's generally possible to avoid these areas of the language without having to compromise your code so it's just a matter of keeping to good practices and of knowing what to avoid.
The third problem is that Javascript is primarily a web technology where it is married to the DOM, and historically browser DOMs have been a mess: non-standardized, buggy, sometimes slow.
Overall the result is a language with a few landmines that need to be tiptoed around but that is still very solid in its fundamentals. Compare that with many other languages that are more polished and yet fundamentally limited in significant ways (such as Java's lack of closures, for example).
The wonderful thing about JS is that because of its expressiveness, power, and advanced featureset, using the language properly becomes a potent self-reinforcing feedback loop, jQuery is one of the better examples of this.
http://joose.it/
http://openjsan.org/doc/s/sa/samuraijack/Joose/3.011/lib/Joo...
It's like a tasteful mix of Python and Javascript, but without any of the fat. It's very dynamic, has a small, extremely portable, and high-performance implementation (in a ~200k C library), has prototype-based objects, a JSON-like native datatype, and a better JIT (http://luajit.org/) than any JS implementation thus far.
Recommended introduction: Ierusalimschy's _Programming in Lua, 2nd ed._ (http://www.inf.puc-rio.br/~roberto/pil2/).
I always commit both files (.coffee and .js) together, so I know for sure that the compiled version is up to date.
(With the disclaimer that the CoffeeScript syntax is still unstable, so it probably shouldn't be used for anything mission critical.)
http://code.google.com/googleapps/appsscript/