Sebastian De Deyne has a tutorial posted to his site showing you how to use two packages to render Javascript on the server side via PHP.

Server side rendering is a hot topic when it comes to client side applications. Unfortunately, it's not an easy thing to do, especially if you're not building things in a Node.js environment.

I published two libraries to enable server side rendering JavaScript from PHP: spatie/server-side-rendering and spatie/laravel-server-side-rendering for Laravel apps.

Let's review some server side rendering concepts, benefits and tradeoffs, and build a server renderer in PHP from first principles.

The tutorial starts with a look at what "server-side rendering" means in this case, how it works with the browser and some of the benefits. It then talks about the rendering process and some of the tradeoffs between it and just using Javascript on the frontend. From there the post gets to the examples of the actual rendering process. If creates a simple Vue.js application that outputs a "Hello, world!" template. It then includes the code to use the packages (that, in turn, use the V8JS package) to render the Javascript and output the result.

On the Symfony Finland blog there's a new tutorial posted sharing the results of their effort to get React.js to play nice with Twig, a popular PHP templating library, via a server-side generated template.

React.js is a JavaScript view library that allows developers to create interfaces is a structured way based on a hierarchical component structure. React can either create the DOM structure from scratch, or attach to an existing one rendered by the server to speed up the first load.

If you create Twig templates that match the React rendering, you can take advantage of this feature without a complicated rendering setup.

While there were other methods created to try to solve the problem (rendering the React.js template on the server side) they show a better way via React.js 16 and Twig templates. Code is included showing how to create a simple React application, and how to hook in Twig via a "hydrate" call to pull in the content. React.js has a bit of an issue by default but a little extra work on the Twig side fixes that (see the post for the solution on that one).

On the Slack Engineering blog there's a new post from one of their engineers talking about a choice the company made about their platform - they decided to take PHP seriously. In this post author Keith Adams talks about why they chose PHP and what kind of experiences they've had with it in their own environment.

Slack uses PHP for most of its server-side application logic, which is an unusual choice these days. Why did we choose to build a new project in this language? Should you?

PHP-the-language has many flaws, which undoubtedly have slowed these efforts down, but PHP-the-environment has virtues which more than compensate for those flaws. And the options for improving on PHP’s language-level flaws are pretty impressive. On the balance, PHP provides better support for building, changing, and operating a successful project than competing environments. I would start a new project in PHP today, with a reservation or two, but zero apologies.

He starts with some background on the history of PHP itself, where the language came from and what kinds of issues it tries to mainly solve. He then gets into some of what he sees are the "virtues of PHP" including the blank slate at the start of every request, one-request-one-process concurrency and the fast programmer workflow. He then gets into the "bad stuff" they've found when working with PHP, things like surprise type conversions, a "failure-oblivious philosophy" and inconsistencies in the standard library. Finally he looks into two options (created by Facebook to improve its use of PHP) - HHVM and the Hack language - and how it was integrated into their environment.

Frank de Jonge has posted a tutorial to his site showing how you can render React.js templates server-side in PHP. He makes use of the V8JS extension to execute Javascript inside of PHP and echo out the rendered result.

The last couple of months I've been working with ReactJS quite extensively. It's been a very rewarding and insightful journey. There is, however, one part that kept coming back to me: server-side rendering. How on earth am I going to use ReactJS when I want to render my templates on the server? So, I sat down and looked at the possibilities.

He suggests two options, running a small Node application or using the V8JS extension, and opts for trying the second option to meet his needs. He talks about the "why" of rendering server-side JS and gives a brief introduction to V8JS and the workflow he'll follow to use it. He helps you get this library via Composer to make working with it easier and provides an example of how to use it. After trying out this method, he then goes back to option #1, the small Node application (what he ended up choosing). He walks through the setup of this application, showing how to set it up inside a Lumen application and using Express to output the generated templates and data. He then hooks this into the PHP application via a simple HTTP client grabbing the results and pushing them back out to the page.

