Theocacao: Separation of Model and View Web Frameworks

Jonathan Badeen — Aug 02, 08 6201

Check out Aptana's Jaxxer. It just reached 1.0. It allows you to use javascript (including your favorite library) as a server side language. I'm really excited to try it out if only I could find a host that supports it. Obviously javascript has it's weaknesses but it would be nice to use the same language on the client and server side.

David McCabe — Aug 02, 08 6202

You can write your entire app in JavaScript. Thanks to JSONP and advanced systems like Orbited, it's now possible to have only a very thin glue layer on the server. You can talk to databases and to other sites directly from JavaScript. The browser basically becomes a Self runtime with free text formatting.

Shawn Lauriat — Aug 02, 08 6203

You cannot write the entire application (or even most of it) in JavaScript for many reasons. The largest of which have always, for me, remained performance and - most of all - security.

Even if you don't care about performance, you'll most likely want some authentication and authorization in your app at some point, and JavaScript in the browser (by design) gives you neither. Someone can easily open up a debugger, or even just view the source, and change the way your client-side application behaves. JavaScript obfuscation does nothing other than add a few minutes to the reading of the code, and shrinking the size of the download.

Unfortunately, for the developers (and those paying developers), this means developing a server-side application and an almost completely separate client-side application on top of that. This has certain benefits for larger, more complex web applications, but it does mean having a server-side MVC and a rather different client-side MVC. For more reading on this, I recommend starting with OWASP.

As far as SproutCore goes, it looks promising and tempting, but until it matures enough to handle the customization and accessibility requirements I have, I don't really have any desire to look any more into it (as such, I haven't a clue as to how it scales or performs).

For everything on which I've worked long-term, I've only used custom frameworks for both client and server, so I can't really speak to how well any particular framework integrates with any particular client-side framework. I think if I wanted to do so, I'd probably start my search by looking at the recent work on the Zend Framework and Dojo Toolkit integration, though.

Jacob Rus — Aug 02, 08 6204

Shawn: you clearly need to have auth/security *somewhere* for many applications, but this is no different for browser-based apps than for internet-using thick clients. A browser-based XMPP or IMAP client, or game, or whatever, can use the same auth that any desktop app would use for the same purposes. Especially once browsers have persistent storage, we will see more and more apps written mostly in the browser, using off-the-shelf server components.

Scott Stevenson — Aug 02, 08 6205

@Shawn Lauriat: Thanks for the insightful response. Very helpful.

@David McCabe and @Jacob Rus: I agree with Shawn's statement that you can't write the entire application in JavaScript. You need to have server-side glue unless you want to expose all of your infrastructure (passwords, schemas) and code to the entire world. Many don't want to do that. A thick client approach would be to have the server respond to specific services requests, which isn't necessarily out of the question here.

@Jonathan Badeen: Jaxer looks suprisingly cool, but it requires you to write raw SQL strings right now until they decide on an API. The most important thing I want from a framework is object-relationship mapping.

omygawshkenas — Aug 02, 08 6206

This is a very perceptive post, Scott. As more sophisticated Ajax-heavy javascript applications are developed, the desire for a thin server and fat client becomes stronger and stronger.

Oddly enough, it seems that with fat client webapps the latest craze in server-side web development, doing everything RESTfully, falls by the wayside first. You quickly get to the point where you'd like multiple updates and deletes across different client-side models to be synced to the server in the context of the same request, and to be able to take in a stream of server-side "push" updates (via polling or comet) and integrate them into the client-side models to keep everything up to date.

The next great javascript framework is going to provide a convention by which javascript models can parallel ActiveRecord ones, and when you update an attribute of a model in javascript, it does two things: Persists that change to the server, and fires off a notification (Cocoa-style) for any listening javascript views to update themselves. A large part of this work would be to figure out a data-interchange protocol for syncing client and server state that is flexible enough to emulate many restful requests inside of a single one, and promoting it with the aim of standardization.

Thanks, Scott.

Tammer Saleh — Aug 02, 08 6207

