[dancer-users] Dancer Advent Calendar 2015

[Warren Young]

On Oct 27, 2015, at 9:07 AM, John Stoffel <john at stoffel.org> wrote:
> 
> Warren> On Oct 25, 2015, at 3:12 PM, John Stoffel wrote:
>>> 
>>> - I'd love to see a simple example of searching with multiple fields and
>>> pagination of the results.
> 
> Warren> That sounds like a front-end problem, plus a back-end problem.
> 
> I'm trying to use Dancer to solve a problem I currently solve
> with PHP?

Modern web design usually breaks such an app into several layers: DBMS, caching engine (e.g. memcached), middleware (e.g. Dancer), proxy server (e.g. nginx), and front-end library (e.g. Angular or jQuery).

No single layer will do everything for you.  You have to know all of the layers separately before you can see how to use them in concert to build the whole app.  The everything-in-PHP days are disappearing.

Because of that, expecting a site dedicated to just one of these layers to cover all of the other layers is unrealistic.  The Dancer mailing list shouldn’t be covering Redis, Postgres, Bootstrap, etc.  They have their own lists and forums.

> Dancer is a means to an end for me.  If it doesn't help me
> get to where I want to be, then I'll drop it and move on.

Dancer will not solve all of your problems.  But then, no other single technology will, either.

> Warren> Pagination is soooo 2001.
> 
> This is for a library thats been around for 200+ years... being 14
> years behind the times is fine with them, and me.  :-)  

Do you suppose that’s what your paymasters were thinking when they hired you?  “I hope this guy custom-develops some old tech for us.”

My day job is in a related field to yours.  I know about sites using “ancient” technology.  The thing is, these sites aren’t uniformly ancient.  They adopt the latest-and-greatest whenever they get the budget to upgrade.  The only difference between them and the consumer and business worlds is that they then they stay on that increasingly-aged bleeding-edge tech for another 10 years.  

Deploying 14-year-old tech today means it’ll be a quarter century old when it’s finally decommissioned.

I’m not telling you to give your clients bleeding-edge untested tech.  Google Reader popularized endless scrolling in 2005.  It’s been the standard way of doing such things for most of a decade.

> It used to be that you could write a user facing app in
> one language.

The consequence of that is that you had to send all processing back to the server, which is slow, and you had to do it all in an interpreted language, which is slow.

Then we invented Ajax, and memcached, and reverse proxies, and more, all to make the web faster.  Study after study shows that faster web sites make users happier, purely because they are faster.  Anything that increases round-trip time is a problem.  

Pagination causes user-visible round-trips.  Endless scrolling solves that problem by loading the next screenful of records in the background, before the user knows they need them.  Processing still takes human-scale time, but because the user rarely sees it happen, your app appears to run faster.  Faster is good.

> I can understand why Node.js is making
> headway, because it drops down the number of seperate tools/languages
> you need to know to get your app out the door.

Yes, and Dancer is potentially similar, in that it has a built-in web server that can work for many real-world applications, allowing you to write more of your code in Perl.

If you want something even more extreme, look at the various Erlang web stacks, where even the DBMS might be in Erlang.

Nevertheless, you still need to write a fair bit of your app in JavaScript if you want it to be fast, purely because every round trip on the web takes human-scale time, even on a LAN.  The more you can do on the client side or in the background, the better.

> I don't have the time/energy to
> become a master of JavaScript, etc.

JavaScript is a much simpler language than Perl.

There never has been a time in computing where you could know only one programming language and be considered well-rounded.

Until you can get browsers to run Perl code, you’re going to have to have at least some facility with JavaScript if you’re going to write web apps.

> One of the problems I had with most Rails tutorials was
> that they all assumed you needed to do CRUD or a blog.  Nothing more.
> They all glossed over the real world uses in my mind.  

It’s not so much that those tutorials were glossing over the real world, it’s that a highly-opinionated framework like Rails puts restrictions on the apps that can sensibly be written in it.  You can write non-CRUD apps in Rails, but you’re fighting the framework constantly to do it.

Dancer doesn’t make you fight it to do strange things, but it doesn’t hold your hand to help you do strange things, either.  It just presents a box of tools and gets out of your way.

Observing that perldancer.org does not contain a library media management system is like observing that a wood shop does not contain trundle beds.  How, then, do trundle beds come into being?