Single-page JS webapps - how to do them right?

[Pete]

I've been doing a lot of Backbone.js single page apps lately, while it
was fun for a while, but I realized it is full of problems.

To name a few:

- search engines won't see js-rendered content
- breaks cmd-click (open in new tab)
- web servers never get to see real request URL (hash fragments in URL
are not seen by webservers), which makes it impossible to do proper
301, 302 redirects (again search engines want it)
- I can't use my rails form builders / helpers in my JST!!!

You can sort of mitigate aforementioned problems by using html5
pushState + making routes respond to html, but then again there are
browser compatibility issues, and it also means the server side is no
longer just returning json, but should also be able to render html
(and you gotta maintain both JST and rails view templates - oh
noes!!!) making it just impossibly difficult to work.

DHH also seems to have a strong dislike for it, it was fun to watch
jashkenas and dhh arguing in hackernews.

Is anyone awesome at this? What's the easiest/best way to do pushState
+ progressive enhancement with ruby?

On Feb 18, 7:27 am, Jason Ong <velve...@gmail.com> wrote:
> Talking about javascript heavy pages, Tamas did a Q&A walkthru of
> Angular.js yesterday at hackerspace and we had a brief comparison of the
> over js mvc contenders. I must say I found Angular to be the most
> intuitive. Might do a "Angular.js on Rails" talk at the next meetup.
>
>
>
>
>
>
>
>
>
> On Sat, Feb 18, 2012 at 1:27 AM, Boon Kiat, Han <wj...@yahoo.com> wrote:
> > If you need books and answers from googling, rails.
>
> > Once you realize the modern webapp are serving single page
> > Javascript-heavy pages and designing Web API server side. Sinatra pretty
> > much does that neatly
>
> > Boon Kiat
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Singapore Ruby Brigade" group.
> > To post to this group, send email to singap...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > singapore-rb...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/singapore-rb?hl=en.
>
> --
> Cheers,
> JasonOng
>
> ---
> web:http://bit.ly/jasonong

[Boon Kiat, Han]

Like many I've played around with the usual suspects - angular, spine, backbone, knockout, batmanjs... ...

I don't even like javascript - but it's the necessary evil yeah.

- search engines: they will have to keep up, we can't entertain them by fetching whole pages forever, to meet them halfway, make sure the index-worthy content are fetched in clear markup

- hash fragments aren't real: -> hash-bang technique if you really need the work around... again you are trying to please the search engines... hash fragments in its essence is not meant as a page-local routing system

PushState + hash fragments + js routing does look nice but just achieves one effect: 'hacking the address bar'. yeah?

I honestly don't mind the single page app to be just at http://app.xyz.com fetching JSON (or html) by xhr using a well-tailored RESTful web api. 

My naive thinking

1) Using any DOM lib you like, craft the UI in classic multi-page (if possible just one server page)

2) design the backend that support classic multi-page, form-posting web calls

3) detect the needed supports, and override to make it stay on single page, calling the same routes *

4) improve backend to better respond if the client is single-page *

* if your skill level = ninja, use your favourite javascript MVC framework(see above) **

** if you are insane like me, use many smaller javascript frameworks instead of one!

...

Boon Kiat

PS: There are many other more interesting html5/javascript areas : canvas, media, offline, async, file, postmsg etc... 

to grind your skulls over

---

From: Pete <rain...@gmail.com>
To: Singapore Ruby Brigade <singap...@googlegroups.com>
Sent: Saturday, February 18, 2012 9:22 PM
Subject: [SRB] Single-page JS webapps - how to do them right?

> > singapore-rb+unsub...@googlegroups.com.

> > For more options, visit this group at
> >http://groups.google.com/group/singapore-rb?hl=en.
>
> --
> Cheers,
> JasonOng
>
> ---
> web:http://bit.ly/jasonong

--
You received this message because you are subscribed to the Google Groups "Singapore Ruby Brigade" group.
To post to this group, send email to singap...@googlegroups.com.

