Hacker News Reader

Comment by notatoad | Hacker News Reader

I agree with the principle of this, but i disagree with including the javascript-is-disabled errors. If you browse the internet with one of the most important components of the internet disabled, you're going to find that a lot of stuff is broken, and displaying a warning that "hey, things are going to be broken here" is preferable to just displaying broken stuff.

View on HN

You might be surprised at what can be accomplished with HTML and CSS alone. Most of github.com works just fine without Javascript. Much of Twitter and Facebook work too. Facebook does give a warning, but they say you should enable Javascript "for a better experience" instead of "for any experience."

I agree that showing a "hey this is broken" warning is better than rendering a totally broken page, but it's still not as good as presenting at least a partially working version, perhaps minus all of the usual bells and whistles. Now, of course, this is not super-feasible if you've chosen to build most of your site using client-side code, especially if that's where most of the rendering happens. But then again, the lack of server-side rendering is the obvious downside of building your site that way.

Not everyone has the resources that Twitter and Facebook have to mantain what essentially are two version of their website.

My position is that if you disable Javascript you get what you get (both you and I will be happy to know that I don't do web development anymore).

If you use progressive enhancement, you don't really need two versions. You have the base version, and you layer javascript and css on top of it. Granted, it might be a bit more work than just rushing out a javascript-dependent version, but it's definitely not twice the work. And you then have a much better structured, more solid base to work on - in the long-run, I'd be surprised if it weren't less work to do things the progressive way.

I find that "progressive enhancement", while perhaps a bit more work, results in a more robust and maintainable webapp. The fact that results in pages that work without JS is almost a side-effect and barely needs to be tested.

The point for me is that links behave like links (perform GET requests against a URL and change the page from one state to another), buttons behave like buttons (perform POST requests and update some internal state), and the effect they have on the page is much the same with or without Javascript. The only difference is that with Javascript I can intercept the action and make the state change a lot more streamlined, or add a fancy animation if I so desire.

By simply intercepting buttons and links (similar to how pjax and turbolinks work) I don't have to dig through JS to find where a specific AJAX request is fired-off and what it does. It just works, and when it returns, it simply updates part or all of the page with whatever the server returned, which could be part or all of a page.

There are, of course, obvious limitations, like local state that changes with user interaction but that isn't preserved on the server in any way. But the more I can get working without Javascript, the more I know will be easily maintainable and translatable going forward even if I do something crazy like get rid of jQuery or convert everything to a React app.

Maybe I'm just a bit odd, but I find this approach a lot easier to manage and a lot more productive in the long run than in marrying myself to any particular client-side framework.

Yes, that's the ideal. Try and do it. Remember to test all the different progressively enhanced paths that only a tiny minority of your users is using.

Do you also take that attitude to your code? I.e. "it's alright, that code path only executes one time out of fifty, doesn't matter that it crashes the program".

That is not what I meant. I meant: “that code path only executes one time out of fifty (thousand), but you have to test it exactly like the core code that runs thousands of times more, so maybe you can drop the feauture since it's used by a handful of users”.

(I have my doubts one in fifty people disable Javascript)

Well now you're talking about an analogy that's 3 orders of magnitude away from what we're actually dealing with, so it doesn't really hold up. BTW, we're not really talking about 'testing' here, either - you don't actually need to test plain HTML beyond the most cursory of glances.

We are talking about people disabling JavaScript in their browser. One in several thousands is still a large over estimation.

[Citation needed]

What a thoughtful and insightful remark. If you don't believe that statement to be in the right ballpark you are out of touch with the world outside HN.

You could always just build one version that is capable of rendering either server-side or client-side. React.js and other similar frameworks (that do diff-based updates) work well with this, or at least better than frameworks where the state changes are discretely coded.

The react-rails gem is capable of doing server-side rendering out of the box: https://github.com/reactjs/react-rails

In my experience, when discussing development problems, there are two types of people: those that say “well, you could just […]” and those that tried to do it and learned from experience how many unexpected problems you are going to have, how much work it's going to be, how much more testing you need, etc.

Fair. I haven't tried rendering server-side with React. I'm sure it's as much a maintenance nightmare as much as any major feature.

But I do have apps I maintain that started as traditional Rails apps and have been progressively enhanced to a point where they perform a lot like more modern client-side apps. And an interesting property I've discovered to be true of such an app is that it's really quite easy to convert that traditional view-rendering pipeline to React, because there is almost no JS-soup being relied on for core pieces to function.

On the flip side, I also work on a couple apps where most of the functionality exists as JQuery DOM manipulation or as Bootstrapified data binding, and these are nearly impossible to port to a diff-based rendering library like React without rewriting most of the functionality.

So while I haven't exactly tried rendering React on the server, I've found that the more traditional server-side rendering flow still holds up quite well on the modern web. It's a good way of thinking about how your app should look/behave given a set of states, and it holds up well even in places where Javascript is required. The fact that it can be accomplished without Javascript is more of a side-effect, but also a good indication that it's not any particular bit of Javascript that is holding it all together.

For eight-ish years, 2002-2010, I made websites that worked with or without Javascript, precisely because I didn't want to make two websites. I would have had to, because a lot of blind people used to use readers that didn't always handle Javascript well, and the sites I made were required to be accessible.

Admittedly, they did not look as good as sites do today.

I think one problem is that it's actually a lot more expensive to build an interactive application-style site that works with well with javascript disabled. So sure, rich companies like Github, Twitter, and Facebook can (and I think should) invest in making things work relatively well. But a less rich company is faced with a choice between giving up that interactivity or committing to it. Most people have gotten used to the interaction patterns of javascript-heavy sites, so giving it up can put a company at a UX disadvantage, with no real pay-off, because it is very uncommon for people to turn off javascript. On the further end of the scale are applications like Google's inbox, which are largely designed around interactivity of the sort you need javascript to achieve, and are never going to work any other way (though it's very silly that it requires Chrome).

Whatever happened to "progressive enhancement"? It's possible to build a very rich experience around standard HTML+CSS and then enhance it with Javascript. This is how much of Github works. I'm not saying you should always take that approach, but if you're a small company with limited resources you can still choose which route you want to go down, and if you choose "progressive enhancement" then you have a site you know will (mostly) work without JS, without having to do any extra work on top of you usual development process. Rich companies can, of course, take both routes, but if you're going to build a javascript-heavy site you should at least understand the trade-offs and alternatives before you dive in head-first.

I feel like I specifically spoke to this in my comment that you responded to, but I guess I wasn't clear. My whole point was that doing progressive enhancement really well is much more expensive and has very little practical pay off (because within the margin of error, everybody has javascript turned on), so if you know you want lots of interactivity, it is reasonable to require javascript from the start. That is an understanding of the trade-offs.

The part I might be wrong about is "doing progressive enhancement really well is much more expensive" - that's just my opinion based on anecdotal experience.

What happened to progressive enhancement is that it's a fair bit of work, and putting in extra hours to support the three "power users" who have decided they want to run noscript isn't worth my time.

It is only a problem if you disregard all previous experience and knowledge and write your app directly in javascript rather than writing it in html+css and then using javascript to provide enhancements.

Taking my previous experience and knowledge into account, it is easier and cheaper to create richly interactive applications by requiring javascript than by using progressive enhancement. Your experience and knowledge is certainly allowed to be different than mine.

I just tried disabling JavaScript and visiting Facebook and Twitter... both were entirely unusable. Nothing on Facebook worked, and on Twitter, all of the links and interactions were broken.

I guess it depends on what you mean by 'works' -- I was able to view my facebook profile, click on links, visit other profiles, and even view a few entries on my news feed. Same with Twitter -- profile, news feed, a few other pages. Posting is broken, certainly, but to do that on Facebook I could click on "switch to our mobile site".

I understand the necessity of Javascript if you have a web app, but a lot of sites fail to display a page of text or a list of links if Javascript is disabled [1]. In my view, this is poor practice. What seems to be happening is that more and more people are using Javascript frameworks to build web sites (not web apps). This probably makes things easier for the developer. I'm not convinced it always makes for a better experience for users.

[1] Some examples of sites that won't display anything if Javascript is disabled (even though they're most displaying text): http://googlecommerce.blogspot.co.uk/ http://googleandyourbusiness.blogspot.co.uk/

Could not agree more! We have an mainly internal-only app that I work on that started out as PHP+HTML+CSS only and then over the years JS has been bolted on in various places. At first it was just to make life easier (Autocomplete, minor AJAX) but now we have entire components that will not function without JS and could not function without JS. Recently some devs have pushed for supporting browsers without JS enabled and I have been vehemently against it for a couple reasons:

1) MAJOR parts of our app will not and can not work without JS. Period, exclamation point.

