Hacker News Reader

Comment by steven777400 | Hacker News Reader

This is a good way to distinguish between someone who knows JavaScript the language from someone who can apply JavaScript to perform DOM manipulation and data requests.

Not that there's anything inherently wrong with the latter.

I fall firmly in that latter camp; I do all my algorithmic work and heavy lifting in C# and just use JS to get data onto the client and display it. But it's easy for someone like to me to start believing "I know JavaScript" when in reality, it's more accurate to say "I can use JavaScript in the browser for common client/server cases". I'm currently working through "Effective JavaScript" to help improve on this.

View on HN

This isn't really true.

There are some programmers who are walking encyclopaedias of language features. It is absolutely no guarantee that they are good coders. Some simply can't code at all, they know all the motions but cannot see how to thread them together past the simplest of programs. Others cannot distinguish between useful language features and terrible ones, using them indiscriminately and making a terrible incomprehensible mess. And of course some are simply the best programmers you will ever meet.

Javascript is a language full of terrible design decisions. Knowing them all doesn't make you a good coder, in fact simply being taught only the safe parts will often make a better coder than knowing a lot of the results of these parlour tricks.

Agreed, I use Java for my heavy lifting. Use JS to display the data, provide some client side validation on forms, switch some classes around or manipulate something in the DOM using JQuery or the like.

I cant create a full fledged client side JS app but I dont really need to if I have a larger language helping on the server side.

I create fully fledged JS apps on a big scale, the difference from this test to reality is startling. The difference is I enforce the use of the closure compiler in our team so 99% of these issues are caught by the compiler. end of story. this test is bullshit.

What exactly do you mean by "fully fledged JS apps on a big scale"?

When it comes to more traditional languages like C, C++ and Java, "fully fledged" and "big scale" are descriptors usually reserved for multi-million line systems consistently worked on by 50+ full-time developers at a time.

I'm very suspicious of such terminology being applied to JavaScript applications. We generally see a much, much smaller scale when it comes to those. The "high end" cases are usually topping out at 100,000 to 200,000 lines of code at most, and perhaps 10 or 20 developers. They're a far cry from the C, C++, Java and C# examples.

Is any of this code you've worked on publicly available?

i mean teams of 20-25 people, working with millions of lines of code over all the modules, that has to be regressed the whole time. Big for the tech stack it is. This is not counting our bucketloads of java and scala code as well.

What benefits do JS apps have over a server-side language such as Java, C# or Ruby? Especially in an enterprise environment.

In most of my limited experience JS has been harder to work with than almost anything I have encountered. My personal experience using JS client side apps has left me feeling sour. Every time I visit a webpage and immediately hit a JS loading screen I cringe. Gmail is about the only I dont completely dislike that I know is written in JS.

response time.

http://www.nngroup.com/articles/response-times-3-important-l...

we use java to render our templates on the server side. https://developers.google.com/closure/templates/ And yes response times, it makes a massive massive difference in perceived responses. Our stack is the same stack which gmail uses (we use the full closure suite so compiler, templates, stylesheets, linter and library)

Reply on news.ycombinator.com