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

241–250 of 342 posts

Re: How true hackers write JavaScript

#241

Post by kozak »

LiterallyDoge wrote: post #234
kozak wrote: post #213

Earlier quoted context omitted.

I'm talking about NPM modules and the build toolchain (which consists of even more NPM modules). This stuff goes stale very quickly (at the 10-year scale). It's good for a project that is kept continuously alive (i.e. when there is a team of developers that is continuously making changes to the project), but not when the project sits on a shelf for 10 years and then needs to be modified.

This is a good point, but if you take NPM / Yarn / Bower (RIP) with a grain of salt and secure your codebase against failures, they work nicely as a toolchain.

Do you mean committing node_modules to the Git repository? Unfortunately, that's not a panacea with build tools, because some of them contain non-JS code that is tightly coupled to Node and OS versions.

Re: How true hackers write JavaScript

#242

Post by firethief »

mattlondon wrote: post #208
xigma wrote: 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…

Less characters really only makes sense in some scenarios, e.g. "unimportant" variables (for loops, temporary storage inside a procedure). Verbose 'variablesToKeepTrackOfPositionInThisLoop' is obviously pointless when 'i' will do. However renaming "important" things to make it quicker to read or type is, in my experience, a mistake if your code base is more than just a handful of files. Descriptive names make it much…

> tl-dr: the further from its declaration that a name is used, the more descriptive it should be.

Interestingly, this results in more or less the opposite of entropy coding

Re: How true hackers write JavaScript

#243

Post by JanisL »

always_good wrote: post #178
vonseel wrote: post #126

Earlier quoted context omitted.

macOS just notified me that one tab in Safari was using so much memory it was threatening performance of my laptop. The website in question? https://idioms.thefreedictionary.com/ It was close to 2Gb RAM usage. Bunch of ad-tracking stuff, I assume, as Firefox and its related processes seem to be using less than 1250mb with 6 tabs open, including the site mentioned in 2 tabs. My firefox has uBlock origin installed. See…

Last week my bandwidth grounded to a halt which is usually the result of someone uploading on my network. I went to my girlfriend's computer to see if she was syncing with Dropbox or something. Nope. She quit all of her applications just to be sure. Except for a single browser tab opened to a recipe for pita bread. Yep, turned out that a recipe for pita bread was saturating our router because what looked to be buggy…

Sounds like a PITA recipe

Re: How true hackers write JavaScript

#244

Post by lucisferre »

I'm not sure if this was linked fatously, but this is actually pretty good JS.

- All functions

- The functions are simple and decomposed into smaller functions

- No usages of "this" (except one necessary one in an event handler)

- No ham fisted attempts at doing OOP with JS

Only complaints really are naming and code style is overly compact which would potentially make it harder to understand, but in this context I think that is ok. There is nothing overly complex going on here. The code seems reasonably easy to understand.

If there are criticism I'd like to hear them.

Re: How true hackers write JavaScript

#245

Post by ht85 »

err4nt wrote: post #220
ht85 wrote: post #219

Earlier quoted context omitted.

el.classList isn't supported by IE < 10

And is it accurate to describe IE < 10 as "more modern"?

It isn't, and I don't think I have.

My point was that using a "more modern standard" would break hn for people using legacy browsers.

Re: How true hackers write JavaScript

#246

Post by jmiserez »

olavk wrote: post #172
TeMPOraL wrote: post #151

Earlier quoted context omitted.

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

Well using divs would at least make you able to group the elements semantically so you could remove a single node rather than having a for loop which removes exactly three nodes. This would be significantly simpler in my opinion. And it would be less fragile since now you can redesign everything inside this node without the JavaScript breaking.

Agreed. But getting divs to do what you want has also gotten considerably easier in the last 10 years. It used to be a lot more work/boilerplate to get a consistent div-based layout across all browsers down to IE 6.

As for the redesign, the total amount of code (HTML/CSS/JS) you’d need to touch is still small. Do web designers still exist that only do HTML/CSS but no JS?

Re: How true hackers write JavaScript

#247

Post by LyndsySimon »

at-fates-hands wrote: post #227
MaxBarraclough wrote: post #210

Earlier quoted context omitted.

> As long as the code works, anything else is just gravy. Nonsense. Maintainability almost always matters. As the adage goes: code shouldn't merely work, it should clearly work. > If you were to peel back the layers on all the major websites out there, I'm sure you'd find less than stellar code everywhere. Indeed, but Sturgeon's Law shouldn't make us feel better.

> Nonsense. Maintainability almost always matters. The last three large corporations I worked for never cared about maintainability because the application or portal would only be in use for maybe a year or 18 months before a complete rewrite or total redesign. All of the recent projects I've been on take the same approach. Get it stood up, make it look pretty and release it. Because agile development makes business…

> The last three large corporations I worked for never cared about maintainability because the application or portal would only be in use for maybe a year or 18 months before a complete rewrite or total redesign.

The first significant web app that I wrote had a similar approach. I was a new developer, but I had a good idea and they hired a manager and a couple of other developers to flesh it out. No need to hire a senior dev, because it was just a POC. We weren't even part of IT, so anything we built would of course only be in use for a few months before IT would allocated "real" developers to rewrite it.

Four years after I left that job, I got a call one day that the site was down and they couldn't fix it. After ten minutes on the phone with a former colleague reading me the logs out loud while I read through an old copy of the code that I (thankfully) still had on an archived drive, it turns out that the LDAP server's address had changed. We updated that and it came back.

Out of curiosity, I had them run `uptime` on that box. It had been up for six years - the two years I was there, and the four since I'd left. Not only had the application continued to function and be used... the box it was running on hadn't been updated restarted since it was built. It hadn't gotten updates since I'd left either.

The point of this story is simple: there is no such thing as code where maintainability doesn't matter, because there is no such thing as "temporary" code. Code can get retired or refactored away, sure, but there is absolutely no way to tell ahead of time if any given code snippet falls into that category.

Re: How true hackers write JavaScript

#248

Post by markbnj »

xigma wrote: post #137
paulintrognon wrote: post #120

Earlier quoted context omitted.

I believe there is a difference between gold-standard perfect code and just making "beginners mistakes". It costs almost nothing more to write "event" instead of "ev" or "removeElement" instead of "remEl", but it makes the code much more readable. You might gain 1s for writting remEl instead of removeElement but you will loose more seconds in the future trying to remember what remEl stands for, or having to check wha…

> 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 less characters makes code more readable (or rather "scannable") as well, it's just another tradeoff.

It might, in a specific circumstance, while in another circumstance it might make the code significantly less readable. That is an indication that number of characters is probably not a good metric for adjusting readability.

Re: How true hackers write JavaScript

#249

Post by habosa »

The code style is fine, it's practical.

But how about what it does? Has anyone ever tried to collapse or expand a 100+ comment thread here? It can lag for 1-2s. So all the talk of "it's simple code that serves its purpose" is not really true.

That said, please don't solve my complaint by adding a bunch of SPA stuff to HN. I love how fast the base content loads here and how there's nothing dynamic.

Post reply on HN