I'm a desktop application developer still finding my feet on the web. Should I bother learning "pure" JavaScript or should I just learn a library like JQuery?
1) Should I learn the language?
2) Should I bother learning to use a DOM library like jQuery.
So the answer to both is actually yes. For someone coming to js for the first time, its very important that you at least learn an intermediate amount about the language before you worry about a browser library like jQuery.
You should get your hands on a copy of Javascript the Good Parts by Douglas Crockford. Its a short book, and easily the best written about javascript. The key thing is that the book addresses only the language. It tells you very simply what and what not to do. Learning these basics will help you get up to speed tremendously.
In regards to jQuery, its important to know that the language and the browser are two completely separate things. The language is basically implemented the same in most modern browsers with a few minor exceptions, 90% of which involve older versions of IE. The thing that people always get confused about is that the things DOM libraries wrap around are the various browser DOM APIs that are made accessible via js.
So, get the book. Learn the core tenets of the language. Then use a library to pave over all the rough bits when writing code that's meant to run in different browsers. In this day and age, the less you have to write "low-level" code to run across multiple browsers the happier you'll be. The exception here is if you're writing a web app that has to be very tiny and still function everywhere. A good example would be a widget that 3rd party sites can plug into their pages. You can never rely on another party having jQuery or whatever library you're using, and its cost prohibitive to load an entire 20k library to support your widget.
You need to learn javascript the language whether or not you use jQuery. You do not, however, need to learn the DOM API if you decide to use jQuery (which I recommend)
I'm a big CoffeeScript fan, but I would never say just learn CoffeeScript and skip JavaScript. CoffeeScript is really just syntax and abstraction on top of JavaScript.
I wouldn't agree with this 100%. I principally use jQuery unless I am working on something that has to very lightweight. However, there are lots of libraries and different reasons people and companies use them. That's why it's important to know the language in detail so that you can switch between libraries as needed.
Right, there is also Dojo hanging out there for large browser Apps. There is a point in which you can outgrow jQuery due to the size and complexity of an application. Dojo kind of fills that upper end so while it is a smaller segment of the market, there are still other toolkits that hold their share of the market for what they are tailored for. In saying that, there are some newer, complementary projects like backbone that are trying to make large web app development in jQuery less painful, but as of right now Dojo owns that space and it remains to be seen if that will change.
I feel in all cases of this questions (say RoR vs Ruby) the answer must ALWAYS be "learn the language first, then learn the framework". If you don't you will do the following:
a) Write bad code (you barely know the syntax)
b) Get really confused, and thus either start hating it, or simply not able to take full advantage of the framework.
c) Do roundabout ways to solve a problem when there is a very simple solution, but you not understanding the language still made the mistake.
d) Hit a big brick wall when looking at code others made.
I made this sort of mistake before. It is a bad mistake to make.
However to note: jQuery makes dom manipulation fairly easy. It is in no way a replacement to javascript, only the browser's dom lib calls. You just wind up not writing a bunch of utility functions to handle the different ways to get at the same information in the browser. Plus I like the syntax.
However to note: jQuery makes dom manipulation fairly easy. It is in no way a replacement to javascript, only the browser's dom lib calls. You just wind up not writing a bunch of utility functions to handle the different ways to get at the same information in the browser. Plus I like the syntax.
Right, browser based JavaScript is kind of a special cases, the reality is that it can be a frustrating experience to even learn JavaScript without the aid of something like jQuery to smooth out the DOM.
My personal recommendation would be either learn JavaScript outside of the browser, chose only one browser to learn it in, or get "the Good Parts" as recommended, but start with jQuery and use "the Good Parts" to make sure you are doing it right while using jQuery.
The fact of the matter is, if you are doing browser work, which most doing JavaScript are, you are going to use a toolkit like jQuery in almost every project. So to me, it becomes almost part of learning the language. JavaScript toolkit are a little different from frameworks on the server side. They are more like language enhancers than a frameworks. So they are in kind of a "chicken and the egg" problem when it comes to making recommendations on which to start with.
Could you explain prototypes? Most of what I learned about prototypes are hands-on. Maybe it's just me but I find there's a lack of good explanations out there and it would be really useful to have an answer that says, "Here are prototypes in their entirety."
Have you tried CoffeeScript and what are your thoughts on it? It's clearly not 'done' yet but I found it really helps clean up my scripts, reduce the amount of typing and avoid a lot of tricky JavaScript mistakes.
Coffeescript is great in theory. The problem is that when debugging stuff in the browser, you're going to be looking at Javascript in Chrome Developer Tools or Firebug. You can hopefully do an inverse mapping from generated JS to the corresponding line in Coffeescript...but that's kind of a pain, especially because it's not a line for line conversion.
Short of patching Chrome Dev Tools to support stepping through Coffeescript itself, not sure how to fix that.
The truth, (and a big part of the reason why we haven't already tried to solve this), is that it hasn't posed a problem for folks who are building apps in CoffeeScript. The transformation is straightforward enough that by glancing at the line number mentioned in the JavaScript, it's immediately obvious where the problem is in the CoffeeScript.
That said, I'd love to have a true solid debugger. The browser vendors (starting as soon as Firefox 4, perhaps) have plans to add better support for compile-to-JavaScript languages.
That's a pretty lame excuse. There also isn't a simple line for line relationship between C code and x86 code or C# code and MSIL code. But there's a standard solution to this problem when debugging: let the compilers generate mapping information.
For something like CoffeeScript, you'd probably have a debug compilation mode where each line of generated code is annotated with comments containing line numbers or full lines of code from the original CoffeeScript source code. It wouldn't be as convenient as a true source-level debugger for CoffeeScript, but it should suffice.
As far as I'm aware, there is no such debugging mode for CoffeeScript. The current method of debugging really is to look in the JS and then find the corresponding CS code. They do make this easier by keeping the JS code as readable as possible.
What's the best JavaScript deployment strategy you've seen?
I.e., are assets always compiled and bundled? How do you split up your bundles? Would you use namespaces, like Closure? How do you handle dependencies? What percent of the code lives on the page in script tags versus external resources? What testing framework(s) do you use? Do you prefer a certain code style?
So you should never think of "sleep" in javascript. Since the language is single-threaded, really if you pause the script you're pausing the entire environment (whether its in the browser or on the server in something like Node.js).
But, to answer your question:
// some code runs here
var continue = function(data){
//more code runs in here after sleep
}
setTimeout(function(){
continue(data);
},2000);
A different pattern:
var obj = {
sleep: function(fn, time){
setTimeout(fn, time );
},
func1: function(data){
console.log('Continuing');
},
init: function(data){
IMO, a better pattern is to use lexical closures in continuation-passing style to share state:
function sleep(time, continuation) {
setTimeout(continuation, time);
}
function start_process(x) {
var y = foo(x);
sleep(1000, function() {
var z = bar(x, y);
sleep(2000, function() {
baz(x, y, z);
});});
}
start_process(42);
Your problem is not with setTimeout, you need to learn how to write evented code because that is how javascript works and you're going to encounter this problem in different contexts. Passing in a closure to setTimeout usually suffices though, it's just slightly uglier than a normal "sleep" call.
If you really, really wanted to you could create a busy wait sleep function, but it's an awful idea and you should never do it.
Node is a server-side js environment. I use it all the time now and its awesome. I still use Python & Django for web development, but in the next few years I will feel completely comfortable switching over to a javascript stack entirely.
WebGL is something I haven't played with much, mainly due to small market share yet. With so much out there, I've had to prioritize on what to learn and when. I recommend http://learningwebgl.com/ to get started.
MooTools is mainly a client-side library. I've found that its syntax, like that of YUI and Prototype are excessive and limited. While you can use any library to get the same work done, I've stuck with jQuery because its just more natural for me to work with it. Its syntax, features, and widespread support are all positive reasons to use jQuery over other libraries.
GWT was designed to let Java engineers write javascript in Java. That's just a bad, bad idea. The resulting javascript code doesn't really take advantage of the language the way it was designed. It helps Java engineers feel like they can write web stuff, but really the end result is not often very pretty.
As a result of all of these optimizations, GWT can produce code that is as fast if not faster then hand written JavaScript. The reason for this is that most large JavaScript projects tend to use a lot of dynamic features (such as dynamic binding) and other conveniences instead of writing super optimized JavaScript code by hand.
Also care to explain what you mean when you say "It helps Java engineers feel like they can write web stuff" are you implying that JavaScript engineers create "web stuff" well Java engineers don't?
Ok: What are some good object creation strategies you employ. Basically I know with javascript there are a handful of different ways to create objects. Some (using a framework) give you java-like inheritence, some other methodologies. Much of the time you don't really need to give a shit about inheritence as you are more focused on containership (the word eludes me, probably will remember it 15 minutes after post).
So what to do you? Do you even code javascript now or you use coffeescript and it's object creation strats (or do you use clojure, or whatever).
And another question: Do you use JSLint or something similar? What about if you want to validate javascriopt 1.7/1.8 syntax.
In a browser, what framework do you use to handle file dependencies? As in I have foo.js which will only run if bar.js is loaded, I don't want to specify in my page: 1) load bar.js, 2) load foo.js 3) order matters... rather I want to say load foo.js (and implicitly it loads bar.js first)
