Live data from Hacker News

How true hackers write JavaScript

news.ycombinator.com

141–150 of 342 posts

Re: How true hackers write JavaScript

#142
post #70

function hidestory (ev, el, id) { for (var i=0; i That 3 there is the problem with “simple” JS. It’s tightly coupled to the HTML but they live in completely different places. On a side note this 3 should be at least assigned to a variable with a meaningful name.

Except there isn't any problem here whatsoever. Yes, it's coupled, but it doesn't matter. No, this kind of code doesn't scale. It doesn't have to.

The time you spent writing this comment was longer than what it took writing this code. Considering what kind of site this is, that code may work indefinitely. Or, if necessary, someone from the future will need to change that 3 to a 4 at some point. In terms of total cost, it's almost certainly the cheapest solution.

Re: How true hackers write JavaScript

#143
post #137

Earlier quoted context omitted.

> It costs almost nothing more to write "event" instead of "ev" or "removeElement" instead of "remEl", but it makes the code much more readable. No, it doesn't. Unless you're an absolute beginner, it takes you a couple of seconds to realize that in this codebase, "ev" (or "evt" or even "e") means "event". The same goes for "remEl". If that's consistent, then it's not a big deal at all. Having less characters makes co…

Having anything take a couple of seconds more to read something is by definition making something less readable. Okay so perhaps a couple of seconds doesn't matter. How many seconds does?

There's an objective definition for readable?

Re: How true hackers write JavaScript

#144
post #88
post #36

Earlier quoted context omitted.

It removes the brackets and the return keyword, const is in fact a constant but this not ES6 it is just doing a function expression instead a function declaration (you create a const variable and assign an anonymous function to it instead of using the keyword 'function') This is used for readability and to avoid hoisting that can be confusing.

Given that brackets and the return keyword (and the function keyword!) are core parts of functions (a scope and a value to return to the caller), I would argue that removing these key parts of a function makes it harder for someone not familiar with ES6 to see that it is a function. This reminds me of Ruby's return-the-last-evaluated-thing-in-a-function semantics (which sadly Rust copied). Having to type one extra wo…

It does seem strange if you think of it as “return the last evaluated thing from the function.” But that’s not the semantic; the semantic is “everything is an expression and expressions evaluate to a value.” Removing this behavior would make these languages less consistent.

(And yes, in both Ruby and Rust not literally everything is an expression, but almost everything is.)

Re: How true hackers write JavaScript

#145

Um, is this supposed to be a criticism? Because this is MUCH better than sites loading megabytes worth of scripts to do nothing more than render text, have dozens of floating elements everywhere, auto playing videos that follow you, "use our app" buttons, etc... JS is the assembly of the web, do you also criticize games written in assembly?

> JS is the assembly of the web, do you also criticize games written in assembly?

hm

Re: How true hackers write JavaScript

#146

Um, is this supposed to be a criticism? Because this is MUCH better than sites loading megabytes worth of scripts to do nothing more than render text, have dozens of floating elements everywhere, auto playing videos that follow you, "use our app" buttons, etc... JS is the assembly of the web, do you also criticize games written in assembly?

I don't know if the author is experienced or not. But something I do know, is that the more experience I get, the more I fear dependencies and the more I value simplicity.

HN is a simple website. I'm glad that they decided to keep the code simple as well. I love the fact that the code almost fits in a single screen. Zero dependencies. You can understand the entire code in a few minutes.

I think new developers greatly underestimate the negative impact of dependencies. Today, something like create-react-app downloads hundreds of megabytes of dependencies. Libraries, transpilers, compiler extensions, and various tooling. Of course all those things come with many advantages, but what most people miss is the huge cost of all that. The increased complexity introduced by dependencies. The unnecessary bloat.

Sure, the way you name your variables have an impact on readability. But it's nothing compared to adding thousands of dependencies to your project.

Re: How true hackers write JavaScript

#147
post #116

There are some polarized opinions in this thread. Someone wrote That might be one of the most readable pieces of code that I've ever read. Apparently it improves readability immensely to rename 'forEach' to 'aeach'. To be honest the code is not very readable, but it is very simple and self contained. It would be very easy to dive into to fix a bug because there are no external dependencies or frameworks you have to u…

Perhaps this why HN still uses tables for presentation - nobody dares to change it?

There's also simply no reason to change it, it works.

Re: How true hackers write JavaScript

#148
While everyone's freaking out over the code I'm remembering the old code that was only 2 functions[0], which leaves me to believe this code was changed not too long ago. I wish we had a github or something of some of these front-end changes to HN just to see how things change over time. I figure it wouldn't be too much, but still.

The original JS was inlined and contained two functions: hide and vote.

[0] https://news.ycombinator.com/item?id=11307758

Re: How true hackers write JavaScript

#149
post #93
post #11

This is neat (how the up/downvote onclick handler sends the info to the server). new Image().src = el.href; Where href looks like this: vote?id=xxxxxxxx&how=up&auth=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy&goto=item%3Fid%3Dzzzzzzzz#wwwwwwww

Is this a GET request? What if my browser wants to peek ahead on some links?

If the Image is being created dynamically there won't be anything for browser to peek ahead at.

Edit: I'd be more worried about repeated calls - but presumably the service being called is idempotent.

Re: How true hackers write JavaScript

#150
post #84

Earlier quoted context omitted.

Really? It just looks compact and efficient to me.

"Compact" (abbreviated) names are negligibly more efficient when machines read them, and they're wildly less efficient when humans read them. Code is read many more times than it's written, so it doesn't make sense to optimize for fewer keystrokes when typing the code. This is especially true with modern IDEs that autocomplete everything.

> Code is read many more times than it's written, so it doesn't make sense to optimize for fewer keystrokes when typing the code.

That's actually probably not the case with JavaScript, so it may indeed make more sense to write it to be more efficient to execute.

Post reply on HN