Client Side PHP

Exploring PHP Compilation to Web Assembly

Unlocking the Potential of PHP for Web Browsers

In the realm of web development, the possibilities are ever-evolving, and the advent of WebAssembly (Wasm) has opened new doors for programming languages traditionally used on servers. Among these languages, PHP, a stalwart of the web, may seem like an unlikely candidate for browser-based execution. However, with the aid of Oraoto’s compilation scripts, achieving a PHP WebAssembly build that mirrors the functionality of PHP on a server or in a command-line interface (CLI) is more achievable than one might imagine.

The Ease of Compiling PHP to WebAssembly

PHP is renowned for its versatility, serving as the backbone for countless websites and web applications. Transitioning it into the browser environment may sound complex, but Oraoto’s compilation scripts streamline the process. These scripts facilitate the creation of a PHP WebAssembly (Wasm) build that faithfully reproduces PHP’s behavior on a server or in a CLI.

While there are certain limitations to the current implementation, such as the ability to only evaluate code and receive printed PHP lines, the potential for crafting innovative solutions remains vast.

Constructing a Playground for Laravel Collections

Laravel’s collections have won the hearts of developers for their ability to simplify working with arrays of data. However, mastering the nuances of these collections can require some trial and error, often involving a back-and-forth between code and documentation. Creating a Laravel collection playground in the browser, reminiscent of JSFiddle, offers an excellent opportunity to explore PHP in a browser context while building something exciting.

For those eager to experiment, the repository on Github provides an interactive platform for hands-on exploration.

The Inner Workings of the Playground

The Laravel Collection Playground relies on a compact PHP package that receives input JSON data and collection code from Vue. This code is then compiled into a Phar (PHP executable) file alongside Laravel’s collection component. The process involves converting JSON data into a collection and using the eval function to execute the provided collection code. Any results or errors, including caught Exceptions or Throwables, are encoded into JSON format and presented to the user. In the JavaScript environment, the PHP’s stdout is connected to display the execution outcomes, offering a surprisingly seamless experience. Furthermore, thanks to Progressive Web App (PWA) support, this playground can even be used offline.

Exploring the Potential of Running Laravel Client-Side

Imagine a world where you can run an entire web application built in Laravel entirely on the client side—truly serverless. To embark on this journey, we looked at the TodoMVC project, a standard framework testing ground, as a suitable candidate.

The first challenge we faced was making requests to Laravel, considering that no web server was in operation. Traditional web requests were out of the question, prompting us to devise a creative solution. Our approach involves running the Laravel framework with a mocked PSR7 request, akin to how the framework operates during integration tests. To facilitate this, we encapsulated the framework’s request cycle within a function:

After a successful console test, Laravel and all its dependencies are bundled into a Phar file. This Phar file is then integrated into the WebAssembly binary. Notably, due to the utilization of SQLite, application state persistence between (simulated) requests is achieved. However, this state is reset upon each reload, as the storage is temporary.

Experimenting in the browser’s console, you can add new todo items and make requests to the index method, effectively simulating an interactive web application.

Concluding Thoughts on PHP in the Browser

While the concept of running PHP in the browser is undeniably intriguing and opens doors to novel possibilities, it comes with its own set of challenges and limitations. Here are some key takeaways:

1. Performance Considerations: PHP in the browser can be approximately five times slower than its traditional server-side counterpart.
2. Resource Intensiveness: It consumes over 1GB of memory during startup, which may pose performance issues on lower-end devices.
3. Browser Compatibility: The technology is primarily compatible with recent desktop versions of Chrome, Firefox, and Safari, limiting its accessibility.
4. Compilation Overheads: Compiling a WebAssembly build can be time-consuming, especially for code changes, as it’s required each time.
5. Limited Functionality: PHP in the browser is confined to the capabilities of JavaScript, meaning certain functionalities, such as web requests, are unavailable, restricting its potential.
6. Download Size: Users need to download the entire PHP build and associated code (unless cached client-side), resulting in a substantial file size of around 4MB.
7. Debugging Complexity: Debugging can be challenging, as the available debugging information is limited, offering little insight beyond PHP’s exit codes.

In conclusion, while PHP in the browser is a fascinating concept, it currently faces several practical hurdles that need to be addressed for widespread adoption. Nevertheless, its potential for innovation and exploration in the web development landscape remains undeniable. As technology continues to advance, we can anticipate further developments in this exciting field.