Post date: Feb 24, 2017 7:29:58 PM
I spend nearly all of my coding time (full time job + countless hours at home) writing either Java or some other JVM language like Kotlin and Groovy. In this world, the JVM world, we take it for granted that you need a build system to compile and manage your code. Usually, it's Maven, but Gradle has been quickly becoming the build system of choice in the last few years. Some neckbeards are still using Ant or even Make, though.
Having worked with businesses that create very different kinds of software (government, simulation, testing, security), I think I have a pretty good idea of what a build system should do to be useful... in broad terms, I think that it should:
download dependencies from one or more configured repositories.
compile (if the language is a compiled one), analyse and test (always) the project's source code.
copy/move files around so that you have a nice distribution folder/server with what your application needs to run.
That's basically it, right? Everything else is a sub-item of one of the above (reports, linting, deployment... etc.).
With Gradle, my build system of choice, all of these are done in a pretty smart way, I'd say.
For example, dependencies are downloaded only if needed. They are cached in a global location so that any other project that later requires the same artifact can use the cached one instead of downloading it again.
Tasks that run compilation and analysis of source code only run if some input or output changed since the last time it ran. Gradle remembers the hashes of all tasks inputs/outputs (as long as the task declare those, which is usually pretty easy to do), so it "knows" when a task can be skipped.
To copy/move files around is made extremely easy (and platform-independent) via Gradle DSLs that you can learn in minutes. And you usually refer to task's outputs, rather than hardcoded file names, so it works much more reliably than any shell script.
I've worked with other build systems like Ant and Maven in the past, and I know that even though they are generally clunkier and less flexible than Gradle, they mostly do the job in a way that at least makes some sense!
So I thought most build systems work similarly... until this week, when I decided I needed to upgrade this website to make it look prettier and modern (and learn a new development environment as a bonus).
I chose to learn node.js and its ecosystem because, apparently, a lot of cool stuff is being built with it.
The first thing you learn when you try to get started with Node is that you need a package manager called npm (Node Package Manager, if you didn't guess it) to download everything else.
My previous experience with JavaScript was only in the browser, where the norm is (or so it seemed to me) to either point to a CDN in your HTML to download JS libraries you want to use, or to simply copy the file in your server. So I was happy to see that the number-one concern of a build tool (downloading dependencies) was covered. Or was it?!
Well, apparently, npm is used for the server-side code's dependencies... for client-side dependencies, there are other tools, the most prominent of which seems to be bower.
In other words, Bower is some kind of parallel to npm for the client-side dependencies (things like JQuery). Why would you need two different tools for basically the same thing, I don't know (but keep reading, more on this later)... but this ultra-focussed, tiny libraries philosophy seems to permeate the Node world on every level.
I spent some time learning both npm and bower, so that I could get some code running in a Node server and bring my new, modern, sleek website to life... but little did I know that I was only getting started with the modern JS toolchain.
Continuing on with the Node Hero tutorial, I found out that Node has something for creating HTTP web servers called Express, which looked really similar to something I was familiar with in the Java world, called SparkJava! Bingo!! I could immediately understand what was going on, so I didn't need to waste too much time there.Â
Moving on, I had a difficult decision to make... which UI framework to use... I had done a little Bootstrap in the past, but knowing from the outside that the JS world revolves at a much faster pace than the JVM world, I assumed that all the cool kids had moved on to something newer by now, early 2017.
Googling around turned up quite a lot of stuff, but one of the newest and coolest seems to be a mysteriously named framework by Google called Material Design. Thinking I am the newest JS ninja in town, I thought I would be able to now add "material" to my bower file dependencies, fire up my node Express server and have it immediately start serving hipster pages to the internet without a hiccup... but that's not exactly how things turned out.
First, Material does not seem to be a framework at all... it's more like a designer specification for frameworks, or something... I don't know, the website says something about a metaphor, or a set of principles... I really don't get it! So googling around a bit more, it looks like there's something that follows Material guidelines and uses the latest web specifications and standards from HTML5, which sounded really interesting to me!
That is called Polymer, also from Google... seemed easy enough to use, so I went back to my bower file and added polymer as a dependency. That's when things started to turn sour.
I ran the command I now thought was obvious to install Polymer:
bower install polymer --save
This saved the polymer dependency on my bower file and created a bowser_components directory containing all polymer resources. And I don't mean just the resources I needed in my website... everything. License, log file, build files, website images,
https://www.reddit.com/r/programming/comments/4bjss2/an_11_line_npm_package_called_leftpad_with_only/
testing :
http://mochajs.org/
var VS let VS const
lodash (everyone is using it)