[dancer-users] Dancer Advent Calendar 2015
xsawyerx at gmail.com
Thu Oct 29 23:43:43 GMT 2015
Taking two steps back from the current position of this thread, I think
John is raising a valid point here: He uses Dancer in a certain way. It
might not be the responsibility of the main documentation to document his
usage, but it would be nice to have an article which does.
We hope to have the Dancer Advent Calendar cover new features and tips, but
also useful articles - whether they are Dancer-specific or around the
perimeter of Dancer usage (like a service or website written in it, or an
example on a common application usage).
I've added it to the list of ideas, and if anyone wants to write it, please
let me know.
Thanks John and Warren. :)
On Wed, Oct 28, 2015 at 6:53 AM, Warren Young <wyml at etr-usa.com> wrote:
> 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
> >>> 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.
> 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
> 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
> > 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?
> dancer-users mailing list
> dancer-users at dancer.pm
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dancer-users