2) Because of point 1 it doesn't make sense to waste dev time on making some views work with/without JS (We are a younger company and don't have time to waste on something like this especially when it isn't public-facing, not to mention QA can't handle testing everything twice).

3) Even if V1 of a component does support both JS and no JS there is no guarantee that future updates will be able to keep feature-parity or have time to code for that.

For me JS is part of the web, not an optional add-on. It would be like saying "make a webpage that works with HTML" (IMHO).

I also feel that it's not fair to complain about the GOOGLE CHROME app store requiring GASP GOOGLE CHROME (Same for GOOGLE cloud print). Not shit sherlock. As for Apple not allowing their video feeds on anything but Safari+OS X I think this is BS, there is no good reason I can think of to alienate so many people on other OS's especially since I would think THOSE are the people you might want to reach with your keynotes to convince them why they should switch.

So while I like the idea of this Tumblr I can't help but think the JS/Google Chrome examples don't really fit and distract from the overall message. To be honest looking through the Tumblr again the ONLY valid concern is the one with Apple's keynote streaming, the other ones make complete sense. How is it Google's fault that they are pushing the envelope in terms of what is possible, even Google doesn't have the time/resources to make every one of their ideas (which may or may not make it long term) work across the board and that is their prerogative.

"I also feel that it's not fair to complain about the GOOGLE CHROME app store requiring GASP GOOGLE CHROME"

