It works reliably and quickly, so mission accomplished.
How true hackers write JavaScript
181–190 of 342 posts
Re: How true hackers write JavaScript
#182I thought I was smart... BEFORE function vis(el, on) { if (el) { on ? remClass(el, 'nosee') : addClass(el, 'nosee') } } AFTER function vis(el, on) { if (el) { window[on ? 'remClass' : 'addClass'](el, 'nosee') } } ...sadly we have to add window when using the square brackets so it's not much shorter. Oh well.
Why not: function vis(el, on) { if (el) { (on ? remClass : addClass)(el, 'nosee') } } ?
Ahh thanks! I forgot about that. I'm guessing I didn't think about it because I'm used to the following pattern ,which is actually useful from time to time in my projects. And typically it happens in an object/class:
this[expr ? 'method1' : 'method2'](args)
Re: How true hackers write JavaScript
#183Way better than loading megabytes of .js just to display stupid animations and other useless gimmicky stuff. This file is just in consonance with this website's style: concise, terse, to-the-point and with minimal bs. Of all of my currently in-rotation news websites, this loads and reacts the fastest, no matter where I am or how crippled my current connection is. I am sure they are factoring load times and speed over…
Animations being badly/over used aside, this is a bit of a straw man argument.
If you load megabytes of JS to do animations, as opposed to using CSS, then yes you are just doing it wrong.
Things aren't either exactly right and done one way, or else terrible. You can of course have bells and whistles like animations if your usecase requires them (HN doesn't!) and still have a fast loading site with clean code, if you do it right.
Re: How true hackers write JavaScript
#184This 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
Re: How true hackers write JavaScript
#185Hacker 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 usually read HN using w3m. It's entirely usable with no javascript.
Re: How true hackers write JavaScript
#186He/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.
Re: How true hackers write JavaScript
#187Way better than loading megabytes of .js just to display stupid animations and other useless gimmicky stuff. This file is just in consonance with this website's style: concise, terse, to-the-point and with minimal bs. Of all of my currently in-rotation news websites, this loads and reacts the fastest, no matter where I am or how crippled my current connection is. I am sure they are factoring load times and speed over…
Animations being badly/over used aside, this is a bit of a straw man argument. If you load megabytes of JS to do animations, as opposed to using CSS, then yes you are just doing it wrong. Things aren't either exactly right and done one way, or else terrible. You can of course have bells and whistles like animations if your usecase requires them (HN doesn't!) and still have a fast loading site with clean code, if you…
I agree with you. And the animations example was simply one of the bad offenders (merely one of the symptoms of the disease).
The disease is overutilizing buckloads of js scaffolding which is blatant in the majority of the websites right now. Even a small blog now "has to have" the latest xzibit framework which pulls 32 foobar dependencies, all gulped into one huge blob of minified compressed clusterfuck-pack.
Re: How true hackers write JavaScript
#188The 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.
Hard to read? The sum total of the script fits on 2-3 pages at most, no single function exceeds about 10 lines, if you have trouble reading and reasoning about that code then something is wrong.
Yeah, I also like to minify the code before reading. It makes up to 5 times less code and it's fun to guess which letter stands for which function.
Re: How true hackers write JavaScript
#189Earlier quoted context omitted.
Your code is not more readable, it is just shorter. In fact, using the online babel transpiler, it transpiles the es6 version you provided precisely into hn's version: https://bit.ly/2MPmjK7 To use es6 to achieve what this tiny piece of javascript could already do, you probably need to introduce some tremendous dependency like babel just to be compatible with all kinds of weird browsers out there. What does es6 give…
It's 2018. Unless you're using Internet Explorer arrow functions are supported natively.
And I bet there are some people here using IE. And old browsers.
Re: How true hackers write JavaScript
#190Earlier quoted context omitted.
"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-processors do that much better than a human and can also tree-shake. There's no reason for a human to do it.