views:

200

answers:

3

With the wide variety of web development frameworks that are available, there always seems to be a perpetual incentive to "try something new". Hence, some of us find ourselves trading one framework for another, never being entirely satisfied with the end results. Granted there will always be niches where a given web framework will serve perfectly. But, there are many who have settled on using C++, Java or C# for building, say, desktop applications. The same isn't quite true when it comes to web development applications. Joel Spolsky touches on this in link text.

Let's say if I were to build such a framework: what would the functional requirements be? The goal here is to list concrete functional expectations (defined succinctly for the sake of a stackoverflow posting, of course). The best answer will be chosen based on its number of votes.

Just to get everyone started, the following would is a partial list of requirements. Note, these items were intentionally left somewhat abstract with the intent that folks can derive more concrete items from them:

  • OOP Consistency: Seamless data exchange and native object representation between server-side and client-side modules: That is, given a function on the client-side: clientFoo() and a function on the server-side: serverFoo() one should be able to pass an object obj of any type T without requiring any marshalling:

    define clientFoo() { T obj = createObject() serverFoo(obj) }

    OR

    define serverFoo() { T obj = createObject() clientFoo(obj) }

This adds the requirement that native object representations must be the same on both the client and server side, including all composition, inter-class coupling, and encapsulation semantics. Basically, it should be entirely irrelevant whether a given class or a given instance resides on the client-side or the server-side.

  • Functional Consistency: Seamless functional and thread execution: One should be able to create a function on the client/server side and pass it over the boundary for execution. This includes uniform support for multi-threading (which should work consistently on both the client and server sides).

    • Multiple Application Session Interoperability: A perfect example here is inter-application "cut and paste" (as mentioned in the article pointed out above). I am not talking about trivial copying of text within the browser to another browser instance (or tab). What if one wants to paste say, a contact object in MySocialApp to YetAnotherSocialApp? This kind of inter-application data exchange is important.

    • Consistent cross-Browser compatible UI: creating AJAX "dialog boxes", progress indicators, tabs, etc should all be achievable using an API that is as seamless with the rest of the framework as the client/server integration discussed above. Oh, and yes, it has to work the same on all browsers (with browser distinctions being completely invisible to the developer).

Note: Just marked as community WIKI.

A: 
  • Complete View/Logic Separation: It should be impossible to code any programming logic in the view files. Here's a good argument for why this is a good idea.
Kaleb Brasee
+3  A: 

Personally, I think the next great web development framework will be "functional" in nature, i.e. it will use a functional language, and all of the views, controllers and such will be functional equivalents. We've already moved in this direction with Linq.

See Beating the Averages by Paul Graham, in which he describes how he was able to outsmart his competitors by building his web applications in Lisp: http://www.paulgraham.com/avg.html

Robert Harvey
+2  A: 

you are missing the important parts.

  • separation of your display logic from your code.
  • separation of data (published content) from your code base.
  • ability to run everywhere
  • how actively is the frame work being maintained.

so you need templates for your output, weather it be xml, or html etc.
a simple model view controller structure is handy
a good database abstraction layer that alows you to both template your SQL, and stop sql injection.
a lightweight footprint.
the ability to run on many different web platforms. (non propriatory are preferable) eg: Apache (PHP)
expandable across many servers: (maintenace of sessions etc)
be easily expandable.
be popular with the community.

cross browser compatibility will be determiend largely by your css, html, and ajax library of choice... which is completely different to you web development framework. You are better off not reinventing the wheel.. Choosing a javascript library is advisable. (eg Jquery)

a method of maintaining content in your applications and still alowing the code to be stored in repositories, and changed/rolled out on dev/test/ and production versions. Often the content gets mixed up in the framework, and it gets very hard to maintain development and continue publishing content. The separation of content and code is very important.

Bingy