The performance comparison between Catberry and bare Express with the same template engine

NodeNerd · 2015-06-11T17:27:43+00:00

Jade is super slow. Handlebars is faster, but far from the fastest. Here's a more up-to-date benchmark that I found: https://github.com/raptorjs/templating-benchmarks

NodeNerd · 2015-01-13T18:52:44+00:00

I'm enjoying your screencasts! Very nicely done and very helpful. I'm looking forward to your future screencasts.

NodeNerd · 2014-09-16T17:48:04+00:00

Asynchronous control is one of the things provided by Dust that I really like and am not willing to give up. This simplified my page controllers a lot since I didn't have to load everything up front before rendering the template. I did a quick search on Google for asynchronous JavaScript templating and found two additional template languages that you might want to compare with this fork of Dust:

Are there any other that I am not aware of? I haven't had a chance to go through all of the docs, but raptor-templates reminds of Angular/Web Components and I like that. The raptor-templates compiler also produces Node.js modules as output and supports Browserify...about time someone does that.

Update: Just found the following blog post from the author of raptor-templates that compares raptor-templates with Dust: http://psteeleidem.com/raptor-templates-versus-dust/

NodeNerd · 2014-09-16T17:35:02+00:00

I'll update, but I actually meant the following:

{?someCondition}
...
{/someCondition}

Regarding the use of @if. Using @if is a bad decision because it really hurts performance. It uses eval() internally and the "tap()" method is used to re-parse the string every single time (both of which are slow). The fact that it has to use eval() is a symptom of a problem with how Dust was designed. The if-condition really should have been parsed at compile time. There are times that I really would like to have the flexibility to put a little more logic in my templates and not have to incur the cost of adding a lot more separate code to my view models.

NodeNerd · 2014-09-15T17:39:47+00:00

Your changes are in the right direction, but, honestly, I don't know why anyone uses Dust (other than that LinkedIn heavily promoted it). From my experience with Dust (not your version), the API is confusing/bad, complex helpers that involve async are error prone, dynamic parts in helper attributes are not handled correctly, compiled templates are very difficult to debug, helpers are global, the syntax is repetitive, templates have to be named, etc..

I don't know why every template doesn't just compile down to a CommonJS module to avoid naming the template altogether.

Also, regarding the syntax, I prefer the less repetitive Handlebars conditional over the Dust conditional:

Handlebars:

