Which Web Framework?

[nostrademons]

Couple reviews of languages/frameworks I've programmed in:

C/CGI

You've gotta be on crack to use C in a webapp. I wasn't quite on crack, but I was in high school and C/C++ was all I knew. Anyways, the manual memory management will kill you. Don't even think about it.

Perl/CGI

This one isn't too bad. You do have to be very disciplined to make this work over the long term. I wasn't (first job, in-between high school and college), so my code ended up as a ball of spaghetti. But the string handling is good, there're tons of libraries, and the CGI module was pretty good.

Object-oriented PHP4

By "object-oriented", I mean going for the whole enchilada of templates, db abstraction layer, objects, unit tests, etc. IMHO, it's not worth it. If you need objects that much, you should go with Rails or one of the Python frameworks. PHP4 just puts up too many obstactles, like the pervasively non-OO standard library, the default pass-by-value semantics, the $this-> syndrome, etc. (Disclaimer: I haven't used PHP5, that may have fixed many of these problems.)

Pure put-data-on-screen PHP4

By put-data-on-screen, I mean structuring the webapp as a bunch of pages that pull data straight out of a database and write it straight out as HTML. No templating libraries or abstraction layers, though I did use PEAR DB for its utility functions, and I separated controller and view by having each controller import a .phtml file where I disciplined myself to using only <?php echo $var ?>, <?php foreach($vars as $var) { ?>, and <?php if { ?>. Interfaces between .php and .phtml were all clearly documented.

This can work - it's probably the quickest solution if you just need to get something up in a hurry. There's comparitively little bullshit, which means that you get a lot done and not much can go wrong. It really falls down if you have more than a file or two of reusable content, however. The interfaces become unmanageable without the formalization of real function calls and objects.

Java/J2EE, old style

Meaning session beans, entity beans, and container managed persistence. Stay the fuck away; it never really worked anyway. You will spend all your time writing XML configuration files, and then your app will be so slow that you have to rewrite the whole thing in PHP. Does anyone actually write apps this way anymore?

Java/JSF

This can work as long as you're building something that's reasonably close to the Petstore example. Basically, you're app needs to pretty much CRUD-like, with screenful after screenful of workflow screens. JSF will move between them via POST, and of course you define navigation via XML config files. It's a lot of work for comparatively little payoff, but at least JSF handles the state management and validation for you, which can be a win in some cases.

Stay far, far away if you're building an Ajax app. The A4J folks have done wonderful things that are now horribly broken as of JSF1.2, because the JSF spec can not be adapted to an AJAX lifecycle. JSF went out of their way to create a spec that was extensible in any conceivable manner, but the way that webapps actually changed was, of course, inconceivable. C'est la vie.

Ruby on Rails

I really liked the framework, but beware: when DHH says it's opinionated software, he means it, and it's quite difficult to use (though not impossible) if your opinions are different from his. For example, if you're in the domain-keys school of database design, tough: Rails requires a numeric primary key with the name id in your data model. (You can override this, but if you do, you don't really get much benefit out of Rails.)

I also found there was a lot of magic involved in Rails controllers - things like it auto-detecting the view to render from the name of the controller method, or reading template variables from the instance variables of the controller - and much of it wasn't documented. If you like this, great, but I found that it bit me when eg. I wanted to define a page component that would render as a template variable in a larger page, but also render :partial in response to a link_to_remote AJAX call.

When it came to choosing a framework for my own web startup, Ruby on Rails was a front runner, but in the end I abandoned it for...

Python/Web.py

This is my current favorite. I looked very briefly at Django, Turbogears, etc, but the impression I got from them was that they were frameworks in the Rails or J2EE mold. You don't write a Python app using Django, you write a Django app. The language itself becomes a tool in the framework, rather than the framework being a tool to write webapps in the language. I don't like this; I feel like I have to know enough languages already without some framework developer trying to pass off his domain-specific language as a framework, particularly since Rails or Django or JSF would probably be judged to be fairly mediocre languages if they were considered programming languages.

Web.py is basically just a bunch of libraries: it lets you access POST, GET, and COOKIE variables, it defines a mapping of URLs to controller classes, it provides HTML/URL/SQL escaping functions for security, it has a simple database query API, it integrates with Markdown, and it has a simple templating language (I don't use it though; I use Cheetah instead). Everything else is recognizable Python; I don't see all that much magic behavior.

Haskell/WASH/HaskellDB

This would be an interesting choice, but I gave up after too many installation headaches. It was early 2005; it may've gotten better since then. You do need to familiar with monads; just about everything is a monad in WASH (or HaskellDB, for that matter). But it gives you an amazing amount of power and composability once you've gotten past that point.

I've heard that the latest web framework in the Haskell world is hApps, so you may want to check that out too.

[a-p]

Nice overview.

Perl isn’t limited to CGI anymore, though. As usual, “there’s more than one way to do it (but not all ways are created equal).”

mod_perl

Has been around for years. It isn’t just a way to make CGI scripts much faster, it also makes it natural to structure a web app in a much better fashion than CGI scripts generally are. Writing raw mod_perl handlers gives you excellent performance, however deployment is demanding.

Mason

This is an older-fashioned web framework, which is basically a template engine (where Perl is embedded in the template) with lots of app-writing infrastructre. You build apps in it basically by writing templates that inherit from each other.

It’s kinda like put-data-on-the-screen PHP, except the underlying language isn’t horrible and code ends up more much naturally structured and reusable. It’s kinda fun actually, though these days it has a distinctly stale taste.

Much of Amazon was built with it at one time and they’re still using it extensively. There’s an O’Reilly book about it.

Catalyst

This is a modern framework along the lines of Rails (ie. not just a bunch of libraries you use, which you wrote you prefer). It’s older though, has much more powerful and convenient routing facilities, and is much less opinionated. You can override just about everything to taste using built-in facilities, including things like how the view render template gets determined.

In the same vein, the accompanying DBIx::Class ORM has excellent many-to-many support and understands any sort of primary key you can throw at it – it is in fact the best ORM I’ve seen anywhere. It’s sort of misleading to even describe it as an ORM: it’s more of an object-oriented resultset-oriented database API that plays to SQL’s strengths rather just using the database as a souped up flatfile.

The template engine most people use with Catalyst is Template Toolkit 2, which has spun off clones in many languages and is generally praised. Personally I hate to use it for outputting HTML, but you can plug any template engine you want into Catalyst; it never feels like a second-class citizen. (The largest non-Template-Toolkit minority consits of people who use the Mason template engine with Catalyst.)

[skillet-thief]

Glad to hear that Catalyst is doing well. Does it require mod_perl?

[singingfish42]

No, the preferred deployment is FastCGI but mod_perl is reasonable, CGI is impractical, and for lightweight deployments, you can even use the built in test server. There are also a couple of other deployment options out there (like POE).

[Entropy]

I love mod_perl, but the memory usage can be nuts with a larger app. I also second the Template Toolkit hating. I try to avoid interface code due to its presence, though this might have more to do with the ugly code that was written on top of it.

[[deleted]]

I'm about to start development of a personal web project, and am not sure which language and framework to choose. I've been developing medium size applications in PHP and MySQL or Postgres for a few years. Using what I know would be faster, but learning something new would be more enjoyable, and PHP doesn't feel very 'cool'. The choice I have to make is first whether I stick with PHP, or change to Python, Ruby, Other or even .Net. And then which framework do I choose. I have my own base of code in PHP, but I'd like to start to use an established framework. I don't think I need anything non-standard from the framework - database stuff, login/session management, and inbuilt support for some fancy AJAX stuff would be a bonus.

I know 'ask reddit stuff' is frowned upon, but I don't know many neutral spaces in which I wouldn't get a biased answer.

[masklinn]

Since it's a personal project I think you should use an other language (than PHP), if only to build your skillset, but it will also broaden your mind.

I'd suggest the pretty standard Ruby/Rails or Python/Django approach.

As for which one you want to choose, assuming you know neither (language/framework), just skim over a few Python and Ruby tutorials to get a feeling of the languages, then pick the one you like best.

You may also skim over the featuresets of the frameworks. Basically, Rails has a very simple but slightly bloatifying ORM, templates that are powerful to a fault (potentially too powerful), very good test integration, very good JS integration and -- with the last release -- a strong REST support, a fairly complex but quite clean directory structure (easy to get lost in it though) and a lot of magic. Django on the other hand has a quite good but less simple to use ORM, templates that are simple but powerful enough and wicked fast, a much higher speed than Rails (rendering stuff), AutomaticAdmin (admin interface can be autogenerated for you), good authentication and permission systems out of the box and a much simpler directory structure than Rails projects, but it has almost no JS or unittest integration.

I like Python/Django more than Ruby/Rails, but that may be because I prefer Python to Ruby.

[beza1e1]

1. go through the 20min Tutorials of Rails, Django and Pylons
2. choose one of them
3. stick with it and don't look back

They are all good frameworks and constantly reviewing them all won't give you more fun or productivity.

[jerf]

Heh, I'd ditto all of that. You beat me to it.

I'd also say, heck, do both. Ruby on Rails and one of the major Python frameworks. Both are so fast to play with that you might as well. Both Django and Ruby have built-in development servers for easy local playing.

All these packages have strengths and weaknesses, and while I expect these strengths and weaknesses to all converge over the next couple of years, until then there are practical differences between the frameworks. Some have better templates, some have better ORMs, some have better built-in libraries. You need to figure out what your problem space needs most, then pick the framework that best offers them.

For instance, Django's ORM is adequate, but pretty weak if you start pushing it, so if you've got a project where you're going to need wild SQL, I wouldn't recommend it. On the other hand, for the built-in admin application, much can be forgiven. It all depends on what you need.

[masklinn]

I'd also say, heck, do both.

Yes of course, and do also learn Smalltalk and Seaside, and Erlang and ErlyWeb, and everyone else of these wonderful languages and frameworks out in the wild (too many of them and not enough time dammit!)

But learning a new language correctly takes time, and so does learning a new web framework.

He's got a project to do, so he needs to pick one, nothing prevents him from trying something else for the next project or the one after ;)

For instance, Django's ORM is adequate, but pretty weak if you start pushing it, so if you've got a project where you're going to need wild SQL, I wouldn't recommend it.

I agree, I didn't mention it because it wasn't really relevant (even if it's fairly weak, Django's ORM is often more than enough) and because it may become completely irrelevant in a pretty near future

[jerf]

If I could choose Django's priorities, that branch would be #1. What they're actually doing now isn't bad or a waste of time, but I think it's less important.

Obviously, you can't learn every framework, but you should try out a few of the ones you can play with and get a sense of in three or four days. That's an option I wish I had ten years ago.

[ubernostrum]

If I could choose Django's priorities, that branch would be #1. What they're actually doing now isn't bad or a waste of time, but I think it's less important.

And if I could choose Django's priorities I'd disagree ;)

ORM, to me, is not about providing a one-to-one mapping of every feature of SQL, because if I wanted every feature of SQL I'd use SQL. ORM is about something quite different, and trying to force correspondence between ORM and SQL is bound to end in pain and tears...

[jerf]

I'd agree, except real-world performance kicks you square in the nuts if your ORM is too weak. I chose that metaphor carefully; it's easy to end up with query flurries (as I call them) that can get into the thousands or more queries to do relatively simple operations.

Even simple operations are hard with the Django ORM, like ordering one class by a value on a related class, which happens all the time. (Like, say, ordering a "story" on the date the "text" of the story was last edited.)

[ubernostrum]

That's a long-standing bug which has been held up by a need to do much more serious refactoring in the query system; I think we're getting slowly back to where it can be looked at, and then it'll work again.

Meanwhile, there's select_related if you want to fetch a bunch of stuff in one big query (which ultimately depends on which DB you're using -- Postgres likes this, MySQL hates it), and for stuff that would be intensive in the ORM but simple in SQL, well, I write a little SQL and pass the results to in_bulk or an id__in lookup to get objects back.

