Live data from Hacker News

How true hackers write JavaScript

news.ycombinator.com

191–200 of 342 posts

Re: How true hackers write JavaScript

#191
Here's something maybe productive to take away from this kibitzing thread:

Consider this code and the range of comments on it while doing (or undergoing) your next non-trivial code review.

(For one thing, it reminds me that a great value of adopting comprehensive code standards is that it resolves these kinds arguments, letting teams get on with the important stuff.)

Re: How true hackers write JavaScript

#192
post #32

Barely readable but I think there's a lot of optimization going on here... I don't think that optimization is done correctly but that is why it's hard to read.

There's minimal optimization (as in tricks), but lots of optimization (as in readability and common sense).

It's also incredibly readable; I'm puzzled as to what the bar for "readability" is if this doesn't meet it.

Re: How true hackers write JavaScript

#193
post #164

Earlier quoted context omitted.

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

I agree that because of common uses of things like match in Rust it makes it consistent to also do it for functions. I don't agree that the reason why it's consistent is because a function body is an expression (though of course you have more expertise than me on this one -- and Rust does actually treat scopes much more strictly than most other languages so you could argue every scope has the smell of a function call…

Here's the citation: https://doc.rust-lang.org/reference/items/functions.html

> A function consists of a block, along with a name and a set of parameters.

https://doc.rust-lang.org/reference/expressions/block-expr.h...

> Blocks are always value expressions and evaluate the last expression in value expression context.

Re: How true hackers write JavaScript

#194
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

Image makes the HTTP request without appending the Image to the DOM? TIL

That's how most tracking scripts operate...

Re: How true hackers write JavaScript

#195
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…

You could reach a happy medium if everything was well commented. Introduce a build step to strip comments if you have to. But you would get maintainability while still having full visibility into all the code that is executing.

Re: How true hackers write JavaScript

#196
post #152

Seriously though... do you guys declare variables with var or let? I thought let was the new standard for scoping reasons. I'm not trying to start a holy war, I'm just a junior looking to learn.

const. I always use const and if I need to mutate a variable, then let.

var is pretty much just for legacy codes. Yes, it has unique behaviors, but better stick to the new keywords, can prevent some headaches.

Re: How true hackers write JavaScript

#197
post #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 cos…

And how will that someone know what that 3 stands for ? At the minimum a comment above that line would have been nice.

Re: How true hackers write JavaScript

#198
post #186

He/she could have put much of the function in the top under the $() to make a super mini jquery. That's close to what I use with Vue. It's made even easier to write considering I almost never find a need for jquery's default behaviour of running its methods on multiple nodes. 99% of the time in my projects I just need to do something with one node.

I’ve replaced jQuery on several projects with $ = querySelector, $$ = querySelectorAll (wrapped in Array.from if you need to support IE11 so you can use all of the new array methods which their NodeList implementation didn’t get until Edge), classList and fetch. Beyond the code size savings, I find the newer standard methods are generally easier to understand when scanning code.

I like what this guy did, talking about native methods. However it's too flexible for me, I prefer to have the most minimal functionality in order to ensure consistency in my code. But maybe that's just me. If the library opens up too many possibilities, then I have both the "problem of choice" when writing code, and also it's more difficult to refactor down the line if you want to change lib. Whereas using your own super simple solution (as long as it's sufficient), you can also do a simple abstract layer when including some vendor API.

https://github.com/eorroe/NodeList.js/

Re: How true hackers write JavaScript

#199

Criticisms and bizarre fawning over beauty that a couple of people have made aside, the one thing that bugs me the most is the inconsistent usage of ;

To my eyes semicolons are like comments in JS code which indicate "this has been linted for publication". But this > (one); (occasion) where a semicolon can have meaning in JS leaps out of the screen - even easier if they are not blanketed everywhere. The incomplete blanketing in this code is very casual. I see it no more than an invitation to hand-lint what I want to touch.
Post reply on HN