To unsubscribe from this group, send email to singapore-rb+unsub...@googlegroups.com.

[Winston Teo]

- search engines won't see js-rendered content

Search engines (Google in particular) do execute javascript and crawl their content.

Source: http://www.searchnewz.com/topstory/news/sn-2-20100315SEOInterviewwithMattCutts.html 

 

Matt Cutts: "For a while, we were scanning within JavaScript, and we were looking for links. Google has gotten smarter about JavaScript and can execute some JavaScript. I wouldn't say that we execute all JavaScript, so there are some conditions in which we don't execute JavaScript. Certainly there are some common, well-known JavaScript things like Google Analytics, which you wouldn't even want to execute because you wouldn't want to try to generate phantom visits from Googlebot into your Google Analytics. We do have the ability to execute a large fraction of JavaScript when we need or want to. One thing to bear in mind if you are advertising via JavaScript is that you can use NoFollow on JavaScript links" 

it also means the server side is no longer just returning json, but should also be able to render html

Why will this make it "impossibly difficult to work"? I mean.. Rails allows you to define different responds to different requests, so imo, this is perfect for your use case right?

 

Cheers,
Winston

[Pete]

It is impossibly difficult to work because you gotta maintain both
JSTs and Rails view templates/partials. You end up doing double work.
While there are hacks involving dynamic generation of JST by rendering
a view partial with fake model objects that return templating code
(e.g. {{ foobar }}), it is far from perfect because you can't have
simple conditional/enumeration logic.

Google executing JS is still quite limited, afaik it's limited to
stuff like disqus comments. They can't execute any arbitrary JS, if
somebody has an infinite loop or extremely slow js, it will slow
crawling significantly (even with timeouts). plus many js content are
rendered in response to dom events, googlebot won't trigger them. Yes,
Googlebot may get better in future, but there is no way we can rely on
it at the moment. Progressive enhancement is the only way now.

On Feb 19, 10:07 pm, Winston Teo <winston.yong...@gmail.com> wrote:
> > - search engines won't see js-rendered content
>
> Search engines (Google in particular) do execute javascript and crawl their
> content.
>

> Source:http://www.searchnewz.com/topstory/news/sn-2-20100315SEOInterviewwith...

[Shiaw Uen Tan]

I think if you're building content focus site, it's best to start building your app from point where older browsers doesn't have to depend on JS to do navigation and other interactions, after you got all the important contents and actions in place without depending on JS, then only start adding stuff that make use of pushState, localStorage, and other HTML5 shits. The reason behind this is that when you're focusing on content, then it's best for you to make sure that even when you JS fail, you are still be able to deliver your main content to your users without worry what browser they are using...

On the other hand, if you're doing a site that function like an app which the contents are usually not that important to be index or necessary to get index by the search engines, then it make more sense to use the single page JS method to handle it

--shiawuen

[Boon Kiat, Han]

Agree- but I think its not one or the other. my point is- we should not build single page apps at the expense of A. less capable browsers B.Web indexibility and C. code manageability. Conversely, we mustn't get entrenched at the lowest common denominator. Which can get really low.. Boon Kiat

---

From: Shiaw Uen Tan <shia...@gmail.com>;
To: <singap...@googlegroups.com>;
Subject: Re: [SRB] Single-page JS webapps - how to do them right?
Sent: Sun, Feb 19, 2012 2:49:25 PM

[SengMing Tan]

Hi Pete,

> DHH also seems to have a strong dislike for it, it was fun to watch
> jashkenas and dhh arguing in hackernews.

Do you still have the link to this? Sounds epic.

> It is impossibly difficult to work because you gotta maintain both
> JSTs and Rails view templates/partials. You end up doing double work.

To cut down on double work you could work with logic-less templates
(e.g. mustache, handlebars) then share the same templates between JS
and Ruby. Just learned that @siong1987 is in the process is converting
his partials/views to do just that.

