My Journey from PHP & Wordpress to FullStack Javascript

15 min readMar 5, 2019

For my first fullstack javascript app I built, Power Todos, a more advanced personal todos app than the typical beginner todos app. It tracks tasks for every todo and can store notes for every task. It was built with React, Express, Node, Postgres. It uses Redis, Redux, React Router and more…

My Background in Programming: PHP, JS, jQuery

I am a php developer, as much as one can be coming from Wordpress. I have built very large, complex plugins for Wordpress and hacked the heck out of its ecosystem for nearly fifteen years. I am proficient with MySql. I have had to optimize performance for websites and networks of websites and am well versed in SQL Stored Procedures and writing proper queries.

My specialty has been search engine optimization. I am hyper aware of small things such as compressing css and js files, properly sizing and minimizing images, descriptively naming URLs, using proper 404 pages and headers, blocking bad bots in the robots.tx file, writing clear h1-h5 headers with organized, keyword dense paragraphs, while always maintaining a clear dom hierarchy, using proper anchor texts in links and creating a buzz to get as many other websites linking back to your site as possible.

However, that skill has lost much of its significance the past few years. Now, all that really matters is social traction. And I would be a great social media supervisor, if I didn’t loathe social media.

I am proficient with vanilla javascript, jQuery and AJAX, though I strayed from programming altogether when the industry took a turn towards OOP. I have built some pretty comprehensive php sites from scratch with no framework, which forced me to learn the ins and outs of things like encrypting passwords, verifying registrations via email confirmation using tokens, storing sessions on the server, keeping users logged in with cookies, and the biggest headache of all, dealing with dreaded cross-browser compatibility issues.

I was about to make the switch to Node/Express a couple years ago, and then PHP 7 came out. It allocated memory better than ever and my servers’ loads were eased, making a switch to a different technology unimportant. Scaling was not as much of a problem with the use of SSD hard drives, meanwhile, simple increases in RAM made my sites run super fast. And then there was the holy grail of all performance optimization techniques: caching sql queries and results. So I never felt the need to move my companies to fullstack JS or any other technology after that.

And Then There Was Node

As much as I have used PHP in the past, I find it frustrating and working with Wordpress has made what remains of my hair jump right out of my head. Plus, I know Node is the future and I refuse to be left behind.

So for the past two years I have studied JS extensively. I read everything by Eric Elliott (about ten times each). I ran through FreeCodeCamp a couple times, took a number of Udemy courses, watched and followed all the Fun Fun Functions, did 30 in 30 by Wes Boss, and I even joined the Hack Reactor bootcamp remotely. Ps — the free prep course Hack Reactor requires before entering is one of the best javascript training tools on the web. But, I dropped out of Hack Reactor the day before classes were to begin because my wife and I excitedly learned we were pregnant with our first child!

A few months after my boy was born I dove back in to learning, this time with more determination to follow through and a better base knowledge of javascript in general. I decided it was time to start building things.

I first found Net Ninja’s courses and I built a Project Manager that taught me about React, Redux and Firebase/Firestore. I then took Andrei Neagoie’s two courses, ‘Zero to Mastery’ and ‘From Junior to Senior Developer,’ on Udemy, and learned all about Node, Express, Postgres, Redis, middleware, libraries, reading documentation, best practices, and much more, including more practice on React and Redux.

React Redux

Redux was the first difficult JS concept to grasp. This is when I realized, after frustration comes progress. I know that if you give up every time you get frustrated, or think you are just not smart enough to do this whole programming thing, you will never make it. So I gave myself a few days to let my brain fully understand actions and reducers. I left the computer several times to go explain the concepts I learned to my wife. She did not care, but that was okay. I found I needed to step away from the computer and explain concepts out loud, from my head, in order to fully grasp them. And she even helped me a couple times when what I said didn’t sound to her like it made sense. Explaining it to her forced me to truly understand the topic. Not that she would remember anything I told her, but I did find that when I was able to tell it to her so she got it I knew I got it.

Eventually, I completely understood Redux and then I was like, why did I think this was so hard? It’s so simple…

You create a store, you make the store available to your app, you pass the props from the store to components that will use them, you pass actions that you create to components that will use them, in your actions you dispatch the type of action that was called, in your reducers you set watch for the type of action that is dispatched from the action, and then you update the store appropriately. Simple! (j/k)

Postgres & Knex

Fortunately, I already have a good understanding of SQL so Postgres was easy for me. The biggest thing I actually learned is that it is a bit too simple of an SQL implementation for my taste. I don’t like that you can’t do little things like reorder your columns after you create a table. Not really a big deal, but it made me realize the lack of control available to Postgres users. I also wasn’t able to change a column’s type after it was created, instead, I had to delete the column and add it fresh. But what happens if you want to change the type a year into the app? You can’t just delete a column and re-add it again. Again, I’m sure there is something I am missing here, but I couldn’t find it.

I used Knex, which is an SQL querying language library for an express backend. This made me a little uncomfortable, after all, if I already knew how to write proper queries, why would I need a library to do it for me? I also couldn’t find answers in the documentation as to whether they actually used placeholders, or did other things to protect against injection behind the scenes. I had to trust someone on Stack Overflow who told me they did.

