Skip to main content

Spyce vs ASP.NET

A former co-worker asked me over IM,

What advantage, other than being able to use it on a Linux box, does [Spyce] have over the ASP.NET Model? Because I can tell you, with Visual Studio, I feel pretty productive.

I answered,

The main one is a significantly shallower learning curve. Once you know how the ASP.NET event model and page lifecyle work, you are set -- but you remember how "easy" that was for [our] students. With Spyce there is only one rule: handlers run before the rest of the page, in the order they were added. That's it.

And, of course, Spyce runs Python. This is significant: Python is addictive; once you start writing code in it, it's painful to use less-expressive languages. This is something most people won't get until they try it, unless maybe they are old-school Lisp hackers.

Now, Spyce isn't quite to the point where it matches ASP.NET feature for feature. But it's close, and getting closer. I checked in an authentication Active Tag earlier today that will be in Spyce 2.1. After that, the only thing I miss from ASP.NET is the (form) validation controls. That will probably also be in 2.1, and then what is Spyce missing? ADO.NET? No, thanks; any feature that has entire books devoted to it has a very suspect cost:benefit ratio. I'd rather use an ORM tool like PyDO. Master pages from ASP.NET 2? Already done. Weird-ass bugs caused by IIS misconfiguration? I think we can leave those out.

Comments

Anonymous said…
Okay, so what about things like ViewState? What about Caching? What about cache invalidation via database changes? I think right now that the biggest thing, and it may or may not seem big to some people, is IDE support. Now, Visual Studio is overkill for most things, but there are some productivity features that make coding things so nice. I don't doubt that dynamic languages are nicer than, say, C# or VB.NET, but at the same time, there has to be something said for code completion and other IDE features that make coding a more productive experience. No? I would love to try Python, but as it is now, there is NO time in my schedule to even spend an hour trying it - unless you are offering to demo it for me . . . :P
Anonymous said…
One other question, what about HttpModules and HttpHandlers? Is there a similar construct available?
Jonathan Ellis said…
To answer in reverse order...

You can do most things you'd use HttpHandler or Module for with a spyceModule. I blogged one example earlier: http://spyced.blogspot.com/2005/04/extending-spyce-with-spycemodule.html. As you'd expect, it's not 100% 1-to-1, but you'd use them for pretty much the same kinds of things.

IDEs have been the last excuse for many people to not use dynamic languages, and it's a very good excuse. But even without a top-notch Python IDE like Wing (wingware.com), I feel more productive in Python + Emacs than in C# + Visual Studio, or Java + Eclipse.

Caching to me falls into two categories: important, and unimportant. In the former category is caching data; all sites I have ever worked on have been database-bound, not python or tcl or C#-bound. In Spyce, this is the job of your data provider, e.g. PyDO or SQLObject.

In the latter category is stuff like "cache the output of this tag/control." In a very few situations this can be useful, and if someone wanted to step up and add this to Spyce I wouldn't object, but as I said above, 99% of sites have a data bottleneck, not a page-processing bottleneck.

Finally, the main purpose of ViewState in ASP.NET is to remember the "initial" state of your page so ASP can decide which handlers to fire on postback. Spyce deliberately chose not to go the event driven route, so it doesn't need that.
Anonymous said…
I think that data caching is incredibly important, and you can't get it just by using PyDO and SQLObject; you need to store the data somewhere, so you need some sort of
cache library. SkunkWeb has one built in,which is very convenient; you can cache data and output with fine control over cache duration. This is one thing I miss in many other frameworks, and it isn't particularly hard to do. (The skunk4 project, which is a deep dark secret, does factor the cache out from the framework as a whole).
Jonathan Ellis said…
Actually, SQLObject does manage a data cache; hopefully PyDO will as well, eventually. Maybe for 2.1? :)
Anonymous said…
Hey,

no big deal but that [[]] tags look a bit scary and more messy than their ASP < percentage equivalent (blogger doesnt allow this stuff to be posted, sorry).

Could we override it? It should be a couple of chars change in your code isn't it?
Anonymous said…
It's an iteresting arguement, but the fact is that when IronPython is at 1.0 toward the end of the year the .NET communities and the CPython communities may have the option of either.

IronPython 1.0, to the dismay of some hardcore MS haters, will be a inflextion point for three reasons:

1. It will not require the emacs/vim crew to use VS, and will allow the VS crew to use emacs/vim

2. It will have the standard (batties included) libraries to run most native CPython apps, so .NET developer can use the best of CPython

