Back in 2008 I started my first blog. Its original incarnation was a WordPress site hosted on Bluehost. I’ll never forget the countless hours I spent wrestling with WordPress plug-in updates, sweating my database back-up process, fighting the content editor to produce valid markup and, on at least one occasion, losing several hours of work as a result of clicking the wrong button somewhere. WordPress was complicated and it sucked.

WordPress was complicated and it sucked.

Many are familiar with the idea of static site generators like Jekyll and why they should use them. But Jekyll isn’t the only SSG out there. In fact, there are literally hundreds of SSGs guaranteed to give you analysis paralysis. With so many to choose from it can be difficult to decide which to use.

After recently planning to do a survey of tools for building rich web apps I stumbled across  github.com/codylindley/frontend-tools, which claims to be an opinionated list of tools for building front-end applications. For those new to building modern web applications, it’s certainly easier to take in than larger lists like github.com/joyent/node/wiki/modules. But lists aren’t necessarily the best place to start for putting an application together. At least not where the rubber hits the road.

WordPress continues to become more and more sophisticated as time draws on, with a constantly improving admin dashboard and easy-to-use plugin architecture. And themes like  Twenty Eleven give both bloggers and web developers something to appreciate. But while WordPress is a great CMS for personal blogs, it’s not well suited for more complex applications such as Drupal, on the other hand, and by design, excels at all of the above and more.

his article will look at some of the similarities and differences between WordPress and Drupal 7, explain how to accomplish some of the less intuitive administration procedures in Drupal, share some newbie gotchas and timesavers, and provide a list of modules useful to get a new Drupal site off the ground. It is assumed readers are new to Drupal but have a familiarity with using the WordPress blogging platform.

In March of 2017 Sir Tim Berners-Lee, the inventor of the Web posted a short article on The Guardian covering three things we need to do to save the Web.

To paraphrase, they are:

• Increase individual control over sharing of personal data
• Improve diversity in Social media and Search channels
• Create more transparency behind political advertising

The third of which is, in my opinion, really just an extension of the second, so let’s briefly cover the first two and what you can do as individuals to address Tim’s concerns right now. When you’re finished, you’ll have a deeper understanding of how to protect your privacy online.

One of the largest perceived drawbacks to creating a SPA or other Rich Internet Application is that they’re not SEO friendly or very accessible. With the advent of technologies such as ARIA, HTML5 and Node.js, things are changing. Web apps are becoming more usable and accessible, though also making them crawlable and highly performant is a formidable challenge.

So I’m putting together this killer new JS front-end development stack called Brunch with Panache, which uses Jake tasks to kick off a custom set of commands for building and managing the app, and I hit a bug while code was running in Node.js. So what now?

Following is a list of cross-browser/platform web development and debugging tools useful for client-side developers. Depending on the application, one or all of these tools can be valuable in completing work on a website front-end.

I wrote this late last year and it gets, well, a lot of traffic. Why? Because it hit home with a common concern in the JS community–a path forward for decorators. It just may change the way you build React apps for the better.

If you’re looking to measure page view events in your Redux app – even if you’re not using the de facto community routers – I found an approach which can be modified to emit analytics events to a number of different providers with relative ease using a single middleware integration.

For several weeks I’ve been thinking about how to go about creating a chat application. After a knowledge drop from Kent Safranski I was inspired to stand-up the chat app using Redis. For the experiment I decided to use Go given the concurrency affordances baked into the language. So I took A Tour of Go and hit the blogs to see what I could find in the open source community.

Reading Redis, Go, & How to Build a Chat Application made me aware of Redigo, a Go client for Redis, and helped demystify use of Redis’ PubSub with Go. The article was a solid introduction and did a great job breaking things down, but ultimately left me wanting a prototype to try things out on the Web. After some more sleuthing on DuckDuckGo I discovered an open source demo app meeting my requirements and providing a great sandbox for experimentation.

In this article I’ll cover how to create a chat application which uses Redis and Go by leveraging open source software and Docker, and use Ngrok to expose the app to the Web over HTTPS.