function hide(id) {
var el = document.getElementById(id);
if (el) { el.style.visibility = 'hidden'; }
}
function vote(node) {
var v = node.id.split(/_/);
var item = v[1];
hide('up_' + item);
hide('down_' + item);
var ping = new Image();
ping.src = node.href;
return false;
}
What's most fascinating to me about this isn't the simplicity, it's that this code has lived for so long with almost no changes.
It's a great counter-example to all the recent articles about JavaScript fatigue. It's good for us to see real examples of sites that aren't caught up in the framework of the week hype.
At the end of the day we're trying to make stuff that works. ES5 vs ES6, React vs Angular vs. Ember vs. Aurelia, Angular 1 vs Angular 2, even server rendered templates vs. single page apps - it all matters a lot less than we think.
For the majority of cases that I've seen, these arguments are simply excuses to avoid doing real work. It's way more fun to decide whether your amazingly awesome Unicorn startup is going to use React or Angular, or Express vs. Rails, or whatever than it is to actually go through the hard work of building a customer base and making money.
Funny you said that, I was looking into ng2 and they've borrowed a few things from the React community. It's all good, I'm glad to see that "framework A is better than framework B" mentality die away and everyone just uses the right tool for the right job.
for the majority of cases i've seen, these arguments are to save developers time and the company money.
my gut & feelies tell me there is truth to "it doesn't really matter what technologies you use" but my brain and experience tell me that is objectively false.
The reason "it doesn't matter what technologies you use" is because successful software gets rewritten multiple times anyway.
It matters a lot eventually, but having an "eventually" to worry about is a nice problem to have.
(There's also a big perspective difference between being an entrepreneur writing initial code for a project vs. an engineer hired to maintain & grow that code. Code quality, architecture, and technology choice matters a lot to an engineer who will be working with it directly. It matters a lot less to a business that can swap out engineers until they find ones who enjoy working on that codebase. The fact that you even have money to hire engineers usually indicates that the existing code is getting the job done. The business only gets screwed when the code quality is so bad that nobody can make sense of it, and the environment changes in a way that requires modifications.)
Totally agree. One problem I find arises from this is that there are no boring workhorses. Time and time again I need boring crud screens, for the admin side of applications, but there is no easy default to choose. ExtJS tends to do the trick, but it's not cheap.
> and how it compares (whether horribly or awesomely).
Given only the tech stack, it can go either way, depending on whether the implementor takes the easy, lazy route or actually puts some thought and hardwork into it. The problem is, as per good old Sturgeon's law, 90% of sites take the lazy route, and end up with tangled monstrosities that look like offerings to the Flying Sphaghetti Monster.
(Also, it's interesting how quickly 'cool new tech' can become 'Enterprise' shudder when it's widely abused and misused.)
Lol. For hiding a voting arrow after it's clicked. Yes, you're right. You don't need any of that stuff. But if you were to write an entire app in the style of those two functions, things would fall apart. That's not even a hypothetical, it's been proven over and over again that it doesn't work.
How is everyone agreeing with you? Is there that much JS fatigue that we're looking at the equivalent of a horse-drawn carriage, and saying wow, I wish things were as simple as they were back then?
I think the point is that there's actually little wrong with using standard HTML forms and hyperlinks most of the time.
There is an increasing trend to move the whole website to the client side to be handled entirely by the JavaScript as a single actual page.
Personally I find most websites work better with a simple round trip to the server to fetch more HTML.
So actually building an entire system in this style isn't out of the realms of possibility at all - you just only write JavaScript for the cases where there is a real legitimate benefit to doing so.
> Personally I find most websites work better with a simple round trip to the server to fetch more HTML.
> you just only write JavaScript for the cases where there is a real legitimate benefit to doing so
The snippet above only works because HN is so simple, normally the rule of thumb is if you are going to use JS to change the DOM at all then you need to render it in the first place using JS or else you are double-implementing the render logic and you open yourself up to changing one implementation and not the other. For hiding arrows sure this works but 99.999% of the time it's a very bad idea to use JS to change the dom to a state that the server would otherwise render on a page reload. You may feel that a round trip works better but that's not what users expect or will tolerate most of the time. That kind of thinking feels very close to people who think CRUD is all you need to build an app. Sure you can build an app with just that but thinks break down very quickly.
JS fatiques starts where web pages (not web apps) start to depend on thousands of kilobytes of javascript.
Now the default thinking is along the lines "I am starting a new project, I will use angular", instead of some analysis what kind of project this is, how much JS is needed and what is appropriate.
I've started chiding those at work who preemptively implement features before they're required, and not scoped. Commit the simplest code that will do the job, and if you like, create a ticket for a future sprint with cool new features.
At home, I wait until lack of a feature (like hot reloading) frustrates me, then block out a couple of hours to do it specifically. Otherwise you've got a flashy stack and no product.
That code is more the equivalent of a digging stick. React is used to build horse-drawn carriages. I'm eagerly awaiting the JS framework that'll let me build cars.
Nowhere did I tell people to write an entire app in the style of hide and vote like you're implying.
In my comparisons I mention a lot of choices people might make, like Angular vs. Ember vs. React that are ultimately meaningless to the success of your product. I think this is what's resonating with a lot of people.
How would things fall apart, exactly? On my home machine I browse with NoScript turned on by default, and it's rare that I find a site which is broken badly enough to notice which I still care about strongly enough that I bother clicking "allow". I don't think that most of what people do with JavaScript in the browser needs to be done at all if you filter the motivations of investors and advertisers out of the picture.
> Is there that much JS fatigue that we're looking at the equivalent of a horse-drawn carriage, and saying wow, I wish things were as simple as they were back then?
The img.src trick is used by google-analytics to log metrics cross-domain as well. Pretty neat trick.
Another thing to note is the "RESTful" nature of the links embed in the page. I guess its some form of HMAC with SHA1 + Nonce that authenticates requests for the server. It differs for every href. Elegant.
function hide(a){if(a=document.getElementById(a))a.style.visibility="hidden"}function vote(a){var b=a.id.split(/_/)[1];hide("up_"+b);hide("down_"+b);(new Image).src=a.href;return!1};
I see a lot of comments here about how not having js on the page is a great thing and lets get back to the old days.
Lets be frank here, HN's UI is not good. At the very least it needs collapsible comments and responsiveness to mobile.
The fact that HN is a success is despite its bad UI, or maybe because of the many HN readers out there that fix all the broken stuff on the page.
While js on sites have surely overgrown, and there is a place for minimalism, I really don't want to go back to the old days where every click reloaded the page and interactivity was really only done in flash.
> At the very least it needs collapsible comments and responsiveness to mobile.
I don't even want that. On root comments, simply add a link (let's call the text "next") that jumps to the next root level comment. That would solve my only complaint about the HN UI.
How is this usable on mobiles? And... Why do I have to rely on a piece of third-party software in order to get features present in any really modern website?
"Responsive" doesn't mean those things. Just because some sites fail to design a decent mobile experience, doesn't mean HN (or you or anyone else) can't.
I remember some of the early HTC Android phones had text reflow enabled by default. That was almost always good enough and it would be "responsive", but for some reason mobile browsers don't seem to offer it anymore.
HN's UI is clear, accessible, and uncluttered. If you want something different, they expose an API which everyone and their mother has written a client with, including native apps for mobile. The only JS on the site is in place to reduce the page reloads you were worried about.
It's certainly not "uncluttered" on mobile, where the text and vote buttons are so tiny and crowded together that it's super easy to tap the wrong thing.
The only think I'd like for mobile is better up and down arrows. That's literally the only thing. Otherwise, don't change the UI in any way. To do otherwise would make this site so much less great!
HN's design is fantastic - it is totally perfect for its function. Collapsible comments are a pig to use. HN looks and works great on mobile now (it didn't used to but they did a redesign in the last few months).
Downvoters do you care to explain why you disagree?
I didn't down-vote you, but "collapsible comments are a pig to use" isn't really a statement I can get behind, nor a statement with any real value (what does "a pig to use" mean, practically?)
I use a (slightly modified) Chrome plugin to clean up HN's styling to make it more readable. Most importantly it adds collapsable comments, without which I would enjoy HN much less.
Collapsable comments makes it easy to tell what you have and haven't read, and to easily skip large threads which bore you without having to mentally watch the invisible vertical line and scroll until it comes back it.
Yeah "a pig to use" might come across as inflammatory and I guess that this expressing my personal preference (which is just as valid as yours but clearly neither are objectively correct).
Disclosure I use no script and am very happy that HN works without any javascript.
Practically I find collapsible comments highly annoying in every case I've seen them used. This is probably because they seem to either (1) require javascript, or (2) require page reloads, or (3) both.
In the case of HN, dang et al do a good job of detaching irrelevant comments.
I guess that collapsible comments should be one of those optional features that could be available with javascript but gracefully degrade to showing the full tree without.
> HN looks and works great on mobile now (it didn't used to but they did a redesign in the last few months).
For the record, after the redesign the comments looks worse on Windows Phone. I know, no one gives a damn about WP, but a "proper" mobile redesign would work on every browser.
Makes me thinkg of that great rant my Linus about breaking userspace by "fixing" a "bug"
If you break something for a significant portion of your users, even if it's caused by someone/something else doing something dumb, it's still your fault
HN is a success despite its UI because it was written in a Lisp and because it has the cachet of Y-Combinator behind it. If this exact site were written in PHP, and posted as a Show HN in an alternate universe, no one would consider it anything but a toy, and no one would be defending the layout with the same cargo cult mentality that HN seems to inspire.
Why compare the margins of nonsense (lisp and php)? If a site like this were written in Node.js and with mobile users in mind, it would be in all means superior to what we see right now.
And right now I see yellow outline around this textarea, which is WebKit's default and they didn't even bother to remove it to make this textarea look the same in all browsers, let alone adapt it for mobiles.
I'm implying that language elitism and faux-intellectual posturing are among the reasons this community seems to correlate the simplicity of the layout with its own intellectual purity. That same elitism would cause the same community to dismiss the same site out of hand, were it written in a language it was popular to hate.
But yes, it could be written in any language and still have a more progressive layout, and people would hate that the site appears mainstream or, heavens forbid, looks and acts more like Reddit.
Is it just me, or it sounds... cult-ish / overly dramatic?
>> it wasn’t obvious to me that Hacker News had any JavaScript at all.
I guess he never votes.
>> I thought it would be weird and complicated, but it turned out to be quite the opposite. You’ll have to watch the video to see what I mean.
Well, it sends a HTTP request and hides an element. How on earth can it be complicated? I mean, ok, you can use The Framework Of The Week to do that and just that. Not everything that is related to HN/YC is some magical rocket science.
I'll give you one reason. I've never done any front-end stuff before. But maybe a month ago, I got curious. Perhaps because I read HN everyday.
And if you try to immerse yourself in the front-end world, you get 'yeah, learn HTML/CSS/JS, BUT, also learn Angular, React, JQuery, et. al...' It's good to get a reminder that Javascript in and of itself is a capable language. I'm sure I'm not the only one in this camp.
Maybe it didn't need to be 12 minutes, and it was certainly more of an 'oh, interesting' than anything, but I'm glad I took the time to watch it.
This is why I encourage all developers to take some time to teach new people. The "everyone knows this obviously" attitude goes away very quickly if you start doing this.
The aim of the video was to make it accessible to just about everybody. So if you know this stuff you can watch the first minute and stop the video and get value out of it. On the other hand, if you're a beginner and you just did Codecademy, you can watch it through and follow it too.
A few weeks ago I turned off javascript in my browser out of principle and to see if progressive enhancement was still a thing web developers cared about (hint: it's not). I was pleased that HN worked fine, and the only annoying thing was that voting caused a page reload. It's nice to see this get the attention it deserves!
Developers! You probably don't need javascript to achieve 90% of your goals. It will just slow your page load speeds.
This is true, however javascript is a tool that can be useful if you are building something that provides an interactive experience for the user.
In such a scenario, I have to write code somewhere to provide the experience. If I am writing it on the server side I run into several issues.
It uses server resources. For example, let's say the user is looking at a large dataset. They want to sort/search/filter that dataset. Given that they already have the data in their client, it often makes sense to use their resources to sort/search/filter the data. This lightens the load on the server.
User actions suffer from latency talking to the server. Again, if the user already has all the data that they want, not talking to the server can often result in a better user experience. Imagine something like an incremental search. Such a thing might even be impossible to implement server side due to latency issues.
Implementing client side functionality in the server can add to software complexity. Things like keeping track of user state can be handled much more cleanly on the client side.
Very often it makes tremendous sense not to make a "web page" for something that needs a lot of user interaction. Instead you want a stand alone application that gets data (without presentation) from a server. Writing your application in javascript, running it in a browser, using HTML as a presentation layer and using HTTP as your communication protocol is not a stupid way of implementing such an application (and I say this having written these kinds of applications with a variety of different technologies).
If you are writing a web page that is intended to simply present data, then Javascript may very well be unnecessary. For me, though, this does not come anywhere close to 90% of my goals.
I don't think client side scripting is always innapropriate. I just think it often is. For example, I've seen a lot of pages that just display some copy marketing a product that won't display properly without JavaScript. On the other hand, complex sites like github work fine without JavaScript.
I totally agree, if you are thinking about maintaining user state on the server, you are probably doing it wrong, as you are violating REST. That's the nice thing about using dumb clients, is it forces you to think about application state changes using hypermedia, instead complex client side logic. I think this leads to clean APIs.
But note what you assert yourself: reloading on every click is annoying. And not reloading, but also not providing feedback that you successfully clicked the button is also annoying.
The 10% of your goals that you do not achieve without Javascript are essential to changing 'the web' from being a clunky to being a nice experience. The web without the least bit of Javascript is like a world without fire: you'll survive, but it won't be nearly as comfortable. Fire inevitably led to nuclear bombs, but we should certainly not disavow fire because of that. We should just be against the nukes.
I agree. Sometimes your soup could use some salt in it, but you shouldn't just skip the soup and go directly to eating salt.
If someone decides they don't want any salt, they should still be able eat the plain old boring soup. They'll get the nutrition they need. Maybe it won't taste quite as nice, but the primary function of the soup is still there. Plus your soup is more accessible to people on low sodium diets, and takes less time to prepare!
The next major update in all browsers absolutely must be this: inability to turn off JS. Because no one in a sane state would EVER do this now.
Why not a checkbox to turn off HTML? It would be just as "useful"...
I do need JS to achieve all my goals that can be achieved with JS. For those things that can be achieved without JS but often mistakenly involve it (hamburger menus, animations etc), I use plain markup and CSS3. But I'm not going to ruin the UX on mobiles, where in developing countries traffic still matters, just for some paranoid freaks' sake.
I'm just curious about how the web works and how modern sites use JavaScript.
Maybe I'm talking out my ass, since UX isn't my field, but I imagine that 90% of UX is "the application allows me to do the thing I'm using it for, it has logically layed out screens, and navigating between screens is fast and intuitive." I think hypermedia accounts for these concerns. Sure there are some annoyances, like "voting on a comment or article causes the screen to flash." It's a little jarring but everything still functions. You can sprinkle some JavaScript in, like on HN, to smooth that over.
Your site will be much more usable in developing countries with low spec mobile devices and high latency, low bandwidth networks if you design it to function first without JavaScript. You will reduce page weight, and client side CPU usage.
Client-side CPU usage, as well as page weight, isn't a problem if JS is done right. Angular-like bloatware certainly ruins all the zen. But that doesn't mean you should rush to another margin and make everything server-side. Modern web technologies allow you to keep everything beautiful, smooth AND lightweight. But in order to achieve that, you'll need to learn more than a couple of bloatware libs like angular or jquery. In fact, you need to forget them and start thinking for real. And study, study and once more study MDN manuals.
Language doesn't make Web slow and bulky. People do.
Agreed! Learning the latest and greatest library isn't going to make you a better developer. I'm not saying client side scripting has no place on the web, I'm just saying for many purposes its place is overrated, and that basic functionality can be provided through hypermedia alone.
The HTTP request for voting should be a POST request, not a GET request, since it changes state. So both the JS hack involving an image and the non-JS fallback are broken. The JS function should use XHR, and I guess the non-JS fallback should be a form with an image button, not a link.
But it is idempotent in this case. The server keeps track of your votes, so regardless of the number of times you do the same GET, the result is the same.
Hopefully the HN voting links never contain relation types which would imply prefetching! I recall that Firefox did some aggressive prefetching in the past, and some websites (maybe Wolfram?) temporarily blocked IPs which did the prefetching due to the extra load they were putting on the servers. It's very dicey, requesting URLs for a user which would have a low probability of being followed. Certainly, requesting tens or hundreds of URLs from a single HN page would be a reportable bug for either the browser (for wasting resources) or the site (for misrepresenting hyperlink attributes).
Regardless of all of this, if the HN server filters out duplicate votes, then the idempotence (is that a word?) of the request is satisfied, and it is OK to be a GET. [EDIT: after reading https://news.ycombinator.com/item?id=11308231 my point here is probably invalid, because voting is not a "safe" method. Voting alters the order of posts that future readers see, which is a material change for a discussion site. In contrast, something like a YT view-count tally doesn't effect a material change in the core material.]
Regardless of that, IMHO a GET request that changes the "fundamental" state of the world (not just UI state e.g. pagination/settings) is somewhat "rude" to begin with, because of the common expectation that GET requests are "harmless" and POST requests can change things. But like, that's just my opinion, man.
Actually, another way to do this is to create a form with the POST method that respond with status 204(which will not refresh the page). There is still no need to involve the XHR. I still think this solution is neat though.
"However, this is not completely true. It means: it won't change the resource representation. It is still possible, that safe methods do change things on a server or resource, but this should not reflect in a different representation."
It is possible to do so but may not be desirable anyway. It is completely possible to wire a fork bomb to the safe methods; you probably don't want to enable the bomb via crawler however.
The funny thing is, it's actually those things (along with Typescript, Flux, etc) that allows us to write readable and maintainable JS that doesn't devolve into spaghetti after a year.
The funny thing is that it's always been possible to write a bit of plain javascript but you don't seem to get much respect for that compared with the buzzword stuff.
Using this approach, a badly written prefetch add-on might automatically vote on everything. Any request that modifies server-side state really should use POST or PUT (or, at the very least, append a CSRF token in JavaScript).
I eventually find this bug on just about every project. One time a user complained that all comments would disappear from her posts. Found that an add-on was prefetching all "delete" links, visible only to her.
Yes, this is an old problem. It came up with early versions of Rails scaffolding, which only used GET at the time. There's no excuse for deleting with GET.
Reminds me of an old story about an internal wiki at a company I once worked. They tried to add a search feature which initially crawled all pages. Once that was done, the complete wiki was empty...
If we ever make it around to a second piece of javascript on here, can I request that it be a collapse comment function? I promise i won't ask for anything else.
It also highlights new comments and collapses threads without new comments on repeat visits. HN now feels unusable without it in scenarios where I can't use a userscript :-/
Quality—don't want to make it too easy to ignore entire chunks of the conversation, and don't want to encourage adding chunks to the conversation that are worth ignoring.
If you want the state of your collapsed comments to be remembered between session you're adding a lot of data to the backend of HN. I can see not implementing it, because threads are short lived and rarely get more comments that can be reasonably browser or searched.
I don't see that collapsing comments would really add much value, especially if the state is to kept per user per comment in the backend.
If you don't care about state, I feel reasonably sure that you could Greasemonkey your way out of not having that feature.
Alternatively, I'd appreciate if comments had a link to their siblings and not just their parents. It wouldn't require any JavaScript, but would (for me) have the same utility.
I wrote this a while ago, which seems to work. I reused the vote arrow with 1/4-turn rotation, placed on the other side of the comment header line to avoid confusion.
Works cross-browser, submits a POST request to record votes, and hides both vote buttons after submitting.
Each up/down arrow is an <input type="image">, part of a form that submits to a hidden iframe. When either goes :active, a CSS sibling selector sets the height of a floating div from 0px to 100% to cover up the vote arrows. There's no selector for "button that's been clicked once before", so I use a CSS transition that has a delay of 0s to expand the height and a delay of 99999999s (basically forever) to shrink the height back down again when the arrow button goes from active->inactive. While the arrow button is :active I use "pointer-events: none" to make sure the click goes through, but once the form is submitted and the button goes inactive the div becomes opaque to click events again, so the UI only allows a vote to go through once.
That's what I thought too, at first. Some of the iterations I went through before reaching this point:
- Links for the up/down arrows with target=<hidden iframe>, that set "visibility: hidden" on :visited. But oh, only color-changing CSS properties are allowed for :visited selectors.
- Links for the up/down arrows with unicode ▲ and ▼ that set their color to the page background color on :visited, using a sibling selector to hide the other arrow as well once either has been clicked. But oh, sibling selectors are forbidden in conjunction with :visited selectors. Same for selecting nested elements inside a :visited link - only the simplest uses of :visited are allowed. One could wrap both arrows in the same <a> tag, but then there'd be no differentiating between an up/down vote.
- An invisible radio button next to each up/down arrow, with both wrapped inside a <label> so that clicking the arrow causes the radio button to become :checked. Use a sibling selector to hide the arrows when either radio button becomes checked. But oh, if you click a link inside a <label> it's not counted as marking the radio button as selected.
- An invisible radio button hidden under each vote up/down image. Each radio button is wrapped in an <a> tag that causes a hidden iframe to navigate to the voting link. The vote up/down buttons are "pointer-events: none", so trying to click on one really marks the radio button underneath as selected and triggers a link click. This works fine in Firefox, but in Chrome, marking a radio button as selected doesn't trigger a link click.
I thought of that, but then the arrows don't hide immediately after you click them as on HN - they'd still be visible until the request completes. So you'd end up with the same problem: hiding both arrows when either is clicked without using JS.
(I assume you mean putting each pair of arrows in an <iframe>, rather than each individual arrow.)
If it's a button, it'll be in the :focused state, you can use that to style it. Or you could use a CSS transition with a very very long time in one direction on the :active state.
And of course, you can use adjacency selectors with buttons, while you can't with :visited links.
If scripts are turned off, the link just navigates to /vote?etc, which redirects you back to the thread. So it works already! It doesn't bring you back to where you were- but an anchor tag can fix that.
If you don't want to leave the page, iframes still work, right? So you can set the target to an invisible iframe, and the vote will go through. The arrow doesn't disappear, but I think you might be able to handle that with CSS:
<input type="checkbox" />
<div style="background-image: url('http://voting-url.com')"></div>
div {
display: none;
}
input:checked + div {
display: block;
}
A background-image won't be requested unless it is visible. (This is why lots of peoples on-hover icons flicker if they don't spritemaps, SVGS or iconfonts).
Edit: Obviously you'd style it to make it pretty :p
Edit 2: For accessibility you'd probably want a visibly hidden - but visible to screen readers - anchor that votes.
Edit 3: Looks like chrome pre-fetches things even when they're not visible now. Presumably to fix all those flickery icons out there :(
- Hiding two elements on the page (one can be hidden with the CSS :visited selector)
- Remaining with your position on the page whilst also sending a message to the server and without opening new windows.
So the only way to do the task is to send a full request to the server which would return you to the page with the buttons correctly disabled. Extra load on the server of course, and a bit of an annoying user experience, but doable - hence why this is the disabled fallback.
You could render the vote buttons in iframes, so just the iframe would reload. But you'd have to load N iframes for N vote buttons on page load. Not worth the performance hit.
HN has to do that anyway. The hide() and vote() functions only run on click. If you refresh the page, you'll see the response lacks anchor tags for comments/posts you've voted on. Those tags are replaced with a spacer image.
That was a legitimate question. I think the problem where the down-voters not you.
To answer the question. Yes you could still vote, but you would need to refresh the page to show the current state. The JS is doing it on the fly.
Maybe people were trying to be helpful by disabling JavaScript and clicking on the down arrow next to your message in order to experimentally determine what the answer to your question was.
Now I see you are downvoted. I thought your comment was humourous which is always alright to me.
In My Humble Opinion downvotes are given out a little too easily here (OK, I'm ready for more downvotes). I hope when I get the downvote ability I will use it wisely, not that many aren't wise.
Downvotes aren't worth worrying about on Hacker News, nor are upvotes. They do tend to even out in time so that only the really objectionable comments get downvoted a lot (and eventually flagged) but because pg more or less decided that there didn't need to be a standard for either, I treat them as worthless.
I take it personally which I know I shouldn't. I think others are the same. You can tell when people say "Why was I downvoted?!".
Everyone wants peer approval. Also you get the same feeling you get when you are being denigrated by someone who doesn't have the backbone to come out and say who they are. I say you get the feeling, not that it is true.
It is kind of fascinating that my votes are going up and down rapidly. Apparently it is a battle of up-voters vs. down-voters. I must have hit a touchy subject.
P.S. I apologize for all the posts. I'll tone it down now.
That would make the whole downvote system useless. Just post spam comments everywhere then delete them after a day and you’ll always have a positive karma.
> That would make the whole downvote system useless
This would not remotely "make the whole downvote system useless". The primary use of the voting system here is to sort out discussion by subjective value. That would only be very indirectly affected (through the very distantly secondary use of karma to confer downvoting ability).
If anything, it would debatably enhance the primary use of the downvote system, by giving authors of unpopular comments an incentive to remove from the discussion what the community has judged to be noise.
Though I would personally hate that, as a fundamentalist anti-deletionist, and as a frequent dissenter from this community's judgements of value.
Ok, I"m facing an armageddon of downvotes but why the heck was this downvoted? He made a point, that while arguable, is a valid comment. Maybe the discussion of downvoting is bringing more downvotes.
Jeeez.
Edit: My upvote brought him back to zero, for now.
I see things more in terms of signal/noise considerations.
Rational minds can disagree, and intelligence can't understand much-greater-intelligence (so lessers might downvote much-greaters for that reason, besides the first-mentioned reason), but you don't have to worry about armageddons of downvotes. Or the balance of votes.
Just upvote what you consider "signal", and downvote the worst kinds of noise.
Thus you, my parent comment, are barely voted on at all, while the one by jewbacca rises to the top all day, no matter the weather.
Seems on-topic to me. You can't call Godwin's Law when the discussion is really about Hitler himself, and you can't claim that discussing how voting works is off-topic when the discussion is about how the voting button works.
Without JS, return false from the vote function wouldn't happen, so I guess clicking upvote would follow node.href, which would send the vote to the server. It would work anyway, there would just be a redirect that would trigger a page refresh. Pretty cool. Just tried it out and confirmed.
Seeing the "auth" query. There is a chance that HN was "too clever" about it, and it might be possible to use other users id to upvote, or upvote many times, if you can figure out the hash algorithm.
What I find interesting is that even this little piece could be done in plain HTML using an iframe for each vote button. The obvious disadvantage is http requests for each vote button, but even a middle ground could be chosen where the vote buttons submit to a hidden iframe and just don't disappear without Javascript. Perhaps even, but I'm not certain, they could be made to disappear using css' a:visited, loosing zero functionality and having no disadvantages.
> Want to take your AngularJS skills to the next level? If so, check out our flagship product, Angular Course. Through 115 HD videos, you'll learn Angular and the latest best practices as you build a fictional startup.
I don't think this is ironic at all. When I mentioned "framework of the week hype" in my initial comment (https://news.ycombinator.com/item?id=11308043), I was thinking specifically about how people are handling the transition from Angular 1 to 2. I am in no way advocating using plain JavaScript to build your app. I even mentioned in the video that I rarely work with plain JavaScript.
There's a lot of distraction around Angular 2 for both existing and new developers, when it's pretty clear to me that Angular 1.9.x will pretty much look like Angular 2. If you read the release notes, this is very clear. They said the the primary theme for the 1.5 release was improving the upgrade path to Angular 2.
What this means is that keeping up with the Angular 1 release cycle will gradually transition you to Angular 2. But everyone in the community seems to think this is boring and wants to blow up their apps and go to Angular 2 right away.
This is the kind of thinking that I wish we'd see less of. Rushing to 2 when it's still in beta makes no sense from a business perspective. It only makes sense from a "I like to tinker with the new thing and try new stuff because it's fun" perspective. Some people will say it's a performance issue (since Angular 2 is better in that respect), but for the vast majority of apps that want to upgrade to 2 now, the improvements won't be noticeable.
