Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How true hackers write JavaScript

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 342 posts

Re: How true hackers write JavaScript

#101

Post by pacifika »

Jaruzel wrote: post #98

I don't understand why people are dissing this. It does what it's designed to do, and fills a specific need for one website. It's not there as a teaching aid, nor is it meant to be shared for other people to use elsewhere. Not everything has to be gold-standard code full of perfect variable names, extensive comments and good whitespacing. If you have a day job that isn't primarily writing code, and/or you are likely…

>If you have a day job that isn't primarily writing code, and/or you are likely to be the only person ever working on that code, who cares if it's not up to the standard that people around here seem to expect of every project?

Future you that has to decipher the code. Why make it hard on yourself? Software is a living thing eventually a decision will need to be made about it and without understanding what it does it's easier to make suboptimal assumptions.

Re: How true hackers write JavaScript

#102

Post by drinchev »

jek0 wrote: post #72

The authors is quite lazy or cannot type fast enough, so he has to create all those cryptic abbreviations: `rks` for `ranks`, `unv` for `unvote`, etc. Which makes it really hard to read. But it's especially the inconsistent use of camelcase in function names than makes me think it's pretty amateurish.

Maybe the author used to write C

Re: How true hackers write JavaScript

#103

Post by pdpi »

whydoineedthis wrote: post #16
gear54rus wrote: post #12

Earlier quoted context omitted.

And burned 3.5 trillion developer brain cells just this january. Sensationalist metrics like this belong in the same trash bin as 'js is objectively bad and non-serious' bs.

so actual information is bad and "3.5 trillion brain cells burned" is good? Hrm....yeah, I'm going to Steam approach and focus on features that matter to the user rather than pedantic code which serves nothing but the developers ego in a vast majority of cases.

I haven't had my morning coffee yet.

That's a piece of factual information for you, yet it has no bearing in this discussion.

Valve's revenue might be factual, but it also does very little to further this discussion. Valve has almost no effective competition, and people will put up with a lot of shit from them because of it — which makes their JS engineering practices largely unrelated to their revenue.

Re: How true hackers write JavaScript

#104

Post by Aardwolf »

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?

Re: How true hackers write JavaScript

#105

Post by adamjc »

tzs wrote: post #100
adamjc wrote: post #15

Either run it through a minifier or have the whole thing unminified, these single lined functions look horrific, and are saving characters for the sake of it. Terrible naming, e.g. 'vis' -> reading the function it means toggle visibility, so it should be called 'toggleVisibility', you shouldn't have to read what the function is doing to understand what it will do. You ever get a bug in your code, It's not fun to look…

> Terrible naming, e.g. 'vis' -> reading the function it means toggle visibility, so it should be called 'toggleVisibility' But it doesn't toggle visibility. It sets visibility.

Yeah, you're right, I misread the code. It should be called 'setVisibility' then.

A problem that wouldn't exist if it was named correctly in the first place ;)

Re: How true hackers write JavaScript

#106

Post by onion2k »

gpvos wrote: post #92
onion2k wrote: post #6

function onready () { recoll(); } document.addEventListener("DOMContentLoaded", onready); Just attach recoll() directly. There's no benefit of going via onready().

You don't have to make every piece of code 100% tight. onready is actually the kind of function that you very likely want to add more lines to in the future, so why not leave it in? (I'm willing to bet it had more lines at some point in the past.)

onready is actually the kind of function that you very likely want to add more lines to in the future, so why not leave it in?

I'm a fan of writing the code you need when you need it. Adding or leaving things things there 'just in case' leads to code that's harder to reason about in the future because it's full of things that may or may not be used.

Re: How true hackers write JavaScript

#107

Post by bausshf »

paulintrognon wrote: post #74
noncoml wrote: 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.

hidestory() is not even used anywhere ; why is it here for? Debugging?

Is this sarcasm? I hope it is.

Re: How true hackers write JavaScript

#108

Post by Tade0 »

saagarjha wrote: post #19

Hacker News also works pretty well without JavaScript at all, which is really nice. Not something that I use often, but it comes in handy when you want to post a comment from your potato device that can't handle the modern web.

I once managed to open HN on a Nokia 3110 classic. Scrolling hanged and eventually rebooted the phone, but nevertheless the signature "HN orange" could be seen.

Re: How true hackers write JavaScript

#109

Post by masswerk »

TheAceOfHearts wrote: post #80

This code would be a bit shorter and simpler if it dropped support for old browsers (specifically, Internet Explorer). Some examples: The functions hasClass, addClass, and remClass could be replaced by Element.classList [0]. Another one is remEl, which can be replaced with a direct call to ChildNode.remove() [1]. I was going to give more examples, but I don't feel like rewriting the whole script. [0] https://develope…

Why should anyone invest lifetime to remove compatibility from a perfectly working application? Just to prove that not everyone is using an evergreen browser?
Post reply on HN