Show HN: A terminal emulator in pure PHP
75 comments
·March 21, 2025throwaway150
aarondf
Thank you!
aarondf
Thanks for all the feedback! I've updated the readme to use the word "renderer" rather an "emulator."
Gonna stick with the name screen though
atarian
I was hoping for an actual desktop app powered by PHP, which would be really cool having PHP as a desktop runtime.
aarondf
You might enjoy https://nativephp.com/
endofreach
Lol, what? Haven't heard of this... What's your experience with nativePHP?
While i am a defender of modern (!) php for web applications, this does sound rather weird. But also interesting. Thanks for the link.
I wonder though how "native" this is? Glancing over the docs it seems to be built upon tauri / electron? Not as native as i expected, but probably more native than most people would dare to think about...
aarondf
I haven't used it for anything, but it is developed by some friends of mine. It's certainly a novel approach! And they got it working on iOS too
pocketarc
Sibling mentioned nativephp, but PHP-GTK[0] was also a thing in the past!
[0]: https://gtk.php.net
jorvi
I am aware modern PHP is actually pretty good, but having grown up with PHP in the 2000s I can't help but get chills up my spine every time I read '$nonWebThing written in PHP'
zerr
And Delphi for PHP.
felbane
...would it?
I guess maybe if it was PHP8 only...
aarondf
Alas
electroly
I'm a little confused--is it an interactive terminal? Or is it more like an ANSI renderer where you are producing a single static image of the final result of printing a series of bytes? I don't see any JavaScript to hint at interactivity.
aarondf
Nope. Not interactive. It's a library you can use inside of PHP to implement a virtual screen. The readme has some pretty thorough details!
mrweasel
Didn't we have this back in 2001. I seems to remember that we kicked a guy of our project because he installed one of the PHP consoles on our Solaris box, which basically gave it the same rights as the Apache user.
jamal-kumar
It's still a mainstay of certain malware for sure. Just pop in 'php shell' to your favorite search engine, and it's basically all stuff for either red teaming or shenanigans
aarondf
Not sure, I was 12
codetrotter
11 at the time here. For me it would be another 10 years or so before I saw a Solaris box or even knew what one was.
I did encounter, and try, Linux much sooner. But didn’t really “get it” either at the time. Like, I understood that it was neat and different. I installed Mandriva Linux on my machine when I was 13 or 14 or so, but I was lacking any books or guidance to understand how to do anything aside from opening the GUI programs that was on it.
It would take all until the age of 18, when I started at the university, before I got the help I needed in order to understand Linux and editing config files on Linux and writing my own scripts and programs on Linux.
johnisgood
> I installed Mandriva Linux on my machine when I was 13 or 14 or so, but I was lacking any books or guidance to understand how to do anything aside from opening the GUI programs that was on it.
It was Gentoo for me at the age of 13 that a random Hungarian guy from Finland helped install through SSH.
I did try SUSE around the age of 11, nothing interesting though, the interesting stuff came after Gentoo. :D
whalesalad
script kiddies are now going to have high-fidelity shells with 256 colors for when they pwn you and get root on your godaddy drupal install
sidenote: screen is a terrible name for this as there is already gnu/screen (colloquially referred to as screen) which has 38 years head start - https://en.wikipedia.org/wiki/GNU_Screen
also til screen is older than me
pmarreck
Neat tech demo, but I'd never rely on something like this- I can't help but recall the guy who wrote his own security code for MTGOX which resulted in its getting hacked... Please do not build software that you expect to last in PHP.
As a long-time engineer who's maintained systems across decades, the core problem with PHP isn't that it's "not Turing complete" or "doesn't work"—it's that it encourages entropy.
PHP grew organically from a CGI templating language into a "language" without clear design principles. It’s inconsistent (in_array(needle, haystack) vs array_map(callback, array)), mutability is everywhere, and its type system has historically been an afterthought. The result is code that's often hard to reason about, test, or refactor safely—especially once the original author is long gone.
The classic junior rebuttals— "It powers half the web," "Laravel is great," "Modern PHP is typed!"— miss the point. The issue isn’t what can be done in PHP, it's what PHP encourages by default: global state, poor encapsulation, inconsistent APIs, and difficult-to-enforce discipline. These become cost multipliers over time.
Yes, a disciplined team can write clean, testable PHP. But so can a team using punch cards. The real question is: does the language guide you toward maintainable, composable abstractions or away from them? PHP has historically done the latter. Worse, its community normalized things like: ignoring its own test suite failures, tolerating runtime warnings, etc.
When you're 3 years into maintaining a PHP codebase that five devs with differing levels of discipline have touched, you’ll wish the original author had used nearly anything else.
The older you get, the more you realize "strictness and determinism are primal virtues" in coding.
Use better tools. Your future self will thank you.
Also, as someone else already stated, "screen" the name is already quite taken by another venerable tool. (That tells me you're kind of junior.)
Feel free to downvote away, I don't fucking care, because I spent years working on spaghetticode hell of exactly the sort that PHP encourages.
aarondf
Thanks for the... rant? Sorry you've had such a rough time.
I use GNU Screen in Solo, where I also use Solo Screen, so I am aware of it.
https://github.com/soloterm/solo/blob/main/src/Commands/Conc...
deergomoo
> its type system has historically been an afterthought
This is a rather outdated view. PHPs type system isn't the most expressive thing out there, but it's very achievable to have end-to-end type safety these days. For a start it's possible to delineate between nullable and non-nullable types, something many more "serious" languages don't support.
It has the weakness that, not being compiled, you need an additional static analysis tool to catch these things before runtime. But at least it has the good graces to crash if you tell it you're expecting a Foo and you try to pass a Bar, unlike e.g. Python.
Modern PHP is a completely different thing to the 5.x days. Yeah you still have the inconsistent stdlib, but everything has a few warts after 30 years.
dgivney
> The issue isn’t what can be done in PHP, it's what PHP encourages by default:
Lets break this done.
> global state,
PHP is stateless.
> poor encapsulation,
Encapsulation in PHP is mostly consistent with Java.
> inconsistent APIs,
PHP is written in C and an original design decision by those C programmers was to make the APIs consistent with libc.
> and difficult-to-enforce discipline.
Its very easy to enforce. All modern projects would run tools like Pint, Phpcs & Phpcbf to enforce their code standards and preferred style in their CI Pipeline.
hnlmorg
> PHP is written in C and an original design decision by those C programmers was to make the APIs consistent with libc.
Old PHP did have some pretty inconsistent naming conventions (or lack of). Which is what I think the GP was referring to.
I’ve not written any PHP in quite a few years but I’ve read that there’s been a concerted effort to address those inconsistencies and the old complaint is now just a relic of a bygone era.
One thing I have learned over the several decades that I’ve been writing software is that literally every language could have a book written about its problems. People often seem to forget that language design is a constant battle of tradeoffs. And because their preferred languages naturally align with their tradeoff preferences, they don’t even realise that their own preferences are deeply flawed for a great many type of scenarios too.
So it really disappoints me when people subscribe to language tribes like it’s their religion.
etothet
It is completely possible to have a PHP application written 3+ years ago that is well maintained, continues to promote best practices, has excellent test coverage, that isn’t a nightmare to deal with. It’s also possible for the opposite, but that’s the case with every language. In my 20+ years of professional experience, the biggest factor come down to what values a team sets as priorities.
lpapez
You come across as pretty opinionated and eager to comment for someone who states they don't care.
I work with spaghetti PHP every day. It pays the bills. There are far worse jobs out there.
The expert wishes to fix the tedious tasks. But a true master understands that all tasks are equally tedious.
Relax and enjoy the ride.
chasil
I have some Oracle Pro*C code that is infinitely more pleasant to use when I rewrite it in PHP.
I don't think the PHP version has greater entropy than the compiled C.
fancyswimtime
we need low barrier to entry langs, it affords some a start. Also The php symfony components are very well written; I recommend giving them a look
calvinmorrison
as your average PHP enjoyer, I agree with all of these complaints, but also will note
- you really need to train the team on PHP footguns, which are as bad as C foot guns
- finding PHP programmers is easy.
- your shits already written in PHP
- in the same way rolling your own stdlib in C is silly, leverage good PHP frameworks
ymmv but its not that bad. at least it keeps my day exciting.
cf100clunk
Nice, but your terminal app has a name collision with the long lived ''screen'' terminal multiplexer utility:
aarondf
Thanks for your feedback!
cf100clunk
To me, name collisions are only a big deal if the app or project exists in very similar use case scenarios. In this case, I'd say confusion could easily happen if ''screen'' replaced ''screen'' in the path or a call. How about "Soloterm"? Have you thought of others?
jeffhuys
Not only confusion, but inability to just install on mac/linux, right? I believe both come with screen by default…
Edit: let me actually think a bit before commenting - it would probably just install, but then you run screen and you might or might not get your newly-installed software (so yeah confusion). Not a great first experience at worst
aarondf
It's a package you install into your PHP application. It's impossible for it to collide.
null
null
null
bschmidt501
[flagged]
bschmidt310
[flagged]
Commendable work but note that this is not a terminal emulator. This is a terminal renderer.