Firebase/Firestore

I have not used this extensively, but the concept of having data live update from one screen to another is thrilling! This makes me excited for the future, and makes my brain churn with ideas. However, most of my brain is thinking how I can implement Firebase with some of my previous PHP websites and most of the answers that I found were that it can be done, but there were going to be limitations because Firebase was not really built with PHP in mind. Thus, another reason why I have to accept that Javascript is the future.

Post Course Work : My First Fullstack JS App

After the courses I went out and built my first fullstack javascript web app, Power Todos. I built it because I needed it. I had so many todos in my mac Notes app and so many Tasks for each todo, I knew I needed a better system, and building a fullstack todo app would be the perfect exercise for implementing all of my new knowledge.

PWA, Serving .txt, or .html Files, & HTTPS

My Power Todos app became a proper progressive web app, which meant learning how to properly setup a proper manifest.json file. In PHP I always wanted my websites to also be PWA’s but the learning curve seemed too steep. In React, this was truly easy. Just adjust your manifest.json file in the public folder, add the proper icons using this cool generator, and make sure your site is using https instead of http (plus a few other small thing.)

Speaking of https. This was much different than a php site. In a php site, typically, the host provides the certificate for you. Just tell them you want it and they set it up for you. Not so simple in a javascript stack.

I used LetsEncrypt.org to create the SSL certificate. Then I used the certbot CLI. It was a bit frustrating because I had to verify my certbot installation by uploading a file to my site but I didn’t have a site, I had an app, that had one root index page. This was another difference between a PHP site and JS one.

In PHP this is simple. You create a file and upload it via your ftp software. This is not the case with a React app on Heroku. Ultimately, Stack Overflow gave me the answer. Put the file in your public folder. Then, in your BrowserRouter, assuming you are using React Router, which I was, create a path to the file with an onEnter={reload} tag like this…

Then, add the reload script in your render method above the BrowserRouter:

const reload = () => window.location.reload()

The Unknown: Command Line & Git

Before I started learning javascript a couple years ago I knew nothing of the command line. I used Sublime to write code, but I never used Emmet or other platform specific plugins to speed up the process. I uploaded files via ftp software like CuteFTP and Transmit. I never had to manually restart a server or SSH into a remote server. I mainly bought dedicated servers or virtual servers and used hosting company tech support to handle networking issues.

I was also a little nervous about github. I use git on my local computer and I love the idea of reverting a change after I take a site down a wrong path, but I have yet to work on a team, create meaningful branches or handle real pull requests. But pushing my site to Heroku has forced me to get into the habit of git add . — git commit -m ‘message’, git push heroku master.

I am still a bit scared about not getting all of the great Apache tools that come with a server such as email setup and mailbox software like Roundcube, spam detection software, built-in stats programs like AWStats, and even php MyAdmin which makes viewing db tables as simple as logging in.

Testing

One of things that annoyed me the most about this new Node world was having to write manual tests. Hack Reactor was big on this when they made us rewrite the underscore library so I knew the importance, but I hated the process. I never understood why you needed to waste your time writing so many useless tests and PHP did not push test driven development at all.

BUT… it finally clicked with me why testing is so important when, at the end of my process of building Power Todos, I had to rebuild something…

Sessions

The very last thing I added to Power Todos was session management. I tried doing it the same way I did in php, which meant storing the sessions on the server and authorizing users based on cookies sent from the frontend. I implemented this system in my express backend using express-session and after a full day of editing I finally got it to work… on Chrome only!

I spent three days investigating. I asked questions on Stack Overflow and even talked with the developer of express-session. No one had no idea why this didn’t work on Safari and I was baffled that something so important would remain unknown.

So, hitting a brick wall, I had no choice but to nix ‘express-session’ and learn about json web tokens, Redis and localStorage for handling my app’s sessions.

This meant I had to create a whole new logic system for the login api, which, instead of simply going to the login function that would check the email and password, would now go to a new login function. I turned the original login function into a function that simply checked the supplied email and password and returned a Promise. I created another function that checked the JWT legitimacy if a token was sent in the authorization header, another to retrieve the stored token in Redis, another for creating a token if none existed, and another for storing the newly created token in Redis.

I then created a middleware to serve proper routes to logged in users for the backend api’s. None of that is the point, the point was I did major changes to section of the api that affected many other sections of the api.

Now, because I had a whole new system, I had to manually test everything again to make sure I didn’t f-up anything anywhere/everywhere. Finally, I saw the light of why writing tests from the start is so damn important!

If I had the tests written for all my functions on the frontend and backend, and they were thorough, I would not have to go through all this manual testing every time I made a change. I would just run the test suite before I uploaded and if all passed, great, if not it, fix what needs to be fixed.

Much better!!!

Even though I studied Jest and Enzyme before I built Power Todos, I did not want to implement any tests, I thought my app was too small and insignificant. But I learned that even the smallest apps can drive you crazy if you have to manually retest everything after little change you make. So, lesson learned, write tests from the start!

