The Single Piece of JavaScript on HN (opens in new tab)

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.

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};

v and item are merged.

http://closure-compiler.appspot.com/home#code%3D%252F%252F%2...

Original Size: 212 bytes gzipped (318 bytes uncompressed)

Compiled Size: 164 bytes gzipped (182 bytes uncompressed)

> 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.

Please no. I like being able to zoom in or out, and too often "responsive" means no zoom and either huge or miniscule text.

What is the problem here?

Downvoters do you care to explain why you disagree?

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.

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.

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.

http://restcookbook.com/HTTP%20Methods/idempotency/

I don't know about other browsers, but this works OK on Chrome.

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 :-/

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.

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.

  javascript:(function()%7Bfunction%20getScript(url,success)%7Bvar%20script=document.createElement('script');script.src=url;var%20head=document.getElementsByTagName('head')%5B0%5D,done=false;script.onload=script.onreadystatechange=function()%7Bif(!done&&(!this.readyState%7C%7Cthis.readyState=='loaded'%7C%7Cthis.readyState=='complete'))%7Bdone=true;success();script.onload=script.onreadystatechange=null;head.removeChild(script)%7D%7D;head.appendChild(script)%7DgetScript('//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js',function()%7Bif(typeof%20jQuery!=='undefined')%7Bif(!$('body').hasClass('collapsible-comments'))%7B$('body').addClass('collapsible-comments');var%20span_html='%3Cspan%20style=%5C'cursor:pointer;margin-right:10px;%5C'%20class=%5C'expand-handle%5C'%3E%5B-%5D%3C/span%3E';if(window.location.href.indexOf('item?id=')!=-1)%7B$('center%20%3E%20table%20%3E%20tbody%20%3E%20tr:eq(2)%20%3E%20td%20%3E%20table:eq(1)%20span.comhead').prepend(span_html)%7Delse%20if(window.location.href.indexOf('threads?id=')!=-1)%7B$('center%20%3E%20table%20%3E%20tbody%20%3E%20tr%20%3E%20td%20%3E%20table%20span.comhead').prepend(span_html)%7D$('.expand-handle').live('click',function()%7Bcurrent_level_width=parseInt($(this).closest('tr').find('td:eq(0)%20%3E%20img').attr('width'),10);$(this).closest('table').closest('tr').nextAll().each(function(index,el)%7Bvar%20elWidth=parseInt($('tbody%20%3E%20tr%20%3E%20td%20%3E%20img',this).attr('width'),10);if(elWidth%3Ecurrent_level_width)%7Bif(elWidth%3C=inner_level_width)%7Binner_level_width=1000;$(this).hide()%7Dif(inner_level_width==1000&&$('.comment',this).css('display')=='none')%7Binner_level_width=elWidth%7D%7Delse%7Breturn%20false%7D%7D);inner_level_width=1000;$(this).text('%5B+%5D').addClass('expand-handle-collapsed').removeClass('expand-handle');$(this).closest('div').nextAll().hide();$(this).closest('div').parent().prev().hide();$(this).closest('div').css(%7B'margin-left':'18px','margin-bottom':'5px'%7D)%7D);$('.expand-handle-collapsed').live('click',function()%7Bcurrent_level_width=parseInt($(this).closest('tr').find('td%20%3E%20img').attr('width'),10);$(this).closest('table').closest('tr').nextAll().each(function(index,el)%7Bvar%20elWidth=parseInt($('tbody%20%3E%20tr%20%3E%20td%20%3E%20img',this).attr('width'),10);if(elWidth%3Ecurrent_level_width)%7Bif(elWidth%3C=inner_level_width)%7Binner_level_width=1000;$(this).show()%7Dif(inner_level_width==1000&&$('.comment',this).css('display')=='none')%7Binner_level_width=elWidth%7D%7Delse%7Breturn%20false%7D%7D);inner_level_width=1000;$(this).text('%5B-%5D').addClass('expand-handle').removeClass('expand-handle-collapsed');$(this).closest('div').nextAll().show();$(this).closest('div').parent().prev().show();$(this).closest('div').css(%7B'margin-left':'0','margin-bottom':'-10px'%7D)%7D)%7D%7D%7D);var%20current_level_width=0;var%20inner_level_width=1000%7D)();

https://jsfiddle.net/5c0ruh8s/10/

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.

No JavaScript required!

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:

http://www.inserthtml.com/2012/04/css-click-states/

  <input type="checkbox" />
  <div style="background-image: url('http://voting-url.com')"></div>

  div {
    display: none;
  }

  input:checked + div {
    display: block;
  }

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 :(

input, input:checked ~ label { display: none; }

---

<input type="radio" id="up">

<input type="radio" id="down">

<label for="up" class="show">Up</label>

<label for="down" class="hide">Down</label>

- 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.

Or do you mean is there a way to asynchronously vote and hide the voting arrows without a page reload?

A lot of those are either without javascript or with minimal, vanilla js.

Anyway, if you download the source and look in the 'copyright' file it says:

"This software is copyright (c) Paul Graham and Robert Morris. Permission to use it is granted under the Perl Foundations's Artistic License 2.0"

http://www.arclanguage.org/arc3.1.tar

(I'd be more worried about the license of the Algolia Search provided on Hacker News. Way more JS there. It's even using AngularJS)

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.

http://angularjs.blogspot.com/2016/02/angular-150-ennoblemen...

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.