For those of you who didn't get it (I had to google what w3m was), his point is that the site context is all rendered by JS, without any fallback static text content. Besides the obvious accessibility issues, it's also not good for SEO.
If you make a website solely to advertise yourself, and not also to make cool stuff you made or found or said accessible to the people who might be looking for it, you may not be doing it wrong, but you are still missing out a bit :)
Not that I have any beef with javascript only stuff or this site, the web is big enough for everything - please don't read my comment as complaining in any shape or form, really. I just want to say that successfully targeting an audience is nice, but people finding stuff at your site(s) you couldn't possibly have imagined they'd be looking for is also nice, and if you go the javascript only route, you might never find out. Just as a general point that doesn't really have anything to do with the site at hand.
Google, the only SE that matters, handles Javascript only websites just fine (actually uses a full browser as the google crawler bot). I'd make a bet that Bing does too.
And most accessibility software works with Javascript sites too, as they use the full DOM and can even handle events. It needs a little care to show changes to content and such, but they definitely don't need static fallback to read a site.
So what ? let's just appreciate a fellow hacker without pointing out the fact that this is JS only, shall we ? I am sure his intention of creating this website is not to "get found on search engines or have awesome SEO or work for people who have disabled JS".
The point is the irony. The website is designed to give the impressing that this mock CLI is used for everything, but it can't be seen using w3m/lynx/links from a real CLI.
Someone else already pointed out the irony of glamorizing hacker identity and "living close to the metal," but the contents of that tribute being un-indexable or inaccessible from a CLI.
For me, it's more about accessibility for users with screen readers or Braille, or non-English-speaking users who want to translate it.
Don't fall into the common trap: you can like/appreciate something and still be critical of (all or parts of) it. I think the site is absolutely gorgeous and creative, but still a little irked that its presentation matters more than making it available to anyone but sighted English-speakers/readers with JavaScript enabled.
So you've intentionally disabled a large part of your browser through NoScript and now it won't render pages that require the browser to work as intended? Isn't this rather like removing all gears but first from your car and then expecting everyone to accommodate the fact that you can only achieve 10mph?
I'm not meaning to have a go at you here, npsimons -- what you choose to do with your browser is your business, and you've not actually complained about the site -- rather I'm seeking to curb the idea that seems to crop up on HN from time to time that browsing without scripts enabled should provide a roughly equivalent experience to browsing with scripts enabled. It's not reasonable to expect developers to cater to a tiny fraction [0] of their audience when that audience wants the developer to essentially give up all client-side interaction other than POSTs.
I've yet to meet another noscript user who demands every site should provide roughly the same experience with or without scripts. Minimally we just want a webmaster to include a goddamn <noscript> telling us why we should temporarily whitelist her domain. And when something is pure text but requires JS to see any of it (as some blogspot templates tend to behave), we'll make complaints about progressive enhancement for that particular use case.
My biggest complaint is that there is no context whatsoever, either in the link, or the target page. Graceful degradation or a quick overview would have helped greatly.
I'm fine with enabling JS for some things - online shopping, web apps, etc. I'm not fine with enabling JS for things that don't require it - blog posts, photo galleries, etc. This page, I closed immediately, again, because I couldn't tell what it did. I'm not about to start randomly enabling JS just to see what will happen.
As for curbing, I'm going to have to strongly disagree with you there. I think more people should be browsing with scripts and flash off by default; how many unpaid tech support calls could have been prevented by a default install of NoScript and FlashBlock? I'd like to curb the idea that people will just run random code off the web. Give us a reason, a justification, and if JS is disabled, tell the user why you need it.
I'm going to agree with you there. The browser environment you set up for your non-technical friends and acquaintances should include a script and flash blocker that supports both whitelisting and blacklisting.
You simply shouldn't allow a script to run on your device without some amount of trust in the site that gave it to you or a thorough code inspection by multiple experts. Even then, it still might have a hidden exploit.
Because of this, there ought to at least be a landing page for script-blockers with a bit of explanation as to why they can't make use of the site without allowing scripts.
I am firmly of the opinion that scripts should strictly be an optional addition solely for the purpose of improving the user experience of visitors. HTTP 1.1 is good enough that about the only thing you do actually need scripts for is persistent and/or two-way communication channels. Almost everything else can be accomplished on the server side with a stripped-down user interface (as one might use with screen readers, text browsers, or even SMS or WAP on feature phones).
Graceful degradation is important not only for users who don't run JavaScript, but users of screenreaders as well. There's no reason not to have a plain text fallback of your site's content.
This is a myth. Screen readers have no problem with ordinary sites built with JavaScript. WebAIM did a survey of screen reader users, and 98.6% have JavaScript enabled when they browse the web.
People that use screen readers use ordinary browsers, like IE, Firefox and Chrome. They don't use special browsers, screen readers read the whole screen.
It is incredibly difficult for me to navigate sites that use JS to render content.
And as a developer, it's outrageous to me that people who consider themselves web developers to think it's OK to render static content (news articles, blog postings, etc) using client-side JS.
Angular, Ember, etc are all amazing tools for building applications. They are not amazing tools for web pages.
Now, I don't know if you specifically also use a screen reader, but if you do, I'd love to know what you use.
But for those of you that don't, I'd appreciate you not trivializing the issue. Accessibility of a site and how it works with screenreaders is up to the individual developer.
Did you know that Flash was accessible to screen readers? Too bad developers never paid attention to how to do that.
Remember, the screen reader reads the entire screen. If you don't provide some thought to the user experience, people using screen readers can still use your site full of menus and sidebars and advertisements and article pagination, but they will probably be very frustrated by it, trying to find the content that they actually want to hear.
Imagine the person who essentially has to look at the world through a drinking straw, and try not to be a dick to him by adding clutter. Copying your content into pages with simple navigation--without frames or scripts, possibly with tree-hierarchy outlines and prev-next links--is not required, but is definitely a nice gesture.
The point for me is, if the site uses so much javascript you can't even just see the text without javascript enabled, it's probably a bullshit experience. Or a neat WebGL demo. This is the former.
Case in point - on that page ^W, ^PgUp and ^PgDn do not actually close the tab or move to the previous/next tab. And not only that, ^W doesn't even erase one word backwards. Why would you go to all the trouble of capturing all keyboard events if you're not even going to support basic commandline editing. This is not a neat use of javascript, this is an annoying use of javascript.
>The point for me is, if the site uses so much javascript you can't even just see the text without javascript enabled, it's probably a bullshit experience. Or a neat WebGL demo. This is the former.
I totally agree with that, but I think it's a tangential point to the one I was making. I certainly think that developers should only use javascript where it's actually more convenient to do so than to use CSS, HTML and server-side code.
I personally find it extremely irritating navigating to sites which use javascript for something which naturally lends itself to another technique (like sites which request all text using javascript, as 'bphogan' pointed out above). When I visit sites such as these, it makes me feel like creating a parody site which draws the entire DOM in javascript just to illustrate the point that javascript is but one of the tools in the developer's toolbox.
The reason I get somewhat annoyed at noscript proselytizers (which I fully admit doesn't apply to any of the commenters in this thread), is that I've seen what happens when developers are forced to attempt to produce a stateful, interactive experience for the user without using (too much) javascript, and that thing is ASP.NET WebForms. As the line shrinks between desktop apps and web apps, we'll have to find ways to make overcome the web's shortfalls in interactive application development, namely state management and responsiveness. If the use of noscript increases, then this becomes harder to do, and makes it a lot less possible to make interactive web applications look like anything more than a poor mockery of interactive desktop applications. I truly want to see a time within the next few years where I can barely tell the difference between a desktop app and a web app, and unfortunately for noscript users, such an experience will probably require javascript.
I truly want to see a time within the next few years where I can barely tell the difference between a desktop app and a web app, and unfortunately for noscript users, such an experience will probably require javascript.
That's fine; believe it or not, most NoScript users are enabling a good chunk of JS (usually for your exact example of web app). What's annoying is when one opens up a link that gives the user no clues whatsoever as to it's purpose, and all that happens is a blank page pops up. No indication, like on some sites, that hey, this site is interactive and requires JS. Just a blank page. It makes one wonder why the URL was even shared.
Is there a noscript type extension that allows you to see the start of the script contents? Or the parts that would be triggered first?
Seems like a sensible option might be to have some sort of button (address bar / extension button) that opens up a pane with the javascript as read-only so its easier to do a quick visual check for "funny business".
I stuck with lynx for the longest time. Somewhere around 2007 the web became COMPLETELY unusable, even on the subset of sites I would visit. Sad times we're living in. :)
I just checked put my sites using elinks and fortunately they came out pretty well.
One is based on bootstrap and one on skeleton. I just made some links that are icons (github, twitter, etc) visible in elinks by adding img tags with src="" alt="some text" style="display:none". Seems like an OK hack.
Wow! Thanks for that, his TinyCC might be the solution to creating something I want badly, a full C language version of Cokos ReaJS VST plugin creator. Any aspiring programmer want to take on a cool project? :-)
I worked with Clark on Google Chrome, where he was a contractor while in school. He wrote our documentation server for Chrome extensions, which was a fairly gigantic project involving compiling IDL-like files and extracting documentation from the types and comments therein.
Anything sufficiently interesting (in this case, truly novel) should be able to make it through from a new user, and "nice!" is about all there is really to say about the site.
Agreed, sometimes a post can just be good enough that all it takes is a few words to show your respect. Any commentary to the nuances of the project feels like arguing about whether or not Monet did a good job picking a paint store. This is definitely that kind of post.
What a unique way to get separate yourself from the typical personal "portfolio" website. This reminds me of Robby Leonardi's interactive resume http://www.rleonardi.com/interactive-resume/
Unfortunately, your site shows me no content except for a black page. You appear to be loading the site entirely from javascript, so it won't work on computers that don't have javascript (like mine).
Same here but on Government system(pre-configured, castrated version of IE8) where Javascript is disabled entirely. Strange though because http://www.rleonardi.com/interactive-resume/
which uses quite a bit JS/JQuery displays mostly fine with a few quirks.
I like this, but just to play devil's advocate: What if I don't know how to use the site? Or worse, if I'm immediately turned off by anything that looks complicated.
Perhaps it could default to a regular site, and this could be an option "Are you a hacker? Yes/no"
That said, I support your decision to keep this as the default in the spirit of hacking.
I just browsed around like a regular site, clicked a couple of the links. I didn't realise you could type stuff in as well. So I would say the "browse like a regular site" is already built in. Plus its probably aimed at other software developers, as it covers the work he has done so his target audience ought to understand it.
Damn. I had a "linux shell" website made with javascript in the nineties, but back then I never managed to get command typing work with all the major players, i.e. both IE 4.0 and Netscape. I finally settled for the browser typing the commands for you by hovering on entries from ls, and "running" them by capturing the onclick event.
I'm really happy to see my vision in action invented and implemented by someone else, even though had to wait a bit over 15 years for it!
Not only does this look great, but the code is really clean too - both the javascript and the generated HTML. Nice touch that things are clickable. Seriously awesome work.