Going Live: Heroku, Docker, docker-compose

I spent a good amount of time learning about Docker. I then set up an image for my Power Todos backend. Then I setup Docker Compose which allows you to combine several Docker images so that you can deploy your entire backend from one Docker file. I was excited about this technology because I understood the significance of simply running one command and having the whole backend up and running without the need for local machine setup.

I was able to create a nice docker-compose.yml file and different images for Node, Redis and Postgres, including all the db tables needed for the app, as well as some seed data to give devs something to work with in the database when they started on a new machine. I was so proud that I got it all working and understood everything, only to finally finish my app and begin to deploy on Heroku to find they do not handle docker-compose.yml files. WTF!

What was the point of all that setup? Why did I even need to use Docker at all? I thought the whole point was that I could setup once and then be able to create new servers in a cinch so that it would be easy to scale should the need arise. This was my biggest road block and biggest pain point of switching to fullstack javascript. Not docker, but the whole deployment process.

What made it worse is that I found no answers on Stack Overflow. This was one of the biggest differences from PHP to node/express/react/javascript. In PHP every question you can possibly think of has like ten different answers, and most are up to date and you can pick and choose which you think is the smartest answer for your situation. But in the node world there are so many different libraries that there just isn’t an answer, or as big of a community ready to answer your questions, for every different pain point you encounter.

I did, however, figure out the docker-compose Heroku problem. Well, not really. What I figured out is that you can’t deploy your docker-compose.yml file to Heroku. So all I could do was deploy my main Docker image, which consisted of just setting up the express server. Then, I had to manually go in and add a Heroku addon for Postgres and Redis, then I had to manually create tables for Postgres using the Heroku CLI. I found out later I could have just added my Postgres and Redis docker image individually after I added the addons, but I already had it set up by then. Next time.

I had to edit my Dockerfile to get it work on Heroku. I will have to now go back and make sure that the Dockerfile will work whether I have to upload it individually to Heroku, or whether I upload to github so another developer can just install straight from docker-compose.yml. This whole deployment process was very frustrating and not even close to as easy as simply uploading files via FTP software in PHP (if you have your own dedicated host you just create a new account for a new site, then you can upload the files). But I do look forward to using Docker in the future so that the databases and backend run smoothly on all machines.

Things I love and things I hate

What I really loved about Javascript and especially the Node, Express, React world, was writing the code. It is so clean, so easy to keep organized, it is like a breath of fresh air. It is so logical once you understand the ecosystem and most of the documentation for different libraries is easy to find and very descriptive. That said, that was only true for the big libraries. The smaller, more unpopular libraries I had to dig through source files to understand what was going on. But in all, I loved the ecosystem.

I also loved building an API on the backend that is completely separate from the frontend. In PHP everything is intertwined, and I am sure Laravel might have been an answer to this, but Wordpress is not. Wordpress is a nightmare compared to Node.

I loved the modularity of React, the pure functions and simple components. I love having the ability to add libraries like Lodash, while only including the exact function I need so it doesn’t bog down the system with its entire library in production.

I hate the deployment. In PHP it is as simple as uploading your files. And editing a file is as simple as, well, open-edit-save. This is not even close to the scenario with javascript, at least not for me… yet.

Being an SEO, I hate the idea of there being no HTML, though I understand this is less important these days. And I am well aware that Next.js solves this problem, it is actually coming up soon on my todo list, behind writing this article and learning and building something in React Native.

I like the separation of backend/frontend, but I hate having to pay for multiple servers for one app. I imagine that after a year or two of doing this I am going to have like 50 different servers, which could make costs insane. In php I would just get one Virtual Server and run as many sites as I want (to a point).

Now, I understand the value of this for big companies as it is easier to scale with a separation of servers, but so many of the sites I built in the past are for small businesses who get 1000 visitors a month max, they usually just need an internet presence, maybe they even have a shop that just isn’t as world-wide or as a full-fledged as an Amazon.

Again, there is probably a solution to this in JS world. For instance, I found a way to run the frontend from the backend server, thus only needing a host for the backend. But still, that seems a bit hacky and goes against the intended purpose of the Node ecosystem and separation of concerns.

Working on a New Codebase

You are not going to look at something and understand it automatically. Don’t think you will ever get to this point! Especially if it something new that you have never looked at before. No programmer, no matter how expert they are can do this like magic.

When you dive into a new codebase, or if you are starting an app from scratch, it is okay to give yourself some time to understand what is going on. Keep a notepad as you go through code and outline your understanding of what is going on. Keep developing your outline and expand your understanding before you write one line of code.

Give your brain some room to grasp the code. Talk it out to a friend or partner, even if they aren’t programmers. If you can make them understand, then you know you understand. And take one little piece at a time and trust you have the brain power to get it, and ultimately, you will be able to contribute something of value.

Next Steps

Create a React Native app
Create a React site using Next.js
Finish course on Mastering the Coding Interview.

PS- A large majority of the techniques I used in my app and which I wrote about in this article came from Andrei Neagoie’s courses on Udemy. I could not recommend his courses higher.