Hacker News Reader

Comment by tspike | Hacker News Reader

First of all, thanks for the nice writeup. I hate that comments tend to hone in on nitpicking, but so it goes. My apologies in advance.

> If you're just starting out with a new web application, it should probably be an SPA.

Your reasoning for this seems to be performance (reloading assets), but IMHO the only good reason for using a single-page app is when your application requires a high level of interactivity.

In nearly every case where an existing app I know and love transitions to a single-page app (seemingly just for the sake of transitioning to a single-page app), performance and usability have suffered. For example, I cannot comprehend why Reddit chose a single-page app for their new mobile site.

It's a lot harder to get a single-page app right than a traditional app which uses all the usability advantages baked in to the standard web.

View on HN

I fully agree with this. SPAs are for webapps, not websites.

For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for.

Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website.

> Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website.

Sure there is, if you care about interactivity, responsiveness, and general user experience. The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. You might as well say that not all potential clients have access to the Internet.

> Sure there is, if you care about interactivity, responsiveness, and general user experience.

And all of these can be provided just fine using progressive enhancement. This is _not_ an argument for SPAs.

> The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small.

Your use of the term 'probably' suggests to me that you have not run any actual metrics. Here's a short list of some examples:

- Bots and spiders

- Low-powered mobile devices

- Privacy-conscious users who use NoScript

- Terminal-based browser users

- Literally every single one of your users until the .js blob has completed downloading

- ...

Requiring JS for a website is not okay, end of story. We all collectively understood this 10 years ago, and I'm not really sure where along the way this understanding has gotten lost.

EDIT: Forgot that HN has a neutered version of Markdown. Fixed.

> Your use of the term 'probably' suggests to me that you have not run any actual metrics.

What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers.

> Requiring JS for a website is not okay, end of story.

It's really not the end of story, and it's not your call except for your own web apps. JavaScript is an integral part of the platform that is the web, just like HTML and CSS. You might as well make the argument that "requiring a web browser for your app is not okay, end of story."

> We all collectively understood this 10 years ago

Things were a lot different 10 years ago, and perhaps your reluctance to update your understanding less than once per decade might explain some of your views. You may as well be saying "making a store than can only be accessed over the Internet is not okay, end of story, we all collectively understood this 25 years ago."

> JavaScript is an integral part of the platform that is the web, just like HTML and CSS

I always think it's interesting when people bring CSS into this, because it's actually a very strong counter to the general argument.

By design a user agent is well within its rights to completely ignore any stylesheets attached to a page, and the idea was always that this should be completely OK, partly because you have no idea what the UA's capabilities are, up to and including whether or not it's doing any kind of visual rendering at all.

This isn't a news flash to everyone, but even those already aware of this seem to think the main reason you'd do this is ADA accommodations and those are some kind of minority afterthought. My experience is that this is misguided -- accommodations for unusual visitors is important, but I think the biggest benefit might be that the simpler you make things for the client, the less complicated the engineering tends be, even if you can't import your Java-imitation-of-smalltalk-inspired application paradigm of choice.

And "too bad if you didn't have JS!" position seems to basically boil down to the idea that serving a custom client that consumes JSON instead of HTML as the media type for a given URI is Real Progress™.

Keep things as simple as possible. Don't require JS unless what the application needs to do can't be done without it.

You are correct all the way.

The problem is that arguments from both sides are often generalized and it's not necessarily wrong. If you have a wide audience e-commerce enterprise you should probably keep JS use as limited as possible. If you build tools for programmers or highly dynamic projects, JS everywhere is probably fine.

If you build tools for programmers, give me some way of interacting with it other than running your JS in my browser. Otherwise, I'm likely to find it horribly awkward to integrate with my preferred workflows, and I'm unlikely to use your project.

> By design a user agent is well within its rights to completely ignore any stylesheets attached to a page, and the idea was always that this should be completely OK, partly because you have no idea what the UA's capabilities are, up to and including whether or not it's doing any kind of visual rendering at all.

