The Single Piece of JavaScript on HN(blog.watchandcode.com) |
The Single Piece of JavaScript on HN(blog.watchandcode.com) |
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;
}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.
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?
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.
auth=311110b7ef0f268cafa8616afcbfcec8d977111efunction 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)
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.
>> 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.
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.
Developers! You probably don't need javascript to achieve 90% of your goals. It will just slow your page load speeds.
God I hate what has happened to the web these days.
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.
What I'm curious is if someone can reiimplement this without and javascript.
A lot of those are either without javascript or with minimal, vanilla js.
https://www.gnu.org/philosophy/javascript-trap.html#Appendix...
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)
> 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.
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.
Everyone should learn the basics before frameworks.
( Also: http://vanilla-js.com/ )
In my honest opinion, the only possibility browser vendors should disable these days is the possibility to turn JS off.
> 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?
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.
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.
Collapsible comments are still, I think, the minimum needed to make HN usable, in long threads it just becomes impossible to find or follow comments.
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.
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 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.
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.
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!
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.
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 :-/
As I understand it.
https://chrome.google.com/webstore/detail/hacker-news-enhanc...
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:
<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.
2. Could you set a background image on a visited to a 1x1 gif of the tracking url? Not sure if CSS lets you do that.
I know there are some limitations around :visited specifically to stop privacy snooping, but out so I can't look up the specifics right now.
Or do you mean is there a way to asynchronously vote and hide the voting arrows without a page reload?
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.
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.
No you don't. Use a FORM with a target of the iframe, make each arrow an <input type=image name="id#">
One form can cover all the arrows at once. Or you can have a form per set of arrows. Either way you only need one iframe.
Making it hide is a bit more complicated:
One way is have it hide on focus using visiblity, then set a very long transition in the CSS rules to unhide.
Not with the iframe srcdoc= attribute! That allows you to make an iframe that initially loads HTML you've specified inline.
Language doesn't make Web slow and bulky. People do.
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.
> (...) we may expand link prefetching support to include prefetching <a> tags, which include a relation type of next or prefetch in the future.
Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...
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.
Link: https://www.microsoft.com/en-US/store/Apps/Hacky-News/9NBLGG...
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
Windows Phone users are a significant portion of HN users?
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.
> 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.
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.
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.
Make Javascript Great Again! (TM)
- 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.
(now to hide from the abuse, and hope my karma doesn't fall below the voting threshhold for suggesting this)
(I assume you mean putting each pair of arrows in an <iframe>, rather than each individual arrow.)
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.
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.
P.S. I apologize for all the posts. I'll tone it down now.
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.
Jeeez.
Edit: My upvote brought him back to zero, for now.
And of course, you can use adjacency selectors with buttons, while you can't with :visited links.
Check my first comment.
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.
For a subset of us, framework authors, open source contributors, etc. It's very useful to keep up to date on the latest trends.
For example, the Angular team has borrowed techniques from React. It helps for them to keep up with things.
For people like me though, let's be honest. I don't need to do the latest thing.
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.
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.)
i take your point none the less- there are contexts where it doesn't matter.
crud is often a feature of frameworks. crud should be an external tool like documention tools (doxygen...).
Not exactly any of these technologies, but it is using more javascript at least. I think the example is pretty awesome actually.
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.)
Is this the hipster corollary to coding? Sure, Java was cool when only 100 people were using it...