Thread: Help with some website design...

Node.js's asynchronous nature and I'm not sure if it's a good thing or not.

Its just a tool. When you learn how to use it then you will find it helpful, but when you don't expect its results it can be frustrating.

The same thing happens in the DOM though imagine your object calls a jQuery animation and you want to write a step function. On the next iteration it won't be your object calling the function it will be the window. In the same way node.js provides the global object that will call your function. Not sure if its good or bad its just a paradigm shift from other languages. You can get your object by passing it into the function, making a variable to store it in the parent function, using the .bind(this) function method, or es6 fat arrow.

Synchronous behavior can be murderous on the DOM rendering engine pipeline. There are web workers that simulate synchronous threads in JavaScript. The support isn't wide yet, but they can be pretty powerful.

I'll give an example: We are currently building a database that manages a set of around 2.9 million and counting rent matrices. They are populated with every bit of information you would need to show all the details of each unit, when its available ect. Web workers have become the main way to import and export data onto the website. It is dependant on a daily updates, and accurately populated data. Data on that scale isn't small either so we have workers running nearly all day in node.js just building this website. The downside of workers in the dom is they don't have access to the dom, but that isn't really what they are for.

I thought since you are requiring the results[1] spot to be the parameter value, it might also be a good idea to guard against the user passing in "(", ")" too. Although I don't know for sure that these would even be valid in the name?

Yea that is a good idea, I haven't really protected it from invalid entry yet. That function is not directly accessible to the user since it is private, but the same variable they pass when they call the get method then gets passed to that function so indirectly it could be a problem.

For a few months we'll probably just be using it at work on some of our Apps. The point is to go through multiple screens without causing page reloads by using

Code:

history.pushState

and

Code:

history.replaceState

We're hoping to greatly decrease the number of calls to the DOM rendering engine and get around it's shortcomings to make our hybrid apps feel more native.

We figure if you just ask the rendering engine to animate transitions for a set of sequences rather than asking for a load everytime we'll be able to start playing by the rules a little more like the native guys do.