How THT Compares to PHP

Overview 

PHP has a lot of good parts:

• Available on nearly every platform & web host
• A simple, atomic (“share nothing”) request cycle
• No build steps — just edit & refresh
• Apache integration is fast and requires no administration
• Large library of built-in commands
• Accessible to novice programmers
• Big performance gains in PHP 7
• See also Taking PHP Seriously (article)

But it also has a lot of shortcomings, which include:

• A haphazard language design
• A massive, disorganized standard library
• An inconsistent approach to error handling and reporting
• Key features that are insecure by default

About This List

The following is a mostly-complete list of differences between THT and PHP.

Some features are meant to address flaws in PHP directly. Others are intended to provide a more consistent experience overall.

Syntax 

• Dot operator . for method calls.
• Parens in control statements are not required.
• Separate Map and List types, instead of one Array type.
• JS literal notation for Maps instead of [key => value]
• Quote fences ''' for multi-line strings.
• Only single-quoted strings. 'my string'
• Regex strings are 1st class objects. e.g. r'\d+'
• No variable references &$foo.
• Can use negative indexes to count from end of List.
• List append syntax changed from [] = to #=.
• String concatenation operator changed from . to ~.
• Only // for line comments. No #.
• Nested block comments /* ~ */ are supported.
• switch replaced with more flexible match.
• Long numbers can use underscore separators 1_000_000.
• Bitwise operatorss changed to + prefix. e.g. +|, +&

Convenience 

THT Syntax

• ||= and &&= - OR and AND assignment.
• ||: and &&: - OR and AND value (coalesce).
• One-line block syntax. e.g. if true: $a = 1;
• Lambda expressions via x{...}
• Quoted lists via q[...]

See Intermediate Features

HTML Syntax

• Closing HTML tags do not need a label </>
• Selector style HTML tags. e.g. <h1.myclass>
• One-liner HTML tags e.g. <h1>> My Heading

See HTML-C Shortcuts

Safety 

• Each file has its own namespace. No implicit globals.
• Variables and functions are validated at compile time.
• Globals managed via Global module.
• No “variable variables”.
• Full stack trace on all runtime errors.
• PHP-level errors and warnings are fatal.
• Standard library uses exceptions, not error codes.
• Function argument type declarations are strict.
• No database, file, or system calls allowed in templates.
• No assignment inside of conditionals. e.g. if a = 1
• All string methods support UTF-8 via mbstring.
• No ===. Instead, == does a strict comparison.
• No warning suppression via @.
• Can’t use math on non-number values. e.g. 3 + 'cat'
• No null. (see “The Billion Dollar Mistake”) Try Result instead.
• Declared argument types are always run in strict mode.

Consistency 

• Standard library is organized into modules and classes.
• Standard library is curated, with more consistent interfaces.
• Function names are case sensitive.
• Only camelCase variable and function names.
• Default charset is UTF-8.
• HTML output is not the default mode. No <? ... ?> tags.
• Unified code formatting via Format Checker.

Security 

• Introduces TypeStrings to prevent injection attacks.
• Db module requires TypeStrings. Uses PDO placeholders underneath.
• Input from different sources (GET, REQUEST, etc.) are not intermixed.
• Input data is only accessible through validation methods.
• Input data is stripped of NULL bytes to prevent Null Byte Poisoning.
• File functions do not work on URLs.
• File functions are sandboxed to the data directory.
• Source files are hosted outside of Document Root.
• Only source files in pages dir are directly executable.
• Web, File, and System modules escape output automatically. (XSS)
• High risk PHP functions like eval are forbidden.
• Default HTTP response headers are set to secure defaults.
• CSP response headers added to prevent client script injection.
• HSTS response headers added to all non-localhost apps.
• Redirects to external URLs are restricted.
• Security workarounds are prefixed “dangerDanger-” for easier auditing.
• Internal THT security functions are in a single module for easier auditing.
• Randomization functions use cryptographically strong methods.
• THT & PHP settings are read-only, not changeable at runtime.
• Non-GET requests are protected with a per-request CSRF token.
• Non-GET requests must come from the local domain, by default.
• All cookie data is kept server-side. Uses a single client-side cookie ID.
• Session settings have secure defaults.
• Database passwords are stored outside of config files, in Environment variables.
• Password inputs are automatically hashed with bcrypt.
• Password objects use password_verify to prevent timing attacks.
• File uploads are validated and sandboxed with random names.
• Uploaded images are re-processed and resized, stripping possible attack payloads.