We hit the same problem you're describing while developing one of our Rails applications. We essentially wanted to be able to use our ActiveRecord models in the clientside code. To that end, we wrote Jester. Jester "mirrors" your models in the same way that ActiveResource does - by interacting with your RESTful controllers. This allows you to do things like "User.find('first', {name: 'billy'})" or "User.save" on the client side.

David Phillip Oster — Aug 02, 08 6208

The obvious answer is: just write the apps in Cocoa. Instead of a web app, write a web-enabled OS X application. When your program needs to talk to a server, use NSURLConnection to do your asynchronous GETs, POSTs, PUTs, and DELETEs. No need to compromise on the app side, and you get the full power of the user's machine for the user interface, with local processing and storage for offline use.

Server side, same deal: use you can write the whole server, or you can install the fastCGI module in Personal Web Sharing (Apache) and just accept requests. Once again, you have the full power of Cocoa available to you: Core Data, for example as a back-end data store.

Of course, there are downsides: the client only runs on OS X, and the server only runs on OS X. The big plus is you get up and running fast. Once it works, you have the leisure to decide if you want to rewrite it in something that opens it up to the rest of the world.

You'll still need to "write your application twice": a quality web app needs a server that can stand up to malicious clients, so every input has to be validated on the client, then validated again on the server, but at least since they are both Cocoa, you can use the same source code in both places.

I've actually implemented a small web app this way. The client was iPhone, so Cocoa was the obvious choice. The test server was the Mac on my desk. The deployment server was not a Mac, but once I had a working system, I translated the server code from Objective-C to C, and just compiled and ran that code on the deployment server.

Simon Richardson — Aug 02, 08 6209

I have to agree that a server side glue needs be written, but there is a better alternative to Jaxxer and that's Helma. Very robust and well worth a look if writing javascript front and back end is required. They're currently working on a version 2, which has some major improvements...

Scott Stevenson — Aug 02, 08 6210

@omygawshkenas: and fires off a notification (Cocoa-style) for any listening javascript views to update themselves

As far as I can tell, SproutCore thankfully has this part covered.

@Tammer Saleh: We essentially wanted to be able to use our ActiveRecord models in the clientside code. To that end, we wrote Jester.

Jester looks pretty interesting and I think it's probably the right direction in the long term for Rails projects. It's hard for me to evaluate at this point, though, because I'm not sure how all the pieces fit together. I'm sure it would be more obvious to me from the overview example if I was a Rails expert.

Although syntactically I think this is the right direction and that you guys have done some good work, my overall goal here is to find one complete package so I don't have to assemble them by hand. In other words, I think something like this needs to be integrated directly into Rails and managed under the same folks with the same coding standards and release schedule. This is just my opinion.

@David Phillip Oster: The obvious answer is: just write the apps in Cocoa

I'd love to do that, but it's completely impractical in this case. The audience is not nearly predictable enough. Although maybe your suggestion was to build a working model since I said "prototype". I may have not phrased that well. It's probably more accurate to say my task is to build a initial version.

@Simon Richardson: I have to agree that a server side glue needs be written, but there is a better alternative to Jaxxer and that's Helma

I took a look at the site. It seems to be written in Java with a JavaScript syntax laid on top. For my purposes, I don't want to use a Java solution.

Adrian Ross — Aug 02, 08 6211

You could use GWT and write the whole thing, client and server, in Java. No duplication of the data model, your calls back to the server are just regular method calls (albeit asynchronous) and you get to use Hibernate or some other ORM layer for database access. Or whatever takes your fancy really - there are so many libraries and frameworks available for Java.

On the client side, GWT takes care of the most of the cross-platform nasties for you, plus you can dip into JavaScript if you need to.

Finally, having compiled your code into JavaScript, you find GWT has also optimised and compressed it within an inch of its life.

You'd need Java hosting though.

Colin Barrett — Aug 02, 08 6212

You might want to check out Rhino. It's a Javascript interpreter written in Java from the Mozilla project. I believe it also offers a way to access Java classes from Javascript, so you could use those (ick) to talk to a database.

I really agree with you though, that this is a big problem with web applications.

Andrew Barry — Aug 02, 08 6213

I'd argue that regular applications are often a sea of interconnecting MVC applications.

