You can't build a web application on Hunchentoot -- a basic HTTP server -- and call it modern. Take a look at Clack for the actual modern approach: http://clacklisp.org/
> You can't build a web application on Hunchentoot -- a basic HTTP server -- and call it modern.
The article does a pretty good job of starting with the basics and introducing more complexity step by step. I would argue that the author's approach is better than any attempt to introduce a full-stack framework, which does not help the beginner level lisp programmer (clearly the target audience) understand - one might take away some recipes from that but no real understanding.
Which, if any, "modern" frameworks one uses then finally depends on the project and taste. After all, gluing together the various routing-, persistence-, ORM-choices only takes a few lines of code anyway.
And, after having been consulting as a lisp programmer for some years now, I would even argue that the overhead of learning some full-stack frameworks is usually not worth the benefits they claim to provide.
> And, after having been consulting as a lisp programmer for some years now, I would even argue that the overhead of learning some full-stack frameworks is usually not worth the benefits they claim to provide.
I'm not an experienced Lisp developer, but this jives with my experiences with frameworks in other languages. It seems like frameworks cover 95% use cases: they make your life easier for 95% of what you're trying to do. But for the other 5%, you can't just work outside the framework, because frameworks couple you to their paradigm. So you end up trying to solve problems through the framework that the framework doesn't have good solutions for. You're stuck solving problems without the debugging tools or basic building blocks that writing your own in a programming language offers you; it's like trying to tighten a screw with a hammer in the dark. The result is that you end up spending a lot of time on that 5% of problems.
What makes this particularly dangerous is that you typically don't start solving the really unique problems of your project until you've already gotten pretty far into your project: you don't run into the 5% problems until you've already committed heavily to using the framework. A lot of less experienced devs get caught up in this: they start using a framework and everything seems easy. Drunk with their newfound power, they try to do everything in a framework, and each new project reinforces their belief that the frameworks are saving them time. It takes a long time to be on enough long-running projects that you see the pattern and recognize frameworks for the double-edged sword that they are.
To be clear, I'm not saying that frameworks are always bad. For simple or short-lived projects, a framework is probably the best way to go: you'll probably never hit those 5% cases where the framework will hurt you. But if you're doing something at scale, or for a long time, or doing something very complex: a framework might not be the best approach. And large-scale, long-running, and complex projects are where the money and job stability are at.
There is definitely a middle ground to explore here. For example, in the Python world, there are some great minimalist frameworks (Flask, Bottle) which can be tied together with a template engine (Cheetah, string.Template) and SQLAlchemy to give you most of what a big framework like Django or Pylons gives you, but in a much less coupled way that allows you to create your own extensions points. Libraries are much more flexible than frameworks. Sure, you'll feel more pain up front, but you won't spend your time trying to get an ORM to emit a specific SQL query, or waiting for your cache middleware library to accept your PR on a 10-year-old bug in its invalidation.
Your complaint isn't about framework, but about other people's frameworks. A framework is always the best approach, when it's your framework and those 5% never happen because you simply modify the framework to be able to do it.
Because in the real world of web development applications are hardly ever written directly on top of the server. They are written on a framework, that sits on top of an HTTP server abstraction (like Clack), that has pluggable servers.
That way, if a new server comes out (e.g. Woo[0]), you don't have to learn all of its internals and rewrite the entire application using it -- you literally just change a keyword argument in a single function call, and now your application is running on a different, much faster server. If someone writes a plugin for Clack (e.g. clack-errors[1]), all applications built on any Clack framework using whatever server can use it. A Hunchentoot plugin works for Hunchentoot applications.
Using Clack is sustainable web development.
Sure, for a five minute demo, Hunchentoot is fine. But why teach bad practices?
Why would you even change your server if a new one came out? If your old server works and is maintained, there's no reason for a switch. Also, 'jlg23 has a good point - learning full-stack frameworks as a beginner only serves to confuse things. For the same reason I never advocate that people new to programming jump straight into RoR or Node.js or whatever framework is hot this week - a person needs to understand the problem a tool solves before using the tool; otherwise you're training a code monkey, not a programmer.
>Why would you even change your server if a new one came out?
Woo is many times faster than Hunchentoot. And projects can die.
>a person needs to understand the problem a tool solves before using the tool; otherwise you're training a code monkey, not a programmer.
There's a reason we use high-level languages: They hide irrelevant details. You shouldn't have to learn how TCP works or know every detail of HTTP to know what can be done with it.
Personally I'd prefer a more representative benchmark, which actually uses the network... Really measuring the qualities of a Web server is a bit more work.
So, for multi-threaded, it's within a factor of 2. That's not bad. I wonder how much of that is likely to be eaten up in a real-world application. Interesting that woo is so much more performant for the single-threaded case though. But it hardly matters as both support multi-threaded, and both are much faster with multiple threads...
> Because in the real world of web development applications are hardly ever written directly on top of the server. They are written on a framework, that sits on top of an HTTP server abstraction (like Clack), that has pluggable servers.
This is only true if you're writing Web 2.0 media websites that are only nominally not static websites. If you are solving an actual hard problem instead of just driving ad traffic, a framework is going to get in your way.
If this is true, then this explains why all the "modern" websites are crappy media websites that don't solve any problem except "How do I drive traffic to ads".
Or one of the frameworks built on it:
http://8arrow.org/caveman/
http://8arrow.org/ningle/
http://eudoxia.me/lucerne/