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).
How true hackers write JavaScript
201–210 of 342 posts
Re: How true hackers write JavaScript
#202Earlier quoted context omitted.
I’ve replaced jQuery on several projects with $ = querySelector, $$ = querySelectorAll (wrapped in Array.from if you need to support IE11 so you can use all of the new array methods which their NodeList implementation didn’t get until Edge), classList and fetch. Beyond the code size savings, I find the newer standard methods are generally easier to understand when scanning code.
I like what this guy did, talking about native methods. However it's too flexible for me, I prefer to have the most minimal functionality in order to ensure consistency in my code. But maybe that's just me. If the library opens up too many possibilities, then I have both the "problem of choice" when writing code, and also it's more difficult to refactor down the line if you want to change lib. Whereas using your own…
I've been using this for years – it's not the end of web development but an awful lot of projects don't need more framework than can fit in a tweet:
let $ = (selector, scope=document) => {
return scope.querySelector(selector);
};
let $$ = (selector, scope=document) => {
return Array.from(scope.querySelectorAll(selector));
};Re: How true hackers write JavaScript
#203Earlier quoted context omitted.
Animations being badly/over used aside, this is a bit of a straw man argument. If you load megabytes of JS to do animations, as opposed to using CSS, then yes you are just doing it wrong. Things aren't either exactly right and done one way, or else terrible. You can of course have bells and whistles like animations if your usecase requires them (HN doesn't!) and still have a fast loading site with clean code, if you…
I agree with you. And the animations example was simply one of the bad offenders (merely one of the symptoms of the disease). The disease is overutilizing buckloads of js scaffolding which is blatant in the majority of the websites right now. Even a small blog now "has to have" the latest xzibit framework which pulls 32 foobar dependencies, all gulped into one huge blob of minified compressed clusterfuck-pack.
Yeah, I guess it is a tradeoff between engineering productivity and performance. Both are features. Past a certain level of complexity it is usually the correct decision to choose the framework and toolchain so that you can deliver and maintain features at all. "Make it work -> make it good -> make it fast" is very relevant here.
Though I agree about what you're saying for blogs and other content sites, where the tradeoff is clearly inappropriate in a lot of cases. With that said, things like https://www.gatsbyjs.org/ offer an interesting '3rd way' here, allowing you to keep the productive toolchain and framework stuff but still serve a blazing fast static content site.
Re: How true hackers write JavaScript
#204Earlier quoted context omitted.
>Having less characters makes code more readable (or rather "scannable") as well, it's just another tradeoff. Only to a point, otherwise minified js would be more legible than plain source. It takes "a couple of seconds" to scan the codebase and find out what el or ev refer to, but it would take zero seconds if they were just called "event" or "element."[0] There's no gain in readability from shaving off one or two c…
Of course, up to a point. The same goes for very long but extremely descriptive variable names. Hence, it is a tradeoff.
[deleted]
Re: How true hackers write JavaScript
#205Earlier 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.
I expect the layout would also be simpler in another way: Give every "child" div a static indentation, nothing more. They'll nest and the indentation will stack the deeper the comments go.
Right now there's already nested tables-within-tables, just to work around how table columns work in order to handle indentation (and each row's indentation is handled separately with a stretched 1x1 image with a width attribute that's calculated server-side).
Re: How true hackers write JavaScript
#206Earlier quoted context omitted.
Perhaps this why HN still uses tables for presentation - nobody dares to change it? There's also simply no reason to change it, it works.
> 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.
I'd argue it's far from ideal. Mainly because closing a large tree of comments can often hang the UI for a second or so while this JS runs to find and hide all the children that need to be hidden.
But it is simple, and it does get the job done for the most part.
Re: How true hackers write JavaScript
#207Earlier quoted context omitted.
Eh, it's only 150 lines of simple functions without external dependencies. It's simple enough to understand and modify on the spot. As long as these are not expected to grow significantly in the future, I don't see why it'd be making it hard on yourself (and if it does grow, then it can always be refactored).
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(' ')}} }
const addClass = (el, cl) => el.classList.add(cl)
Re: How true hackers write JavaScript
#208Earlier 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…
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 easier to understand the code which is more important in my experience. As the number of code files gets beyond a few files any benefits you get are rapidly lost because now you need to keep all that knowledge in your head and start having to jump around between 5, 10, 20 or more files to work out what everything is let alone what it is doing. This is why naming stuff in code is so important (and sometimes so hard).
Golang has a good philosophy on this front: https://github.com/golang/go/wiki/CodeReviewComments#variabl... tl-dr: the further from its declaration that a name is used, the more descriptive it should be.
This sort of attitude about brevity & speed appears to be a common problem with some developers I come across - they are absolutely obsessed with "productivity" when it comes to writing code. They've just got to have their 97 plugins/extensions to their editor and they simply must have their finely-honed emacs keybindings. If you are focusing on just churning out code as fast as humanly possible (i.e. "productivity"), then your job as a programmer can probably be safely replaced with a couple of shell-scripts.
I've never been in a situation where the limiting factor in programming has been how fast I can read it or write it - the limiting factor has always been understanding the problem at hand, and designing a solution that solves the problem and is maintainable.
Re: How true hackers write JavaScript
#209Um, is this supposed to be a criticism? Because this is MUCH better than sites loading megabytes worth of scripts to do nothing more than render text, have dozens of floating elements everywhere, auto playing videos that follow you, "use our app" buttons, etc... JS is the assembly of the web, do you also criticize games written in assembly?
>JS is the assembly of the web, do you also criticize games written in assembly? No it isn't, any more than C++ is the assembly of your operating system. Assembly has the terseness that it does because of constraints that javascript doesn't have -- this javascript looks the way it does because the author wanted it to look like lisp code, not because it has to.
At least it's the lowest level programming language for browsers I know. So perhaps I should have said "machine language of the web" because assembly isn't the lowest level :)
Re: How true hackers write JavaScript
#210I 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.