In a a previous post Stoyan Stefanov introduced a setup where you could render React templates on the server-side with the help of PHP and the v8 parsing. In this second part of the series, he extends that system and shows how to use it to update views based on new data.

Part 1 ended with todos. The first one was to couple the server-side generated code with the client-side React, so that any updates past the initial page load will be handled by React's client JS, which is where React shines. Let's see how you can do just that.

He gives an example similar to his previous one - displaying a table - but shows how to inject some values from PHP as a JSON string into the component. This time he saves the output of that rendering into a variable and reuses it as a part of a whole site render later.

In a new tutorial posted to PHPMaster.com today, Lukas White talks about using the Browscap functionality to do server-side device/client detection in your applications.

An alternative solution to the problem is to use server-side device detection and then take certain actions based on that information. One possibility is to simply forward requests for a mobile site to a different URL. Another possibility is to adapt the layout – or indeed content – programmatically as it’s generated on the server. Taking a server-side approach is the basis of this article, which looks in detail at the Browser Capabilities Project, or Browscap for short, to provide the information on which to base these decisions.

He starts with some of the basics - User-Agent strings that most devices will send to your site and their structure. He then talks about the Browscap project and the PHP support for its use. He shows how to get it all installed via Composer and how to use the "browscap-php" library to get the current browser information. He includes an example of the output and shows how to use this to redirect the user to a mobile site if needed. He also adds in a bit at the end about using it for layout switching or for showing the user the correct download links based on their client.

New on the L2Admin.com site today is the first part of a series they're doing comparing three of the popular server-side scripting languages for web development - PHP, Perl and Python - and what benefits each can give.

For a very long time I have wondered if there were any real benefits between Perl, PHP or Python from a performance standpoint [...] So after much wondering I have decided to answer the question for myself once and for all. I am going to perform three tests that I think typify the use cases for all three languages, I am also going to code the same tests in C and in static HTML.

This first post shoes the results from the most basic of tests - a "hello world" that's echoed out to the page. He ran the tests with Apache's ab tool for 10,000 times and recorded the request per second, average request time and the overhead as compared to plain HTML. It's interesting to see the jump from the HTML baselines when the languages start getting involved with the stock PHP install coming in as the slowest of the group.

On the SitePoint "Server Side Coding" blog, there's this look at caching to help solve some PHP performance issues.

In the good old days when building web sites was as easy as knocking up a few HTML pages, the delivery of a web page to a browser was a simple matter of having the web server fetch a file. [...] Then dynamic web pages came along and spoiled the party by introducing two problems: a delay for processing and a check of the file's age before it's sent to the browser.

They talk about what caching can do for you, what you can do (both server and client side) to prevent caching, working with the headers sent from and back out to the browser, using output buffering, partial caching and using PEAR::Cache_Lite in your application.

On the SitePoint "Server Side Coding" blog, there's this look at caching to help solve some PHP performance issues.

In the good old days when building web sites was as easy as knocking up a few HTML pages, the delivery of a web page to a browser was a simple matter of having the web server fetch a file. [...] Then dynamic web pages came along and spoiled the party by introducing two problems: a delay for processing and a check of the file's age before it's sent to the browser.

They talk about what caching can do for you, what you can do (both server and client side) to prevent caching, working with the headers sent from and back out to the browser, using output buffering, partial caching and using PEAR::Cache_Lite in your application.

Many thanks to Raphael Stolt for letting us know about his latest post, a tutorial on using the Zend Framework with Ajax to perform a server-side identification request.

He used a "@ajaxaction" marker in a previous article to implement the Ajax requests, but with other tools there could be an issue with the response. To help with this, he's worked up a handler to detect what needs to be done with the response. He applies this to create the authentication system, making it easy to include a simple ACL method into his application.

He includes code examples for the Controller to handle the detection, how to implement it, and the class to work with those "doclet" markers for the Ajax actions.