I think that is just an outdated idea that does not apply to highly interactive, long-lived web applications. The user agent is well within its rights to ignore anything it wants, of course, but the user agent is not owed anything by the server. With CSS, or JavaScript, the app may just not work.

> With CSS, or JavaScript, the app may just not work.

When it comes to CSS, generally most apps will continue to work even if the CSS is simply ignored.

Because that was one big point of CSS. Separation of presentation from content and function.

It's funny. That kind of separation of concerns is something developers talk about valuing, but the SPA/webapp craze erodes the user-facing aspect of it, even while developers are very proud to demonstrate they're thinking hard about which specific kind of separated-concern architecture they're working with well away from the boundary where an outside user or UA would care.

Yes, highly interactive applications are an exception. But most things people build on the web (except for games) aren't highly interactive.

A forum, for example, isn't highly interactive, whereas an online spreadsheet editor is.

The comparison between JavaScript and a browser is very weak as a web app absolutely requires a browser, but JavaScript is most certainly not required. But, that aside, requiring JavaScript with absolutely no workarounds is a very bad idea.

Consider people who are sight impaired. Screen readers and heavy JavaScript really are not friends, but there is legislation in many countries that makes this basic kind of accessibility a legal necessity.

First, this is rude. Second, your comparison between JavaScript and click-only commerce is even weaker than your previous comparison between a web browser and JavaScript.

But, those points aside, the web was a lot different ten years ago. Ten years ago, I could browse the web with JavaScript turned off and I rarely came across sites that didn't work for me. When I came across sites that didn't work, they always politely had a <noscript> that told me that the site needs .js. Today, my experience is the exact opposite and basic accessibility has faded.

Change is not necessarily positive - no website should require JavaScript. And, I'd argue that most applications should work without JavaScript.

Screen readers a JavaScript get along just fine if a site is coded well. A SPA can be perfectly accessible. The Section 508 refresh is well underway and will essentially be WCAG 2.0 AA [1]

[1]: http://www.w3.org/WAI/WCAG20/quickref/

> What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers.

I was refering specifically to websites, not webapps.

> It's really not the end of story, and it's not your call except for your own web apps. JavaScript is an integral part of the platform that is the web, just like HTML and CSS. You might as well make the argument that "requiring a web browser for your app is not okay, end of story."

That analogy makes absolutely no sense, nor does your comparison to CSS. JS is an entirely different class of dependency than either CSS or web browsers.

JS is turing-complete, has a significantly bigger attack surface (both in terms of vulnerabilities and in terms of tracking), is much, much harder to optimize for a low-powered device than HTML and CSS, and so on.

Further, the web browser is a necessity to view something on the web. It is well understood, it is easy to optimize, and it is widely deployed. JS is no such 'required dependency' - and you should not make it one, when it can be done just fine without.

> Things were a lot different 10 years ago, and perhaps your reluctance to update your understanding less than once per decade might explain some of your views. You may as well be saying "making a store than can only be accessed over the Internet is not okay, end of story, we all collectively understood this 25 years ago."

The support/compatibility landscape for JS has not changed in those 10 years. The types of non-JS clients are still the same, the reasons for progressive enhancement are still the same. The only thing that has changed is standardization.

"Old" is not the same as "obsoleted". Unless you can come up with a concrete reason as to why this knowledge has been obsoleted throughout the past 10 years, it still applies.

And I'm getting a little tired of these poorly fitting analogies, you're using them as a crutch.

> I was refering specifically to websites, not webapps.

Okay, then yes, we were using terms differently. I consider web apps to be a subset of web sites (which is the standard usage as far as I knew), and thus I thought you were claiming that JavaScript should not be a requirement for any web site, including web apps. But you're using "web site" to mean web sites which aren't web apps, and in that case, I do agree.

I disagree with several claims you make later in that comment, but since I think I've addressed our primary disagreement I will leave it at that.

Thank you for making these points, I'm just disappointed at how often they need repeating for some people, do you know of a website that explains the reasoning behind not relying 100% on JavaScript for your website?