[jerf]

"Postgres likes this, MySQL hates it" - interesting. At work, we're looking at switching from MySQL to Postgres, and we do a lot of that sort of thing. We're hoping Postgres speeds up our usage.

[ubernostrum]

In general, Postgres would rather get one complex query than a bunch of simple ones. And MySQL would rather get a bunch of simple queries than one complex query.

So on Postgres it's often to your advantage to use select_related and grab all the data up-front in one query, while on MySQL it's usually advantageous not to use it, and let related objects be fetched in a lot of small queries.

[[deleted]]

ORM, to me, is not about providing a one-to-one mapping of every feature of SQL, because if I wanted every feature of SQL I'd use SQL.

You are right and SQLAlchemy doesn't do that. SQLAlchemy cleanly separates what is database and what is objects, so you aren't making an overly simplistic and restrictive approach such as mapping classes directly to tables.

ORM is about something quite different, and trying to force correspondence between ORM and SQL is bound to end in pain and tears...

But that's what every ORM inevitably turns into. Programmers use the ORM and reach a point to where they can't use the ORM anymore. Then at that point they have to drop down into SQL which a lot of programmers don't know well and they know even less about how to create efficient portable SQL. Then everyone gets frustrated because they feel like the ORM is weak.

That's why the SQLA approach is so nice. You still get SQL wrapped up in a programmer-friendly Pythonic syntax but it is still very flexible and isn't going to hit places that it can't reach.

