As I dive more into web programming in an effort to become stronger at the front-end, I figure I’ll drop some notes for any other enterprising embedded / server programmers wanting to join in.
Plodding along on the internet, I’m rapidly discovering that the choice of libraries seems to expose on to an endless array of different methods of building / compiling your web-app. PHP seems much more straightforward in comparison. The first, and most confusing element to me was ‘nodejs’ itself.
Wait, I thought JS was interpreted by the browser? True, but you want something to maintain all the dependencies and automate things like minification and creating map files.
5 minutes in to reading a basic tutorial on several different frameworks, I’ve already had to discover new terminology for nodejs / npm. And, at this point, I haven’t even started down the alphabet soup of different environments:
- Yarn vs. Npm vs. Bower – Ok, we’ve got multiple competing package managers here to get going… And each has it’s own quirks. Maybe the best answer is to stick with npm since it came with the environment? Crud, looks like these tutorials use yarn.
- Gulp vs. Grunt. – Ok, so now we start to discover that inside this JS environment are apparently new environments for running tasks… Ok, not too much a problem.
- Webpack vs. Browserify – Well, these are what I installed this node thing for anyway aren’t they? What am I getting here?
Annoyingly, each JS developer has their own ‘special sauce’ combination of components that yield something for the back-end developer. The larger the application (and the more 3rd party utilities one brings in), the more likely it seems one will need to go ‘off script’ from recommended configurations provided. That doesn’t even begin to raise the shear number of potential library combinations that may (or may not) be tested.