Slide 1

Slide 1 text

1@bryantebeek Comparing the PHP & Node.js ecosystems

Slide 2

Slide 2 text

1@bryantebeek History We switched our technology stack a couple of times and learned a lot in the process

Slide 3

Slide 3 text

1@bryantebeek History Stacks before Lifely + Yii v1.1 + Laravel v2 - v4 v5.2 + v5.3

Slide 4

Slide 4 text

1@bryantebeek History Stacks at Lifely + Laravel v5 + Symfony v2.8 + v3.4 v5.4 + v7.x

Slide 5

Slide 5 text

1@bryantebeek History Stacks at Lifely + + v0.10

Slide 6

Slide 6 text

1@bryantebeek History Stacks at Lifely + + + Meteor v1.2 - v1.6 v0.12 - v8.x

Slide 7

Slide 7 text

1@bryantebeek History Stacks at Lifely + + v4.x - v10.x

Slide 8

Slide 8 text

1@bryantebeek History Stacks at Lifely v0.10 - v10.x v5.2 - v7.2

Slide 9

Slide 9 text

1@bryantebeek History But how do they compare?

Slide 10

Slide 10 text

1@bryantebeek

Slide 11

Slide 11 text

1@bryantebeek Comparing the two Let's take a look at the Node.js and PHP ecosystems

Slide 12

Slide 12 text

1@bryantebeek 1. Architecture

Slide 13

Slide 13 text

1@bryantebeek Comparing the two Single-threaded (uses an event loop) Non-blocking, asynchronous I/O Bad on CPU intensive tasks (blocking) Runs on the performant and actively updated V8 engine (powers Chrome browser) Process exception, whole application restarts if not handled correctly 1. Architecture

Slide 14

Slide 14 text

1@bryantebeek Comparing the two Process pool (FPM) Synchronous I/O Execution failure / crash, much less of a problem Bootstraps whole application on each request (includes DB connection etc.) 1. Architecture

Slide 15

Slide 15 text

1@bryantebeek Comparing the two Overview 1. Architecture

Slide 16

Slide 16 text

1@bryantebeek 2. Development

Slide 17

Slide 17 text

1@bryantebeek Comparing the two Both client and server are written in Javascript, easier to develop full stack (SPA) Need to wait for code to be build on file change No all-in-one frameworks that match the quality of their PHP counterparts Except for the big frameworks, there are a lot of small, actively updated packages 2. Development

Slide 18

Slide 18 text

1@bryantebeek Comparing the two A lot of great frameworks like Laravel and Symfony speed up development Easy local development environments (WAMP / LAMP / Laravel Homestead) Instant able to retest application on code change, no need to wait for builds There are a lot of packages that integrate directly with said frameworks, which make installation a breeze 2. Development

Slide 19

Slide 19 text

1@bryantebeek Comparing the two 2. Development Amount of packages from modulecounts.com PHP averages at 111/day, Node.js averages at 538/day

Slide 20

Slide 20 text

1@bryantebeek Comparing the two Overview 1. Architecture 2. Development

Slide 21

Slide 21 text

1@bryantebeek 3. DevOps

Slide 22

Slide 22 text

1@bryantebeek Comparing the two Less hosting solutions, needs more custom work to run it in production Requires building the code most of the time (Babel, Typescript) Need to watch the main process and make sure it keeps running at all times Docker helps, or other solutions like Systemd or Supervisor 3. DevOps

Slide 23

Slide 23 text

1@bryantebeek Comparing the two Countless of easy hosting solutions online Also means there is a lot of competition, drives down prices Extensions can be a bit of a problem (does your hosting support / include X?) Same holds for upgrading PHP versions 3. DevOps

Slide 24

Slide 24 text

1@bryantebeek Comparing the two Overview 1. Architecture 2. Development 3. DevOps

Slide 25

Slide 25 text

1@bryantebeek 4. Language

Slide 26

Slide 26 text

1@bryantebeek Comparing the two Iterates really fast Javascript a few years ago was worse than PHP Evolved a lot with the recent ECMAScript editions Typescript saves the day. Write fully typed, highly maintainable code (generics, etc.) 4. Language

Slide 27

Slide 27 text

1@bryantebeek Comparing the two Iterates slower, so it's easier to keep up PHP has way better support for reflection than Javascript (Laravel dependency injection) Magic methods can be used in creative ways (Laravel "User::where()") Standard lib functions are inconsistent and aren't methods on their respective primitives (e.g. array_* and str* families) Anonymous functions require the `use` statement and have no shorthand notation 4. Language

Slide 28

Slide 28 text

1@bryantebeek Comparing the two 4. Language $message = 'Hello'; hello(function ($user) use ($message) { return "$message $user!->firstname"; });

Slide 29

Slide 29 text

1@bryantebeek Comparing the two 4. Language const message = 'Hello World' hello(user !=> "${user.firstname} ${message}")

Slide 30

Slide 30 text

1@bryantebeek Comparing the two 4. Language $numbers = [1, 2, 4, 8]; !// 16, 8, 4, 2 implode(', ', array_reverse(array_map(function ($num) { return $num * 2; }, $numbers)));

Slide 31

Slide 31 text

1@bryantebeek Comparing the two 4. Language const numbers = [1, 2, 4, 8] !// 16, 8, 4, 2 numbers.map(num !=> num * 2).reverse().join(', ')

Slide 32

Slide 32 text

1@bryantebeek Comparing the two Overview 1. Architecture 2. Development 3. DevOps 4. Language

Slide 33

Slide 33 text

1@bryantebeek The two at Lifely So why did we switch to Node.js instead of PHP and why you probably shouldn't do the same?

Slide 34

Slide 34 text

1@bryantebeek The two at Lifely Why we made the switch In 2014 Node.js was the all new hype Created bundlin.com in Node.js One of our early customers requested we use Meteor We then used Meteor for one more application Client and server written in the same language MongoDB + NoSQL

Slide 35

Slide 35 text

1@bryantebeek The two at Lifely Why you probably shouldn't Performance is more dependent on how well the backend has been written instead of the actual core architecture Node.js is not magically going to make your application fast PHP ecosystem has great frameworks and CMS-like systems Laravel, Symfony, Wordpress, etc. Easy to deploy, focus on the actual application being build

Slide 36

Slide 36 text

1@bryantebeek Conclusion We settled with Node.js and our custom 'framework', but PHP would really be a viable option as well

Slide 37

Slide 37 text

1@bryantebeek Conclusion Always use the right language for the situation

Slide 38

Slide 38 text

1@bryantebeek Thank you