Very cool, if true

I have Firebug. But that didn't tell me why it wasn't finding the function in the first place. And I couldn't see a way to have it tell me what the actual structure I should be using to find my textarea.

What was I doing wrong?

From:

Two things, first of all:

1) If you're writing raw Javascript by hand, stop now!. Go and have a look at e.g. JQuery, and if that looks like what you want, download it or pull it in from e.g. Google's cache.

2) WebKit browsers (e.g. Chrome or Safari) have a damn useful inspector pane that does do auto-complete. Switch to the console and explore object hierarchies and properties interactively like a dynamically-typed language; anything you dump to the console (by calling e.g. console.log(object)) will get dumped in its full form, and you can explore it via disclosure arrows and so on. This only works if you dump only the object, e.g. console.log(object) rather than console.log("This random object I have is " + object)

Then get used to Javascript stupidities, like using + for a concatenation operator, or the really silly one where parseInt("12345") == 12345 but parseInt('012345') == 5349 because the leading 0 means octal, obviously. (You should have been specific and said parseint('012345', 10) because people decide to use bases other than 10 all the time in real life.)

From:

If you have JQuery, and you've given your textarea either an id or a reasonably-identifiable hierarchy, you could just say e.g. $('#PostTemplate').val('Replacement Text') without having to walk a tree of uncertain objects. ($ is a cute JQuery way of injecting a very short function name into your program's namespace that you almost certainly weren't using before; you can rename it if it bothers you, but it's pretty much idiomatic among JQuery programmers.)

From:

One thing I often do when debugging Javascript, incidentally, is a) declare a variable in the outward-mode scope (e.g. put something like "var storedWhatever" before the function's that's going wrong), and b) when it comes to the code that's going wrong, add e.g. "storedWhatever = whatever"; then reload the page. I now have storedWhatever available to me in the console, and I can run arbitrary Javascript commands until I work out what I was doing wrong. While there's a fully-fledged debugger in Webkit, with breakpoints and everything, that's often all you need for simple problems. Your main issue with debugging Javascript is minimising the time waiting for the damn page to reload.

From:

andlosers.livejournal.com

This. jQuery turns JavaScript into a language that is approximately nine bazillion times more useful. Even Microsoft ships it now. It's just the way to go.

From:

I want to understand JS before I start importing libraries on top of it.

From:

1) Bringing in a whole library for a single method call seemed silly. And I'd like to understand JS before I start building things in libraries on top of it.

2) Chrome also doesn't show up "document.DeliciousPoster" in its autocomplete. Any ideas why?

From:

1) If you bring in JQuery from Google's servers, odds are reasonable that your visitor's browser will already have it cached.

2) Pass; possibly it's only auto-completing methods? I get plenty of auto-complete on document.DeliciousPoster itself.

From:

Don't do any Javascript without jQuery. It makes JS not shit.

From:

I want to understand JS before I start importing libraries on top of it.

From:

The stuff you're banging your head against, though, is stupid stuff that JQuery patches around so you don't have to bother with it. It's like dynamically-typed languages handling your memory management for you, rather than having to faff about with malloc and free and all of that wonderful stuff that C gave us, which leads to buffer overflows and segmentation faults. Javascript + JQuery is almost a different language - and that's even before you start talking about coffeescript.

From:

Yes,but I work in a language with GC, and I still understand memory management, because (a) I want to and (b) the law of leaky abstractions tells me that at some point I will need to...

From:

Then fine; once you've solved your problem with JQuery, and spent a bit more time fiddling with Javascript as a whole, go back to working out why your initial approach didn't work. Maybe read the (non-minified!) source of JQuery. But it sounds like your problems have been DOM-traversal issues, which a) aren't a major part of Javascript (unlike the type system, the object system, or any of the core libraries), and b) are much, much nicer to do in JQuery.

From:

Seconded. DOM-traversal is what jQ is MADE FOR. Don't reinvent the wheel -- or in this case, don't drag heavy blocks of stone across rough terrain when there is a wheel already invented and right next to you!

From:

Nonono. Really. Don't. JS is CRACK without jQ. Don't even TRY to understand JS. Work with jQ and understand jQ and let it deal with the crap for you. Anything else is just masochism, trust me.

From:

I'm a computer scientist. I have near-to-zero interest in writing code that I don't understand pretty much all the way down. Once I understand it I'm happy to layer stuff on top of it.

From:

I'm a developer. I'm happy to use stuff that Just Works and get on with doing interesting things with it ;)

(Do you understand machine code though?)

From:

Of course I do, I studied it first year at uni. I've written a compiler.

(And I've generated code in IL, which is the .Net version of assembly)

Edited Date: 2011-11-10 11:35 am (UTC)

From:

cartesiandaemon.livejournal.com

I apologise for adding yet another voice. I agree 100% that you should understand what your environment is built on and not just trust it to abstract the details 100%, but I don't think you always need to start at the lowest level.

I don't have any personal experience with javascript or jquery: I used javascript when I was a teenager for some hobby projects that I never finished (old link: http://www.vickeridge.clara.net/main.htm). But the second-hand opinion I get from seeing answers on stack overflow seems sufficiently widespread and reasonable that I'm pretty sure it's right even without any domain knowledge, and is: just use jquery. Always. (eg. http://stackoverflow.com/questions/471597/is-jquery-always-the-answer).

I think (although I don't have personal experience) an appropriate analogy might be the c standard library. Yes, you should be able to reimplement it all from scratch, and some of the functions a beginner maybe should write themself the first time -- but others I think it's much better to take as a black box and learn about the messy details (down to and including the exact architecture of a processor) later, often years later. I guess (although I don't know) understanding how jqueary implements things in javascript is useful to know, and following along with what's going on under the scenes is useful, but the impression I get is that javascript+jquery is the language of choice to start learning, and learning javascript alone is like learning C without functions: possible, and possibly informative, but generally not actually helpful...

From:

Oh, I'm happy enough to play with jQuery. But I'd like to be able to wire up a couple of basic events and see how they work too.

From:

cartesiandaemon.livejournal.com

Yeah, that makes sense. Sorry for jumping in, it seems I always comment immediately superfluously, or leave it too long and never do... :)

From:

Oh, no, commentary is always good!

From:

cartesiandaemon.livejournal.com

Thanks. I'm curious how it does go for you actually: my impression 10 years ago was that javascript was cutting edge compared to static websites, but completely sucked by modern standards for writing anything non-trivial, and I never really used it since, but it supposedly started to not-suck at some point in the last few years, and I know I may end up going back to it for some other project eventually, and I'm curious what someone's else's first impression of it is :)

From: