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 flexiblematch
. - 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[...]
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”) TryResult
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.