The environment you're in dictates the "toolbox" of APIs available to you. The browser's primary "tool" is the DOM, or document, which is the live, interactive model of your HTML page. Its entire world revolves around this document and its parent, the window. It's a secure sandbox, so for very good reasons, it has almost no access to the user's hard drive. It's a client, built to make network requests to servers.


Node.js, on the other hand, has no document, window, or HTML. It has no visual components at all. Its "toolbox" contains powerful built-in modules for backend tasks. The most important of these is the fs (File System) module, which gives you full permission to read, write, and delete files on the server. Its http module allows you to create a web server from scratch, listening for and responding to the requests that browsers send.


This means you simply cannot do the same things in both. You can't use a TQTXWidget in Node.js because there is no document to draw it on. Likewise, you can't use Node's file system module in a browser to read a user's hard drive—that would be a massive security hole.


Quartex Pascal is awesome because it's designed to work in both environments. The project type you choose in the IDE determines which "toolbox" your code can use.


  • When you build a Visual DOM Application, you are writing code for the Browser. You'll use all the qtx.dom.* units to create forms and widgets that interact with the user, like TQTXForm and TQTXButton.
  • When you build a Node Project, you are writing code for the Server. You cannot use any qtx.dom.* units. Instead, you'll use the universal, non-visual units like qtx.classes (for TQTXMemoryStream) and qtx.sysutils (for TDataTypeConverter) to build high-performance services that handle files, data, and network logic.


If you have ever written a DLL in Delphi or Lazarus, well -- nodejs would be the DLL in that parallel.