Client Process

OK, so, I'm my own client here. Perhaps this is not the ideal situation in an engineering process, but at least its pretty clear to me what my process IS. I need to decide what tools I'm going to use to approach this task I'm on. Its important when you work with a client to work within their process. You can always enhance that process, or maybe even create it, but the process should be owned by the client. If they don't own it, if they can't master it and live with and make it serve them, then ultimately it will wither. What you see then is some later contractor comes along and looks at the dusty remnants and sweeps it all away to start again! This isn't really, usually, a cost-effective result for your client.

In my case there are tools and technology which I'm comfortable with and know how to employ. These are things that I can pick up with relative ease, and with which I have, generally speaking, some degree of mastery. Now, in the web-app development space there are a truly vast number of tools, frameworks, libraries, platforms, etc. At this point, 20-some years into the web era you could likely find something that does almost exactly what you want. The problem is finding it isn't going to be easy. Once you do find it, its likely to be something obscure (most stuff is). Anyway, part of my motivation is going through the process and mastering some newer techniques. Besides, I don't want to spend the months it takes to learn Wordpress (or whatever) well enough to write a plugin for it, and then need to be hooked up into that world forever. Particularly when the feature set I need is not that extensive.

To get more specific, I've been a Java guy for a long time now. Nothing is more conveniently portable and likely to remain supported than JVM-based code. Today you can write this code in a wide variety of languages, leverage a huge number of libraries, and work with a vast array of tools. There are other ecosystems out there. At one time we might have compared the Java ecosystem to that of .NET/Mono, but to be perfectly blunt I just don't see it anymore. .NET has essentially disappeared from serious consideration in Enterprise web-application development circles.

Of course Node.js has, at the same time that .NET faded, risen to significant prominence. There are now more libraries, frameworks, languages, and toolkits residing in the Node.js/NPM space than you can shake a stick at. Of course this is kind of the problem, the noise is deafening. Now, I've used Angular and done my share of Javascript (blech, what a horrible little language) development. It is what it is. I just can't help feeling kind of like its another fad. Sure, I'm as biased as the next guy, but I did say I was a Java guy!

So, between the JVM and Node.js there are various pluses and minuses. The tools most commonly used for web client development now tend to be in the Node.js space. Java has a very solid Javascript interpreter in Nashorn, but it isn't the primary target for most of the currently popular tools. On the flip side, there are JVM-based tools that simply have no compare in the Node.js world. Frankly I'm happy sticking to the JVM world for now.

This also means I can stick with Eclipse. Crufty though it may be Eclipse 4.7 (Oxygen) is a pretty darn good IDE. It may be huge, and the quality of Eclipse plugins is pretty varied, but it is pretty solidly a part of my process. Remember what I said? Process is important. I might change some day, but for now Eclipse holds sway. There is certainly no IDE with the same level of support for Node.js as Eclipse has for the JVM and everything in it.

So, I feel like I'm going somewhere here. I have a process, Eclipse, JVM, and Gradle. I didn't talk about build tools. There are, once again, many build tools. I just like Gradle. Maven is a little more common in the JVM world, but I find its approach too rigid. You end up spending 50% of your time wrestling with Maven to get it to let you copy the file to the place when and where you want. Gradle is a LOT more flexible, and its DSL is pretty nice, vs the ugliness that is the POM.

This is a tool set that is well-supported, unlikely to vanish into obscurity any time soon, and which has a rich ecosystem. In any case, we can always bring in other technologies if we need to. There's nothing stopping us from installing a copy of Node.js and NPM on our dev box. I'd rather use a JVM as a runtime, but I'm not hostile to using any good tool for what is good for.