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.
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.)
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.
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.
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!
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.
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
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.
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.
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'?>
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.
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.
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.