Hacker News Reader

Comment by HarrietJones | Hacker News Reader

"I will learn at the root, not the abstraction: JAVASCRIPT BEFORE JQUERY"

I'm not sure why one high-end abstraction finds favour over another slightly higher high-end abstraction, but this sure sounds a lot like the people who insist that you can't be a good programmer unless you've learned some kind of assembler.

On the "shoulders of giants" means we don't need to know javascript as well as jQuery. It means we don't have to know assembler as well as pascal. It means that we don't need to learn IP when we can just learn TCP/IP, and we don't need to learn TCP/IP when we can just use REST over HTTP.

Learning at the root goes a lot further down than you want to go, need to go or are capable of going.

View on HN

I pretty strongly disagree.

> this sure sounds a lot like the people who insist that you can't be a good programmer unless you've learned some kind of assembler.

This isn't a very good analogy. JavaScript is a high level language, and jQuery is just a library with features that make it a high level DSL. But when you "write jQuery" you're really writing JavaScript, not some other language, so I don't think the analogy with languages compiled to assembly really makes sense. That being said, I do think that knowing some assembly will not hurt you writing C, and likely will help. Similarly, understanding some of how JS is implemented in browsers won't hurt, and might help you write JS.

It's true that there's almost no limit to how deep the rabbit hole goes. Someone building web apps probably doesn't need to have a degree in electrical engineering, but I don't think this kind of slippery slope argument defends someone using jQuery without knowing JavaScript.

In a grandchild comment you wrote:

> It took me ages to unlearn certain practices and just accept the garbage collector would do its job and I no longer need to think about unallocating memory.

You don't need to explicitly think about unallocating memory, but that doesn't mean your knowledge of manual memory management isn't useful. You do need to be aware of how the GC works if you're working with one. You can still have memory leaks, so how could you possibly debug them if you think the GC is magic?

There's this meme that is floated around HN and elsewhere, that the title "software engineer" is just puffery, because we aren't "real" engineers. I try to avoid this discussion because I think it's mostly stupid, but I can't help touch on it here given the title of this manifesto. I just don't think anyone could seriously call themselves a "front end engineer" if they refuse to learn JavaScript, claiming it's not necessary to use jQuery. Given that the author thinks this title is appropriate, I think the assertion about learning JavaScript is perfectly acceptable.

I'd be interested to hear more about what you think though, and about how the negatives to understanding lower levels of the stack outweigh the benefits. In my (limited) experience, some or more understanding of one or even two "levels down the stack" has never been a net-negative.

99% of devs building the popular sites on the Internet have never needed to think about GC beyond maybe the vaguest terms of "if you keep too many references to too big things your app will slog." 0.5% write tools, libraries, and compilers that worry about this, and 0.5% debug extreme cases in their apps.

Numbers made up, of course.

I think you're wrong, and I don't know what the point of making up numbers is. It might be your experience that you've been able to treat garbage collection as magic, and that's nice, but it's not been mine. I was speaking generally, about all programmers, not just web developers.

My point was that if you don't have any understanding of how garbage collection works, you simply don't have all possible tools at your disposal when you need to debug a memory leak. I'm not suggesting every programmer needs to have spent years hacking on garbage collectors and studied all of the literature, just that having some familiarity with the tools available to you is important.

And this was just one example meant to support my main argument that gaining understanding below the level of abstraction you are working at is not a bad thing.

I don't think the assembler analogy holds with jQuery vs. JavaScript/DOM.

There's a reason why an event handler has a DOM element and not a jQuery object as its `this` keyword. At the time jQuery was designed, we thought everyone understood the DOM well enough to use it directly. Yes you can take the DOM element and wrap it in a jQuery object, but it's not always appropriate.

For example, `this.checked` is about 100 times faster, much prettier, and shorter to type than `$(this).is(":checked")` [1]. No amount of optimization inside jQuery will really change that performance gap.

Sometimes people get a misguided belief that every access to every JavaScript object should be through jQuery. Then we get reports that `$(window).attr("location")` don't work. [2] So yeah, learn JavaScript and the DOM.

[1] http://jsperf.com/bens-test [2] http://bugs.jquery.com/ticket/7607

> On the "shoulders of giants" means we don't need to know javascript as well as jQuery.

Not necessarily. I like to view it this way: When you are learning a new language (English, German, Chinese, whatever), in day to day conversations it is useful to know some expressions, idioms, or terms, but you should also know where they come from and how to explain them, and not just how to use them.

Learning what "I'm pissed" means in British english is quite nice but if you say that to an American and responds "Who pissed you?", how are going to teach this person of the use of the word "pissed" in this context?

Similarly, a jQuery-only developer will find it difficult to understand and explain what he meant to do with some piece of code, let's say $.each. A "native speaker", ie. a javascript developer, may be able to offer some advice or corrections, like "you could use Array.forEach in this scenario". (Granted this particular example may not be so good due but you get the point).

There's always a tradeoff between knowing what something like "each" does and having that extra architectural clutter being a cognitive drag. I can see the point being made, and there are obviously going to be situations where getting closer to the metal is important, but getting closer to the metal isn't always a good thing.

Sometimes, knowing things closer to the metal isn't good either. It took me ages to unlearn certain practices and just accept the garbage collector would do its job and I no longer need to think about unallocating memory.

Like all things, this one isn't black and white and it's open to subjectivity. For me though, I feel that the negative side of having knowledge of lower levels of your architectural stack is a hindrance more than it is not.

jQuery abstracts the DOM, not JS, so this item doesn't make sense. Much like the DOM doesn't make sense cross-browser. Does OP also bugger himself about the difference between VGA and DVI when designing his UI?

Reply on news.ycombinator.com