[twic]

(I'm guessing that was "So why separate ...", and you've just had root canal)

They're separated in the sense that the app server is something you download that exposes an API, and the app is something you write on top of the API. It's much the same as the way the JVM and the class files are separated, or the way the OS and the JVM are separated. It's a fairly straightforward, pragmatic application of layering.

[jshen]

Maybe we mean different things by "separated". I want the app server bundled into the app, not an assumed dependency that the app has on the target environment.

Rack in the ruby world exposes an API that ruby web apps build on top of, but you never install an app server then install your app into the server.

[twic]

Aha, yes, that makes sense. I don't think there's anything fundamentally wrong with packaging the app server along with the app. It's just not traditional in the Java world.

My preferred solution would be to package the app and the app server as operating system packages, and have the app depend on the app server. That makes the dependency explicit, but doesn't leave you with a gigantic deployable.

[jshen]

Here is one reason I like the bundled approach. I've been using golang recently which compiles into a machine executable. I was building a REST API that many third parties would use. When they wanted to use the API for development all I had to do was send them the bundle and tell them how to start. There were no other dependencies at all. It didn't assume a particular package manager, OS, or anything else. Take this file and execute it, that's it.