Live data from Hacker News

How true hackers write JavaScript

news.ycombinator.com

311–320 of 342 posts

Re: How true hackers write JavaScript

#311
post #292

Maybe I'll respond in a general way to what's come up here. This code isn't unreadable, or accidentally readable—it was written specifically for readability. Similarly, it isn't unmaintainable or accidentally maintainable—it is written specifically for maintainability. Unlike in most programming debates, we can actually prove this. Here is the proof: I've talked to everyone whose job it has ever been to read this cod…

> I've talked to everyone whose job it has ever been to read this code, and all agree that it is easy to read. I've also talked to everyone whose job it has ever been to maintain this code, and all agree that it is easy to maintain.

So, like, maybe two people besides yourself.

Re: How true hackers write JavaScript

#312
post #215

Earlier quoted context omitted.

I was at the bottom of Africa last month with unstable internet connection barely faster than dial-up. HN was the only site I could connect before getting timeouts and bs.

I get one of your points, that some sites should work in the bottom of Africa. But there is a counter-point here, no? Why should a site be developed for the worst of connections out there? Is there a middle point here?

If it works on a crappy dial-up connection it should be nice and fast on a decent connection. Slow loading pages turn visitors away.

Re: How true hackers write JavaScript

#313

https://twitter.com/triskweline/status/798443082740023296 > Valve's Steam Store renders on the server, uses ancient jQuery 1.8, loads 12 unminified JavaScripts. > It moved 3.5 billion dollars in 2015.

Steam forums on the other hand are an abomination stitched together from every content tracker and third party js library ever written.

Re: How true hackers write JavaScript

#314
post #308

Earlier quoted context omitted.

Assembly, used this way, just means “the words that create action at the layer below which you cannot go”. Also referred to as “metal”. Depending on where you are starting that could be JavaScript, or it could be Basic, or any of a number of things. In the browser it’s JavaScript. This only makes sense if you can see that there are machines within the machines, within the machines.

Fair enough, it's a metaphor, but a fragile one that breaks down easily, as I believe it has here. Using actual assembly to defend terse coding in javascript because javascript is "assembly for the web" doesn't work.

That’s true.

Re: How true hackers write JavaScript

#315
post #301
post #195

Earlier quoted context omitted.

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.

It might be interesting to see an example of a comment that you (or anyone) thinks would add to maintainability. What isn't expressed in the code? If there is such information, there are two possibilities: either we could easily modify the code to express it; or we could not. Each would be interesting, but for different reasons.

