While this is interesting, comparing Dancer with anything more than a micro-framework is not really accurate. On Ruby, that's Sinatra, for one. Python has Bottle and Flask, perhaps others. But to compare Dancer with either Django or Rails is something that I don't quite understand. The fact that Dancer is a micro-framework, and not a full framework, is why I love it. I love Rose::DB::Object as n ORM, and Template Toolkit as a view layer. What I was missing was Dancer. Now I have what I need. On Wed, Jul 2, 2014 at 6:12 PM, fabioniguel3@gmail.com < fabioniguel3@gmail.com> wrote:

Thanks for that Andrew.

On Thu, Jul 3, 2014 at 12:02 AM, Andrew Solomon <andrew@illywhacker.net> wrote:

...

I've been conducting a series of interviews of my students to understand the motivation for learning Perl. This one I thought would be of particular interest to the Dancer community as I've asked an established Perl developer with a broad background in other languages and technologies why he learnt Dancer

http://blog.geekuni.com/2014/07/why-learn-perl-interview-3-savio.html

Hope you find it interesting!

cheers

Andrew _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

This is just my own understanding, but here it is: Let's first get on the same page about web frameworks. To me, a web framework is basically giving you everything you need to get started with a database-driven website or web application. Everything, that is, between the webserver software and the database software. And in many cases the framework itself includes a webserver. This is true of Dancer (which I'm not saying is a full framework) and Rails and most others, because the *basics* of a webserver are pretty simple. So when I say "everything you need to get started," that's generally going to include each of the MVC layers. Some code that handles the Model, some code that handles the Controller, and some code that handles the View. Of course, there are lots of ways to deal with a database, and most of them have nothing specific to do with web frameworks. In Perl, there's pure DBI, there's DBIx::Class, there's Rose::DB::Object, and I'm sure many others. There are also lots of ways to do templating. Template Toolkit, HTML::Template, and many others. There are also websites and web applications that are so simple that you don't even need those parts at all. For those reasons and others, there is an appetite for the "micro web framework." As far as I can tell, there's only one real requirement for a micro web framework. And that is route handling. When certain types of requests come in, how do we handle those requests? Different HTTP methods, different URIs, different query parameters. How do we parse the arguments? How do we handle error conditions? File uploads. Session data. Etc. All of this is included in a full framework as well, as the Controller. And they also contain code for the Model and View. But the micro-framework does not. You might think of a micro framework as simply a controller framework. Anyway, that's my impression. I might be wrong. On Thu, Jul 3, 2014 at 9:40 AM, Andrew Solomon <andrew@illywhacker.net> wrote:

Hi John

I've read this and I still don't really know what a micro web framework is

http://stackoverflow.com/questions/6784007/what-does-it-mean-to-be-a-micro-f...

but my gut feeling is simply that for a micro framework, a large portion of functionality is acquired via plugins.

Can you clarify the definition?

Andrew

On Thu, Jul 3, 2014 at 12:45 AM, John Ingram <john@rotogrinders.com> wrote:

...

While this is interesting, comparing Dancer with anything more than a micro-framework is not really accurate.

On Ruby, that's Sinatra, for one. Python has Bottle and Flask, perhaps others. But to compare Dancer with either Django or Rails is something that I don't quite understand.

The fact that Dancer is a micro-framework, and not a full framework, is why I love it. I love Rose::DB::Object as n ORM, and Template Toolkit as a view layer. What I was missing was Dancer. Now I have what I need.

On Wed, Jul 2, 2014 at 6:12 PM, fabioniguel3@gmail.com <fabioniguel3@gmail.com> wrote:

...

Thanks for that Andrew.

On Thu, Jul 3, 2014 at 12:02 AM, Andrew Solomon <andrew@illywhacker.net

...

wrote:

...

I've been conducting a series of interviews of my students to understand the motivation for learning Perl. This one I thought would be of particular interest to the Dancer community as I've asked an established Perl developer with a broad background in other languages and technologies why he learnt Dancer

http://blog.geekuni.com/2014/07/why-learn-perl-interview-3-savio.html

Hope you find it interesting!

cheers

Andrew _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

On 7/3/2014 10:07, Andrew Solomon wrote:

Anyway, I'd like to know peoples' views on whether this is a healthy approach to developing maintainable web apps.