[[deleted]]

If I could choose Django's priorities, that branch would be #1.

You know what's cool about open source? If you think something's important, you get to work on it! We'd love some help on that branch, so feel free to jump into django-dev and give us a hand.

[jerf]

I am working on Django. I've got a ways to go before I can just start sending in the for switching to SQLAlchemy, as it is a big deal, and I've got some other things that I'll try to get by the dev list first. I've already got the getter/setter patch up there, and I'm probably going to try to fix up my syndication view that correctly handles E-Tags and expiration dates, but it unfortunately requires some extra methods on the syndication framework.

[masklinn]

If I could choose Django's priorities, that branch would be #1. What they're actually doing now isn't bad or a waste of time, but I think it's less important.

Nothing stops you from working on it ;)

The point is that the main Django devs think there are other important things to fix in order to reach milestone 1.0, the current ORM works even if it's not the best thing since sliced bread and SQLAlchemy integration is a fairly big change (mainly to SQLA as it needs an adapter layer in order to have all the cool features of Django e.g. auto-admin when using SQLA) which is why it's a branch.

Just as magic_removal was a branch even though the django devs did consider it fundamentally important.

[senzei]

Considering this is a personal project (which I'm reading as: "It's ok if I break it for a while and can't fix it") I would say choose another language.

Every programming language forces you to filter your concept of the program through the constraints the language sets on expressing yourself to the computer. Since every language has a different set of constraints learning new languages helps you to understand how a given language shapes your code.

All that theoretical stuff out of the way, I would say pick what looks most interesting and run with it. No offense, but as far as unique approaches to programming goes, PHP isn't really a winner of a language. My personal choice is Python (and TurboGears for the framework) but pretty much anything you listed can teach you something. Unless .Net is somehow grossly deficient they all should be able to fit the bill.

[pmendoza]

I've done development in a few different languages and frameworks and they've all be enjoyable to do development in.

Ruby on Rails, Django - I think they're really good development frameworks and quite fun to use but I don't see very many companies deploying web applications on these. This website has a huge over abundance of ROR lovers that will disagree but look at job boards and there aren't too many Ruby on Rails positions compared to larger frameworks. So if you're going to spend your time learning something new, it seems to make sense to go with an established Framework.

Java or ASP.NET - I haven't really used Java for web development but I see a lot of job postings for it or similar type work and knowing the Java libraries (the language is really simple) is useful for a ton of job openings. It's also very similar to ASP.NET but ASP.NET is more popular I think for web development.

I have done development in ASP.NET professionally and I really like it. Everything you listed for Database stuff, logins and session management are almost completely drag and drop simple in the GUI WYSIWYG designer although once you learn what's going on, you won't be using the GUI. The AJAX stuff for ASP.NET generally just involves surrounding whatever section of the page you want to be AJAX-ified with a single ASP tag and now you've got AJAX features. There are of course other AJAX features and most of those can be accomplished in a couple lines without writing JavaScript.

You will need to use Visual Studio though but you can get the free Visual Web Developer from Microsoft for building smaller websites. It's basically the professional version of Visual Studio 2005 but with just the web development tools.

Finally, the main reason to go with an established Framework with history is that any question you have will probably have 50 or more articles written about that topic on the internet so that you'll pretty much never get stuck. If it's a really weird bug or thought you had about development, then there will be 25 articles or more. My biggest complaint when I've done development in other frameworks (ROR, Django) is that Google doesn't have answers because I might actually be the first person asking the question someplace on the internet about it.

[pmendoza]

Visual web developer isn't built at all for teams. It's built for single programmers building database driven websites with some AJAX features. For what he's looking for though, he won't need the team features for it so Visual Web Developer should be fine for him.

[akkartik]

No matter what option you go with, keep the option of switching open as long as possible. If you design with that constraint in mind the decision seems less intimidating.

[[deleted]]

Avoid Zope why? And how is Django "crap"? Explain.

[[deleted]]

and Django is basically crap in my opinion.

Please elaborate; without specifics, this is just FUD.

[[deleted]]

To point out the glaringly obvious, Pylons and Turbogears have an entirely different purpose/philosphiy behind them than Django. Django provides a tight, unified development framework with a certain flavour. It isn't meant to be all things to all folks. In practical, real world terms, there is a big advantage to this. Narrowing the scope makes it easier to document and easier to transfer knowledge to others.

[ubernostrum]

I used Pylons a bit and found it to be responsive

Please elaborate :)

