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

151–160 of 342 posts

Re: How true hackers write JavaScript

#151

Post by TeMPOraL »

aleksei wrote: post #147
olavk wrote: 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.

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

It works, and it's arguably simpler than the div-soup with extensive styling, which is the "kosher" way of doing this.

Re: How true hackers write JavaScript

#152

Post by Timpy »

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.

Re: How true hackers write JavaScript

#153

Post by TeMPOraL »

kruczek wrote: post #128
pacifika wrote: post #101

Earlier quoted context omitted.

>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'…

Eh, it's only 150 lines of simple functions without external dependencies. It's simple enough to understand and modify on the spot. As long as these are not expected to grow significantly in the future, I don't see why it'd be making it hard on yourself (and if it does grow, then it can always be refactored).

This 100x times. There is very little code there. Any effort in trying to bring it up to modern webdev standards would likely make the code expand significantly, and that's not even counting the complexity of the deployment pipeline. This here, it's just 150 lines of plain code. It's not hard to work with something like this.

Re: How true hackers write JavaScript

#155

Post by jwally »

Vinnl wrote: post #45
Tajnymag wrote: post #4

That might be one of the most readable pieces of code that I've ever read.

I think the main reason this is somewhat readable is because there's hardly any code. Which is fine.

The supreme art of war is to subdue the enemy without fighting.

-sun tzu

Re: How true hackers write JavaScript

#156

Post by derekbreden »

olavk wrote: 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…

I think the purpose of 'aeach' is not to rename, but to provide a conversion. 'aeach' converts to an array in order to be able to perform a 'forEach' on the non-array NodeLists.

The 3 elements being removed are the tr containing the story options, a literal whitespace node, and a tr used as a spacer.

I agree it is a coupling, and while accurate to describe as fragile or even really fragile, I personally would not have used those words.

I would feel more comfortable daring to make changes in this html and JavaScript than any other front-end code I've worked with in the last 15 years of my career. If for no other reason, the sheer small size of it and lack of external dependencies that you mentioned.

Re: How true hackers write JavaScript

#157

Post by TeMPOraL »

golergka wrote: post #130
Aardwolf wrote: post #104

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? If it's a typical platformer from 1980s, now. If it's a modern game with a modern game's complexity, it would never be finished in assembly anyway.

Then again, clones of games from 1980s in modern engines are considered toy projects. The equivalent on the web is considered standard practice.

Re: How true hackers write JavaScript

#158

Post by fb03 »

Way 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 'shiny new features'.

Keep going, YC!

Re: How true hackers write JavaScript

#160

Post by barrkel »

pacifika wrote: post #101
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'…

The code is entirely self-contained. That's what makes it easier for future-you to understand and decipher. Dependencies won't have gone out of date, library versions won't have moved on, APIs won't have disappeared, etc.
Post reply on HN