Consider this complexity continuum: CGI::* < mod_perl < Apache::ASP < Dancer < Catalyst < CMS This does not say that everything eventually becomes a CMS, or that everything is based on CGI or mod_perl at bottom. It just ranks web frameworks by increasing complexity. The more the web framework does for you out of the box, the greater the complexity, but also the more policy it tends to drag along with it. Web frameworks occupy a span along the continuum, not a single spot. Some spans are wider than others. Rails, Django and Catalyst all roughly overlap, Mason+Poet roughly overlaps Dancer, etc. I show Apache::ASP to the left of Dancer only because it isn't as big or complex as Dancer, but in reality, there's considerable overlap. Drupal is so flexible a CMS that the leftward edge of its span overlaps Catalyst's space on the continuum. At the far left, you are given almost no tools, but you have ultimate freedom. The farther to the right you go, the more your end application needs to match the preconceived notions that went into the framework. Some people try to fight this. They will build something other than a CMS on top of Drupal, or a non-MVC app on top of Catalyst, or a non-DBMS-backed app on top of Rails. These are all signs that you should have started with something farther left on the continuum. You can make the opposite mistake, too. If you're building a CMS on top of Dancer, you're probably reinventing many perfectly good wheels. Finding the right place along the continuum can be tricky. When you choose Catalyst over Dancer, you are buying into a set of policies and assumptions. Catalyst assumes that MVC is a good design for your app, that you have a DBMS, that it makes sense to connect the DBMS directly to the web app, and that it makes sense to use the web framework's ORM to do that. I chose Dancer over Catalyst because three of those four assumptions are untrue for my app. That is to say, I moved to the left until I stopped violating framework assumptions. I went no farther left than I had to because I have no wish to build up my own framework from the stone knives and bearskins level of technology. Dancer is at an interesting position on the complexity continuum. It is just to the left of the border where features start turning into policy and design. The best reason to choose Dancer is when you are building something that isn't already designed and implemented.

"Finding the right place along the continuum can be tricky. When you choose Catalyst over Dancer, you are buying into a set of policies and assumptions." Using Dancer and any other technology which is not very low level implies a set of policies and assumptions also. "Catalyst assumes that MVC is a good design for your app, that you have a DBMS, that it makes sense to connect the DBMS directly to the web app, and that it makes sense to use the web framework's ORM to do that.". This is not true. Catalyst apps don't need to use a dbms and doesn't asumes that you are using one. Catalyst doesn't promote the idea of connecting to the dbms directly, but it considers that the best idea is to create simple standard Perl modules that can be used with the web app created with Catalyst, or with other CLI programs, or in any other way, so the code can be easier tested and reused in other apps than the web app. Those standard modules could be also used with Dancer or other Perl web frameworks. Only the basic tutorials for beginners explains how to use the Catalyst app as a web app only, because those examples involve only Catalyst and they are easy to understand. Catalyst doesn't have its own ORM, so it can't consider that it makes sense to use that ORM. Catalyst apps can be made to not use a dbms at all, or to use a dbms by DBI module directly, or to use the Perl ORM you choose, depending on the needs. "I chose Dancer over Catalyst because three of those four assumptions are untrue for my app." Because those assumptions are not correct, you need to consider other reasons for using Dancer. :-) --Octavian ----- Original Message ----- From: "Warren Young" <warren@etr-usa.com> To: "Perl Dancer users mailing list" <dancer-users@dancer.pm> Sent: Friday, July 04, 2014 8:53 AM Subject: Re: [dancer-users] Why learn Dancer?

On 7/3/2014 10:07, Andrew Solomon wrote:

...

Anyway, I'd like to know peoples' views on whether this is a healthy approach to developing maintainable web apps.

Consider this complexity continuum:

CGI::* < mod_perl < Apache::ASP < Dancer < Catalyst < CMS

This does not say that everything eventually becomes a CMS, or that everything is based on CGI or mod_perl at bottom. It just ranks web frameworks by increasing complexity. The more the web framework does for you out of the box, the greater the complexity, but also the more policy it tends to drag along with it.

Web frameworks occupy a span along the continuum, not a single spot. Some spans are wider than others. Rails, Django and Catalyst all roughly overlap, Mason+Poet roughly overlaps Dancer, etc. I show Apache::ASP to the left of Dancer only because it isn't as big or complex as Dancer, but in reality, there's considerable overlap. Drupal is so flexible a CMS that the leftward edge of its span overlaps Catalyst's space on the continuum.

At the far left, you are given almost no tools, but you have ultimate freedom.

The farther to the right you go, the more your end application needs to match the preconceived notions that went into the framework.

Some people try to fight this. They will build something other than a CMS on top of Drupal, or a non-MVC app on top of Catalyst, or a non-DBMS-backed app on top of Rails. These are all signs that you should have started with something farther left on the continuum.

You can make the opposite mistake, too. If you're building a CMS on top of Dancer, you're probably reinventing many perfectly good wheels.

Finding the right place along the continuum can be tricky. When you choose Catalyst over Dancer, you are buying into a set of policies and assumptions. Catalyst assumes that MVC is a good design for your app, that you have a DBMS, that it makes sense to connect the DBMS directly to the web app, and that it makes sense to use the web framework's ORM to do that. I chose Dancer over Catalyst because three of those four assumptions are untrue for my app.

That is to say, I moved to the left until I stopped violating framework assumptions. I went no farther left than I had to because I have no wish to build up my own framework from the stone knives and bearskins level of technology.

Dancer is at an interesting position on the complexity continuum. It is just to the left of the border where features start turning into policy and design. The best reason to choose Dancer is when you are building something that isn't already designed and implemented. _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users