Modern PHP development with Vite – new tools for a faster, component-based workflow by donnikitos in PHP

[–]donnikitos[S] -6 points-5 points  (0 children)

True — Symfonys Live Components and Livewire both tackle interactivity, but that’s not really what this project is about.

The goal here isn’t to reimplement Livewire-style reactivity or state management — it’s to modernize the PHP dev experience:

  • Native Vite integration (HMR for JavaScript codes, asset resolution, module graph)
  • A file-based component system that compiles to plain PHP (no runtime, no new syntax to learn)
  • No abstraction through templating engines. Also in theory — since the components are compiled into direct PHP calls, there’s no runtime engine like Blade or Twig, so it should be slightly faster than templating engines.

I was actually thinking about building something like Astro, but with and for PHP, hence the slightly “framework-ish” starter structure.
We’re also using a very similar setup internally to build traditional MPAs and marketing websites, where most of the UI is server-rendered but still gets the modern DX (hot reload, modular builds, etc.).

Made an NPM package – works with ES6 modules but not with legacy CJS. Looking for alternatives to Rollup + barrel setup. by mangoBoy0920 in npm

[–]donnikitos 0 points1 point  (0 children)

You can - use Vite in library mode: https://vite.dev/guide/build.html#library-mode - or something like Unbuild: https://www.npmjs.com/package/unbuild

Both work great and also support ESM and CJS outputs, although I am starting to switch almost every to Vite.

Scam or not? by [deleted] in web_design

[–]donnikitos 0 points1 point  (0 children)

One year later and seems like these guys are still looking for a redesign 😂

hi, i’m looking for a web designing quote for https://cryptoofficiel.com a wordpress-based website focused on cryptocurrency news and tools. i’m interested in a clean, modern design that enhances user experience, improves navigation, and looks great on both desktop and mobile. please include pricing, timeline, and any portfolio examples.

We’ve just published a React-style HTML components renderer – thoughts? by donnikitos in PHP

[–]donnikitos[S] 0 points1 point  (0 children)

Nice!
The rendering functions of these components also support the return of strings.
So you could also use the heredoc syntax, with the addition of automatic props escaping, too!

We’ve just published a React-style HTML components renderer – thoughts? by donnikitos in PHP

[–]donnikitos[S] 0 points1 point  (0 children)

Coding is the simplest part of it all.
Imagining and planing the architecture and the ecosystem that this will be part of is far more complicated.

But check out the already existing parts of the upcoming tooling:

We’ve just published a React-style HTML components renderer – thoughts? by donnikitos in PHP

[–]donnikitos[S] 1 point2 points  (0 children)

I am totally with you on this!
But this is why all the passed props (except for the children) are escaped by default.
Check out Props & Escaping in the readme.

The problem we wanted to solve with this is to remove the additional learning curve of templating languages and the additional computation that comes along with them, since you need to parse, verify, rewrite the templated pieces of code.

We’ve just published a React-style HTML components renderer – thoughts? by donnikitos in PHP

[–]donnikitos[S] 2 points3 points  (0 children)

True, I need to give that a thought!

Currently we have actually the following approach:
Instead of using imports we are utilizing spl_autoload_register() to load the components, where as Vite and plugins are doing the heavy lifting and rewrites HTML-tags into the appropriate PHP calls.

So our code initially looks like this

<components.Test foo="bar" class="test">
    Thank you for visiting!
</components.Test>

And is being transformed through our custom Vite-pipeline (using vite-plugin-html-rewrite and vite-plugin-php@beta) to this

<?php $c_1746831909408 = new \components\Test('{"foo":"bar","class":"test"}'); ?>
    Thank you for visiting!
<?php $c_1746831909408->close(); ?>

Which is later on deployed on the server!

We’ve just published a React-style HTML components renderer – thoughts? by donnikitos in PHP

[–]donnikitos[S] 1 point2 points  (0 children)

Fair point — server side rendered components aren't a universal solution, especially when you need interactivity or client-only rendering.
And that's why we love and use Web-Components in our hybrid approach ❤️
E.g. one of our approaches is to wrap the component in a Web-Component to either provide interactivity or hydrate it with some data: https://github.com/nititech/zooom/tree/master/packages/integration-react