eg a dialog box represents a little MVC island, involving the data that's being collected - and only when they choose OK (or hopefully a verb better representing the task), does the dialog's data get incorporated into the wider application's Model.

My own preference with web applications is to do as you consider - implement the server side as effectively web services (though not necessarily SOAP or XML based, my preference is JSON for complex data), and do as much of the application as makes sense client-side. Typically the only places that I'll do page transitions are when it makes sense from a backtrack/bookmark perspective.

If anything this makes security easier, because you at least have a well defined business logic layer, rather than having all those decisions intertwined with your user interface.

Scott Stevenson — Aug 02, 08 6214

@Andrew Barry: eg a dialog box represents a little MVC island, involving the data that's being collected - and only when they choose OK (or hopefully a verb better representing the task)

I don't think this is the same thing. The dialog box is in the same memory space as the rest of the app and can freely share data without serialization/de-serialization, is written in the same language, uses the same frameworks, and so on.

I realize that the client side is written in JavaScript by nature, and don't expect that to change. What I'm looking for is a server-side framework that at least does most of obvious stuff in terms of implementing ajax-style interactions without asking the developer to invent all of the glue themselves.

Rails has been a pioneer in this area, and it looks like Zend Framework (PHP) is integrating Dojo in the upcoming 1.6 release, which is currently at RC1.

Jeff Watkins — Aug 02, 08 6215

Scott, you don't mention whether your app has to function for visitors with JavaScript disabled. While this isn't a large portion of the internet population, it still represents about 8% (according to Omniture).

I believe very strongly that a Web application should work for all visitors whether they have JavaScript enabled or not. Of course, the luddites might not get all the fancy features��just try to use the image gallery on the Apple Store without JavaScript��but at least they can get some value out of the application. This philosophy means I've always had to essentially build two applications ��the static Web version and the dynamic Web version. Fortunately, the dynamic version is usually enhancements to the static version.

I suppose a lot of this is different when you are building something from scratch, but legacy environments also factor into how you build your app. As I've learned more about WebObjects, I've been increasingly disappointed. While it has some of the Cocoa coolness, it's very Web 1.0. In contrast, the more modern frameworks' ability to return JSON data or HTML mark up from the same request is fantastic.

If you don't need to consider non-JavaScript visitors, SproutCore might be the right tool for you ��it seems to excel if you're starting a Web app from scratch and you can completely ignore anyone who doesn't have JavaScript enabled.

I can't talk explicitly about what's going on with Coherent, but I can tell you that personally, I'm very keen to solve the server interaction problem. What I'd like to build is essentially Core Data on the client-side. Provided your server application supports RESTful interfaces, the client-side model would then be synchronised with the server.

I'm far more excited by Jaxxer than Helma, because like you, I don't want a Java environment. Jaxxer is built on SpiderMonkey, which is written in C. As a result, ISPs might be more willing to install it. I haven't been tracking the development of Jaxxer as closely as I'd like, but it sounds like they are tackling some of the server integration issues as well.

Mario Enriquez — Aug 03, 08 6216

Scott, would you please briefly comment the reasons you would like to avoid a java base solution for web development. I'm currently evaluating this approach, and would like to hear your opinion. Sorry for the off topic question.

Scott Stevenson — Aug 03, 08 6217

@Jeff Watkins: Scott, you don't mention whether your app has to function for visitors with JavaScript disabled

Fortunately, I think we can dictate that JavaScript has to be enabled (I think). Do you have any idea who the folks without JavaScript support are? Clearly Firefox is available for every platform and MobileSafari/WebKit seems to be leading the charge in the mobile space. Do you think these are these folks that have actively disabled JavaScript, or just have incredibly old browsers?

As I've learned more about WebObjects, I've been increasingly disappointed. While it has some of the Cocoa coolness, it's very Web 1.0

It was certainly designed in that era. I think Project Wonder (you can ask Angela about that one) addresses some of that. There's a page on the wiki that mentions an Ajax framework.

I'm far more excited by Jaxxer than Helma, because like you, I don't want a Java environment. Jaxxer is built on SpiderMonkey, which is written in C.

