How THT Compares to PHP
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.
- 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.
- Regex strings are 1st class objects. e.g.
- No variable references
- Can use negative indexes to count from end of List.
- List append syntax changed from
- String concatenation operator changed from
//for line comments. No
- Nested block comments
/* ~ */are supported.
switchreplaced with more flexible
- Long numbers can use underscore separators
- Bitwise operatorss changed to
&&=- OR and AND assignment.
&&:- OR and AND value (coalesce).
- One-line block syntax. e.g.
if true: $a = 1;
- Lambda expressions via
- Quoted lists via
See Intermediate Features
- Closing HTML tags do not need a label
- Selector style HTML tags. e.g.
- One-liner HTML tags e.g.
<h1>> My Heading
See HTML-C Shortcuts
- Each file has its own namespace. No implicit globals.
- Variables and functions are validated at compile time.
- Globals managed via
- 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
==does a strict comparison.
- No warning suppression via
- Can’t use math on non-number values. e.g.
3 + 'cat'
null. (see “The Billion Dollar Mistake”) Try
- Declared argument types are always run in strict mode.
- 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.
- 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
- Source files are hosted outside of Document Root.
- Only source files in
pagesdir are directly executable.
- Web, File, and System modules escape output automatically. (XSS)
- High risk PHP functions like
- 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
- Password objects use
password_verifyto prevent timing attacks.
- File uploads are validated and sandboxed with random names.
- Uploaded images are re-processed and resized, stripping possible attack payloads.