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...
How true hackers write JavaScript
261–270 of 342 posts
Re: How true hackers write JavaScript
#262Way 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…
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?
Re: How true hackers write JavaScript
#263Earlier quoted context omitted.
Except there isn't any problem here whatsoever. Yes, it's coupled, but it doesn't matter. No, this kind of code doesn't scale. It doesn't have to . The time you spent writing this comment was longer than what it took writing this code. Considering what kind of site this is, that code may work indefinitely. Or, if necessary, someone from the future will need to change that 3 to a 4 at some point. In terms of total cos…
And how will that someone know what that 3 stands for ? At the minimum a comment above that line would have been nice.
They'll figure it out. They're a programmer, figuring things out is their job.
Re: How true hackers write JavaScript
#264Am I the only one who thinks this is unreadable? var on = !afind($(id), collapsed()); (on ? addClass : remClass)($(id), 'coll'); where function afind (x, a) { var i = apos(x, a); return (i >= 0) ? a[i] : null; } where function apos (x, a) { return (typeof x == 'function') ? posf(x,a) : Array.prototype.indexOf.call(a,x) } where function posf (f, a) { for (var i=0; i
[deleted]
Re: How true hackers write JavaScript
#265Am I the only one who thinks this is unreadable? var on = !afind($(id), collapsed()); (on ? addClass : remClass)($(id), 'coll'); where function afind (x, a) { var i = apos(x, a); return (i >= 0) ? a[i] : null; } where function apos (x, a) { return (typeof x == 'function') ? posf(x,a) : Array.prototype.indexOf.call(a,x) } where function posf (f, a) { for (var i=0; i
+1,000.
The best programming advice I ever got was to write code for other people to read (and understand at a glance), not for the machine to execute.
This code is the precise opposite of that.
Re: How true hackers write JavaScript
#266Am I the only one who thinks this is unreadable? var on = !afind($(id), collapsed()); (on ? addClass : remClass)($(id), 'coll'); where function afind (x, a) { var i = apos(x, a); return (i >= 0) ? a[i] : null; } where function apos (x, a) { return (typeof x == 'function') ? posf(x,a) : Array.prototype.indexOf.call(a,x) } where function posf (f, a) { for (var i=0; i
It's not too descriptive, however it is descriptive by function name. Take the afind line, you can ascertain what it does by afind's name and provided params:
afind -> find, $(id) -> find id, collapsed -> find id's collapsed state.
I agree it's not a simple glance to figure out what it does, however it is not unreadable.
Re: How true hackers write JavaScript
#267Earlier 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…
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.
Re: How true hackers write JavaScript
#268Write 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).
If by 10 years ago you mean two years ago, then yes. Unvote was added two years ago.
Thing is simple, unreadable, and it works. Turns out, code can both work and be shit at the same time. We've all done it.
Re: How true hackers write JavaScript
#269Thanks for sharing this nice bit of code; we always learn from examples, we should see more of this. I feel the naming is too short, things are just a little too specifically compact and slightly cryptic ... almost like the author is trying to say something ... I've never said this before about code ... but I think that code is 'smug'! Like odd facial hair, or one of those valley-specific t-shirts ... the code trying…
Too compact? It's the size of an APL implementation, and all it does is some ux... ;)
Re: How true hackers write JavaScript
#270Am I the only one who thinks this is unreadable? var on = !afind($(id), collapsed()); (on ? addClass : remClass)($(id), 'coll'); where function afind (x, a) { var i = apos(x, a); return (i >= 0) ? a[i] : null; } where function apos (x, a) { return (typeof x == 'function') ? posf(x,a) : Array.prototype.indexOf.call(a,x) } where function posf (f, a) { for (var i=0; i
+1,000. The best programming advice I ever got was to write code for other people to read (and understand at a glance), not for the machine to execute. This code is the precise opposite of that.
Why it can't be both? And, Yes - it can