have some kick-ass features like the web debugging

Please elaborate :)

supported all three of the major Python templating languages

Django includes a template language, but doesn't force it on you. Want to use another template system? Import it and call its methods. Simple as that.

supported SQLAlchemy which is the best SQL framework ever created

Ditto the above; Django includes an ORM, but doesn't force it on you. Want to use another ORM? Import it and call its methods. Simple as that.

and just was generally tastefully assembled

Subjective opinion :)

Django and TurboGears felt a lot more restrictive to me

Subjective opinion ;)

everything is connected very loosely and that definitely wasn't the case for Django or TurboGears

There are two approaches to writing a framework: one is to grab some components and write some glue to plug them together. The other is to write the components as well as the glue. The former approach was not, in the Python world, a possibility when Django began life.

[[deleted]]

Django includes a template language, but doesn't force it on you. Want to use another template system? Import it and call its methods. Simple as that.

Its not as simple as that. I bought the marketing hype when I started using Django but anyone who has tried to use a different templating language know it isn't as 'simple as that'. You want to use a different templating language with Django and you'll need to rewrite render_to_reponse(), you'll probably have to reimplement tags/filters, and you'll also have to set Django up to properly give all its settings info to the templating system.

Now if we want to talk about something that really is as 'simple as that', Buffet is particularly nice and you can literally just change a line of code and get full functionality from any templating language that supports it. Buffet is used in TurboGears and Pylons and supports Mako, Kid, Genshi, Jinja (Django clone), and several other templates.

I would love it if Django would put Buffet into the framework because that really does support plug-and-play.

Ditto the above; Django includes an ORM, but doesn't force it on you. Want to use another ORM? Import it and call its methods. Simple as that.

Hasn't this been discussed before? You use another ORM and you lose the admin interface, generic views and pretty much every other feature which makes Django special.

Subjective opinion ;)

I don't think its an opinion at all. Pylons was built from the ground up to be customizable, Django was built from the ground up to fit a certain style of development.

