These days, my framework of choice got spectacularly in my way. Don't get me wrong: D3.js is a good framework. It was the right tool for the job. But it slowed my progress nonetheless.
You know, I wanted to write a particularly fancy presentation. Everybody knows PowerPoint slides by heart, and even a nifty presentation framework like reveal.js has become boring. But there that nice little framework I always wanted to play with. And there's this nice interactive sunburst diagram. What about converting it into an interactive presentation? And while we're at it, why don't you translate the code to TypeScript?
This turned out to be a stupid idea. Luckily I'm not in a hurry, so I don't mind, and the result is impressive indeed. But with a tight deadline it had been a disaster.
It's not the first time I experienced this. Even the best framework comes at a price.
Evolving base technologies
For many years, we developers have learned it pays to use a framework. But that's not always true. Plus, things seem to change recently, at least in some areas of programming. The base technology has matured to a point many frameworks become superfluous.
A very convincing example is JavaEE 7. This is something most enterprise developers consider base technology because it's already part of their application server. It's astonishing how many features JavaEE 7 offers. I don't think I'll ever be able to learn more than twenty or thirty percent of the features of JavaEE. Putting it with Adam Bien's words: JavaEE 7 is the only dependency you'll ever need.
Granted, there are still valid use cases for frameworks like Apache Deltaspike, PrimeFaces or BootsFaces. But today, you don't need such frameworks just to get started. More often than not, you can get rid of most frameworks in your technology stack. Use these frameworks if they make your life easier.
Wrapping one's head around a framework
However, that's precisely the question. Do these frameworks make your life easier? I'll never forget the day when an external consultant sold Spring to my boss. "You'll finish the project ninety days earlier", he said. The said truth is that migrating to Spring did cost us ninety days. Probably even much more.
That's because we had started to learn CDI. Our entire application was optimized for CDI. We couldn't simply replace CDI by Spring. That was a major project. Adding insult to injury, it was difficult to find documentation for Spring at the time. Some time before, there was a major version update of Spring. The vast majority of the documentation in the web covered the old, XML-heavy programming style. This is nothing you can learn in a quarter of an hour. That's special knowledge requiring an open mind (as opposed to a mind used to annotations) and a lot of time.
That's why I keep reminding people that even the best framework comes at a price. And the price is not always the same. It depends on your team's skill set, on your company's culture, on which kind of application you're writing and of course on the application size. This tweet nails it:
Just downloaded 89MB worth of dependencies to get started on an Angular 2 hello world app #hashtagproductivity
— Austin Walela (@AWalela) 19. Mai 2016
Obviously, "hello world" is not the right use case for Angular2.
If you've already got the infrastructure because you've written three or four applications with Angular2, things look a little different. It's little extra effort to add Angular2 to a "hello world" app. In fact, it may be simpler to use the framework you already know that to figure out how to do it without.
Evolving browsers
Another example of evolving base technology is the browser. Don't even try to address Internet Explorer 7 without jQuery. But if your target platform is the evergreen browsers (i.e. the self-updating browsers like Edge, Chrome, and Firefox), chances are you don't need such a framework. jQuery is still a useful tool, but you don't need it just to circumvent browser incompatibilities. As of today, the most popular browsers are more or less compatible with each other. In earlier times, they were clearly on the "less" side. Frameworks like jQuery were needed to get rid of all those browser detections.
TypeScript and D3.js
I've started the article with my D3.js project, so I'll conclude it with the same project. As I've said before, D3.js is a very good framework. Thing is, it strongly supports (or enforces) a declarative programming style. Not only that, it's very opinionated about the data-driven approach. When I stumbled into my sunburst presentation project, I'd completely missed this point. It's not that difficult to paint a sunburst diagram, so I did it by calculating every angle and radius by hand. The problems occurred when I tried to use the killer feature of D3.js. I wasn't able to make the diagrams interactive.
That, in turn, was caused by two mistakes: I used the wrong base class to represent my data, and I ignored the data-driven approach.
When I tried to replace the wrong base class by the correct one, I found myself in hell. The compiler emitted an overwhelming number of errors.
A couple of days later, I learned that most of these errors were false positives. They were caused by TypeScript. More precisely, they were caused by an incorrect interface definition at the DefinitelyTyped project. That's a project providing interfaces for more than 900 JavaScript libraries. So you can use these libraries with TypeScript and can still benefit from autocompletion and useful error messages. However, these type descriptions are usually not supported by the library author, but by someone else, so errors are almost unavoidable.
That's what happened in my case.
Let's take a step back. From a project management perspective, my mistake was that I tried to do two or three things at once. I tried to use D3.js without actually wanting to learn it, I tried to use it with TypeScript and I tried to migrate a program written by someone else to TypeScript. And again, I didn't really want to learn how the program works. At the end of the day, this didn't work out. I had to spend some time learning D3.js, I had to analyze how the Coffee Wheel written by Jason Davies works, and I even had to fix an error in the DefinitelyTyped library. Chances are I'll even submit a pull request to them.
None of this was part of my original project plan. I just wanted to modify the coffee wheel and add some fancy slides to it.
Wrapping it up
Don't believe the consultants. They tell you how much you can cut off your project's costs just by using a particular framework. Before you ask: I'm a consultant, too, so don't trust my words, either. More to the point: don't trust them blindly. They may have a point. But it's your responsibility to check whether the recommended framework suits you or not. Or if you don't need a framework at all. Both Java and JavaScript development has come a long way. Many frameworks you couldn't live without five years ago have become expendable. They're still useful, but typically only in major projects. Small projects may be better off with the base technology.