I was skeptical of Jaxer at first, but the web site changed my mind a bit. Until it has object-relational database access, though, it's not even an option for me.

Scott Stevenson — Aug 03, 08 6218

@Mario Enriquez: Scott, would you please briefly comment the reasons you would like to avoid a java base solution for web development

There are two reasons for me.

The first is that (in my experience) adding a Java virtual machine, a Java compiler, and an app server to the equation introduces a lot of complication and potentially a lot of resource overhead. Java can provide "robustness" that something like PHP can't, but it can also be complete overkill for small or mid-sized apps. Obviously, companies with a dedicated app server staff have an easier time.

Secondly, I don't really like working in the Java environment. I'm not saying the Java approach doesn't have value, it clearly does. Personally, though, I'm used to framing things using dynamic languages and the design concepts in Cocoa. That said, I could be convinced to use the Java language if the frameworks and design patterns were closer to those in Cocoa and Rails.

Ian — Aug 03, 08 6220

Scott, take a look at the Wicket framework for an interesting model. It's in Java, so you won't want use it directly, but I think the way that it handles Ajax is really interesting.

Each dynamic part of the code is a component, and is marked with a generated ID. When the user hits a button or link to initiate an action, it initiates a XMLHttpRequest that tells the server what action to perform on what component. Then the server re-renders each affected component and returns new HTML for the updated components, and the Ajax code just replaces the original DOM for those components with the new DOM.

So, the javascript code is very simple - it just sends a request, receives a chunk of HTML, and replaces the existing parts of the DOM tree with the updated parts. That makes the javascript part a very small part of the equation, and all the logic is handled server-side.

Ian — Aug 03, 08 6221

Looking back at the other comments, there is one other really cool thing about the Wicket model that I forgot to mention.

Once you have done the work to make each component addressable and updatable via an XHR, it's pretty easy to make the Ajax-enabled links work without Javascript enabled.

The only difference is that the href of each ajax link also encodes the component and action, and instead of asking the server to re-render the specific components, they hit a link that re-renders the entire page.

I'm probably describing it poorly, because it's very late and I have an extremely high BAC, but I'd strongly suggest you take a look at how it works.

Andrew Barry — Aug 03, 08 6222

@Scott: I don't think this is the same thing. The dialog box is in the same memory space as the rest of the app and can freely share data without serialization/de-serialization, is written in the same language, uses the same frameworks, and so on.

I'd argue that this was an implementation detail rather than a key requirement, but it's otherwise a distraction from the question at hand.

The core issue is how confident you are moving your business logic down to the client. If your data is well secured, then I'd argue that there's no risk going the whole hog and having everything on the client. If the data in the database was well secured, then I'd have no trouble opening up SQL access directly to the client, giving you the world's smallest server side component.

Alas most shared-hosting environments seem to be designed to not allow this - inasmuch as you usually only get a single database login with db admin privileges.

Oh yes, and PHP is truly horrible. Watch out for the magic quotes stuff.

Sean — Aug 03, 08 6224

I think when it comes down to it, any UI component can be viewed, in the academic sense, with the MVC glasses, as to the previous example of the Dialog box, if you open it up you can identify a View, a Controler, and a Model.

For what you are trying to achieve I would suggest that if you approach writing the client web app with MVC and look at the 'server side' as just another mechanism for accessing data i.e. Core Data, File, etc, you can design the web app with MVC. I take this approach when I build Flex apps at work. The Flex app itself relies on MVC, and the server side, which is REST like applies different design patterns as it does not have a UI. This separation of responsibilities helps me apply the correct design where needed and doesn't force me to fit any round pegs into square holes.

A little background on me, I write enterprise applications, some that are very large, and some that have an audience of less than 50, and This approach helps be with designing and building both applications regardless of the technology.

Scott Stevenson — Aug 03, 08 6226

@Ian: Each dynamic part of the code is a component, and is marked with a generated ID. When the user hits a button or link to initiate an action, it initiates a XMLHttpRequest that tells the server what action to perform on what component

Sounds pretty cool, and I think it's a good approach. The only challenge is the underlying platform, as you mention.