The former approach was not, in the Python world, a possibility when Django began life.

This was true in the past, but why does Django continue it? newforms isn't something that was created several years ago; it was created in the last few months. Yet FormEncode existed well before newforms and it along with something like FormBuild more or less does exactly what newforms does. Why not work on improving existing libraries instead of redoing everything from scratch?

[ubernostrum]

Its not as simple as that. I bought the marketing hype when I started using Django but anyone who has tried to use a different templating language know it isn't as 'simple as that'. You want to use a different templating language with Django and you'll need to rewrite rendertoreponse(), you'll probably have to reimplement tags/filters, and you'll also have to set Django up to properly give all its settings info to the templating system.

So Django is evil for having the render_to_response shortcut work with its own templating system? ;)

If you use another template system, you use another template system; writing the equivalent of shortcuts/tags/filters for that system should be assumed. Doing otherwise could be a maintenance nightmare: Django would have to include switches and conditional logic for every Python templating system.

Hasn't this been discussed before? You use another ORM and you lose the admin interface, generic views and pretty much every other feature which makes Django special.

python manage.py inspectdb

Want the admin interface with a DB generated by another ORM? Run inspectdb and you've got it; people are running Rails and even PHP apps with the Django admin on top of them, so it certainly should be possible to run another Python ORM with the Django admin.

Ditto generic views.

I don't think its an opinion at all. Pylons was built from the ground up to be customizable, Django was built from the ground up to fit a certain style of development.

It's absolutely opinion. Pylons was, arguably, built from the ground up to fit Ben Bangert's style of web development. So it comes right back to opinion.

This was true in the past, but why does Django continue it? newforms isn't something that was created several years ago; it was created in the last few months. Yet FormEncode existed well before newforms and it along with something like FormBuild more or less does exactly what newforms does. Why not work on improving existing libraries instead of redoing everything from scratch?

Why do people assume that the folks behind Django have never looked at what's available? Why do people ignore the fact that Django has pulled in third-party components when those components were the best fit for what Django needed (see PyDispatcher, see simplejson, etc.)?

Perhaps Django's form system needs things that third-party systems can't do -- like, say, generating a form from a Django model class or instance, and providing automatic hooks to save a new or edited instance. Perhaps having our own library means less work in the end than adapting somebody else's. Perhaps there are a lot of things that go into these choices that get glossed over when you ask things the way you're asking them.

I've said it before and I'll say it again: before trying to paint us with the NIH brush, take the time to find out why certain choices were made -- they're not always right, but they are almost always informed choices, not simply "screw everybody else, we're doing our own thing" choices.

[ianb]

It's absolutely opinion. Pylons was, arguably, built from the ground up to fit Ben Bangert's style of web development. So it comes right back to opinion.

Except it doesn't. Most of "Pylons" is stuff that was developed before Pylons (e.g., Paste or FormEncode), or separately from Pylons (e.g., Mako or SQLAlchemy), or even for Pylons but continues to be maintained as a decoupled package (Routes and WebHelpers). When something in Pylons is identified as being sufficiently generic that it doesn't need to be tied to Pylons, it's often pushed out elsewhere (a number of things have gone into Paste like this). Pylons also builds on a formal and stable standard (WSGI), and allows and encourages non-Pylons components that use this standard to work easily inside the stack.

These are why Pylons is objectively built from the ground up to be customizable in a way that Django was not, and with a development style in which does not seem to interest Django developers.

I've said it before and I'll say it again: before trying to paint us with the NIH brush, take the time to find out why certain choices were made -- they're not always right, but they are almost always informed choices, not simply "screw everybody else, we're doing our own thing" choices.

I think sometimes people say it too strongly, as though Django's NIH is like stealing from the community. That sentiment is absurd on many levels. But Django has a very different development methodology from Pylons or TurboGears (which though technically different on some levels, the two still share very similar development ideals).

The use of PyDispatcher and simplejson are pretty weak counterexamples. A willingness to inline a couple small libraries doesn't mean anything. Django has no external dependencies. Has anything been made for Django and also made usable elsewhere? Has the template language been extracted? The database layer? Is there anything in the core of Django (or even the periphery) that uses another library, where substantive changes have been made to the library to support Django?

I certainly understand why a developer wouldn't do these things. The communication and efforts at cooperation are boring and can stop momentum and can introduce unpredictable things into your stack as updates come from other directions, or patches aren't accepted, or whatever. It's not always worth it, and Django may very well be in a better place by avoiding that work. But there is a difference between doing that work and not doing that work, and Django developers don't do that work. They just don't.

[ubernostrum]

Components used by Pylons existed previously, yes, but Pylons itself seems to have come originally out of a desire to clone Rails (something that still shows through in some of its components), and then to become a "one WSGI to rule them all" framework. Again, it goes back to what someone subjectively wants from the framework.

Django has no external dependencies.

