Hacker News Reader

Comment by pbiggar | Hacker News Reader

This is bullshit. One-page JS apps exist because there are a few big advantages to them. There are also disadvantages.

Take my site: https://circleci.com. Doesn't work in IE8 or less, and it has some bugs. But when you click a new page, it happens immediately. Properly immediately.

Inside the app, when you click a new page, it takes 1 AJAX request to load. Not 50 JS/CSS/img assets. No white flash. Just 1 click and it loads instantly.

Now, that's not to say that the majority of sites like this couldn't be done better. They could, and so could we. We need to sort out our SEO story for a start. But we made a conscious decision to do this because it makes sites fast, and much easier to write.

View on HN

If you're saying that the only way to build a fast website is to use single-page design, you're wrong. Having reasonable amount of images and CSS, as well as efficient server side components does way, way more for noticeable performance than being single-page.

But I think the real issue at hand isn't about being single-page, it's about using single-pageness as an excuse for ignoring certain usability and architectural issues.

No white flash. Just 1 click and it loads instantly.

Unless you're using IE9.

Also, I couldn't click any of the top links on my Galaxy S.

It's not the only way, but once you optimize everything in a static app, the only place to go is one-page.

> But I think the real issue at hand isn't about being single-page, it's about using single-pageness as an excuse for ignoring certain usability and architectural issues.

Agreed. Funnily enough the architectural issues are easier with one page apps, IMO. You just expose a REST API, do your asset caching, and don't need any HTML caching at all!

> Unless you're using IE9. Also, I couldn't click any of the top links on my Galaxy S.

Thanks for the reports. I think those are orthogonal from the one-page JS app though, and are more due to building a PaaS with 2 people. We'll fix it though!

Funnily enough the architectural issues are easier with one page apps, IMO. You just expose a REST API, do your asset caching, and don't need any HTML caching at all!

Let's say I want to build a new search engine. How do I crawl your website without having Google-esque budget? More importantly, if all websites were built like that, how would anyone could build a new search engine?

That's also architecture. How do things interact? What is possible and what is not? What kind of things would happen if technology became popular?

The real issue here is not that the page is not crawlable right now. I know there ways of addressing this. The issue is that it's not semantic and that you need to do extra work (separate from normal development) for search engines.

With absolutely no offense intended, your search engine is very low in my priority list. I care about how my customers experience Circle.

If you were to create a new search engine, and it didn't take into account one-page-apps, I'd say you've built the wrong architecture too.

Finally, it's not that we don't have the time, it's that we dont have the time _right now_. Web apps suddenly became hard in the last 3 years - people expect a lot more than they used to. But our priorities must be to deliver the kind of experience that customers desire. Technology should be our servant, not our master.

Presentation does not trump content, and the spread of this attitude will destroy the web. If nobody can reference and repurpose that content in ways you never thought of, it ceases to be more useful than print or even television.

CircleCI is an application, a tool, not a collection of documents. It has no use being crawled, since there isn't much content, and what you have is not for sharing. This applies to 90% of web apps.

It's not about my search engine, though. It's about any new search engine. It's about the future possibilities.

I care about how my customers experience Circle.

If your customers care about privacy and security and browse with JavaScript disabled by default, they will be annoyed. If they have disabilities and use a screen reader, they're likely screwed. If they get lost in your docs and decide to use "site:circleci.com" query to find the page they need, they will get nothing. If they would want to use a mini-crawler to download your docs for local usage, they will get nothing.

That is user experience, and those things are objective. They either work or not. On the other hand, performance gains and development time gains of single-page apps are -- debatable.

If you were to create a new search engine, and it didn't take into account one-page-apps, I'd say you've built the wrong architecture too.

There is no reliable way to build a search engine that would crawl through websites created mostly in an imperative language. Even unreliable ways to do that are complicated enough that Google and Microsoft fail miserably at them.

When I visit your site, a blurb of text flashes for a minute then turns into your headline/call-to-action. Also, "Continuous Integration for Web Apps" jumps to "Continuous Integration (3 extra spaces) for Web Apps" after half a second. I'm on your side but there are very obvious deficiencies in your client-side app.

I'm on Chrome 21.0.1180.89 on OSX Lion BTW.

Agreed. There's only so much you can do with 2 people, and we've chosen to prioritize fixes to our platform over the UI. Difficult choice, but I don't think having a 1-page app affects it except positively.

The "Continuous Integration for Web Apps" flash is due to our Kissmetrics client-side A/B testing. An interesting point is that if we were doing server side A/B testing, we probably wouldn't see that. On the other hand, once I saw that for the first time, I realized it drew my eye to it, and figured it's not a bad thing. But maybe I'm compensating.

OT: Circle CI looks really impressive. May I ask if you used a library like Meteor to build the app?

We have a clojure backend, the front-end uses Sammy.js for routing and history, and Knockout.js for data-binding, written in CoffeeScript and HamlCoffee, delivered using dieter (which is sprockets for Clojure).

(PS: like the sound of hacking on dev tools in clojure? We're hiring!)

The downside of building sites that are exclusively client-side rendered is that it stops working if the user has Javascript turned off.

That's why I personally use the strategy of rendering server-side only upon initial load, then hooking in client-side routing/templating libraries afterwards. This solves the issue of search engine visibility and client JS support in one fell swoop. (Mustache templates are great in this regard since there's libraries supplied for most languages.)

By the way, just a nitpick: your site seems to have a empty margin to the right, which creates a horizontal scrollbar. I'm using Chrome Version 21.0.1180.89 on OSX.

We made an explicit choice not to support non-JS users with our product. For simplicity, we don't support non-JS users in our marketing material/web site. We do intend to do something better there, for example by having a no-script pitch for why you should enable JS on our site.

We have a very pragmatic attitude. When people complain, we start to prioritize it (thanks for the bug report/nitpick!). If no-one complains, it can't be important. We haven't heard any complaints from non-JS users yet :)

> the strategy of rendering server-side only upon initial load, then hooking in client-side routing/templating libraries afterwards

Is there a name for this strategy? How can I read more about it?

Hmm... interesting. Do you have a write-up on your tech stack?

No. We have it planned but not written yet. Follow http://blog.circleci.com or http://twitter.com/circleci if you're interested, or if we're very lucky you might find it on HN too :)

fyi, your header menu is breaking for me - http://i.imgur.com/nstFX.png - Firefox 15.0.1 on Ubuntu 11.

Thanks!

Reply on news.ycombinator.com