I’ve started using Webpack in my build process and I must say, I’m quite impressed. So over the past couple of years my build process has migrated a bit. I started by using Grunt, moved to Gulp and then created my own build process to address some custom items working with Red Pill’s infrastructures and Domino. But since finding Webpack, I’m finding that it does a much better job, with much less effort.
Part 1 – node.js and Domino
So that leaves to question, what can we do with it? Well, we can do a whole lot with it actually.
With the recent announcement of upcoming node support for Domino, I think we need to start looking into what it takes to get into node.js development. The truth of the matter is, it’s not really that difficult. To start with you need to install node.js. Then find a decent editor (I recommend Visual Studio Code).
Once you’ve got these things, create a new project directory somewhere (I’m gonna use hello-world).
Here lately I’ve been writing a lot of tooling in preparation for upcoming projects. This tooling is meant to lessen the amount of work to start up a new project. A while back I watched this video. That video inspired me to come up with a repository in which a front-end developer could clone, run a couple of commands and be ready to write code for the new project. Going down this route has been quite the eye opener to the complexity of what a modern progressive web app is today.
As web developers the ability to troubleshoot a web application is a very important part of the development process. To be able to see what’s happening and understand what may be causing a certain behavior is key and should be employed during the entire development process, not only when something is broken. In this series I will outline my process of troubleshooting web applications.
First off the tools. While there used to be a hand full of tools you might use now you only need one,
- Performs and records all AJAX requests
- Provides a basic PubSub system
- Provides a basic Request/Response service
- Provides a global variable to interact with the context
The entire idea here is to provide a communication channel similar to that found in Backbone/Backbone Marionette for application specific communication.
Over the past few months I’ve started working pretty extensively with TypeScript. For those of you who don’t know what TypeScript is:
If you followed Peter’s series on replacing Lotus he outlined some of the pitfalls, processes and decision points to undertake for success. I wanted to point out the technical side to a lot of those decisions. The short answer is that you need a tool to surface your domino data en-masse until such a time when decisions are made on each application. I have been working on that solution for quite some time now and I have to say,