What I'm trying to do is build a simple app in PhoneGap and Backbone.js. The app has a login page which, on a successful login, sends the user to a simple menu with a few options. The user has the option to view their saved lists, view a list of items or view an info page. I know how I want to structure all of the Views and Models so the question I have is whether or not doing this all on one page has any downsides when compared to using multiple pages.
To break it down into smaller parts:
Does loading all the javascript in the one page have serious performance implications?
If the router closes, .remove() and .unbind(), all the current view when switching to a new view, do I still risk memory issues?
Backbone was designed to be built for SPA applications. Im not saying that you can't span Backbone over multiple pages, but in my opinion that adds more complexity. From your description, I would keep your application as an SPA.
Secondly, build your application using modules. Use a library such as require.js. I could not recommend it enough. I wont go into too much detail about why you should use it, because you can read more about it here (I would recommend reading the entire book). Once your application is ready for deployment, you can use r.js, require.js's build script. This will concatenate all or some of your modules into a single file. This will drastically speed up the performance of your app especially if you have a bunch of modules.
Finally with regards to memory optimization, I use a method developed by Derick Bailey which you can read up about here.
Hope this helps.
Related
I'm currently developing a Single Page Application (in this case AngularJS), but as it grows I find it more and more tempting to refactor it into a multi page app.
However, I still need the ability to have sophisticated, dynamic UIs on the client (which requires more than just DOM manipulation but awareness of my information model).
I know most people use jQuery for this; I'm afraid it won't get me as far as I want, and I'm wondering if ReactJS is suitable for that job (well, when you're running a small company, not Facebook).
To be quite honest I've tried the single page app route with Angular, Backbone and even Knockout to an extent.
In my efforts I've found the most maintainable solution, especially for large teams is to use a multi-page app and rely on React to create a dynamic single page type experience where it's necessary.
Due to the buzz term SPA I've found a lot of teams think they need to be cutting edge by adding unnecessary complications like an SPA where a standard multi-page MVC app is a much better solution.
To me, React is the perfect solution for the problem of building a large scale website which may act as a multi-page app in some areas where necessary, but use standard sane MVC elsewhere.
React just works very easily with Django, ASP.NET, Ruby etc...
I just recently got introduced to MV* frameworks and have taken a chance to try out Ember.js with the TodoMVC app tutorial they have on their site.
I was considering using Ember for one of my upcoming projects (a Ruby on Rails CRUD app, similar to Twitter in some of the functionality), but I'm still a bit confused and before I take a final decision I would love it if somebody could clear the following concerns:
Is it a good idea to use such an advanced framework as Ember for a medium-sized multi-page CRUD app? Will it improve development time and maintenance compared to an interactivity layer built with jQuery's DOM manipulation and AJAX capabilities? Or is using Ember (and the like) only good when developing complex single-page apps (e.g.: Grooveshark)?
Considering the app will be developed using Rails, and assuming Ember will be used, is it going to be possible to offer a fallback with basic functionality for browsers with JavaScript disabled and/or for search engine crawlers? Will it require code duplication or other dirty tricks? Do you know of any technique that can be used to achieve it?
Will it be possible to adapt the website for mobile browsing (using only CSS) with valid results, or will the overhead imposed by running Ember on the phone make it hard for the device to render the website in a way that keeps it responsive?
We're in the middle of a pretty big Ember project right now, so here are my thoughts on your questions.
We've found Ember to be really productive for creating rich UIs for our single page app, but I don't know that it's going to be that much more helpful if you're creating an app designed for traditional multi-page (viewing pages, submitting forms, etc) layout.
I think this is the clincher - Ember is completely JS-based, so if you need to support browsers without JS, you'd basically have to write a parallel application. If this is a hard requirement for your app, I think Ember (or any MV* JS framework) would be out of the question
We've had very few performance issues on mobile - our site is fully responsive and renders on everything from Blackberries to the latest Chrome on desktop with good performance.
#Scott Rankin, has addressed most of the concerns with going with the Pure Ember approach. I'll add one quick way to make this decision.
Go with Ember/MVVM if the application is behind a login. Then you don't have to consider search engines, as the content is generally private and not supposed to be indexed.
For SEO you have to build atleast part of your content such that it is indexable. A good example of this is the Discourse application. They use Ember but also send down some generated html along with the app html slugs, so that search engines can index them. You can read about their approach here.
We have a different approach which can be seen as a fall back: We pre-render a static version of each page in the application (daily scheduled task). This static version is stored on the server as HTML file. Whenever we sniff as spider/ robot user agent, we deliver that version.
As I understand it the "conventional" way to handle page reloads is to duplicate functionality and presentation on the web stack using its controllers, views, and models. I'd appreciate insight on other (possibly better) ways to handle these situations. As well as feedback on the following two approaches:
Reload the js framework based app/suite on every web (stack) app page thus
forcing the js framework to handle all routing and rendering
Use the web stack to route interactions and then use backbone to
display views depending on the interactions.
Thanks!
IMHO the 2. approach is the one Backbone has born to :)
Following this approach we'll finish with what is called Single Page Application.
But to achieve this in medium-large applications can be very exhausting. You have to deal with complicate Router that has to be in charge of initialize or replacing elements, also you have to take care with memory leaks and ghost Views. You have to define a system to refresh your Collections and Models due you are reusing them in every page, ...
So a combination of both approaches can be also a good idea. You can split your application in modules like: ManagingUsers, ManagingPosts, ManagingMedia, create Single Page applications for these modules, containing index, edit, show, ... actions that don't reload the page, and if you move to another module the page will be reloaded and in company of the whole framework and with a healthy memory reset.
We need to change/rewrite an existing series of pages/workflow screens into one standard page. The project in itself will essentially be to build a single web page app inside the context of a larger existing application.
Our goal is to leave the server side implementation the way it is as much as possible. This means we won't be using a REST model, but rather just some form submissions to a java backend. Each end point will point to a JSP.
Each form will be created as a widget. When one widget submits it may affect the value of the other widgets which need to change their values on the fly.
It seems the 2 main options for single page web apps are Backbone.js or Ember.js.
Given our requirements, which of these 2 (or any other frameworks) will fit best? Or is there some other approach all together we should take?
Did you have a look at AngularJS? It is more comparable to EmberJS.
I would recommend you EmberJS for the moment, as it is more mature in term of ecosystem (Routing, Data, ...)
Backbone is lower-level than both precedents.
There are probably a bunch of things you should look into.
Emberjs is 42k minified+gzip while Backbone.js is just 5.6kb. Emberjs packs a lot of power in it which the barebones Backbone doesn't give you.
Analyse if you even need all those features. If your requirements are covered by just Backbone, IMO you should give Emberjs a pass. Shipping all those extra bits for no use is foolish.
With Emberjs, you will have to use jQuery as well. Not sure if you are already using it or not.
IMHO, I would use Emberjs if the single page web app is super complex with lots of feature requirements else Backbone should suffice.
Either will accomplish what you want.
I am partial to Ember as it provides a Routing/statechart framework which really helps lock an application's behavior down. Not to mention that it is MVC, which will help you separate your concerns. Each form or widget in your app will be a view that you define, binding inputs to your model layer.
I have build a basic backbonejs application and it is one page now handling login, list view and detail views.
I now need to add more business objects to be viewed listed and edited, and I was wondering if there is a best practice on when to move beyond the one page?
BTW it is backbonejs on the front, nodejs and express is on the back
Not really.
You can build the entire thing as a single page app using a router to handle the dispatching between all the various views.
You might want to make "namespace" pages, so like /auth/ is a file that loads just the auth parts of your site, /posts/ might be all the blog posts, etc.
This way you're not loading a ton of javascript into the browser in case someone doesn't never need to use a certain function.