@Andrew Barry: I'd argue that this was an implementation detail rather than a key requirement

I'm not sure what you mean exactly, but the main reason I commented on the dialog box example is that I personally don't agree that "regular applications are often a sea of interconnecting MVC applications." Though to be fair, I don't really have enough context to know what you mean.

The core issue is how confident you are moving your business logic down to the client ... If the data in the database was well secured, then I'd have no trouble opening up SQL access directly to the client

This approach doesn't seem right to me. A lot of this is due to the fact that I, "well secured" is sort of a matter of perspective. It also probably helps to remember the context: a small company with little or no dedicated programmers on staff.

The sort of strategies that would be approriate for an internal enterprise app or even a public app with a dedicated technical staff has more options. In this case, the app needs natural barriers in place. One of those is not exposing raw SQL queries and internal structure in the JavaScript.

Oh yes, and PHP is truly horrible

As a language, I think it's actually pretty good. The problem has historically been lack of design patterns or built-in frameworks. The Zend Framework may change that. It certainly can't do the acrobatics that Ruby can, but it is a fairly dynamic language and is ridiculously fast, which puts it ahead of a lot of other options.

@Sean: For what you are trying to achieve I would suggest that if you approach writing the client web app with MVC and look at the 'server side' as just another mechanism for accessing data

In theory, I agree with this. In practice, I still actually have to implement each side using a completely different language, frameworks, etc. The main question I had when I posted this is: what do people do to unify the two separate worlds? The answer I've seen so far is that there really is no unification for the most part -- although things like Jaxer seem to be moving in that direction.

Scott Stevenson — Aug 03, 08 6227

A quick update: the two main options I'm weighing right now are Zend Framework and Rails, since both offer some level of integrated ajax support. A lot of people would say Rails is the obvious choice, and from a design perspective I agree. The catch is that pushing a Rails solution potentially means me involving myself in a lot more sysadmin work than I want to.

I know there are tutorials for getting Rails up and running using MacPorts and so on, but it's still potentially days of work mucking around with configuration files and googling for solutions to things. I'd rather spend that time working on the app itself. There's also a minor consideration of being able to reuse some PHP code (which is not setup to act a service).

The one potential saving grace here is Passenger, which promises a PHP-like level of deployment simplicity. If that is the case, then it may make Rails a practical solution.

Nick Caldwell — Aug 03, 08 6228

Fortunately, I think we can dictate that JavaScript has to be enabled (I think). Do you have any idea who the folks without JavaScript support are?

Well, at the very least, many users with visual disabilities. And you've got mandates from various governments that web software needs to be mindful of accessibility.

I'm not seeing any evidence that any of the new flash-bang Javascript UI libraries like Sproutcore are being built with accessibility in mind and it's not something that you can readily bolt on afterwards. Screen readers are currently pretty crummy at noticing the page has changed after a javascript event has fired so it's up to the developer to build semantically and accessibly first and then layer on the sexy interactivity.

At least on the desktop an app can rely on the OS's built-in accessibility functionality.

Scott Stevenson — Aug 04, 08 6229

@Nick Caldwell: I'm not seeing any evidence that any of the new flash-bang Javascript UI libraries like Sproutcore are being built with accessibility in mind and it's not something that you can readily bolt on afterwards

An excellent point, yes. It's not clear to me where this work has to be done, though. In Mac apps, the frameworks are largely responsible for providing accessibility infrastructure for the screen readers to use.

But something like SproutCore is in a different position: it's just providing HTML and CSS for the browser to interpret. I'm not sure if this is something a JavaScript library can enforce on its own, or if the browser has to take an active role in making the ajax behaviors accessible by screen readers.

meekish — Aug 05, 08 6230

Passenger deployment works well and is simple to set up. I use for it for all of my clients' sites. Here's a screencast for a Ruby tool that will provision a bare Ubuntu server with everything needed to deploy a Rails app. I'd say that Rails deployment is a problem that has been largely solved.

pete — Aug 05, 08 6231

In addition to Passenger, there's http://heroku.com and similar Rails hosting services.

Marc J. Driftmeyer — Aug 05, 08 6232

