211–220 of 342 posts
Write it with all the modern "proper" approaches, and good luck even just recompiling it in 10 years. While this code - however imperfect - remains just as maintainable today as it was when originally written (which is probably more than 10 years ago).
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…
> 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.
The HN code is meant to be understood as a self-contained piece, and that's contextually very different from most code out there.
Write it with all the modern "proper" approaches, and good luck even just recompiling it in 10 years. While this code - however imperfect - remains just as maintainable today as it was when originally written (which is probably more than 10 years ago).
That's true if you're talking about using React, Vue, etc. but do you really think ES5 JavaScript is more likely to be supported in the future than ES6?
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…
Based on a Fortran convention, IIRC. Within a web setting, "el" and "ev" are extremely conventional.
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…
- minimal functionality
- rarely if ever changes
- is maintained by a very small group (Hacker News)
- large and/or transient teams
- large quantity of inter-dependent features
- constant changes
Modern web apps are less about being performant and minimal, and more about dealing with the complexities of large software teams
Earlier quoted context omitted.
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.
I'm not saying a rewrite is necessary at all, but refactoring this code to use more modern standards would NOT increase the line count at all, my guess it it might cut it by 15%+ in total size if you leveraged the beautiful builtin functions. Compare these: function addClass (el, cl) { if (el) { var a = el.className.split(' '); if (!afind(cl, a)) { a.unshift(cl); el.className = a.join(' ')}} } Could turn into somethi…
Earlier quoted context omitted.
I'm not saying a rewrite is necessary at all, but refactoring this code to use more modern standards would NOT increase the line count at all, my guess it it might cut it by 15%+ in total size if you leveraged the beautiful builtin functions. Compare these: function addClass (el, cl) { if (el) { var a = el.className.split(' '); if (!afind(cl, a)) { a.unshift(cl); el.className = a.join(' ')}} } Could turn into somethi…
el.classList isn't supported by IE < 10