[Jason Ong]

@sengming saw your tweet regarding seranade.js. looks good.

--
You received this message because you are subscribed to the Google Groups "Singapore Ruby Brigade" group.
To post to this group, send email to singap...@googlegroups.com.
To unsubscribe from this group, send email to singapore-rb...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/singapore-rb?hl=en.

[Sebastiaan Deckers]

Relevant: Twitter to move away from Hashbangs
http://news.ycombinator.com/item?id=3614037 

Easy solution:

1. Nginx rewrite rule to serve the same HTML bootstrapper regardless of URL

2. JavaScript/CSS loaders that parse the location.href and fetch the appropriate content via JSON/XML/HTML/Mustache/etc. Allows for maximum caching specificity.

3. a) Intercept clicks on pushState-supported browsers, basically IE ≤ 9 (GOTO #2)

3. b) On old browsers simply make normal HTTP requests (GOTO #1)

Let the search engines do their job. These days googlebot is essentially a headless chromium. It probably supports more javascript/html5 magic than your average user.

Unless you're targeting Curl, why bother with "compiled" (content+markup) output? You probably want to expose an API instead.

My €0.02

[Sebastiaan Deckers]

3. a) Intercept clicks on pushState-supported browsers, basically IE ≤ 9 (GOTO #2)

Oops, I meant ~(IE ≤ 9)

[Pete]

> Do you still have the link to this? Sounds epic.

http://news.ycombinator.com/item?id=3603367

Not really arguing per se, but they have different principles for
sure.

> To cut down on double work you could work with logic-less templates
> (e.g. mustache, handlebars) then share the same templates between JS
> and Ruby. Just learned that @siong1987 is in the process is converting
> his partials/views to do just that.

This is not a solution. There are too many problems with that
approach:
- You lose the ability to use helpers/form builders.
- You move far too much code from the view to the controller (or
presenter)
- You break delayed query mechanism in ActiveRecord (arel) since you
force them to run in the controller before the view is rendered.

[Pete]

> Let the search engines do their job. These days googlebot is essentially a
> headless chromium. It probably supports more javascript/html5 magic than
> your average user.

You sure about this? I haven't found a single definitive source that
confirms this.

[Sebastiaan Deckers]

Strong suspicions that Googlebot is based on Webkit:

http://ipullrank.com/googlebot-is-chrome/ 

(Relevant HN discussion http://news.ycombinator.com/item?id=3182579 )

Wonder if anyone has figured out how to target Googlebot on the client side yet. Might be possible to do SEO trickery via the Instant Preview screenshot?

[Tamas Herman]

i tried http://www.phantomjs.org/ headless webkit browser not too long ago
and it can run http://angularjs.org/ which is a client side templating framework (unlike zombie for node).
this way you can have 1 template, although u have to run this phantomjs as a separate process from the app server.
but since its role would be to generate cacheable / crawlable content it shouldnt serve huge load..
i havent put it into production yet though, but i will try it on http://www.bandwagon.sg/ probably soon.

--
tom

[Chin Chau Low]

This discussion inspired me to explore 2 options: PJAX and Backbone.js
with PushState.

Writeup: http://cclow.github.com/Programming/2012/03/22/crazy-fast-web-app-with-pushstate/
Code: https://github.com/cclow/PushState-Demo-w-PJAX-and-Backbone

I think the PJAX solution addresses Pete's remaining concerns.

Honest feedbacks are welcomed. Hope it's helpful.

[Matthew Rudy Jacobs]

On 23 March 2012 11:34, Chin Chau Low <chin...@gmail.com> wrote:

This discussion inspired me to explore 2 options: PJAX and Backbone.js
with PushState.

Writeup: http://cclow.github.com/Programming/2012/03/22/crazy-fast-web-app-with-pushstate/
Code: https://github.com/cclow/PushState-Demo-w-PJAX-and-Backbone

I think the PJAX solution addresses Pete's remaining concerns.

Honest feedbacks are welcomed. Hope it's helpful.

 

I'm currently working on a new project.

Using PJAX seems like the right way to go for me.

Thanks for writing this.

[Boon Kiat, Han]

Codeschool has this really good beginner tutorial on backbone.js (level one is free) As previous, pushstate or client MVCs are "good to have", to me, but not material to single page app Boon Kiat

From: Chin Chau Low ; To: Singapore Ruby Brigade ; Subject: [SRB] Re: Single-page JS webapps - how to do them right? Sent: Fri, Mar 23, 2012 3:34:42 AM This discussion inspired me to explore 2 options: PJAX and Backbone.js with PushState. Writeup: http://cclow.github.com/Programming/2012/03/22/crazy-fast-web-app-with-pushstate/ Code: https://github.com/cclow/PushState-Demo-w-PJAX-and-Backbone I think the PJAX solution addresses Pete's remaining concerns. Honest feedbacks are welcomed. Hope it's helpful.

On Feb 20, 11:26 pm, Pete wrote: > > Do you still have the link to this? Sounds epic. > > http://news.ycombinator.com/item?id=3603367 > > Not really arguing per se, but they have different principles for > sure. > > > To cut down on double work you could work with logic-less templates > > (e.g. mustache, handlebars) then share the same templates between JS > > and Ruby. Just learned that @siong1987 is in the process is converting > > his partials/views to do just that. > > This is not a solution. There are too many problems with that > approach: > - You lose the ability to use helpers/form builders. > - You move far too much code from the view to the controller (or > presenter) > - You break delayed query mechanism in ActiveRecord (arel) since you > force them to run in the controller before the view is rendered.

--

[Matthew Rudy Jacobs]

On 23 March 2012 14:22, Boon Kiat, Han <wj...@yahoo.com> wrote:

As previous, pushstate or client MVCs are "good to have", to me, but not material to single page app

This depends on your use case.

My current app involves;

• a page for each user showing what things they like
• a page for each thing showing what users like it
• a whole load of user-specific actions and views

I don't care about making particular user interactions bookmarkable, or linkable,

but the particular pages for a user or thing I want to be bookmarkable, linkable, and indexable by search engines.

I guess it comes down to creating the right solution for your problem.

[siong1987]

It is really hard to reply this email because someone mentioned my name on the thread. Personally, this will be how I will go about this:

non-public-facing app: backbone

pubilc-facing app: rails local templates

I learned this the hard way. http://dailymus.se is built on backbone but it is a public-facing app. Google won't be able to parse. And, let's not talk about just Google. When someone tries to share your link on Facebook, Facebook won't be able to parse it too. So, now, I am in the process of converting all my backbone + haml(frontend haml) to rails local template. And, people who diable javascripts won't be able to view your website too. You may say fuck those people who do not use JS. But, I have demo'ed DailyMuses to at least 5 users who disabled JS on their browsers. And, YES, fuck them.

Before I start my rambling on this, let me put a shameless plug here. Guys, check out DailyMuses(http://dailymus.es). It is built on pushstate/backbone/rails.

Many people think that Backbone is the next cool thing to be used in their apps. But, most of the people I talked to, they have hacked Backbone to work with their ways. At DailyMuses, I hacked a few things to make Backbone more awesome, rails-like routing(think config/routes.rb but routes.js), multiple rendering on single page(multiple router called when rendering a single page), section-only caching(when rendering navigation bar twice if it is on every page). They all feel hackish to me. But, it works.

Pete:

- You lose the ability to use helpers/form builders.

Not really. Try check out https://github.com/infbio/haml_assets. you can still use helpers in your js template. Worst case, use `view_context` in your controller.

Btw, using pjax will just help to make your application slightly faster. rack-pjax only saves the bandwidth. rails_pjax is the most stupid, you still get the whole page response from the server, but, you only render the page you want on the frontend using JS. Note that the new Basecamp is not using pjax. They are using something customized, so, I don't think that their customized library works like rack-pjax or rails_pjax.

What I am going to do for the next DailyMuses:

1. pjax. But, I may want to customize it. We see how it goes.

2. rails local rendering because we are a public-facing app.

3. mustache, logic less template. i don't want my designer to worry about writing front-end logic with ruby.

4. fuck people who disables javascript on their browsers.

To unsubscribe from this group, send email to singapore-rb+unsubscribe@​googlegroups.com.

For more options, visit this group at http://groups.google.com/​group/singapore-rb?hl=en.

To unsubscribe from this group, send email to singapore-rb+unsubscribe@​googlegroups.com.

[Matthew Rudy Jacobs]

On 23 March 2012 14:51, siong1987 <sion...@gmail.com> wrote:

non-public-facing app: backbone

pubilc-facing app: rails local templates

I like this explanation of the logical split.

[Sau Sheong Chang]

I have zilch experience in backbone.js but this sounds about right, if backbone.js etc are like the Rich Internet Applications of yester-years.

[Low Chin Chau]

That's assuming backbone buys you something for non public facing app. The only thing I find that must-have client mvc, is disconnected app.

--
Chin Chau Low

[Boon Kiat, Han]

Whaaa? 

Same: no personal experience to use backbone - though the reasons and their track record are compelling.

I think backbone is already one of the thinnest framework-likes out there.

For this purpose, backbone I don't see the distinction public-facing or not.

It seems a matter of which layer does the logic and templating.

In days of yore, all these is server side and the browser is a dumb client.

As we now dive into all the new UI needs: offlineable, no-refresh, responsive, local storage

As more and more people/organizations stepping forward to share the solutions/structures/approaches that they built up during the past 5 years while making RIAs, pjax sounds stupid to me but is probably relevant to certain kinds of applications.

Yes - anyone who disables javascript in their browser is pretty much locking himself out.

But that's no reason why we should write large, copious amounts of it.

BK

---

From: Sau Sheong Chang <saus...@gmail.com>
To: singap...@googlegroups.com
Cc: "chin...@gmail.com" <chin...@gmail.com>; wj...@yahoo.com
Sent: Friday, March 23, 2012 3:44 PM
Subject: Re: [SRB] Re: Single-page JS webapps - how to do them right?

To view this discussion on the web visit https://groups.google.com/d/msg/singapore-rb/-/cAXSjUaaR7wJ.

To post to this group, send email to singap...@googlegroups.com.

To unsubscribe from this group, send email to singapore-rb...@googlegroups.com.

[Jordan Brock]

SS

-Jordan Brock, President of Hit the Sticks LLC

---

From: Matthew Rudy Jacobs <matthewr...@gmail.com>

Sender: singap...@googlegroups.com

Date: Fri, 23 Mar 2012 13:31:23 +0800

To: <singap...@googlegroups.com>

ReplyTo: singap...@googlegroups.com

Subject: Re: [SRB] Re: Single-page JS webapps - how to do them right?

--

[Tamas Herman]

how come i still don't hear http://angularjs.org being mentioned?
backbone is still too low-level.
like a language w no garbage collection...

@siong, u were talking about routing and multiple routes on 1 page, etc
sounds a like reinventing what angular knows by default anyway.
i understood ming's worries about it. it was a very young framework a yr ago.
it indeed went thru a couple of major changes (~3 times in a yr).
however a conversion to a newer major version might have taken a few hours,
it's negligible compare to the days of work it has saved.
it's going thru a major change right now, before they release v1.0 in a few weeks,
but i was using it all the time for almost a year now and it was truly awesome.

what i would explore deeper about crawling is using phantomjs.
it can run angular perfectly (v0.9.6 was fine at least)
and can spit out the resulting html,
(which u can cache in files for minimizing server load,
however u introduce the dared cache invalidation problem…)
this way there is no need for dual maintenance of template code
on front and backends.

--
tom

[Jason Ong]

Phantom looks interesting.

--
You received this message because you are subscribed to the Google Groups "Singapore Ruby Brigade" group.
To post to this group, send email to singap...@googlegroups.com.

To unsubscribe from this group, send email to singapore-rb...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/singapore-rb?hl=en.

[Pete Kim]

I've been using haml-coffee-assets, because logicless templates didn't
feel quite right, but I guess I will give haml-assets + handlebars a
try for a new project I am doing.

On Mar 23, 2:51 pm, siong1987 <siong1...@gmail.com> wrote:
> It is really hard to reply this email because someone mentioned my name on
> the thread. Personally, this will be how I will go about this:
>
> non-public-facing app: backbone
> pubilc-facing app: rails local templates
>

> I learned this the hard way.http://dailymus.seis built on backbone but it

> is a public-facing app. Google won't be able to parse. And, let's not talk
> about just Google. When someone tries to share your link on Facebook,
> Facebook won't be able to parse it too. So, now, I am in the process of
> converting all my backbone + haml(frontend haml) to rails local template.
> And, people who diable javascripts won't be able to view your website too.
> You may say fuck those people who do not use JS. But, I have demo'ed
> DailyMuses to at least 5 users who disabled JS on their browsers. And, YES,
> fuck them.
>
> Before I start my rambling on this, let me put a shameless plug here. Guys,
> check out DailyMuses(http://dailymus.es). It is built on
> pushstate/backbone/rails.
>
> Many people think that Backbone is the next cool thing to be used in their
> apps. But, most of the people I talked to, they have hacked Backbone to
> work with their ways. At DailyMuses, I hacked a few things to make Backbone
> more awesome, rails-like routing(think config/routes.rb but routes.js),
> multiple rendering on single page(multiple router called when rendering a
> single page), section-only caching(when rendering navigation bar twice if
> it is on every page). They all feel hackish to me. But, it works.
>
> Pete:
> - You lose the ability to use helpers/form builders.

> Not really. Try check outhttps://github.com/infbio/haml_assets. you can

> still use helpers in your js template. Worst case, use `view_context` in
> your controller.
>
> Btw, using pjax will just help to make your application slightly faster.
> rack-pjax only saves the bandwidth. rails_pjax is the most stupid, you
> still get the whole page response from the server, but, you only render the
> page you want on the frontend using JS. Note that the new Basecamp is not
> using pjax. They are using something customized, so, I don't think that
> their customized library works like rack-pjax or rails_pjax.
>
> What I am going to do for the next DailyMuses:
> 1. pjax. But, I may want to customize it. We see how it goes.
> 2. rails local rendering because we are a public-facing app.
> 3. mustache, logic less template. i don't want my designer to worry about
> writing front-end logic with ruby.
> 4. fuck people who disables javascript on their browsers.
>
>
>
>
>
>
>
> On Friday, March 23, 2012 1:22:22 AM UTC-5, bummer wrote:
>
> > Codeschool has this really good beginner tutorial on backbone.js
> > (level one is free)
>
> > As previous, pushstate or client MVCs are "good to have", to me, but not
> > material to single page app
>
> > Boon Kiat
>

> > *From: *Chin Chau Low ;
> > *To: *Singapore Ruby Brigade ;
> > *Subject: *[SRB] Re: Single-page JS webapps - how to do them right?
> > *Sent: *Fri, Mar 23, 2012 3:34:42 AM

>
> > This discussion inspired me to explore 2 options: PJAX and Backbone.js
> > with PushState.
>
> > Writeup:

> >http://cclow.github.com/​Programming/2012/03/22/crazy-​fast-web-app-with-pushstate/<http://cclow.github.com/Programming/2012/03/22/crazy-fast-web-app-wit...>
> > Code:https://github.com/cclow/​PushState-Demo-w-PJAX-and-​Backbone<https://github.com/cclow/PushState-Demo-w-PJAX-and-Backbone>

>
> > I think the PJAX solution addresses Pete's remaining concerns.
>
> > Honest feedbacks are welcomed. Hope it's helpful.
>
> > On Feb 20, 11:26 pm, Pete wrote:
> > > > Do you still have the link to this? Sounds epic.
>

> > >http://news.ycombinator.com/​item?id=3603367<http://news.ycombinator.com/item?id=3603367>

>
> > > Not really arguing per se, but they have different principles for
> > > sure.
>
> > > > To cut down on double work you could work with logic-less templates
> > > > (e.g. mustache, handlebars) then share the same templates between JS
> > > > and Ruby. Just learned that @siong1987 is in the process is converting
> > > > his partials/views to do just that.
>
> > > This is not a solution. There are too many problems with that
> > > approach:
> > > - You lose the ability to use helpers/form builders.
> > > - You move far too much code from the view to the controller (or
> > > presenter)
> > > - You break delayed query mechanism in ActiveRecord (arel) since you
> > > force them to run in the controller before the view is rendered.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Singapore Ruby Brigade" group.
> > To post to this group, send email to singap...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > singapore-rb+unsubscribe@​googlegroups.com<singapore-rb%2Bunsubscribe@googl egroups.com>
> > .

> > For more options, visit this group at

> >http://groups.google.com/​group/singapore-rb?hl=en<http://groups.google.com/group/singapore-rb?hl=en>
> > .

>
> On Friday, March 23, 2012 1:22:22 AM UTC-5, bummer wrote:
>
> > Codeschool has this really good beginner tutorial on backbone.js
> > (level one is free)
>
> > As previous, pushstate or client MVCs are "good to have", to me, but not
> > material to single page app
>
> > Boon Kiat
>

> > *From: *Chin Chau Low ;
> > *To: *Singapore Ruby Brigade ;
> > *Subject: *[SRB] Re: Single-page JS webapps - how to do them right?
> > *Sent: *Fri, Mar 23, 2012 3:34:42 AM

>
> > This discussion inspired me to explore 2 options: PJAX and Backbone.js
> > with PushState.
>
> > Writeup:

> >http://cclow.github.com/​Programming/2012/03/22/crazy-​fast-web-app-with-pushstate/<http://cclow.github.com/Programming/2012/03/22/crazy-fast-web-app-wit...>
> > Code:https://github.com/cclow/​PushState-Demo-w-PJAX-and-​Backbone<https://github.com/cclow/PushState-Demo-w-PJAX-and-Backbone>

>
> > I think the PJAX solution addresses Pete's remaining concerns.
>
> > Honest feedbacks are welcomed. Hope it's helpful.
>
> > On Feb 20, 11:26 pm, Pete wrote:
> > > > Do you still have the link to this? Sounds epic.
>

> > >http://news.ycombinator.com/​item?id=3603367<http://news.ycombinator.com/item?id=3603367>

>
> > > Not really arguing per se, but they have different principles for
> > > sure.
>
> > > > To cut down on double work you could work with logic-less templates
> > > > (e.g. mustache, handlebars) then share the same templates between JS
> > > > and Ruby. Just learned that @siong1987 is in the process is converting
> > > > his partials/views to do just that.
>
> > > This is not a solution. There are too many problems with that
> > > approach:
> > > - You lose the ability to use helpers/form builders.
> > > - You move far too much code from the view to the controller (or
> > > presenter)
> > > - You break delayed query mechanism in ActiveRecord (arel) since you
> > > force them to run in the controller before the view is rendered.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Singapore Ruby Brigade" group.
> > To post to this group, send email to singap...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > singapore-rb+unsubscribe@​googlegroups.com<singapore-rb%2Bunsubscribe@googl egroups.com>
> > .

> > For more options, visit this group at

> >http://groups.google.com/​group/singapore-rb?hl=en<http://groups.google.com/group/singapore-rb?hl=en>
> > .