You can always use Cocoon 2.2 and Maven 2.0.9 with Cocoon's extension of MVC via Separation of Concerns.

You can swap out your choice of scripting languages and when JavaFX shows up you can easily plug that in as well.

http://cocoon.apache.org

Rob. — Aug 05, 08 6233

As a minor point, PHP5 is robust and stable. Has been for a good few years. Widely reporting problems such as the magic quotes and global registration of request variables haven't been a issue for years and years. (Unless you are using a very cheap hosting provider still using the old fashioned PHP4 I suppose.)

I think the main choices at the moment are Rails and a reasonably good PHP framework such as Zend Framework or Sympony. (I'm in the ZF camp personally). There's also Django which uses Python, of course.

One advantage to using PHP is that there's significant resources available now providing information on how to write a secure PHP appliction. I don't know if there is the same breadth of security information avialable for using ruby and python for web applications. On the flip side, the "cool kids" are using Ruby or Python nowadays, if that matters to you.

In terms of allowing usage without JavaScript, I'm of the opinion that this is still important for accessibility reasons. It's much easier to write an accessible website when JS is off than to write one when it's on. Also, search engine crawlers don't do JS, so you need to keep in mind what you are shutting Google out of too. (This may of course be irrelevant for your application.)

Whatever you do, make sure you have a debugging solution available for stepping through your code both server side and client side :)

Regards,

Rob...

Bill Shirley — Aug 05, 08 6234

I totally agree with you. The two layers and duplicated coding is quite annoying.

fousto — Aug 05, 08 6235

Looking at web development from a non - programmer!! I was able to really get some cool stuff working with WebObjects. Right when I got to a point where I may be able to
create a full blown Web/database app then of course Apple killed the java bridge and all the tools we had all been using. They let it go opensource and have just created a mess for everyone except total gurus. One of the problems I see in the industry is that all the tutorials are fragmented, much of the new technology is also fragmented or changes nightly because someone is always hacking on it. It also seems that everything made to work on Microsoft ends up having too many issues to deal with. Java seems to be sooooo ungodly huge that one can program in several directions and end up with the same result. Making tutorials almost impossible. So my point is that Apple has been very successful creating their entire system around Cocoa. The last pre-java release of Webobjects was 4.5 which was totally objC. (cocoa) It was nice when it only worked on Apple which is now why Apple should update it to CocoaWO and let the best ever web dev program live on.

Currently you can go back in time via SOPE or GNU/Step/Web which are trying to keep that dream alive. It is all objc

I have been playing with Netbeans Visual Web lately and have been making so progress. It is still not up to Webobjects but at least headed in the right direction.
I will begin with the database shortly and that should be quite interesting.

Dreamweaver was fun to play with as it has been around long enough for people to write tutorials that make sense for non-gurus. Currently my understanding is to do a database connect you would have to learn coldfusion or be quite proficient in Java.
Apparently the Gui tools die when you get to the db. I am not done looking at this so if anyone knows the best way to connect dreamweaver to a database please tell me.

There are several cool programs out that will let you visually design you pages and write all the HTML but once the word �dynamic� shows up the fun ends. For Mac users Stone�s Create program is one of the coolest out there and can built a total static website with NO programming.

meekish — Aug 05, 08 6236

fousto — Aug 05, 08 6237

Andre — Aug 05, 08 6238

Apache Cocoon has a very interesting set of patterns for web applications. It's written in java but you don't have to write any java if your model is just database access (CRUD). Cocoon is basically the swiss-army knife of XML publishing.

First, you make your view in XML/XSLT/Ajax library du jour. A sitemap file is used to wire patterns of your URL space to what you want to show, which allows a very high level of creativity.

Then the model: it can be simply querying data from a DB (use Database Actions or the SQLTransformer) or it can be accessing a WebApplication (in my case accessing session beans in my JBoss server).

To glue it all together: the controller. In cocoon, this is flowscript: server-side javascript allowing to write the app like a normal desktop app instead of a patchwork of scripts cobbled together in a finite state machine. The developers basically added continuations to Rhino to do things like sendPageAndWait(), which freeze-dries the program until the user answers.

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). The combination of Flowscript and something like SproutCore lets you organize your model-view interaction in many different ways, depending on the constraints you may have for each part of your app (reactivity, security, etc).

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.