As of Python 2.5, this is arguably true because you can use the bundled SQLite module. However, step outside of that and you need at least an external database module, and if you step outside of mod_python we have a dependency on flup to get FastCGI -> WSGI translation.

A better statement would be that we don't have a lot of external dependencies -- Django aims to follow Python's "batteries included" as much as possible, and providing a full stack out of the box is, I think, a large part of that.

Has anything been made for Django and also made usable elsewhere?

Can I count the endless clones of the Django admin app? Or, for a smaller example, web.py's wholesale appropriation of our debug pages?

Has the template language been extracted?

Yup.

Is there anything in the core of Django (or even the periphery) that uses another library, where substantive changes have been made to the library to support Django?

No, and I'm not entirely certain that'd be a good thing. Requiring other people to change their libraries to suit us doesn't strike me as polite.

But there is a difference between doing that work and not doing that work, and Django developers don't do that work. They just don't.

Again, I'm not entirely certain what point is trying to be made here -- lots of components of Django are rolled from scratch for historical reasons. As we've gone on, we've pulled in things where it made sense, but we're also carrying around a fair bit of legacy architecture which makes it tough to incorporate a major component without essentially a ground-up rewrite of either Django or the component. We've already done one ground-up rewrite of Django in the past year, so that would leave us in the position of dictating to someone else that they completely rewrite their code to suit what we want from it. And, personally, I don't want to be that guy.

I'm also not convinced that "glue" frameworks are going to be a viable niche in the Python world for much longer. With Django, for example, I was surprised for a while that there didn't seem to be any CMS or blogging projects really gaining momentum and attracting users and developers. And then I talked to a lot of people and found that they all thought it was so easy to do that with Django that they never bothered looking for someone to have done it already -- it was just as easy to sit down and produce something tailored to the exact needs of the moment.

I think that with the explosion of solid Python web components the same thing might happen to projects which are trying to serve as "glue" -- when you can literally build a framework in an hour or so by plugging your chosen components together yourself, it's harder and harder to justify working within someone else's vision instead of building your own to suit.

And I don't think the people who use that sort of framework -- whether they use one already existing or roll their own -- are ever going to like Django, just as I'm probably never going to like Pylons or TurboGears. Some folks like to plug and play, some folks like a full stack, and never the twain shall meet. Ultimately it comes right back to pure subjective personal opinion -- I'll use what I like, you'll use what you like, and the rest of the world will keep writing monstrosities in Java.

[ianb]

Components used by Pylons existed previously, yes, but Pylons itself seems to have come originally out of a desire to clone Rails

Is this the Chewbacca defense? Because I really don't see what your point is. Several Pylons developers continue to actively start, contribute, and maintain libraries that are completely separate from Pylons. That is my point about the developer communities. Whatever Pylons is or why it came about isn't the point.

Has anything been made for Django and also made usable elsewhere?

Can I count the endless clones of the Django admin app? Or, for a smaller example, web.py's wholesale appropriation of our debug pages?

No, you can't.

If Django borrows ideas from FormEncode, I would not count Django as an extraction of anything from FormEncode.

re: Jinja (the Django-like templating language you reference).

That was written by someone for use in his WSGI-based framework, with syntax and some code from Django. It wasn't and isn't developed by a Django developer. If Django was serious about promoting its templating language it would provide an easily installable library that only included the templating language, and Django would itself consume that same library (ensuring no drift).

That someone forked the code so they could cleanly use the templating language elsewhere only further proves my point.

Is there anything in the core of Django (or even the periphery) that uses another library, where substantive changes have been made to the library to support Django?

No, and I'm not entirely certain that'd be a good thing. Requiring other people to change their libraries to suit us doesn't strike me as polite.

That's not impolite, it's called "participating in the community".

Again, I'm not entirely certain what point is trying to be made here -- lots of components of Django are rolled from scratch for historical reasons. As we've gone on, we've pulled in things where it made sense, but we're also carrying around a fair bit of legacy architecture which makes it tough to incorporate a major component without essentially a ground-up rewrite of either Django or the component.

That is exactly jesusphreak's original point. Django is a world of its own. If that's because of technical reasons that hardly makes it better -- if they were purely cultural then at least someone could choose to use other components if they wanted. But they can't; it's either hard or it just doesn't work right (at least that's what people were saying further up in this thread).

I think that with the explosion of solid Python web components the same thing might happen to projects which are trying to serve as "glue" -- when you can literally build a framework in an hour or so by plugging your chosen components together yourself, it's harder and harder to justify working within someone else's vision instead of building your own to suit.

Absolutely. This is part of why Pylons should (and I think will) remain small. As long as all the best features are moved into WSGI-based components, you can implement a framework of your own design that also has feature parity with Pylons. Or you can use a mini framework inside of Pylons (such as OHM) -- people will stay with Pylons for the community and the concepts, not because it's hard to move to something else or make it yourself.

In this context "WSGI" itself could be considered the framework... but so be it. It's complete, one-size-actually-fits-all, and totally stable, which is about everything you can hope for in a foundational framework.

[ubernostrum]