3. CPython developers can use the best of .NET

This day is coming... This is your future...
Jonathan Ellis said…
re syntax, there's already a "compatibility mode" -- see http://spyce.sourceforge.net/docs/doc-lang_asp.html

most people find that [[ ]] grows on them, though... it's significantly faster to type.
Jonathan Ellis said…
I think it's pretty optimistic to think IronPython will be out by year's end, but I hope you're right.

I don't see how they would get VS support in this late in the product cycle for 2.0, though. And 3.0 is a very long ways off.
Anonymous said…
Well, once u have IronPython i'm pretty sure SharpDevelop support will follow VERY soon.

Regarding the caching comment look what I've found:

pgpool is a connection server for PostgreSQL. pgpool runs between
PostgreSQL's clients(front ends) and servers(back ends). A
PostgreSQL client can connect to pgpool as if it were a standard
PostgreSQL server.

pgpool caches the connection to PostgreSQL server to reduce the
overhead to establish the connection to it.

Anybody using MySQL is just crazy! ;)
Jonathan Ellis said…
Connection caching (more commonly called "pooling") isn't unique to PostgreSQL, although it's slightly more important to use in a PG environment since (at least historically, I have no idea if it's still true) MySQL had lower per-connection overhead.
Anonymous said…
http://sqlrelay.sourceforge.net/
Anonymous said…
The person asking to change

[[

to

< %

must be kidding . . . I mean, [[ is WAY quicker to type, I would rather have that any day.
Anonymous said…
Jonathan, do you read Chris Anderson's blog? He just posted on the subject of dynamic languages and the hiring of the IronPython guy.
Jonathan Ellis said…
http://spyced.blogspot.com/2005/05/microsoft-ahead-of-sun-in-dynamic.html
Anonymous said…
Right . . . I knew that. My mind is going . . .

Popular posts from this blog

Why schema definition belongs in the database

Earlier, I wrote about how ORM developers shouldn't try to re-invent SQL . It doesn't need to be done, and you're not likely to end up with an actual improvement. SQL may be designed by committee, but it's also been refined from thousands if not millions of man-years of database experience. The same applies to DDL. (Data Definition Langage -- the part of the SQL standard that deals with CREATE and ALTER.) Unfortunately, a number of Python ORMs are trying to replace DDL with a homegrown Python API. This is a Bad Thing. There are at least four reasons why: Standards compliance Completeness Maintainability Beauty Standards compliance SQL DDL is a standard. That means if you want something more sophisticated than Emacs, you can choose any of half a dozen modeling tools like ERwin or ER/Studio to generate and edit your DDL. The Python data definition APIs, by contrast, aren't even compatibile with other Python tools. You can't take a table definition

Python at Mozy.com

At my day job, I write code for a company called Berkeley Data Systems. (They found me through this blog, actually. It's been a good place to work.) Our first product is free online backup at mozy.com . Our second beta release was yesterday; the obvious problems have been fixed, so I feel reasonably good about blogging about it. Our back end, which is the most algorithmically complex part -- as opposed to fighting-Microsoft-APIs complex, as we have to in our desktop client -- is 90% in python with one C extension for speed. We (well, they, since I wasn't at the company at that point) initially chose Python for speed of development, and it's definitely fulfilled that expectation. (It's also lived up to its reputation for readability, in that the Python code has had 3 different developers -- in serial -- with very quick ramp-ups in each case. Python's succinctness and and one-obvious-way-to-do-it philosophy played a big part in this.) If you try it out, pleas

A review of 6 Python IDEs

(March 2006: you may also be interested the updated review I did for PyCon -- http://spyced.blogspot.com/2006/02/pycon-python-ide-review.html .) For September's meeting, the Utah Python User Group hosted an IDE shootout. 5 presenters reviewed 6 IDEs: PyDev 0.9.8.1 Eric3 3.7.1 Boa Constructor 0.4.4 BlackAdder 1.1 Komodo 3.1 Wing IDE 2.0.3 (The windows version was tested for all but Eric3, which was tested on Linux. Eric3 is based on Qt, which basically means you can't run it on Windows unless you've shelled out $$$ for a commerical Qt license, since there is no GPL version of Qt for Windows. Yes, there's Qt Free , but that's not exactly production-ready software.) Perhaps the most notable IDEs not included are SPE and DrPython. Alas, nobody had time to review these, but if you're looking for a free IDE perhaps you should include these in your search, because PyDev was the only one of the 3 free ones that we'd consider using. And if you aren