A Change Is As Good As Rest
In football you’ll sometimes hear a coach tell you to “play back”. It means, back up so you can get a better read on the ball and therefore be in a better position to see what you’re dealing with. If you play too close up, you’re vulnerable. You’re opponent will have the advantage and beat you play after play. Suffering too many defeats results in feeling defeated. My old football coach used to quote Vince Lombardi:
“Fatigue Makes Cowards of Us All”
Playing too close to the bleeding/cutting edge in technology will result in many defeats. You’re vulnerable and you’ll suffer death by a thousand cuts. Those defeats will mentally wear you down. It’s better to “play back”, get some perspective and proceed with caution.
Google And Pray:
These previously non-existent problems are essentially an increase in technical debt. Evolution drives extinction as much as it drives new features. Many of these “extinctions” come in the form of deprecated apis, dependency chains and workflows. Deprecations that directly convert to technical debt. Instead of working on adding a new feature to my application–I found myself spending more and more time working on my tools themselves. A never ending attempt to bail myself out of technical debt that seemed to have no end in sight.
A False Dichotomy:
Become A Jedi:
The Proof Is In The Pudding:
I’m now thinking how shameful it would be if I ended this article here. I should at least make an attempt at providing you with a starting point. I should also provide an example of something I’ve done that demonstrates such an approach.
Where to start:
- You don’t need grunt, gulp, etc. All they do is point to npm packages that you can install and configure yourself. You can easily roll your own build and dev tools. You can even call them with npm run if you want. I keep reading more articles on this more and more...here’s one (TLDR;)
Although I can’t share code I’ve written on the job with you I can show you the beginnings of a project that I’m working on. It’s probably the best example I could provide because it’s non-trivial and touches an many different facets including: structure, build tools, testing, polyfilling, etc. It’s called OEM. Irony of ironies–it’s a small web component framework that allows you to write and maintain your own custom web component library. I wrote it for myself. It’s not perfect and it’s probably not ready for primetime but I have put some serious thought into it and rebuilt from the ground up 3 or 4 times until I felt I was on the right track. I’d love for you to check it out and tell me what you think in light of this article. I’d also like to hear/see from those of you out there rolling your own solutions.
But What About New Language Features?
The End Of The Beginning