Express and Backbone : best practices for view ?
738 views
Skip to first unread message
isil
Jun 4, 2012, 4:51:40 AM6/4/12
to Express
Hi,
What is the best practice to use Backbone with Express.js ?
Both rendering views !!
When use Express for rendering view or Backbone ?
I'm lost ....
Thanks for your help.
Best regards.
What is the best practice to use Backbone with Express.js ?
Both rendering views !!
When use Express for rendering view or Backbone ?
I'm lost ....
Thanks for your help.
Best regards.
John Teague
Jun 6, 2012, 3:00:39 PM6/6/12
to expre...@googlegroups.com
While I have yet to apply this directly to jade, but I have used backbone with other frameworks that used view engines so I don't know why it wouldn't work.
Personally, I like to have the server render as much of the the view that is possible at page rendering time. I'll create the basic html that I know doesn't change when actions occur on the client. Then I use client side templates for dynamic changes on screen. The downside to this is that testing your backbone views is much harder, in fact I don't have a consistent strategy that I'm really happy with yet.
I also render as much data as I can, as an array of objects in the view, then use the Collection.reset method, so the collections are fully populated, but doesn't require a second ajax call to get it.
This has worked for me but I'd like to hear how others are doing it as well.
--
You received this message because you are subscribed to the Google Groups "Express" group.
To post to this group, send email to expre...@googlegroups.com.
To unsubscribe from this group, send email to express-js+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/express-js?hl=en.
deitch
Jun 7, 2012, 11:56:47 AM6/7/12
to Express
I do almost nothing view-related on the server. The server does the
following:
- respond to REST requests at /api/whatever....
- serve up static resources: my main.html page, CSS, JS, images, etc.
Everything else happens in the browser (which BTW makes moving to a
mobile app relatively trivial).
I have a main.html, partials (each ending in .html) for major sections
of an app, and everything else happens inside the app (Sammy for
routing, Backbone for models/views/collections, jQuery).
For testing the server, it is easy, since it is all REST.
For testing the client, I use zombie (headless browser) + nodeunit
(but you could use vows, expresso, mocha, whatever tickles your
fancy). This gets 96%+ of cases, and allows me to make changes with
confidence. I still need *some* level of manual testing because of
browser-specific issues (IE, anyone?), but speed is dramatically
faster.
following:
- respond to REST requests at /api/whatever....
- serve up static resources: my main.html page, CSS, JS, images, etc.
Everything else happens in the browser (which BTW makes moving to a
mobile app relatively trivial).
I have a main.html, partials (each ending in .html) for major sections
of an app, and everything else happens inside the app (Sammy for
routing, Backbone for models/views/collections, jQuery).
For testing the server, it is easy, since it is all REST.
For testing the client, I use zombie (headless browser) + nodeunit
(but you could use vows, expresso, mocha, whatever tickles your
fancy). This gets 96%+ of cases, and allows me to make changes with
confidence. I still need *some* level of manual testing because of
browser-specific issues (IE, anyone?), but speed is dramatically
faster.
tjholowaychuk
Jun 7, 2012, 1:01:29 PM6/7/12
to Express
keep in mind to analyse your app on a case per case basis, don't
fall into the trap of "single page apps all the time everywhere is the
best solution!!"
because it's not. Facebook and Twitter have great writeups on these
issues but
it's very much an app-specific problem.
fall into the trap of "single page apps all the time everywhere is the
best solution!!"
because it's not. Facebook and Twitter have great writeups on these
issues but
it's very much an app-specific problem.
deitch
Jun 7, 2012, 1:04:29 PM6/7/12
to Express
You have links to their write-ups? I would enjoy reading them.
mgutz
Jun 8, 2012, 12:58:52 PM6/8/12
to expre...@googlegroups.com
Use Express to generate the single page app view, not-found, error and any informational static page. In some cases, you might want to create more than one app view. For example, an app can be divided into admin and public and it's a pain trying to do all of that in one Backbone app.
Most hackers try to dynamically fetch data for their Backbone views from page load. I would advise against that. The issue is a user can be left viewing a blank page if your data services are too busy. Bootstrap the data the initial set of data, then fetch as needed. We do something like this:
# app.mustache on server
<html>
<body>
<script>
var bootstrapData = {
posts: {{{firstPageOfPosts}}}
};
$(function() {
// set the app in motion
App.run(bootstrapData);
});
</script>
</script>
</body>
</html>
App views for the app can be handled by Backbone. The usual practice is to use inline <script> tags for Backbone view templates. We have a different approach and precompile all our Backbone templates as Javascript functions which are then sourced as any other javascript file. You might also want to start with a good foundation such as Backbone.Marionette which has some best practices built-in.
Bobby Chambers
Jun 9, 2012, 1:39:21 PM6/9/12
to expre...@googlegroups.com
@deitch: I am interested in why u are using sammyjs for routing and not backbone. If u get a chance would u mind explaining?
deitch
Jun 9, 2012, 1:55:48 PM6/9/12
to Express
Sure. In principle, it is because I like:
1) around/before/after for routes
2) using the actual function rather than the name of the function in a
string (always found that messy 'bout backbone)
3) control by verb
My routes look a lot like express:
app.get('#/post/:id/edit",showEditPost);
app.post('#/post/:id/edit",submitPostChanges);
Of course, to be really honest, also because I have been using Sammy
since well before backbone. :-)
1) around/before/after for routes
2) using the actual function rather than the name of the function in a
string (always found that messy 'bout backbone)
3) control by verb
My routes look a lot like express:
app.get('#/post/:id/edit",showEditPost);
app.post('#/post/:id/edit",submitPostChanges);
Of course, to be really honest, also because I have been using Sammy
since well before backbone. :-)
Bobby Chambers
Jun 9, 2012, 2:23:00 PM6/9/12
to expre...@googlegroups.com
@deitch: thank u for replying. Those are exactly the reasons I am not in love with the backbone router. Sweet, now I can try something else. Thanks
deitch
Jun 16, 2012, 2:08:38 PM6/16/12
to expre...@googlegroups.com
Interesting. I tend to break into multiple files to keep my server.js more readable, and I used to do what he does for bundle() to load up scripts, although I have tried requirejs lately on the client side and find it much cleaner.
On Saturday, June 9, 2012 6:24:08 AM UTC+3, Dan Stroot wrote:
I also try to keep sql out of the routes, and do something much more mvc-like on the express side.
Still, good reference point. Thanks for posting.
On Saturday, June 9, 2012 6:24:08 AM UTC+3, Dan Stroot wrote:
Search github for "Bookmarkly" - Express serves the app and REST API, App itself is all Backbone. Great way to learn the difference.- Dan
On Monday, June 4, 2012 1:51:40 AM UTC-7, isil wrote:
Reply all
Reply to author
Forward
0 new messages