How true hackers write JavaScript • Hacker News Board

Re: How true hackers write JavaScript

#321

Post by olavk » Thu, Sep 06, 2018, 7:46 AM UTC

btown wrote: post #315

dang wrote: post #301

Earlier quoted context omitted.

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

While I agree that comment would be very helpful given the code, It would be much better to rewrite the code so it didn't have to know about those three nodes at all. For example by collecting them into a single element which could be removed in a single operation. The comment here is just a bandaid for code which is much more complex than it needed to be.

Re: How true hackers write JavaScript

#322

Post by olavk » Thu, Sep 06, 2018, 8:17 AM UTC

dang wrote: 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 don't like criticizing the code since it clearly works as intended and HN works very well, and I am a happy user. But since you argue that the code is very deliberately maintainable I will challenge that, because I am not convinced. The code is tightly coupled to the HTML in a way that makes it difficult to change the HTML without breaking the code. For example it should (if the code is so maintainable) be trivial to change the use of tables for presentation into semantic HTML like say UL/LI. Since this would improve accessibility this is a net win with no drawbacks, right?

Re: How true hackers write JavaScript

#323

Post by spiralx » Thu, Sep 06, 2018, 9:02 AM UTC

mercer wrote: post #136

gpvos wrote: post #89

Earlier quoted context omitted.

No, it is because some array-like objects like node lists actually aren't Arrays and don't have those functions in their prototype.

this is why I usually go for something like const $ = (el) => [...document.querySelectorAll(el)]

Although NodeList has forEach defined on it now at least.

Re: How true hackers write JavaScript

#324

Post by spiralx » Thu, Sep 06, 2018, 9:16 AM UTC

xigma wrote: post #267

mattlondon wrote: post #208

Earlier quoted context omitted.

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…

The point I'm making is not "use short variables everywhere", it's that in this case , the verbose alternative is not "much more readable". Abbreviating "element" to "el" or using "attr" instead of "attribute" (etc.) can significantly reduce noise in web client code. Everybody either knows what it means, or they shouldn't be editing the code in the first place.

I prefer "elem" as then it's easier to distinguish from "event" than it is for "el" and "ev".

Re: How true hackers write JavaScript

#325

Post by spiralx » Thu, Sep 06, 2018, 10:32 AM UTC

anonlastname wrote: post #261

I approve of those wrapper functions in the first few lines... those would have saved me so much time when I was a web dev I'd say I'm going to copy them next time but there is no license header...

If you really need a shortcut then

    const $ = (sel, elem = document) => [ ...elem.querySelectorAll(sel) ]

is nicer as you can use CSS selectors.

Re: How true hackers write JavaScript

#326

Post by spiralx » Thu, Sep 06, 2018, 11:30 AM UTC

dang wrote: post #298

Ataraxy wrote: post #134

Criticisms and bizarre fawning over beauty that a couple of people have made aside, the one thing that bugs me the most is the inconsistent usage of ;

I should fix that, since sctb probably agrees with you and is too polite to say so. Any suggestions for me as a shitty semicolonist?

You can always use either Prettier or Standard JS to lint and format your code, and both can be set up with or without semicolons...

https://standardjs.com/

https://prettier.io/

I prefer Standard JS, but either way it's easier to not need to think about the exact details IMO :)

Re: How true hackers write JavaScript

#327

Post by spiralx » Thu, Sep 06, 2018, 11:33 AM UTC

JTbane wrote: post #255

function $(id) { return document.getElementById(id); } Nice! Now I don't need jQuery.

Here's the smallest jQuery replacement I've seen :)

https://gist.github.com/paulirish/12fb951a8b893a454b32

It let's you do

    $('p').on('click', el => /* ... */)

which is handy for smaller scripts :)

Re: How true hackers write JavaScript

#328

Post by giancarlostoro » Thu, Sep 06, 2018, 11:48 AM UTC

dang wrote: post #297

giancarlostoro wrote: post #148

While everyone's freaking out over the code I'm remembering the old code that was only 2 functions[0], which leaves me to believe this code was changed not too long ago. I wish we had a github or something of some of these front-end changes to HN just to see how things change over time. I figure it wouldn't be too much, but still. The original JS was inlined and contained two functions: hide and vote. [0] https://new…

We expanded it for collapsible comments a few years ago.

Been here a little minute, feels like it was just yesterday, but if I had to guess at least after 2016? Since that's when that comment is from. I guess it's my fault for not looking once collapsible comments were added though :)

Re: How true hackers write JavaScript

#329

Post by at-fates-hands » Thu, Sep 06, 2018, 2:25 PM UTC

owl57 wrote: post #251

at-fates-hands wrote: post #227

Earlier quoted context omitted.

> 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 application or portal would only be in use for maybe a year or 18 months before a complete rewrite or total redesign Why on earth is this such a popular idea? Do customers somehow prefer to see all the buttons in new places and old urls broken every other year?

I'm honestly not sure. When I first started out, all the applications I used had been built five years prior. We made small tweaks and continued to use them because they just worked

Now? I think newer technologies come out faster and capture people's attention. They want to use the new shiny thing. I think the "business people" want to have a big budget project to get recognition within large orgs. I think developers want to use the latest and coolest stuff. I think people feel like we already live in a disposable culture, why would our sites and apps be any different? You combine all of these and suddenly the pressure and inertia not to move or rebuild or redesign regularly is too much to overcome.

I still remember going to a ReactJS class and the guy running it kept saying, "Don't get me wrong, BackboneJS is still a hell of a library and is still relevant and awesome to build stuff with BUT React does a few things better."

This is where we are. Huge financial investments, time and energy to get a 3-5% bump in efficiency? Doesn't make sense to me.

Re: How true hackers write JavaScript

#330

Post by lucisferre » Thu, Sep 06, 2018, 4:20 PM UTC

criveros wrote: post #271

lucisferre wrote: post #244

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

should be using fat arrow functions.

What possible benefit would this have? Particularly considering it doesn't rely on "this" anywhere.