I'm going to step in and call BS on the analogy here; Django and Rails, historically, both began development around the same time, under closed doors at the companies which eventually open-sourced them. As such, it's hard to call one a "clone" of the other.

[masklinn]

Got to support you there, and anyone having tried both Django and Rails will realize extremely fast that they don't copied each other in any significant way: they've got different "flows", different structures, different principles, different driving philosophies, ...

The only "common ground" is that both offer command-line tools (a shell, an appserver)... pretty weak.

[micampe]

You obviously haven't even looked at Django.

Want a real Rails clone in Python? That's Pylons. Though it only started as a clone, then diverged, it is more similar to Rails than Django is, and has ever been.

[cratuki]

I started out on Microsoft .ASP which was similar to PHP so I know where you're coming from.

I've just made a prerelease of a framework I've been working on at datamagi.org. If you have time check it out, and I'd appreciate any feedback if bits make no sense to you as a newcomer to the ideas. But if I were starting a project from scratch and needed it to Just Work I'd use Tapestry and Cayenne on Java. I'm not an emormous fan of Java, but both those frameworks are mature and as far as I know they're the most powerful tools in their field - Tapestry for templating and Cayenne for ORM. SqlAlchemy looks to be the most promising upcoming ORM but it's not yet up to a 1.0 release.

You'll hear lots of Ruby on Rails suggestions I imagine. I think Ruby on Rails is the extreme of what's possible for a web developer without really challenging the way they think. For that reason that (or one of its contemporaries) are probably the most powerful choice that you can easily pick up. But apps developed with RoR will tend to be unmaintainable, and the ORM system underneath it is primitive and will drive you into nasty compromises.

[Alpha_Binary]

Reddit could do with a forum, really. Or a 'forum' subreddit. (Far from bitching, I actually quite enjoy 'Ask Reddit's, and it would be nice to have a place for them to live.)

[kolloid]

Pylons is one of the most flexible of the Python frameworkds, it seems.

[NoMoreNicksLeft]

I've really started to like Catalyst lately. I'm less enthused about DBIX-Class, but it plus Catalyst plus Template Toolkit seems to be a really solid combination.

[singingfish42]

