Using Ember: How big or small to go?

Design
1

Hi all,

I’ve started using Ember on a new project I’m working on. I used it for the login form so far as an experiment and I really like it.

But now as I’m about to start doing the “real” work, like lots of forms for creating data, viewing and editing data (the system helps small shop owners, but is not a POS system), I’m struggling with how much or how little Ember to use.

I think there are three parts to my dilemma…

Define the full app up front vs pull in on-demand

When a shop owner logs in, I want the initial page to load quickly so I figure it should define minimum scaffolding then load the rest of the Ember app by ajax. But I don’t see examples following this approach so I wonder if I’m on the wrong track already.

Short term quick-and-dirty vs long term cohesion

Some of my functions could be done with just “plain old forms+jquery” - but I like the idea of tying everything together with Ember, as I think the effort will, over time, result in a cleaner and more cohesive result.

And finally…

One “page” or many pages?

Historically, I’m mainly a server-side guy so I tend to build a lot of the functionality on the server side. But as I read the Ember docs about routing and URLs, I see it is so powerful I could build the app entirely on one page and have ember handle all the routing, and never reload the page or go to another (server-side) page for different functionality.

For example, “transactions” and “administration” functions, in the old days, would have been totally different server side functions but now I feel like I could do both and more in one gigantic ember app.

I’m struggling to see where I should separate Ember from the back-end.

Wrapping up

What are your views on…

  1. How much app do you put in your initial load, vs pulling in more app on-demand?
  2. Do you do all of your functionality in Ember or throw in some work without it?
  3. Where do you draw the line between an all powerful Ember app running your whole site and different server-side pages for different parts of your site?

Thanks a lot JR

3 Likes
2

I personally would render the header and footer server side. There is rarely dynamic content there, so I can cache aggressively, and the site will appear faster than doing it on the client. The space between the header and footer is where I would use ember.

My preference is that the entire webapp be done in a consistent manner. For me, ember it is about as fast as the quick-and-dirty jquery solution. If I’m transitioning from a mostly server model to a heavy client side model, I may have a mixed ecosystem. However, my goal would be to move to a consistent model there as well.

I prefer to think of webapps as a composition of smaller applications. There needs to be a clean separation of responsibilities between these smaller applications. For example, I might treat something like account management, finding a product, and checkout as separate applications. I could easily define an ember app that only handled that portion and I would host it on separate pages. Something like login is a cross-cutting concern for many pages, and that I would extract out into a reusable piece of code between applications. If I can’t mentally separate my app into a set of smaller applications, then there may not be a separation and a single page app makes sense in that case.