Theocacao
Leopard
Design Element
Comment on "Separation of Model and View Web Frameworks"
by Scott Stevenson — Aug 05
@Andre: Yes there are still several environments involved but they bridge nicely: from the client-side JavaScript to the sever-side JS, JSON is your friend. From the server-side JS to the back-end Java app, any Java object can be used straight within your JS so it's transparent.

I think you've actually helped me see something more clearly. I don't necessarily mind working in different languages or frameworks within the same app. What I want to avoid is having to configure and glue together all sorts of different moving parts.

I don't mind writing a number of classes in Ruby/PHP then another set of very similar classes in JavaScript if I'm confident they'll work well together out of the box. My goal is to see something working quickly so I can figure out if it's a good solution, then build on that.

To use a metaphor we're all familiar with: I want to buy a Mac pre-built and pre-configured, not assemble a PC from individual parts. I'm looking for a single vendor with a single point of accountability. Rails may not be far off from this, but I haven't spent enough time with it recently to know for sure.

This is very flexible as you're not tied to one way of doing things (though this comes at the cost of a high abstraction and the resulting higher learning curve)

I think this highlights the point really well. I honestly don't want flexibility and choice in this case, I just want one option that works reasonably well. I'd rather have a less perfect solution (meaning fewer features, not something that is poorly written) that I can get running in two hours versus two weeks, particularly because this is a side project.

But this is just my perspective. I really appreciate you sharing this for other people reading this who may be interested.
Back to "Separation of Model and View Web Frameworks"
Design Element

Copyright © Scott Stevenson 2004-2015