There's motherfuckingwebsite.com but the tone of that site is very adversarial, I think one that lays out the reasoning in a noncombative way would be more successful at reaching some of these people.

Hmm. None in particular, though you could just look around for some of the older resources on progressive enhancement - that's what it's called, and it used to be a recommended practice everywhere.

There's also this post, that goes into it somewhat: http://allinthehead.com/retro/367/why-is-progressive-enhance... - also, Brad Frost has some posts about this.

> huge class of web apps

You have a failure of understanding here.

There is a difference between a web site and a web app (although there is blur in the middle obviously). A web site (e.g. this site, a news paper, a blog, a search page, a job application form etc) should not need JS - and frankly if you put it in there then you're over-engineering things. Meanwhile web apps like e.g. Google docs/Office 365, a webmail client etc are clearly going to need specific JS.

Come on, really? Some of those are legit (although manageable if you do things right), but how many web Apps truly need to worry about accommodating terminal based browser users?

Unless Stallman is in your target market that's probably something you don't need to consider for any longer than fifteen seconds.

There is a simple argument for making sure that a web site looks good in a terminal based browser (note: web site, not web app).

This is how Google sees your web site.

Sure, there are lots of meta data enhancements and Google is probably much smarter than it was 10 years in extracting data from your js gobbled up web page (as we know, they even try to interpret javascript to some extent).

But it still boils down to this: The easier you make it for Google to get at the text of your web site, the better for your page rank.

You'd be surprised how commonly used terminal browsers are.

You should check your stats some time and see how many of your users fail to load your JS, rather than are capable of loading your JS. You might be surprised, especially if you have lots of mobile traffic.

Just out of curiosity, what's the standard way to gather that data? I guess you could put a non-JS request (like an image) and a JS request (like XMLHttpRequest) on each page, and compare numbers.

A `<noscript>` tag seems most intuitive to me, perhaps paired with some server-side Google Analytics.

Also, most of the corporate people still have forced IE installed on their work laptops. SPAs do generally break in IE.

"if you care about interactivity, responsiveness, and general user experience"

A simple web page (no-js) in a browser covers these three things to a highly acceptable standard. It's when you start to add the other junk that these three become compromised.

For example:

Interactivity: Hyperlinks work great from HTML 1.0 onwards

Responsiveness: Without additional items like JavaScript or even CSS, web pages are incredibly responsive.

General User Experience: The basic web page user experience is EXCELLENT for web pages because it is incredibly basic. Even date pickers can consist of 3 select drop downs (or even a text box; there are plenty of human-date-to-ISO-3306 convertors out there)

What is ISO-3306?

LOL thats the mysql port! I'm an idiot

He probably meant ISO 8601

I think he means that it's best to offer both variants with a graceful fallback for no-js users. This doesn't require sacrificing interactivity, responsiveness or UX for users with JS enabled.

"Graceful fallback" is what came before progressive enhancement, and is considered obsoleted for good reason.

Graceful fallbacks tend to be maintained as a separate version, and neglected over time. Progressive enhancement means taking a basic page and adding snazzy functionality to it - eg. ajaxified page loads. The latter is what you want.

It does, however, require a potentially large amount of work for a SPA. Granted, server-side rendering for JavaScript libraries like Ember and React is doable now.

First page load can be totally server side generated. Once loaded on client side, you can check using modernizer or something if your user's browser supports the features that you need for SPA if yes then you can replace server side generated HTML structure with a client side version. Now, you can proceed with all of your server and client communication via your favorite SPA framework.

Maybe not all my clients support javascript, but substantially all I care about do.

I even take advantage of this on my blog by rigging a field in the comments section to not be visible for users but be visible for spammer bots, so that they will fill it out and the software can auto-reject it.

Works very well.

> Maybe not all my clients support javascript, but substantially all I care about do.

See here: http://bradfrost.com/blog/post/fuck-you/

