Announcing The New Platform

Four years after Developer's Notebook was launched, we are excited to announce that we have finally replaced WordPress with a custom Node.js-based platform. It has been quite the journey to get here and we are proud of what we have accomplished.

In this announcement, we are going to talk about why we replaced WordPress and what technologies we chose for the final version.

Why We Replaced WordPress

This question is the easisest to answer, so we'll start there.

The first reason is speed. If you were familiar with the old WordPress website, you will probably have noticed by now that the new website feels much snappier. WordPress isn't necessarily slow per se, but it requires a lot of caching and despite utilizing a caching system, it never felt quick.

In fact, it always felt bloated and not particularly reponsive despite the caching. Part of that was simply because we had a number of plugins we needed that bogged down the website despite offering additional functionality. Viewing the page source in the browser revealed a lot of extra code that, as a developer, was painful to look at.

WordPress is a great piece of software that gives non-developers a lot of control over their website. The WordPress team has done a fantastic job at making it insanely stable even when overloaded with badly programmed themes and plugins. Despite that, a generic solution can never beat a custom platform made exactly for your use case. WordPress has also become a juggernaut and we don't need most of the new features it has to offer now.

The second reason we replaced WordPress is that we have big plans for this website that require a lot of programming. The choice was either to create custom plugins for WordPress that would have added the required functionality or to go with a new, custom platform.

Both options were evaluated, but since we were going to be putting the effort into programming anyway, we decided to do it the clean way and go with a new, custom platform. This gives us additional flexibility as well as a much leaner, cleaner codebase to work with without having to deal with any of WordPress's quirks and bloat.

Technologies

So what did we replace WordPress with? Well, as mentioned at the top, we chose to create a Node.js-based platform. That is because it is our Boring Stack and we wanted to move quickly while creating the most stable platform possible. While we love programming and working on the platform, we also want to make sure we still get to producing content in a timely fashion.

This is the technology stack we chose:

• Node.js + TypeScript
• Fastify for our server
• EJS for our templates
• SASS (SCSS)
• Bootstrap
• Prism.js for code highlighting
• Marked for converting Markdown into HTML

That's it. That's all we're using for our production stack. Of course, we're using tools like ESLint for linting and a couple of smaller ones for development, but the final stack that runs on production is what you see above. We wanted a very lean stack with as few dependencies as practicable.

What about a CMS?

Behind the scenes, we decided not to worry about a CMS and go with a static, Markdown-based approach instead. That means all posts are now written in Markdown, saved to disk, committed and pushed to our git repository. This might sound tedious, but it has several advantages.

First of all, the tedious parts can be and are automated with scripts. The blog runs off a system of generated cache files that are dynamically read during runtime. That means all we have to do to publish a new post is to run a script on the server that pulls the changes and updates those cache files. That's it. There's no rebuilding or anything.

Using Markdown files in git also gives us the ability to version our changes, review any new articles through pull requests and have a light-weight portable system to work with without having to mess with database dumps and so on. Since we're all developers, we all know our way around git and it just makes a lot of sense.

It will also help us fulfill one of the goals we have with this website later on down the road. But you'll find out more about that at some point in the future.

Otherwise, we are now platform independent without the heavy burden of developing with Docker. The only requirement is that the developer's system can run Node.js which means the developer can work on Windows just as well as macOS, Linux, BSD, etc.

Why did we choose to build a classic multipage application?

There is a modern tendency in the world of web development to use single-page applications (SPAs) for new projects. Frameworks such as Next.js or Nuxt.js provide options for websites that want to be both SEO-friendly and use an SPA. Even Node.js's official website uses Next.js after its relaunch earlier this year.

So why didn't we hop on the bandwagon and go with an SPA instead of a classic multipage application (MPA)? Despite having plenty of React, Vue and Angular experience, we went with an MPA for a simple reason: simplicity.

Those frameworks have their use cases and do their job just fine, but they also add another layer of complexity that we didn't want to worry about. It would have required two separate applications for the backend and frontend which adds architectural complexity, plus programming the frontend would have required a lot more time coding than just just throwing up a couple of HTML templates with some CSS and basic JavaScript.

Another reason is that our frontend simply doesn't require a lot of JavaScript. In fact, we hardly have any at all. Most of the JavaScript is used to define the few custom web components we made such as for the off-canvas menu button for mobile or the "to the top" button that appears when you scroll down a page.

Other Choices

We chose Fastify over Express as our server framework which might seem like an interesting choice, but that is because we have the feeling that Express's development has slowed to a crawl over the past few years. It doesn't even support HTTP/2 yet and its developers get grumpy when you ask them about it. So, we decided to go with something more modern for our server.

There really isn't much else to add to the rest of the choices we made about our technology stack other than that our primary concern was stability. We didn't want to worry about performing any major rewrites just because a core technology we chose is no longer supported. Every developer has encountered that at one point or another and it can be time-consuming and frustrating. I'm sure we will have to in the future, but it would be nice to have a few years before having to do it.

The other frameworks and libraries we chose such as Bootstrap, Prism.js and Marked have either been around for a very long time or are widely used.

Conclusion

That pretty much sums up the new platform. It should provide a more flexable, stable, faster and lighter platform for us going into the future which should improve the overall user experience. We are certainly excited about it.

Some features from the old website are still missing, but we figured we will get to those in time. Post ratings, comments and polls are the main features missing for now, but we have plans to implement those as well in the near future. We were just so excited to get the new platform out that we decided to launch without them.

Let us know if you find any bugs or have any other feedback by visiting the contact page for now. We would certainly appreciate anything you have to say whether postiive or negative!

In the meantime, we hope you enjoy the improved user experience and check back again soon for more content as well as new, never-before-seen features coming to Developer's Notebook!