This blog post is not about either of the things you may think ;-) As I mentioned in my dev curses, I'm a forker – person, who likes to start new projects. For me it's mostly because I like the quick progress in the beginning.
The Pareto principle says, that initial 80 % of work require 20 % of time. The problem is, when I start reaching the last 20 %, the task tends to get much harder and with to incentives to finish it, I abandon it.
Especially with a new generation of my framework, I tend to try it on so many previous projects or even projects we competed for but didn't get to do. But because I have all the public documents for it, I'm basically eligible to do it on my own anyway.
So with ES6 Qedy.js it was the same story all over again.
My reasoning is I can test the framework in different scenarios, before there's a real project with no time for reengineering, so all needed changes would go to a tech debt.
On one of my projects the project owner hired a junior JavaScript programmer, so there are 3 devs in the frontend team now. I gave the newbie a two hours long walkthrough of the system and we agreed on further steps.
During the following status call I was told it's too complicated and the team decided to go with a simpler approach, led by the third dev, who proposed the rewrite in the first place. I didn't protest much, because I could use some free time right now, after months of long hours.
But I expected him to have a solution in the pocket, not to come up with it along the way, as he apparently did. The project leader warned we need it up an running in a better than current shape by September and it looks he thinks it could be done.
I have to admit I was kinda disenchanted by the decision, so I didn't confront them with a warning the current version took over a year to finish. Moreover, the “simpler approach” is pretty much vanilla JS with HTML in it. In my eyes it's a recipe for a maintainability and customizability disaster and it feels like how I did stuff in early PHP 5 almost two decades ago.
I created quite comprehensive list of all the features the current and past versions have, to give him some kind of check-list and overall scope of the task, but I got the feeling they just read it and were done with it. I also hoped it might put them into perspective how much work it will be.
But what strucked me the most was the whole concept of QetriX was apparently incomprehensible for them. They didn't get it's pretty much just a different approach to MVC, because they argued the new version will be MVC at last. My primary motivation was to make stuff easier – did I fail?
I admit I'm no mentor and I didn't want to dump all the quirks of QetriX on them, so I glossed over it and explained only modules, components, datastores and converters. In my eyes this is sufficient enough and everything had an example and some documentation.
Anyway, pretty much all my projects went away from IE11 now, so I don't need to stick with ES5 any more. ES6 allows for much leaner code in many ways, so I decided to try what I can do with it. Because it suppose to be fun project (at last), to distinct it from work, I'll use VS Code for it.