Show HN: I reinvented PHP in TypeScript (demo)
github.comI built Morph, an experimental fullstack HTML-first library for Deno, Node, and Bun.
Everything returns HTML, not JSON. No React, no Vite — just plain HTML with server-side rendering.
No build steps, no preprocessors, no complex configs — everything runs from a single file.
Perfect for Telegram Web Apps, internal tools, simple admin panels, dashboards, or anywhere a full-blown SPA feels like overkill.
Important: I built this entirely for myself — to solve my own problems. I hate complex frontend. I hate writing it. And I don’t want to waste time on it. But maybe it’ll help you too.
I think this misses one of the main selling points of PHP, the shared nothing, single thread, fire and forget methodology that I can throw behind a load balancer and spin up 100 servers.
You can probably use something like https://www.cgi-node.org/ to get close to the PHP model in the JS world.
But, I wouldn't be surprised if its slower than PHP due to the overhead of starting up NodeJS for each request, as PHP has been optimised to have fast start times.
This project is suggesting Deno, which has rather different startup characteristics to Node, and tuned for Deno Deploy which is already a "serverless" scale-to-zero/scale-as-many-as-you-need-behind-a-load-balancer deployment host. Deno Deploy is a proprietary solution, of course, but not alone in the growing world of JS-based "serverless" (Netlify, Vercel, Cloudflare Edge, and more).
PHP can be multi-threaded, share many things. So can nodejs.
So this is supposed to be following the practices that were common in PHP ten years ago? Modern PHP is not written in such a way where business logic is mixed with templating. For good reason.
For applications you're right.
For trivial scripts, though, that practice is still pretty common. You don't necessarily need Twig or whatever if you just need a script to spit out the rows from a single database query.
Not everything is a big web app. Applying this separation of concerns to everything, and assuming everything will scale into Facebook, brings a lot of needless complexity into what should be simple little pages. Old PHP was great at that, and still is. I’m continually shocked that it has seemed to be the only game in town for decades. It seems like such an obvious use case. Maybe this is a testament to how well PHP solve this space, despite catching a lot of flack online. Similarly to this project, PHP also started out of the developer’s need to manage his Personal Home Page, not large scale enterprise apps.
So many people talk about missing the old Internet and the virtues of the small web, and breaking free from platforms… then at the same time speak out against the tools that allow a person to start small and dip their toe into the water of web development, without needing to spend several months in a boot camp for a few lines of server side code.
My naive question: so if I have node, express, and JS tagged template literals. Is not that what PHP does. Route some url to a html interpolated with code.
What is the add-on from this library? The only thing I read out of it, is some css and other templating benefits. Which is not the essence of PHP. The essence of PHP is that you mix html and code (which many JS tagged templates support).
This goes more in the direction of component oriented development (e.g. what Blazor does... even Angular). So my rant is about comparing it with PHP.
Not a node & browser dev, but I have my past in PHP and currently some Blazor.
php has not been "mix html & code" for the last 10 years if you use it properly
No it's still proper to mix html and php code. You could always use a templating language like smarty 20 years ago so if it wasn't proper 10 years ago it wasn't proper 20 years ago. The truth is <=$variable?> is very readable.
The issue is not the readability, it's that you don't handle how your stuff is sent. Using php as a template language, it starts to send everything until it reaches a Php tag to be executed.
That's why people taught each other that "you absolutely need to make session_start at the beggining of your file". No you don't, but since afterward the content starts to be sent the headers are already too.
I'm not saying you absolutely need to use a framework, but you should have only one echo in your requests.
I've never said the syntax you're saying is bad, I mean pretty much any templating language such has Twig uses this kind of stuff. The issue I have with this is how it works behind the scenes
You mean that the general patterns that people implement when using PHP changed. The language hasn't changed in a fundamental way that prevents it from being utilized in this way.
Yes
This project is cool but the author seems to have never actually touched PHP that he compares it to.
You should call it NodeFusion
The selling point of PHP is the case of deployment on shared gisteren, who either use the pho module with Apache or fpm, or other CGI method. But, as a user, you do not care about this.
Just unpack, set MySQL credentials, and done.
The title originally threw me off but reading the link made me quite like the idea. Keep existing skills and use them in other contexts better suited for the application.
Interesting pattern. This is specially nice to me:
"No build steps, no preprocessors, no complex configs".
I worked on a project recently that followed this and Devs loved it. The DX was amazing.
A lot of people here are comparing it to PHP, but it looks more like python to me.
Oh my god I have to share this with my php friend ahahaha.
Not really. That implies that you’re running each HTTPS call as a lifetime process that starts and ends with that request, and the entire body of the JavaScript file, beginning to end is HTML with subtrees of the document including optionally some JavaScript that is synchronously run.
Respectfully, this doesn’t look anything like that at all.
PHP is a templating languages designed to be so inadequate that you have to implement other templating languages in it.
https://news.ycombinator.com/item?id=32961202
>PHP was already a templating language, but somebody got it in their head that there should be an iron-clad separation between designers and programmers, and that PHP gave designers too much power and confused them, and that their incompetent untrustworthy designers who refused to learn anything about programming deserved something even "simpler" than PHP, so they came up with Smarty.
>Then over time the realized that their designers were powerless, so their programmers would have to learn TWO languages so they could wade into the Smarty templates to make them actually work with all the extra code they had to write because Smarty was so crippled, so they nickle-and-dimed more and more incoherent programming language elements into Smarty, making it EVEN HARDER to use and more complicated and less consistent than PHP, yet nowhere near as powerful.
Modern PHP is not a templating language. It can be, much like many other languages can be, but it's not how it is used. Most other languages also implement their own templating languages. Have you seen modern PHP ... I don't know, sometime in the last 10 or so years, or is this just another circle jerk of hating on something you have little clue about?
Now if you see that as a bad thing, separating business logic and presentation, and sandboxing presentation so it has no larger access to the system, then I'm afraid you're just not a good programmer.
> Modern PHP is not a templating language. It can be
Modern PHP has the same capabilities as PHP 5 had, and more. There was nothing fundamental removed from the language that keeps it from being used as it was in PHP 5.
It didn't seem like they were suggesting otherwise?
Not sure we read the same thing?
Object-oriented PHP, i.e. PHP 5, was released in 2004. PHP 4 was killed in 2008.
Separating out templates was already something one used to do back when Laravel added Blade back in 2010-2011 sometime, in one of the first iterations of the framework. It's not like they experienced pushback because of Blade.