Scott Stevenson — Aug 05, 08 6239

@meekish: Here's a screencast for a Ruby tool that will provision a bare Ubuntu server with everything needed to deploy a Rails app

Interesting. Looking at this now.

Scott Stevenson — Aug 05, 08 6240

@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.

nibble — Aug 07, 08 6242

You mentioned RoR and Zend Frameworks, but I can suggest to take a look at seaside.

This is a smalltalk web framework (obj-c takes a lot of idea from smalltalk, so this can be a good match for a cocoa developer).

One of the sweetest feature of seaside is the availability of an integrated debugger in the browser environment that you can use during development:
small screencast.

best regards
nibble

Elmar — Aug 11, 08 6245

I know that there probably won�t be a lot of love for this as it is based on ASP.NET but the simplest Web Development Model that I ever worked with is VWG.

It just works, has AJAX backed in for every operation and it�s base is OpenSource. No client side scripting or WebFormControls that need to be wired up with AJAX - all you do is write C# Backend-Code.

Sure it abstracts pretty much everything away from the developer but it makes web development simple, consistent and much faster. Not suited for every project and probably more suited for projects that imitate traditional desktop apps.

It uses the concept of empty clients which means that it treats the client as an empty shell and really just renders a dumb view that only knows how to talk back to the server to request a view change.

All UI design is done by simple element drag&dropping in the VisualStudio environment. As far as I know it also works with the free versions of VisualStudio.

I did several enterprise projects using this and I can say that it makes creating complex Web apps child play - at least compared to the usual PHP/Java/ASP.NET stuff.

lance — Aug 16, 08 6250

David Phillip Oster: The obvious answer is: just write the apps in Cocoa. Instead of a web app, write a web-enabled OS X application.

hi- more than one of my beautiful cocoa client apps have been rewritten into mediocre javascript/browser implementations. I cry every time I see it happen.

- lance

Juan — Aug 16, 08 6251