I read that as complaining about a WEB APP store requiring google chrome. Web apps tied to a specific browser are destructive to the overall ecosystem; you might as well just distribute native apps.

Ok, if Gmail was an app in the Google Chrome store only then that might be a problem but this is "Offline" Gmail which I'm sure is using Chrome-specific API's to do it's magic. Google used to have thing called Google Gears (or something like that) that was a framework that would allow for things like Offline Gmail in FF but if I had to guess they either didn't have great adoption or where too limited in what they could so they dropped it and rolled it's features into Chrome.

What I'm not a fan of is "Lowest-denominator web is the best web" arguement. It's not and I'm sorry but unlimited backwords-compatibility is a pipedream, at some point you have to move forward.

There are non-Chrome-specific "offline" APIs. Some already found in the wild, and some still exist as specs. Google is free to roll their own and keep it to themselves, but I think it's perfectly okay to shame them when they do. It's the same reason I was against ActiveX components in IE. Theres nothing fundamentally wrong with a company pushing things that align with their interests, but there's also nothing wrong with complaining about it like this Tumblr blog does.

Can you provide any details about the internal app? What features does it have that need javascript? Also, since it's internal only, does it even need any extra compatibility, since all the configurations are known? The "web" and the "intranet" are quite different situations.

So while it is heavily used inside our company (where everyone is on the latest chrome) it is also used by LEA's which we do not control. This means we have to support Chrome/FF/Safari/IE 9+ but we have yet to come across a group that disabled JS.

As for what requires JS: we use google maps and people need to be able to draw zones on the maps which is not possible without JS (unless we have them a bunch of text inputs that they could enter the lat/lon of all the vertices. That is just one example and I can't go into much more detail. Bottom line is we would not have the customers we do if we didn't use to make it faster/easier and we don't have to resources to support JS+Noscript/no JS.

Javascript is not an important component if the internet. You can argue it is an important component of the web, but even that is pretty sketchy. I do browse without javascript. And 90%+ of the sites I have to turn it on for are just text. Javascript being required for webapps makes sense. Javascript being required for every blog on the planet does not.

While I agree that a user with JavaScript disabled should not expect all fancy features to work, the site should still be able to present its main content in a non-broken visual environment. A minimal version built only with HTML and CSS, which is then expanded upon with JavaScript.

This does appear to be the case with the first warning published on the blog, where the site is put into a "read-only mode" and I disagree with it being listed there, but I come across many other sites which do not display any form of content at all when JavaScript is disabled.

It used to be the case (I haven't checked lately) that certain documentation pages on Apple's site were javascript-only - they were actually blank unless you had javascript on. These were literally just standard text-heavy pages with no discernible client-side behaviour that I ever saw. Whatever side of the argument anyone reading this is on, surely you have to agree that such behaviour is strange in the very least.

What about if you are using a screen reader?

That's a valid concern, but unrelated to JavaScript being required. Making a JavaScript web application screen reader accessible is no problem.

Reply on news.ycombinator.com