4 ms·

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 https

by pbiggar 14y ago

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 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.

hardik988 14y ago
OT: Circle CI looks really impressive. May I ask if you used a library like Meteor to build the app?
- pbiggar 14y ago
  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!)
  - Gigablah 14y ago
    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.
    - pbiggar 14y ago
      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 :)
    - bgilroy26 14y ago
      > 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?
  - mattdeboard 14y ago
    Hmm... interesting. Do you have a write-up on your tech stack?
    - pbiggar 14y ago
      No. We have it planned but not written yet. Follow http://blog.circleci.com http://blog.circleci.com or http://twitter.com/circleci http://twitter.com/circleci if you're interested, or if we're very lucky you might find it on HN too :)
romaniv 14y ago
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.
- pbiggar 14y ago
  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!
  - gambler 14y ago
    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.
    - pbiggar 14y ago
adatta02 14y ago
fyi, your header menu is breaking for me - http://i.imgur.com/nstFX.png http://i.imgur.com/nstFX.png - Firefox 15.0.1 on Ubuntu 11.
- pbiggar 14y ago
  Thanks!
rgbrgb 14y ago
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.
- pbiggar 14y ago
  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.

by pbiggar 14y ago

hardik988 14y ago

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

pbiggar 14y ago
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!)
- Gigablah 14y ago
  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.
  - pbiggar 14y ago
    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 :)
  - bgilroy26 14y ago
    > 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?
- mattdeboard 14y ago
  Hmm... interesting. Do you have a write-up on your tech stack?
  - pbiggar 14y ago
    No. We have it planned but not written yet. Follow http://blog.circleci.com http://blog.circleci.com or http://twitter.com/circleci http://twitter.com/circleci if you're interested, or if we're very lucky you might find it on HN too :)

romaniv 14y ago

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.

pbiggar 14y ago
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!
- gambler 14y ago
  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.
  - pbiggar 14y ago

adatta02 14y ago

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

pbiggar 14y ago
Thanks!

rgbrgb 14y ago

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.

pbiggar 14y ago
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.