> I even take advantage of this on my blog by rigging a field in the comments section to not be visible for users but be visible for spammer bots, so that they will fill it out and the software can auto-reject it.

That is a reverse CAPTCHA, it works very well, and has absolutely nothing to do with Javascript. They are typically implemented using CSS.

Actually I think you are right that this particular one uses CSS - but I may have to upgrade to JS if the spammers get past it.

I enable JS for sites I feel are valueable for me. The first impression is always without JS. If navigation-buttons dont work without JS - I just leave.

if you self-select into the group that isn't cared about, then do you expect your leaving to be cared about?

i ask only because i'm puzzled as to the purpose of your reply.

I am too small a group to be cared about. But in my opinion only poor designed websites use JS for layout or navigation. And the way back to the search-engine is always just one mouse gesture away. JS = code written by someone with not neccessarily my best interests in mind running on my computer.

Honest question - What are you trying to prove by not enabling JS by default?

I think it's a matter of prevent: links to facebook, linked-in, and god knows what other service; and possibly save some bandwith, cpu time and ram.

I doubt she tries to prove anything. It is probably rather the peace of mind of not having ads stabbing in your eyes, subscribe popups appearing as you scroll, things wiggling around, images fading up in a popup instead of loading directly, protection against exploits and saving bandwidth just to name a few benefits.

Aside from the fact that JavaScript is often poorly written, I generally don't want untrusted code running on my computer.

I didn't even use a SPA for a webapp on my main work project I wrote a lightweight base and send down the page specific stuff and that model (so in a way it's lots of little SPA's not sure if that has a name) which means I get most of the advantages with few of the downsides.

The title and article are also for web apps, not web sites.

This was one of the points that stood out for me in the article too, also because I strongly disagreed with it. There is nothing inherently wonderful about doing everything client-side.

You get a much more limited range of languages and libraries to work with. You get to use overcomplicated build and deployment processes with ever-changing tools. You get to reinvent the wheel if you do want to use things like URI-based routing and browser history in a sensible way. In many cases you are going to need most of the same back-end infrastructure to supply the underlying data anyway.

Also, it's tough to argue the SPA approach is significantly more efficient if it's being compared with a traditional web app built using a server-side framework where switching contexts requests exactly one uncached HTML file, no uncached CSS or JS in many cases, and any specific resources for the new page that you would have had to download anyway.

Of course some web apps are sufficiently interactive that you do need to move more of the code client-side, and beyond a certain point you might find it's then easier to do everything there instead of splitting responsibilities. I'm not saying everything should be done server-side; I'm saying different choices work for different projects and it is unwise to assume that SPA will be a good choice for all new projects.

This is totally true.

If you're just starting out, chances are you are not (or should not be) making any sort of application where the performance increases by operating as a SPA will be even be noticeable compared to a standard server app.

Plus, I'd argue that you won't really understand what a SPA adds (or takes away) unless you are thoroughly familiar with the traditional model.

Finally, at the end of the day traditional apps are just a lot easier to put together even compared to the latest SPA frameworks, especially if your server side tech is something like Ruby or C#. A beginner will be better served by getting something nice up quickly, before attempting to do it the 'purist' way and possibly getting discouraged by the difficulty.

> I cannot comprehend why Reddit chose a single-page app for their new mobile site

They should but not the way they are making it.

It should be server side render for initial page (not just home page but any page). And mostly changing content through AJAX when you navigate between pages.

SPA is hard specially when it comes to usability. One of the biggest issue I see with SPA is going back. Browser handles back history pretty good for non-SPA. Replicating similar behavior in JS in not easy.

Reddit SPA should be like this with server side rendering. http://reddit.premii.com/

If you need a backend, starting with a SPA has one strong point, decoupling, you can leave your backend unmodified and start writing that native iOS, Android client or desktop client when needed it.

I often find many ajaxy effects on websites don't work work. For example, when I click to expand a comment in Quora, it often fails and I find it much quicker to just open it in a new page.

Reply on news.ycombinator.com