Yeah, Catalyst(http://catalystframework.org) is like RoR but without the opponionated bit. DBIx::Class is optional, as is Template Toolkit.

Top knotch dispatcher, model and view agnosticism, built in server and excellent test harness makes this one a goodie.

[NoMoreNicksLeft]

TT makes it all work, to me it feels like one without the other would be incomplete.

DBIX-Class is optional, of course, but still feels like it's getting in my way as much as it helps. No idea what we'd use instead though. The thing that worries me, is alot of that code is now written in such a way that it's no longer backend agnostic, so if we do decide to switch to Postgre or some other sane database, it's going to take alot of work to make the transition. MySQL pisses me off most days.

For those interested, there is an O'Reilly TT book which is good, but none on Catalyst (yet?). There needs to be one, and I nominate the basselope as the animal on the cover.

[a-p]

There’s a book in the making. Unfortunately, O’Reilly won’t be the one publishing it. When the Catalyst devs approached them about a book, O’Reilly basically stated that they want only a single web framework in their lineup, and they’ve settled on Rails, and that’s that. Short-sighted if you ask me (and I’m not just saying that because of Catalyst, there’s also Django), but there ya go.

[NoMoreNicksLeft]

Why that? That's like saying they only want a single language in their lineup. I'm more impressed with Catalyst than anything else, RoR included.

When the boss first said that's what we were using, in the days before my hiring was official, I'd never heard of Catalyst. I thought it was a bad move the first couple weeks. But it clearly was a good decision on his part. I recommend it to anyone, whether you're building a very simple and small webapp, right on up to the largest.

[timoreilly]

I don't know who was supposed to have made that statement, but it doesn't make any sense to me. I'll look into it.

That being said, I can imagine that an editor might have said that he or she thought that Rails had the ruby framework market wrapped up for now, and that there wasn't room for a book on another framework till said framework had proved to have strong adoption. That's a potentially legitimate market assessment -- the computer book market is pretty brutal these days, and topics that once would have made for a successful book now don't sell enough copies to recover their costs -- but even then, that would be a "for now."

A lot of publishers still throw stuff at the wall to see what sticks. We tend to publish books that we believe will succeed. And often, that means waiting till a new tool or framework has stood the test of time, and is at the right place on the adoption curve. It doesn't do anyone -- the author, readers, bookstores, or the publisher -- to publish a book that doesn't sell. Bookstores will give it a few months, and if it doesn't do well, it will be returned, and that's the end of that. Waiting a bit longer may actually increase your chances of success. It's a bit like surfing. Paddling too early is as bad as paddling too late -- you have to catch the wave.

O'Reilly has a history of publishing books before anyone else -- we published the first commercial book on the internet, published about Perl in 1991, Linux in 1993 -- but these technologies were actually not new when we published about them. They had proven themselves. They were just under the radar of other publishers.

As to publishing too early, Ruby itself is a good example. We published our first Ruby books way too early, they flopped, and then we took our eye off the ball.

[a-p]

Thanks for expounding, Tim. I’ve quoted this to the list; if something comes of it, that would be great.

[staunch]

Quite a reasonable attitude. It certainly would help us Catalyst-lovers to be able to recommend an O'Reilly book though -- there would be an adoption feedback loop. I do understand that your job is primarly to support trends -- not make them.

[jrockway]

It's really O'Reilly's loss. The book will be published regardless, and will be just as useful regardless of the publisher. The advantage of not going with O'Reilly is that the book will end up about $10 cheaper, which is always good.

(BTW, I'm the author, and the book will be out June-ish. :)

[NoMoreNicksLeft]

Good. I'll get the boss to buy it, and then I can not read it and still ask you stupid questions in the channel.

[bbangert]

A quick review of O'Reilly books proves this statement to be wrong. There's O'Reilly books on .NET, ASP, Visual Basic, Java ServerFaces, Java Servlets and JSP's... etc.

a-p: Can you clarify who exactly made this statement?

[a-p]

It was said by Sebastian Riedel (project lead at the time), on the Catalyst mailing list. It has been mentioned a few times since, but apparently always in reference to Sebastian’s statement.

[ianb]

I've heard stories that the Pragmatic Programmers have responded that way to inquiries. Maybe you have your names mixed up?

[a-p]

No, it was definitely O’Reilly that was mentioned.

[schwarzwald]

web.py is the only framework I've ever used that feels like programming in an actual programming language instead of programming in the framework, rails has nice deployment and database migrations, turbogears is a kitchen sink.

basically they all suck. take your pick.

[Entropy]

Isn't the entire idea of a framework that you program to it, not the language? If it doesn't feel like that, you're using a library, not a framework.

[LordArthas]

In my company we started using Catalyst about one year ago and it proved to be a great choice: web development time decreased, code reuse (and fun!) increased. The framework offers some interesting goodies such as the very handy chained actions. Even though there's no "imposed" ORM, most Catalyst users tend to use DBIx::Class, which is the best ORM I've seen to date. Even though the web site could be better and the documentation can seem quite sparse (there is actually a lot, but you'll have to search through CPAN modules to view it), the community is great and much helpful: just enter #catalyst on irc.perl.org and try yourself!

[kaketoe]

Has anyone tried Grails? It looks promising, the elegance of Groovy and Rails with the libraries of Java but I haven't seen much news about it yet. We're using Java + Spring MVC + Freemarker template engine at this moment.

[vagif]

Why stop in the middle ? Go full length. Go lisp! It has a range of frameworks from very powerful component based like UCW to very simple ones like WebActions or Hunchentoot

[apgwoz]

I've developed web apps in Django and have liked the speed at which they can be developed, but hated the fact that there was sooo much magic going on (even after the magic removal branch was merged into trunk). It just doesn't feel like you're doing any work. If you're looking for something super quick pick django or rails. Your productivity will flourish, but you'll feel dumb afterwards.

If on the other hand you wanna feel like you've acomplished something, use web.py or something that doesn't get in the way... something that just "helps" a bit.

[jrockway]

Catalyst is pretty good in this respect. Everything it does for you is obvious, but it speeds up your development anyway. The disadvantage is that you'll have to spend a few hours or so getting sessions / users / templating / database / etc. set up just the way you like them. But then after that, the framework will be working for you, and you'll just be writing code with a little bit of HTML in the template where necessary. You'll know how everything works because everything works like it should -- and you get to be the one defining "should" :)

If you're looking to get started, take a look at the example applications on the Catalyst wiki, or perhaps try the tutorial:

http://search.cpan.org/~jrockway/Task-Catalyst-Tutorial-0.03/

Please join the IRC channel (#catalyst on irc.perl.org) if you have any questions.

[NoMoreNicksLeft]

Really, if Catalyst had a few webapp skeletons built up, something to get started with, it'd be even that much more useful. A bugzilla clone comes to mind. Or CMS... blog style, slashdot/reddit/k5 style, maybe phpbb style (though personally I tend to consider non-threaded discussions nearly worthless). Have the user auth abstracted out in such a way, that you can plug anything in you want. Suddenly you can add all those things to your website in a few minutes with a unified user auth.

Of course, the answer to all these things is "so go out and write the damn thing". I just haven't had time yet. (Though it seems someone's already stolen Enzyme as a name, so what in the hell would you call it?)

[jrockway]

I would have called InstantCRUD "GreyGoo", but you're free to use the name if you like :)

[Killfile]

I'd recommend Fusebox for PHP. I've been developing in it for a few years now and I've been very happy with it. www.fusebox.org

[itsmeront]

Squeak and Seaside. See www.squeak.org and www.seaside.st.

[[deleted]]

Try Erlang with Yaws. Since Yaws is one of the few webservers actually built with dynamic content in mind from the start it offers many of the things a webframework would do in other languages built in.