FAQ
Please also refer to the FAQs for Sincerity and Scripturian.
Technology
How is Prudence different from Node.js?
Both are server-side platforms for creating network servers using JavaScript. Both have evolved to support package managers: Sincerity for Prudence, npm for Node.js.
But that's pretty much where the similarities end.
Prudence is a comprehensive platform for REST services, such as web pages and RESTful APIs. Node.js is a minimalist platform for asynchronous services, such as streaming video and audio servers. These are very different use cases.
First, note that both use non-blocking servers at the low level. So they're both asynchronous in that particular respect.
On top of the multi-threaded server Prudence builds a RESTful application environment, using Restlet to handle the many intricacies of HTTP. Why multi-threaded? Because generating HTML is logically a single-event procedure: at the moment you get the client's request, you generate the HTML content and send it immediately. Thus, via a managed, configurable thread-pool, Prudence can leverage multi-core CPUs as well as highly-concurrent database backends to serve several several user requests simultaneously.
Node.js could not be more different: it is by design single-threaded and event-driven: requests are never handed simultaneously, and only a single CPU core would ever be used by the HTTP server itself.
Seems odd? Actually, this "raw" architecture makes a lot of sense for streaming applications: as opposed to HTML pages, streams are always multi-event procedures, each event generating a "chunk" of the stream that saturates the socket with data. There is no advantage to using more than one thread if a single thread is already taking up all the bandwidth. In fact, thread synchronization could introduce overhead that would slow the server down. Really, your only variable in terms of scalability is the size of the chunks: you'll want them smaller under high load in order to degrade performance fairly among clients. That said, other libraries you might use from Node.js can and do use threads: this is useful for CPU-bound workloads such as video encoding.
Node.js is great for its intended use case. It's vastly easier to write event handlers in JavaScript than in C/C++, and JavaScript also makes it easy to bootstrap the server. If you're writing a streaming asynchronous server, we highly recommend Node.js.
If you like Node.js but JavaScript is not your favorite dynamic language, similarly excellent event-driven platforms are available for other languages: check out Tornado and Twisted for Python, and EventMachine for Ruby.
That said, it's very odd that Node.js has become a popular platform for the non-streaming, data-driven web: the Express framework, for example, provides some minimal RESTful functionality on top of Node.js. But event-driven servers are not designed for REST, and are in fact quite a bad fit: consider that in a single-threaded runtime, if a single event handler hangs, the whole server will hang. Node.js deals with the problem by in effect offloading the thread pools to external libraries, written in C++. For example, Node.js's database drivers handle queries in their own connection thread pools, and push events to Node.js when data is available. Still, in your Node.js JavaScript event handlers, you have to take extra care not to do any time-consuming work: a delay you cause would affect all operations waiting their turn on the single-threaded event loop. Thus, to create a properly scalable Node.js application, you must have event handlers with no risky "side effects": that heavy lifting is left to the C++ libraries. The bottom line is that you have an illusion of single-threadedness: you've merely shifted the workload to the drivers.
And even if you did a good job in JavaScript, your implementation will not in any way be more scalable for this use case than by using a thread pool: users still need to wait for their requests to complete, and databases still have to return results before you can complete those requests. There's nothing in an event-driven model that changes these essential facts. (It's worth repeating again: both Prudence and Node.js use non-blocking I/O servers; Node.js having an event-driven programming model does not allow it to magically handle more concurrent connections than other platforms can.)
You can add some parallelism by running multiple Node.js processes behind a load balancer, but the problems quickly multiply: each process loads its own version of those C++-written drivers, with its own connection thread pool, which can't be shared with the other Node.js processes. In Prudence, by contrast, the same pool is trivially shared by all requests. (Prudence's threads can also share an in-process memory-based cache backend for the best possible caching performance at the 1st tier.)
It should be clear that Node.js is simply the wrong tool for the job. So, why is Node.js so misused? One reason is that its raw architecture is attractively simple: multi-threaded programming is hard to get right, single-threaded easy. JavaScript, too, is attractive as a language that many programmers already know. So, despite being a problematic web platform, it's one in which you can build web services quickly and with little fuss, and sometimes that's more important than scalability or even robustness (especially if the goal is to create in-house services). But another reason for Node.js' popularity is more worrying: ignorance. People who should know better heard that Node.js is "fast" because it's "asynchronous" and think that would lead to faster page load-times for web browsers and the ability to handle more page hits. That's a very wrong conclusion. You can do great REST in Node.js, but would have to work against the platform's limitations for the scenario.
We believe that Prudence is a much more sensible choice for the RESTful web. Beyond the basic multi-threaded model, also consider Prudence's many features aimed specifically at RESTful scalability, such as integrated caching, full control of conditional HTTP, and clusters for scaling horizontally in the "cloud." Check out our Scaling Tips article, too, which is useful even if you don't choose Prudence.
Prudence was designed specifically for the JVM, to provide you with access to its rich and high-quality ecosystem, to leverage its excellent concurrency libraries and monitoring/profiling capabilities, and to be portable and integrative. The JVM platform is very mature and reliable, as are many of the libraries that Prudence uses, such as Jetty, Restlet and Hazelcast. It's easier to connect C/C++ libraries to Node.js, but on the other hand it's easier to write and deploy extensions in Java/Scala/Groovy/Clojure for Prudence.
And Prudence is not just JavaScript: it supports many dynamic languages running on top of the JVM—Python, Ruby, PHP, Lua, Groovy and Clojure—as well as their respective ecosystems. That said, it does give special love to JavaScript: Sincerity comes with a rich foundation library, offering essentials such as OOP and string interpolation, as well as friendly wrappers for powerful JVM services, such as concurrent collections and cryptography.
Node.js is JavaScript-centric, and though it has a much younger and narrower ecosystem, it is vibrant and quickly growing.
In terms of sheer computational performance, Node.js has done well to leverage the "browser wars," which have resulted in very performative JavaScript interpreters and JIT compilers. However, it's worth remembering that these engines have been optimized for web browser environments, not servers, and thus have very limited support for threading. By contrast, Prudence can run JavaScript on your choice of either Nashorn or Rhino, which can both use the JVM's excellent concurrency management. Nashorn promises excellent performance, on par with Java code in some cases. Rhino is not as fast, but still performs well and is very mature.
But a comparative benchmark would make little sense. Node.js' single-threaded model really needs blazing-fast language performance, as it directly affects its scalability. Prudence's multi-threaded model and RESTful expectations mean that it's rarely CPU-bound: for example, you spend orders of magnitude more time waiting for database backends to respond than for functions to be called. For the web page use case, smart architecture—and smart caching—are far more important for scalability than language engine performance.
Note, too, that all the performance-critical parts of Prudence are written in Java, just as they are written in C++ for Node.js. There should be no noticeable performance differences in the basic request handling performance.
And it's important to remember—and repeat to yourself as mantra—that performance does not equal scalability. Prudence's default HTTP engine is Jetty, which is designed from the ground-up for scalable web services, and it behaves smartly under high volumes, even if it might not seem so under trivial and misleading localized benchmarks. It's also easy to replace Jetty with other servers.
Choose the right tool for the job! Node.js is a great choice for streaming and streaming-like services, and Prudence—we hope you'll agree—is a great choice for web services and RESTful APIs.
How is REST better than RPC?
Well, it's not necessarily better. One important advantage is that it works inside the already-existing, already-deployed infrastructure of the World Wide Web, meaning that you can immediately benefit from a wide range of optimized functionality. We discuss this in greater detail in The Case for REST.
But we don't advocate REST for every project. See this discussion for one reason why RPC may be more appropriate. Choose the right tool for the job!
Why does Prudence support LESS instead of SASS?
Prudence implements LESS using the Less4j library. Unfortunately, there is no SASS implementation that would directly work on the JVM: we could potentially run it using JRuby, but that is simply too big a dependency for a single feature.
However, nothing is stopping you from running SASS from the command line to create your CSS.
An alternative to LESS is ZUSS: smaller, but not quite as comprehensive. Code to support it is included in Prudence, though you must install the ZUSS Jar yourself.
How do I use other HTTP servers instead of Jetty?
We recommend Jetty and install it by default, but in some cases it may be worth using alternatives: for example, you may want to experiment with different performance characteristics for certain deployments or make comparative benchmarks.
Fortunately, Restlet decouples its API from the server library, and comes with extensions to connect to several server libraries in addition to Jetty. You can install these easily with Sincerity, though note that you would need to exclude the Jetty extension if you do so: Restlet does not currently run if several server extensions are in the classpath at the same time.
For example, let's use the Simple Framework instead of Jetty:
sincerity add prudence.example : add restlet.simple : exclude org.restlet.jse org.restlet.ext.jetty9 : exclude org.eclipse.jetty jetty-server : install : start prudence
If Restlet does not find any server extension in the classpath, it will default to its own "internal" server, which is adequate to simple deployments and for testing:
sincerity add prudence.example : exclude org.restlet.jse org.restlet.ext.jetty9 : exclude org.eclipse.jetty jetty-server : install : start prudence
Performance and Scalability
How well does Prudence perform? How well does it scale?
First, recognize that there are two common uses for the term "scale." REST is often referred to as an inherently scalable architecture, but that has more to do with project management than technical effectiveness. This difference is addressed in the "The Case for REST".
From the perspective of the ability to respond to user requests, there are three aspects to consider:
Prudence comes with Jetty, an HTTP server based on the JVM's non-blocking I/O API. Jetty handles concurrent HTTP requests very well, and serves static files at scales comparable to popular HTTP servers.
Prudence implements what might be the most sophisticated caching system of any web development framework. Caching is truly the key to scalable software. See "Scaling Tips" for a comprehensive discussion of the role of caching.
There may be a delay when starting up a specific language engine in Prudence for the first time in an application, as it loads and initializes itself. Then, there may be a delay when accessing a dynamic web page or resource for the first time, or after it has been changed, as it might require compilation. Once it's up and running, though, your code performs and scale very well—as well as you've written it. You need to understand concurrency and make sure you make good choices to handle coordination between threads accessing the same data. If all is good, your code will actually perform better throughout the life of the application. The JVM learns and adapts as it runs, and performance can improve the more the application is used.
All language engines supported of Prudence are generally very fast. In some cases, the JVM language implementations are faster than their "native" equivalents. This is demonstrable for Python, Ruby and PHP. The reason is that the JVM, soon reaching version 8, is a very mature virtual machine, and incorporates decades-worth of optimizations for live production environments.
If you are performing CPU-intensive or time-sensitive tasks, then it's best to profile these code segments precisely. Exact performance characteristics depend on the language and engine used. The Bechmarks Game can give you some comparisons of different language engines running high-computation programs. In any case, if you have a piece of intensive code that really needs to perform well, it's probably best to write it in Java and access it from the your language. You can even write it in C or assembly, and have it linked to Java via JNI.
If you're not doing intensive computation, then don't worry too much about your language being "slow." It's been shown that for the vast majority of web applications, the performance of the web programming language is rarely the bottleneck. The deciding factors are the usually performance of the backend data-driving technologies and architectures.
I heard REST is very scalable. Is this true? Does this mean Prudence is "web scale"?
Yes, if you know what you're doing. See "The Case for REST" and "Scaling Tips" for in-depth discussions.
The bottom line is that it's very easy to make your application scale poorly, whatever technology or architecture you use, and that Prudence, in embracing REST and the JVM, can more easily allow for best-practice scalable architectures than most other web platforms.
That might not be very reassuring, but it's a fact of software and hardware architecture right now. Achieving massive scale is challenging.
Errors
How to avoid the "Adapter not available for language: xml" parsing exception for XML files?
The problem is that the XML header confuses Scripturian, Prudence's language parser, which considers the "<?" a possible scriptlet delimiter:
<?xml version='1.0' encoding='UTF-8'?>
The simple solution is to force Scripturian to use the "<%" for the page via an empty scriptlet, ignoring all "<?":
<% %><?xml version='1.0' encoding='UTF-8'?>
Licensing
The author is not a lawyer. This is not legal advice, but a personal, and possibly wrong interpretation. The wording of the license itself supersedes anything written here.
Does the LGPL mean I can't use Prudence unless my product is open sourced?
The GPL family of licenses restrict your ability to redistribute software, not to use it. You are free to use Prudence as you please within your organization, even if you're using it to serve public web sites—though with no warranty nor an implicit guarantee of support from the copyright holder, Three Crickets LLC.
The GPL would thus only be an issue if you're selling, or even giving away, a product that would include Prudence.
And note that Prudence uses the Lesser GPL, which has even fewer restrictions on redistribution than the regular GPL. Essentially, as long as you do not alter Prudence in any way, you can include Prudence in any product, even if it is not free. With one exception: Prudence uses version 3 of the Lesser GPL, which requires your product to not restrict users' ownership of data via schemes such as DRM if Prudence is to be included in its distribution.
Even if your product does not qualify for including Prudence in it, you always have the option of distributing your product without Prudence, and instructing your customers to download and install Prudence on their own.
We understand that in some cases open sourcing your product is impossible, and passing the burden to the users is cumbersome. As a last resort, we offer you a commercial license as an alternative to the GPL. Please contact Three Crickets for details.
Three Crickets, the original developers of Prudence, are not trying to force you to purchase it. That is not our business model, and we furthermore find such trickery bad for building trusting relationships. Instead, we hope to encourage you to 1) pay Three Crickets for consultation, support and development services for Prudence, and to 2) consider releasing your own product as free software, thereby truly sharing your innovation with all of society.
Why the LGPL and not the GPL?
The Lesser GPL used to be called the "Library GPL," and was originally drafted for glibc. It is meant for special cases in which the full GPL could limit the adoption of a product, which would be self-defeating. The assumption is that there are many alternatives with fewer restrictions on distribution.
In the case of the Linux project, the full GPL has done a wonderful job at convincing vendors to open source their code in order to ship their products with Linux inside. However, it doesn't seem likely that they would do the same for Prudence. There are so many great web development platforms out there with fewer restrictions.
Note that the LGPL version 3 has a clause allowing you to "upgrade" Prudence to the full GPL for inclusion in your GPL-ed product. This is a terrific feature, and another reason to love this excellent license.
The Prudence Manual is provided for you under the terms of the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. The complete manual is available for download as a PDF.