It's probable that HN is so feature-frozen it's not worth doing at this point, but if it were not, there are a few good reasons. The parent's example in hideStory() is a good start:

    for (var i=0; i 
This way, if (for instance) someone were to try to modify the layout to use margins rather than spacers, or if someone were to strip whitespace from the rendered HTML, a quick search (or manual skim of the code when something breaks) for "spacer" or "whitespace" would help someone avoid needing to step through what's being removed in Dev Tools. Minimally invasive, would greatly help someone doing code review, and doesn't even increase line count. Documenting the helper methods at the top would help newcomers to the codebase as well.

More generally, going a step further, I've been inspired in my commenting style by Jeremy Ashkenas's literate code for the Backbone library. See, for instance, http://backbonejs.org/docs/backbone.html#section-111 . The code itself is as self-explanatory as any other code I've ever seen, but the comments serve to accelerate that browsing process. Backbone, while somewhat dated nowadays, is a great level of abstraction in that the entire library can be grokked in an afternoon - but without comments, I think it would take longer. Reading time does not monotonically increase with number of characters :)

And as a third point, if there's ever something confusing enough, or you're using some infrequently-used feature of the CSS/DOM spec, such that the author or reviewer needed to look up how it worked in documentation or a forum somewhere, I encourage my team to simply add that documentation or forum link into the comments. Extremely helpful for maintainability, particularly when onboarding junior team members, allows code reviews of that line to be asynchronous whereas they would otherwise require synchronous explanation, and it's ideally just as quick to keystroke "select-url/copy/close-documentation-tab/tab-into-codebase/start-comment/paste/enter" as it is to "close-documentation-tab/tab-into-codebase."

This is Hacker News - we're the antithesis of enforced Javadoc-style comments :) But if you consider someone needing to read code without having the live input of the author, minimal comments for especially terse or creative code can quickly start to make sense, certainly in the territory of the rightmost columns of https://xkcd.com/1205/

Re: How true hackers write JavaScript

#316

  My opinion of the code is this. 
  It's pretty tight, which I can respect. 
  I haven't run it, but it PROBABLY works.

  But it's hard to read. 
  Things are named poorly. 
  Many edge cases are missed (not checking args properly).

  These functions are not pure and therefore, harder to test. 
  Maybe true 1337 H@X0Rz don't need to write tests, but some of us have mortgages to pay...

  I didn't re-write all of this mess, but check out the few util functions that I re-wrote.

  As a developer, which version would you rather work with?
  If you said the original version that's cool with me.
  But don't try to come work on my team.

  // isNull :: a -> Boolean
  const isNull = x => x == null

  // isNullOrEmpty :: String -> Boolean
  const isNullOrEmpty = string => string == null || !string.length

  // $ :: String -> HTMLDocument -> HTMLElement
  const $ = (id, _document = document) => {
    if (isNullOrEmpty(id)) return null
    if (isNull(_document)) return null
    return _document.getElementById(id) || null
  }

  // findClassInElement :: HTMLElement -> String -> [HTMLElement]
  const findClassInElement = (el, className) => {
    if (isNull(el)) return []
    if (isNullOrEmpty(tagName)) return []
    return el.getElementsByClassName(className) || []
  }

  // findTagInElement :: HTMLElement -> String -> [HTMLElement]
  const findTagInElement = (el, tagName) => {
    if (isNull(el)) return []
    if (isNullOrEmpty(tagName)) return []
    return el.getElementsByTagName(tagName) || []
  }

  // findClass :: String -> HTMLDocument -> [HTMLElement]
  const findClass = (className, _document = document) => {
    if (isNullOrEmpty(className)) return []
    if (isNull(_document)) return [] 
    return findClassInElement(_document, className) || []
  }

  // elementHasClass :: HTMLElement -> String -> Boolean
  const elementHasClass = (el, className) => {
    if (isNull(el)) return false
    if (isNullOrEmpty(className)) return false
    return el.className.includes(className)
  }

  // addClass :: HTMLElement -> String -> Boolean
  const addClass = (el, className) => {
    if (isNull(el) || isNull(el.className)) return false
    if (isNullOrEmpty(className)) return false
    if (el.className.includes(className)) return true
    el.className = `${el.className} ${className}`
    return true
  }

Re: How true hackers write JavaScript

#317
post #316

My opinion of the code is this. It's pretty tight, which I can respect. I haven't run it, but it PROBABLY works. But it's hard to read. Things are named poorly. Many edge cases are missed (not checking args properly). These functions are not pure and therefore, harder to test. Maybe true 1337 H@X0Rz don't need to write tests, but some of us have mortgages to pay... I didn't re-write all of this mess, but check out th…

I prefer the original one.

I don't see the value, for this use case, of all those checks. We know what the input values are, essentially what's in the DOM that we 100% control.

I feel ES6 syntax much less readable than ES5 (probably because I have worked more in ES5 than ES6), it introduces a bunch of new symbols.

How can this

  const isNull = x => x == null

Be more readable than

  function isNull (x) { return x == null}

Another example,

  const addClass = (el, className) => {
  }

I always have to remember what this construct means and translate / unroll it in my mind to a regular function.

Also, why would an addClass return a boolean? Doesn't make much sense.

  // $ :: String -> HTMLDocument -> HTMLElement
    const $ = (id, _document = document) => {
      if (isNullOrEmpty(id)) return null
      if (isNull(_document)) return null
      return _document.getElementById(id) || null
    }

How can above be more readable than

  function $(id) { return document.getElementById(id); }

I bet I can give the original code for Python/C/Java developers and they would understand / change it easily.

That said, I consider myself a backend / devops person who sometimes needs to do work in the frontend, the biggest project I did was a medium size app with around 40 routes that I used react, es5 and bootstrap.

Big fan of Go and it's very readable / limited syntax.

Re: How true hackers write JavaScript

#318
post #172

Earlier quoted context omitted.

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?

> Do web designers still exist that only do HTML/CSS but no JS?

That is really beside the point. HTML and JS should not be coupled to the extent that adding or removing some whitespace from the HTML will cause the JS to fail. This kind of things turns a trivial improvement into a nightmare, so you end up not daring to change anything.

Re: How true hackers write JavaScript

#319
post #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.

[deleted]

Re: How true hackers write JavaScript

#320
post #293

Earlier quoted context omitted.

> Not only is is shorter, but it's more readable too! And won't work on IE. Not just because of el.classList, but also because of the arrow notation. So by doing this change, you either have to ditch one of still used browsers, or introduce a stupidly complex transpilation chain into the mix.

I'm aware, but I'm responding to the myth of: > Any effort in trying to bring it up to modern webdev standards would likely make the code expand significantly That's just not true, and nowhere did that person say: "Because of legacy IE support requirements", they only mentioned "modern webdev standards". Are you suggesting arrow functions, and classList aren't modern standards then?

I was that person, and what I meant was that "modern webdev standards" would include modules and features requiring transpilation, which would introduce many dependencies, all of which count into code size (you have to keep track of them mentally).
Post reply on HN