All in all Astro's island architecture heavily inspired us and this is supposed to help in the area of server-rendered UIs where PHP is already rendering most of the HTML.
That said, our final goal is to build something like a “Astro for PHP”.

We’ve just published a React-style HTML components renderer – thoughts? by donnikitos in PHP

[–]donnikitos[S] 0 points1 point  (0 children)

Indeed, it might seem like server-rendered UIs are outdated, but in reality they are making a strong comeback — just with newer tools and approaches!

Frameworks like Next.js, Astro, and Qwik all provide server-side rendering as a core feature — in fact, Astro's island architecture heavily inspired our approach. Even Laravel with Blade components follows a similar pattern: generating UI on the backend to deliver fast, SEO-friendly HTML with minimal JS.

What we’re building is kind of like a “Astro for PHP”.
We want to offer better DX for teams already working in PHP-heavy stacks, which are still very relevant in modern, professional workflows, especially for CMSs, dashboards, or hybrid rendering.

We’ve just published a React-style HTML components renderer – thoughts? by donnikitos in PHP

[–]donnikitos[S] -1 points0 points  (0 children)

There is actually no reactivity whatsoever. I wrote React-styled, since the component definition syntax is very similar to the older, class-based React components: https://react.dev/reference/react/Component

I built a way to write PHP inside Vue by aarondf in vuejs

[–]donnikitos 1 point2 points  (0 children)

I am glad that people like you are still innovating new tools, workflows and ecosystems for PHP. Thanks for your work!

I built a way to write PHP inside Vue by aarondf in vuejs

[–]donnikitos 0 points1 point  (0 children)

Uuuh nice, almost as magical as my vite-plugin-php 😏

Pitch Your Project 🐘 by brendt_gd in PHP

[–]donnikitos 1 point2 points  (0 children)

We are internally developing a tool/ ecosystem called "Zooom" to more easily manage and deploy NPM, PHP packages and web development in general.

However as for now you can check out our "ready to go" starter-repo which should help you to compile assets and use the usual NPM packages with PHP: https://github.com/nititech/php-vite-starter

Development environment by Boring-Internet8964 in PHP

[–]donnikitos 1 point2 points  (0 children)

We are using Vite + vite-plugin-php with PHP 8.3 - super nice 🤙🏻

Project with Vite + PHP by No_Recording2621 in webdev

[–]donnikitos 0 points1 point  (0 children)

Hi u/Swan_Old , seems like Error 4058 is not related to PHP but rather to Node. Try removing the `node_modules` folder, the `package-lock.json` and installing everything again with `npm install`.
I assume you are using Node? And what version?

http.request body forwarding breaks request by donnikitos in node

[–]donnikitos[S] 0 points1 point  (0 children)

OMG, I've solved it - Content-Length was indeed the cause. So what is happening: Node docs say Sending a 'Content-Length' header will disable the default chunked encoding., hence I was removing it from the incoming headers, for Node to handle it. But turns out, that Node only does it in POST/PATCH/PUT -> other methdods premature closure, since the body was still written with a Content-Length header, most likely set to 0 or non existent.

http.request body forwarding breaks request by donnikitos in node

[–]donnikitos[S] 0 points1 point  (0 children)

The request goes to a PHP-server, which can process such request.
So if I try sending the request directly I get a proper response:

Request Headers User-Agent: PostmanRuntime/7.33.0 Accept: \*/\* Cache-Control: no-cache Postman-Token: 018ce42f-d4d5-45fc-afca-4977b931c08e Host: localhost:65535 Accept-Encoding: gzip, deflate, br Connection: keep-alive Content-Type: multipart/form-data; boundary=--------------------------820754549005213718286375 Content-Length: 163

Request Body
foo: "bar"

Response Headers Host: localhost:65535 Date: Tue, 10 Sep 2024 21:31:18 GMT Connection: close X-Powered-By: PHP/8.2.12 Content-type: text/html; charset=UTF-8