Around June, I changed my mind about AngularJS and thought that Angular 2 could arrive on time for our project (hint: it didn’t), so I decided to tag the current state of my personal project and tried to actually start developing my site using it.
I spent some time during my holidays to migrate my app to Angular 2. During that time, I banged my head against the wall so many times it still hurts; not because of Angular 2, but because of RxJS and Reactive Programming; those made me feel really stupid for a while :)
Also during that time, I spent time improving my build. The build story was starting to itch me real bad, so at some point I put my project aside and decided to extract the build to a separate project and concentrate on that for a while. That effort led to the creation of modernWebDevBuild” (MWD for friends). MWD was my take at providing a reusable build for creating modern web applications. You could argue that that solution is not modern anymore but hey, I can’t stop time ;-)
If you look at the feature list of modernWebDevBuild, you’ll see that it’s basically Web Starter Kit on steroids with support for TypeScript, tslint, karma, etc.
I’ve put some effort into making it flexible enough so that it doesn’t put too many constraints on the client project structure and I’m pretty sure that, with some help of the community, it could become much more malleable and could be reused across many more projects, independently of whether those are based on Angular 1, Angular 2 or something else.
A while after, I’ve also created a Yeoman generator called modernWebDevGenerator to make it easy to scaffold new projects using modernWebDevBuild. The generated projects include many personal choices (e.g., Angular 2, TypeScript, SystemJS, JSPM, sass, jshint and a rule set, jscs and a rule set, …) and style guidelines (e.g., component approach for Angular and SASS code), but most if not all can be stripped away easily.
In my opinion, modernWebDevBuild was a good shot at providing a reusable build for front-end web development. I’ve used it for multiple projects and could update it easily without having to worry about the build or having to maintain a ton of build-related dependencies and whatnot. That was a relief: fixing an issue meant fixing it once in one place, much better!
For me, the idea of having a complete build as a dependency of a project is something I find immensely valuable.
Recently though, with the project at work (where we’ll use AngularJS for now) we’ve evaluated different solutions for bundling, module loading & build tasks in general which led to the decision of using webpack. So far, it’s been a blast. I’m not going to explain in detail what webpack is as there are already more than enough articles over it out there, but IMHO it’s the clear winner at the moment. The most important for me is that it has a very active/vibrant community around it busy maintaining & developing tons of plugins. Those plugins add support for pretty much anything that you might need in your front end build. You need transpilation? Check. You need autoprefixing? Check. You need cache busting? Check… well you get the idea.
With our project template, our goal is to integrate the whole stack that we’ve decided to use (e.g., Redux, RxJS, JSData, webpack for module bundling/loading, …) and use that template as basis for our next projects.
The thing is that I’d still like to extract the webpack build to a separate project (or at least a part of it). Again, I really believe that it should be possible to provide a reusable build configuration as long as it is flexible enough to accommodate for general use cases. Ultimately the discussion boils down to pragmatism versus the pleasure of reinventing your own wheel each time. Personally, I like round wheels and if one is flat then I don’t want to fix all my cars. What about you?
In the next post, I’ll explain what my new goal is for my site; as I said, I took a different route for a while because I had lots to learn, but now it’s about time for me to go back to my initial goal :)