On the PHP side have a look on CakePHP, is a framework a la Rails (haven't try Rails my self) you can have the very ugly inline javascript code for the ajax automatically.

Scott Stevenson — Aug 16, 08 6252

@Juan: On the PHP side have a look on CakePHP

I looked at it briefly. Definitely interesting if going the PHP route.

Rusty — Aug 20, 08 6263

Sounds like you might like aap.net web forms with Ajax and now silverlight. That is the unified programming model: high pert, feature rich, etc. Inevitably, with such a thing, you findthe output incompatible with your reqs. Rails is the opposite: a commitment to mvc where v is whatever web thing u need and c is in charge. You are suggesting bringing c and v together. That is not a step in the direction of quality. IMHO

Scott Stevenson — Aug 20, 08 6266

@Rusty: Rails is the opposite: a commitment to mvc where v is whatever web thing u need and c is in charge. You are suggesting bringing c and v together

I'm not sure what you mean by this. Can you elaborate?

roamy — Aug 21, 08 6284

So let me get this straight?
David Phillip Oster says you can write the entire "ebay" application in Cocoa as a web enabled app and just deploy it on OSX Servers and it would work???

Could this be the return of WebObjects done properly??
thanks

Scott Stevenson — Aug 21, 08 6293

@roamy: David Phillip Oster says you can write the entire "ebay" application in Cocoa as a web enabled app and just deploy it on OSX Servers and it would work?

I'm not sure what you mean by "just deploy it on OS X Servers". You can absolutely write a Cocoa desktop app that talks to a server, and a lot of people do that. You also technically can write a Cocoa app which acts as a server (running on Mac OS X Server, for example), but it's far less common. It's fine for internal or test apps, but I don't think many people use it like that in a production environment.

You can create apps in other language/framesworks that call out into the Apple frameworks, though. Red Artisan has an article on using Core Image from a Rails app.

roamy — Aug 21, 08 6295

If you can write a cocoa app - connect it to a database - dynamically retrieve data from user input and display a webpage in xml then I can't understand what everyone is doing with all the other crap out there. what am i missing??

Matt — Sep 09, 08 6368

Check out appcelerator.org. Seems to offer an awesome way to bridge the gap between client-side Javascript and services (as in SOA) on the server-side. I think this is the future of the web...

...except for maybe long-running web apps that need to feel just like desktop apps, which is why I'm currently looking at Cappuccino.

Matt — Sep 09, 08 6369

P.S. I just saw that you're looking to implement something in PHP, which is also my interest. appcelerator supports PHP as well as an impressive array of other languages, including Java, .NET, Python, and Ruby

Scott Stevenson — Sep 10, 08 6372

@Matt: Check out appcelerator.org. Seems to offer an awesome way to bridge the gap between client-side Javascript and services (as in SOA) on the server-side

I read through this site quite a bit, and it's interesting in that it seems to be a different approach. That is, it treats the server as more of a services-centric data vendor and tries to do all of the formatting on the client side.

I don't necessarily disagree with this design, but I couldn't find any stand-out examples on the site that really sold me on the framework. The Overview page is a little bit vague and cites a number of things covered by other popular solutions.

In general, I want to keep my web app environment as "stock" as possible so that I don't have to watch over each piece and play mediator between them. This framework introduces another layer to the stack and a separate syntax. I'm willing to take that on if there's a clear advantage in doing so, but like I said, nothing jumped out at me.

For people that want to have more of the smarts on the client side, it's an interesting option. For me personally, I'd like some specific examples of what problems it solves, rather than just a dicussion of what service/message-oriented design mean in the abstract sense.

Scott Stevenson — Sep 10, 08 6373

@roamy: If you can write a cocoa app - connect it to a database - dynamically retrieve data from user input and display a webpage in xml

Hi, roamy. I'm still a little unclear on the details, but let me try to answer this in a more general way. The Cocoa desktop API is really tuned for desktop applications, and doesn't have a lot of the design decisions in place that would be good for backing a high-traffic site.

WebObjects is the closest to what you're describing, but it's based on Java now. There's nothing to prevent a third party from writing a service that sits in front of a desktop Cocoa app, but it's not clear if this would really be a good approach when there are so many other frameworks specifically designed for web apps.

Ringo De Smet — Dec 03, 08 6550

@Scott: Personally, though, I'm used to framing things using dynamic languages and the design concepts in Cocoa. That said, I could be convinced to use the Java language if the frameworks and design patterns were closer to those in Cocoa and Rails.

If you are still interested in hosting on a Java VM, but want more of the nice things of a dynamic language, have a look at Groovy and Grails. I have a background in Smalltalk, and I was quite delighted to find this language on the Java VM.

Oh, and on the application server side, a new kid on the block: SpringSource dm Server. It is not only limited to JEE, but it can also host a real server process. Packaging is based on the OSGi specifiacation, which is in the process of becoming a standard packaging model in the Java world.

I am writing a series of articles on the combination of Groovy, Grails and the dm Server product. The first article has been posted. The second article is in the preparation phase as I write this. Have a look at my blog and feel free to contact me for more details.

Joel Hooks — Mar 21, 09 6633

This is when I turn to Adobe and the Flex framework. I can write a proper MVC application that is independent of the awful cross-browser issues that plague a html/css/js stack.

This doesn't do much for your service layer, but again I feel the need to seperate this anyway. I've used Java, PHP, and Python service layers to access my data via AMF. All will return strongly typed objects and create a great stack. Java with LiveCycle/Hibernate is fantastic, as is Python/PyAMF/Django. PHP makes me ill, but it is the easiest to deploy, and ZendAMF is solid.

Land Rover Geek — Oct 22, 09 6966

I think you talk about Cappuccino and Objective-J somewhere else on this site. I think it is the best answer fitting your desires so far. If you used Google App Engine as the back end, you would still need to write in Java or Python on the back end. But depending on your app you might not need to do that much on the back end. So not a lot of coding there - do some in python to fetch and serve data requests from your front end, and put all the biz logic in the front end, which would be Cappuccino and just about like coding in Cocoa.

Comments Feed

Separation of Model and View Web Frameworks