Offer HN: I'll answer your javascript questions
I'll gladly answer javascript questions this weekend if you have any.
geuis.teses@gmail.com
geuis.teses@gmail.com
If you're not, Javascript + JQuery is the way to learn for the client side stuff, you also need a server side language (python, ruby, etc).
Ruby or python is probably the best choice, and I personally favor python.
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.
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.
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.
Short of patching Chrome Dev Tools to support stepping through Coffeescript itself, not sure how to fix that.
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.
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=618650
http://intertwingly.net/blog/2010/11/25/Hobgoblin-of-Little-...
That are great news, Do you thing we will see many new languages that compile to JS in the near future?
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?
javascript:(function(){q=document.getElementById("question-title").getElementsByTagName("b")[0].innerHTML.split(" ",3);})();
That is only a snippet of the code but you get the idea.
Is it possible to repeat the code every 3-5 seconds in a bookmarklet?
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.
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){
console.log('Starting');
obj.sleep(obj.func1, 2000);
} 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);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.
GWT performs comprehensive optimizations - in-lining methods, limiting property access, removing dead code, limiting code size, and more.
http://code.google.com/p/google-web-toolkit/wiki/CompilerOpt...
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?
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.