The silver-bullet framework that shoots us in the foot
The big red flag
What are the costs?
- First we need to make a large investment to learn, deploy, and maintain a big-to-vast compiler infrastructure.
- Next we need to learn a big-to-vast Domain Specific Language (DSL) that will constantly be changing as the maintainers vacillate about design fundamentals.
- We will also kill our iteration times because running and testing code moves from fast-and-simple to slow-and-complex. At the very least testing requires a compile step and a multi-step debug process. Sometimes we need to add a compiler-specific test library. Or three. Or a even a complete custom test environment.
So what do we get for our big investment? We’ll tackle that next.
What are the benefits?
Some benefits of X-to-JS languages are are pretty silly on their face. CoffeeScript provides the make-it-look-like-Ruby benefit because, you know, a code closure should never be easy to find or compute. And Cappuccino provides the make-it-look-like-Objective-C benefit which apparently is a big deal for Tim Cook, Sir Jonny Ive, and some guy in Kansas. Maybe it’s just me, but aren’t compilers supposed to convert from high-level to low level languages and not the other way around?
foo_str - and adjust our code management tools to get most of the same benefits less than 10% of the effort. Yes, I’ve tried both, and I’m sticking with Plan B.
Enter the Kraken
Many of us have seen web projects with multiple developers and numerous GUI frameworks selected without a single GUI prototype. Let’s pause for a moment and let that sink in. One should not hire a full developer team and select tools before knowing what to build. That’s like hiring a construction crew and buying building materials before even sketching the design of a building.
This post was originally published on Linked-in