Offer HN: I'll answer your javascript questions

https://news.ycombinator.com/item?id=2018924

by geuis • 16 years ago

21 41 16 years ago

news.ycombinator.com

I'll gladly answer javascript questions this weekend if you have any.

geuis.teses@gmail.com

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?

maxwell• 16 years ago

jQuery is just the de facto DOM API; learn them concurrently.

geuis7• 16 years ago

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.

johnswamps2• 16 years ago

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)

gte910h3• 16 years ago

If you're a desktop guy, and MS based, learn some silverlight, it's very nice and also a MS-win7 phone.

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).

pshirishreddy2• 16 years ago

If possible can you throw some light on which would be good for starters on server side language Python (which I am currently learning) from http://learnpythonthehardway.org/static/LearnPythonTheHardWa... OR PHP (which I already know)

geuis7• 16 years ago

So there's 2 questions in there.

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.

dekz2• 16 years ago

You don't even need to learn javascript for web dev, checkout a project called Coffeescript.

lukeinth• 16 years ago

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.

GrandMasterBirt4• 16 years ago

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.

kls2• 16 years ago

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.

windsurfer• 16 years ago

What's your opinion of technologies like Node, WebGL, MooTools, and GWT? All are interesting to me but I'm not sure where to invest my time.

geuis7• 16 years ago

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.

jhuni• 16 years ago

For small scripts there is no reason to use GWT, however, for large AJAX applications it can be incredibly advantageous.

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?

heyrhett• 16 years ago

setTimeout drives me crazy. How can I implement "sleep" without going insane?

johnswamps2• 16 years ago

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.

geuis7• 16 years ago

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){

        console.log('Starting');
        obj.sleep(obj.func1, 2000);
    }

} obj.init()

psykotic3• 16 years ago

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);

sarenji• 16 years ago

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."

geuis7• 16 years ago

Please email me at geuis.teses@gmail.com. Bit easier to handle questions there.

GrandMasterBirt4• 16 years ago

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.

dekz2• 16 years ago

encapsulation?

GrandMasterBirt4• 16 years ago

composition. Told you 15 minutes later.

barrydahlberg2• 16 years ago

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.

ramanujan• 16 years ago

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.

psykotic3• 16 years ago

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.

jashkenas• 16 years ago

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.

https://bugzilla.mozilla.org/show_bug.cgi?id=618650

http://intertwingly.net/blog/2010/11/25/Hobgoblin-of-Little-...

GrandMasterBirt4• 16 years ago

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)

geuis7• 16 years ago

Look at RequireJS, http://requirejs.org/

aiurtourist• 16 years ago

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?

tomfluff• 16 years ago

Say i have a bookmarklet with the following code

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?

Offer HN: I'll answer your javascript questions

Related Stories