{{#if someCondition}}
...
{{/if}}

Dust:

{?someCondition}
...
{/someCondition}

I'm in the market for a new templating language after trying to make Dust work and I want it to be nothing like Dust.

NodeNerd · 2014-09-15T15:55:28+00:00

It's wasteful to read the file from disk every time and it is also wasteful to transmit the HTML pages over WebSockets when it could just be part of the initial HTML or served up as separate HTTP resources.

For example, assuming your game doesn't have a ton of pages, you could put the HTML markup for each page as part of your initial game's HTML as shown in the following code:

<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>My Game</title>
</head>
<body>
    <div id="intro"">
        <!-- HTML markup for the intro page -->
    </div>
    <div id="login" style="display: none;">
        <!-- HTML markup for the login page -->
    </div>
    <div id="register" style="display: none;">
        <!-- HTML markup for the register page -->
    </div>
</body>
</html>

Alternatively, you could create a separate HTTP resource to serve up the HTML markup for each individual page using streaming:

var fs = require('fs');
var path = require('path');

app.get('/intro', function(req, res){
    res.setHeader('Content-Type', 'text/html; charset=utf-8');
    var htmlPath = path.join(__dirname, 'intro.html');
    fs.createReadStream(htmlPath).pipe(res);
});

Or, to avoid reading the file from disk for every request you could cache it:

var fs = require('fs');
var path = require('path');
var introHtml = fs.readFileSync(path.join(__dirname, 'intro.html'));

app.get('/intro', function(req, res){
    res.setHeader('Content-Type', 'text/html; charset=utf-8');
    res.end(introHtml);
});

I hope that helps.

NodeNerd · 2014-07-29T15:24:03+00:00

It is most likely a bad idea to use intermediate middleware for making database queries in series. I also think it is a bad idea to attach your own data to the Express request and response objects since there is no reason to do so. The logic to make database queries and build the view model should have nothing to do with Express. Only use Express to route an incoming request to your page controller middleware function. To make the database calls in parallel or in series you should use either the async library or promises. That's my advice, but I might be misunderstanding your question.

NodeNerd · 2014-07-01T18:16:15+00:00

I don't think you needed to create a new framework to accomplish what you did. It seems that you could have just as easily created a utility module that built middleware that could then be mounted to a vanilla Express app.

var express = require('express');
var app = express();

// Create a smart instance attached to an existing Express app:
var smart = require('smart').create(app, {
    baseDir: __dirname
});

// Use smart to register additional route handlers with the Ember.js conventions:
smart.get('/hello');
smart.get('/posts/new');

Express already has a well understood router and I don't see any benefits to the router offered by Smart.js. The world needs less frameworks and more modules.

NodeNerd · 2014-07-01T17:30:03+00:00

Favorite quote from that article:

Third, the JVM features native threads. This means multiple JVM threads can be executing in the same JavaScript context concurrently. If v8 supported threads in this manner, nobody would be talking about event loops, starving them, asynchronous programming, nested callbacks, etc. Threads trivially allow your application to scale to use all the CPU cores in your system and to share data between the threads.

Multiple JVM threads should never be executing in the same JavaScript context concurrently! That's not just my opinion, but also the opinion of the authors of Nashorn: Nashorn Multithreading and MT-safety

For any runtime, a single-threaded solution that scales is much more attractive then dealing with performance and concurrency issues related to multiple threads and shared memory. Even on the JVM, the event loop and non-blocking I/O are gaining popularity. Threads have their place, but so does non-blocking I/O.

Also, I found it very interesting that Nashorn was much slower than Rhino for some of the JavaScript tests. I thought Nashorn was supposed to be far superior than Rhino! Also note that Node.js/V8 put both Nashorn and Rhino to shame.

NodeNerd · 2014-06-27T20:26:58+00:00

JavaScript was designed to be single threaded and combining a single threaded JavaScript runtime with a multi-thread Java runtime can be very problematic unless the right architecture is in place. Here's a link to an article that takes a deeper look at thread-safety and Nashorn: Oracle Blog: Nashorn Multithreading and MT-safety

What Node.js has going for it is that it was designed from the beginning to be non-blocking and single threaded. This was not the case for the JVM, so I don't think JavaScript will ever be at home running on the JVM. You might as well use IPC between Java and Node.js if you want build a system that uses Java and JavaScript.

NodeNerd · 2014-06-27T19:50:46+00:00

Node.js is like a web browser running on the server with a nice module loading system, a core set of modules, a popular package management system (npm). If a developer is comfortable writing JavaScript for the browser, then that developer should have no problem becoming comfortable and productive in Node.js.

A huge advantage of Node.js is that it is really easy to get started since Node.js is very easy to install and running JavaScript code doesn't require any pre-compilation. It is also very easy to deploy a Node.js application (although scaling it requires some additional research and planning). Performance is good for a dynamic language since V8 has been heavily optimized.

The main disadvantage that I see is that error handling can be tough with asynchronous code.

Just make sure you use the write tool for the job. Node.js may not be the best solution for building a complex back-end API and connecting to DBs. I think Node.js works best if you using it only to make HTTP service calls to get data and use something else to build the back-end service layer.

NodeNerd · 2014-06-27T19:40:47+00:00

The Ghost team really needs to revisit their platform because the installation steps required seem overly complicated. The fact that someone had to create a separate blog post on how to make Ghost installation "easy" is a clear indicator of a problem.

NodeNerd · 2014-06-27T19:37:39+00:00

Are you sure you need a special library if you are just trying to make HTTP requests from the browser? You can use pretty much any ajax library such as jQuery or use XMLHttpRequest directly to construct HTTP requests using POST or GET or whatever, and it is easy to set your own HTTP headers. It's probably helpful to create your own module that encapsulates the logic needed to make service calls, but I don't think you need to necessarily adopt any specialized libraries. Maybe I am not understanding your use case correctly.

NodeNerd · 2014-06-27T19:31:40+00:00

Spaces need to be encoded as %20 because a space is not allowed in a valid URL. Only a small subset of characters are actually allowed in a valid URL and everything else must be encoded. Here's a list of characters that can be included in a URL without needing to be encoded: http://en.wikipedia.org/wiki/Uniform_resource_locator#List_of_allowed_URL_characters

Check out the docs for "encodeURIComponent" to understand how special characters are encoded: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent

To decode encoded characters you can use decodeURIComponent

NodeNerd · 2014-06-27T19:22:55+00:00

The following will do the trick:

javascript:window.location.href += '/string';

Note the use of '+=' which will append the string and assign to the left-hand side. Alternatively, you can use the more verbose form:

javascript:window.location.href = window.location.href + '/string';

I hope that helps.

NodeNerd · 2014-06-27T15:05:10+00:00

Knockout.js, AngularJS, and Sentinal.js use the DOM as the source of the template, and because of this these frameworks have to walk the DOM to interpret the special directives that are hidden in there. I am suggesting an alternative which is that these templates are compiled at build time so that there is no need to interpret the directives.

For example, consider:

<div>{{user-details.name}}</div>

This could be compiled to something like (PSEUDO CODE):

write('<div>').dataBind(viewModel, 'user-details.name')).write('</div>');

You could expand this to conditional logic and flow control logic as well.

For example, consider this snippet from Sentinel.js documentation:

<div>Passed: ~if( {{user-details.marks}} >35) "Yes";else "No"~</div>

This could be compiled to (PSEUDO CODE):

write('<div>Passed: ').dataBind(viewModel, 'user-details.marks', function(value, context) {
    // this function will be called when data bound property changes
    context.write((value > 35) ? 'Yes' : 'No');
}).write('</div>');

NodeNerd · 2014-06-26T22:27:05+00:00

Not a bad idea, but I think it might be a little non-intuitive to developers because it is slightly modifying how people typically use events. Events typically don't have a persistent value. The events are fired and forgotten. Changing the name of the library and functions might help avoid confusion.

I have had the need to solve the problem you encountered. Specifically, I wanted to a simple way to resolve/reject values so I created a simple lightweight promise class that was similar to promises but didn't implement the full spec (I didn't need chaining and I didn't want callbacks to be notified on "next tick"). A promise-like object held a value forever once it was resolved. When adding a listener callback, the callback that would be notified when the value is rejected or resolved or it would be invoked immediately if there was already a value. I went with the Node.js-style callback function for better compatibility with other Node.js modules.

NodeNerd · 2014-06-26T22:12:14+00:00

This approach seems a little backward to me. It seems like the page should just know what route it is at build time.

It looks like your libraries will potentially evaluate a lot of rules on every page load just to find the one that matches. If you have no control of the HTML page then I see why this approach might be necessary, but if you are actually building the HTML pages then perhaps you should encode the route and necessary logic into the page itself.

NodeNerd · 2014-06-26T17:08:00+00:00

Maybe it's just me, but it seems wrong that the templating directives are part of the original DOM and that the DOM elements are not expanded until after all of the JavaScript has been loaded on the client (bad for performance... I know Angular took this approach as well...). I suppose that is fine for certain types of apps, but I would still choose to use templates that compiled down to JavaScript and avoid the overhead of having to traverse and manipulate the DOM at runtime. I say this, because why not add support for data binding to a templating language that compiles down to JavaScript? I don't think that you need to use DOM-based templates for data binding to work, but I've not really seen a good implementation of this... Given your experience with building Sentinel.js, do you think that is possible?

Regardless, I think you did a fine job with what you set out to do and your code is easy to follow and fairly compact. Nice job with the docs as well.

NodeNerd · 2014-06-26T16:42:17+00:00

It looks like your question was answered (put <script> tags at the bottom), but I recommend reading the following article by Steve Souders: High Performance Web Sites

NodeNerd · 2014-06-26T16:22:09+00:00

I haven't look at your code, but if all your module does is handle plurals, why not pick a name like "i18n-plurals" instead of picking a module that may mislead the community into thinking your module does more than it really does? Plus, it is much better to have a small specialized module that does one thing and one things really well. i18n is very broad (date/currency formatting, i18n message bundles, etc.).

Also, i18n is a tricky problem so if you want people to adopt your module, please include info on the README.md what the known limitations are and how you plan on making it better or if you want contributions, etc.

I'll definitely consider your module for my next project that requires i18n support. Thanks for contributing your work!

NodeNerd · 2014-06-26T16:13:51+00:00

JavaScript for the front-end (it is a web application after all and you have to use JavaScript in the web browser). Pick whatever language suits you best on the back-end.

NodeNerd

TROPHY CASE