

Show HN: Spar - Single Page Application Rocketship - mhodgson
http://goboundless.github.com/spar/

======
whalesalad
The outerspace background is totally the killing the 'rocketship' paradigm. It
kills scrolling performance and uses quite a bit of CPU. Then again a
rocketship uses tons and tons of fuel so perhaps this is intentional? =)

~~~
efields
Winner!

------
brian_c
I really want to like this, but I can't get behind Sprockets when RequireJS
and Browserify exist. Code in comments, obtuse file extensions,
`require_tree`, etc. make code modularization an inelegant kludge.

------
mpobrien
The stars animation behind that logo seems to be using quite a bit of CPU...

~~~
antonwinter
seems like a good excuse to buy a new shiney laptop to me

------
dmix
I currently use <http://middlemanapp.com/> to accomplish this. It works really
well.

~~~
aaronwhite
Middleman looks great; Spar attempts to help on deployment as well as
development. Excited to see folks building/using frameworks like these.

------
vineet
Some of the story behind Spar:
[http://www.slideshare.net/wyrmwood/ultramodern-frontend-
dev-...](http://www.slideshare.net/wyrmwood/ultramodern-frontend-dev-
introducing-spar)

------
doublerebel
The concept is great. I use Spine.app for this myself.

A nodejs stack makes more sense to me because the app itself is powered by
JavaScript, not Ruby, and then I am truly decoupled from other languages.
However, I can see why someone coming from Ruby would prefer Spar -- even
Spine.app includes Sprockets support for Ruby devs.

~~~
aaronwhite
Spar itself requires no knowledge of Ruby, that was one of the design goals.
It happens to use Ruby tech under-the-hood, but no user of Spar would ever be
exposed to those choices.

------
ajacksified
This is a ridiculous concept and the opposite of "modern" web development, as
it purports to be. Maybe I'm using a different definition of "modern" - it
seems here that it means "using new shiny things" rather than "using
accumulated knowledge of web development patterns to build the best user
experience." But, I digress.

There is a massive gap here, and with any framework that is purely client-
side. Here's what you get if you serve html from the server:

* SEO. You can't crawl a page that loads purely over Javascript. Google has an API to allow access to ajaxed-in pages, but that means modifying you code to fit exactly what each crawler needs. Not going to happen.

* Better accessibility. Yes, some screen readers handle Javascript now, but many don't.

* Page performance. Time-to-usability on a page served by a server is several orders of magnitude faster than when you load javascript, then load data, then render the page. If the server can serve html, you can start using the page while the scripts load and initialize in the background.

If performance isn't a big deal, you want to make awkward hacks to force SEO
to work, and you don't care about reaching all possible people? Build a
single-page-app and nothing else.

I'm not saying don't make a single-page app; I'm saying be smart about it.

You've got two steps out of three - building an API and a single-page app. The
missing middle step is building a second server side app that reads from that
API (RESTful, right?) and bootstraps the page, which is built using language-
agnostic templates like Mustache. Then, you load your Backbone/whatever JS on
top, which takes over, and points at your api. It's easy to do with something
like Node that can even share the same code to build pages.

~~~
aaronwhite
Your opening digression is a bit harsh. We're all experienced web-devs, with
the accumulated knowledge of building websites that have reached in excess of
several hundred million individuals.

SEO - True. There are many different strategies to deliver solid SEO results
using technologies like Spar. You can use headless browsers to pre-render and
deliver on-demand rendered content, if you know your URL space completely, you
can pre-render all documents. Spar isn't an attempt to solve SEO for you, you
may not even care if you are building a phone-gap app, for instance. So does
that invalidate the technology?

Accessibility: I'm 100% behind accessibility, and if the compatible tricks
don't work... do you still make your site accessible for IE3? No... screen-
readers MUST catch up. We can all do what we can to help, but shouldn't
engineer for the past, which is an orthogonal concern from accessibile
technology choices.

Page-performance - I'll challenge the several orders of magnitude claim, we've
seen incredible performance w/ the approach, and best-case you're only talking
about first-page speed, even ceding that it becomes a much different story
later on... and if you're building an 'app' thats a big difference.

~~~
ajacksified
I apologize that it came off as harsh; it _is_ good, technically, but I also
think it's very important to stress what something like this can't do. There's
a big mentality right now that "single page apps" are the hotness - and they
ARE - if done _right_.

> do you still make your site accessible for IE3? No...

I subscribe to the ideas behind progressive enhancement, so I don't have to
_make_ that choice. An application can be built that works everywhere, for
every technology, with little development overhead (and in my experience, the
lowest-experience-first PE approach generally leads to better code anyway.)
This isn't just theory - I've done it with apps large and small, and it
_works_. I highly suggest <http://filamentgroup.com/dwpe/> to find out more.

> best-case you're only talking about first-page speed

I'd also argue that that's what matters most to visitors - numerous studies
show that there's a dropoff as that first page takes longer to load. Here we
have the difference between loading a page, being useful, and then loading
scripts vs loading an (empty, so faster) page, load libraries, load templates,
then load data, then push the template to the screen. Additionally, if you're
doing server rendering, you can probably cache that first hit at the web
server level and avoid even hitting the web application at all.

The difference won't matter if you have a tiny app, so you don't have much js
to download - but it will make a big difference if you have anything
reasonably-sized.

