Follow-ups on My Perfect 2020 Stack
Responses to reader comments
In a recent Medium article, I shared my thoughts on how far we’ve come since the good old days of the LAMP stack. The simple four-layer stack of 2000 has expanded to encompass many more layers in 2020.
A few comments from close readers deserve to be answered.
For Peter J Theobald and all the others expecting disclosure, yes I am the developer behind three of the components in the article: Blue Phrase, Read Write Serve, and Read Write Doc. They are part of My Perfect Stack because dogfooding is a good thing. The Medium publishing process emphasizes content and story-line over self promotion, and in honor of that tradition I appear to have erred on the side of being too subtle about that.
For Alex Shipp, Bob Torres, Stefano Tabacco and anyone else wanting direct access links to those three, I’ve posted them at the bottom.
Time will tell whether Patrick Hastings is right about Node.JS being a fad, taking a back seat to Dart, and Andrew Knapp is right that I should add GraphQL to my perfect stack.
For Austin Keeton and others wondering why I stay away from polyfills, here’s my reasoning. The last two major additions to the ECMAScript language that I got excited about were async/await and ES modules. Now that all of the browsers have both of those I view the newer features more in the “nice to have” category than in the “must have it now” category. Waiting a year for new language features to trickle through the TC39 process is less painful than having to develop/test/deploy once this year, only to have to redo it all next year.
Jason Child rightly observes that the current trend seems to be towards more functional programming, not less. Here’s my reason for being a holdout. My code used to be heavily sprinkled with the keywords prototype and function, and with Immediately Invoked Function Expressions (IFEE). This lacked clarity and caused confusion when it needed maintenance. When ECMAScript added class, extends, static, bind and Object.seal() I found myself writing modular code that was much easier to read, and I finally conquered the ever wayward this. Functions grouped together and working in concert to do related things were easier to comprehend than any other organizational technique I knew. Old dog, new trick? Maybe. When I stopped using C in 1993 and started using C++, I found a pattern that just felt right. I still haven't found a similar kind of organization within the functional programming paradigm. I'm waiting for someone to prove me wrong.
Dan Gilbert asked me to expand on why I think JSX is a bad idea. My short answer: separation of concerns. A longer answer: too many escape sequences makes it difficult to parse visually. Plus, I find the mixture of languages all jumbled together to be jarring. On the other hand, the classic template approach allows HTML, CSS, and JavaScript to be kept separate, and all their dedicated linters, minifiers, prettiers, and validators put to full use.
For Titus Decali and anyone else who is still using SASS/SCSS, the technology to keep your eye on is Web Components. Until now my CSS has not been as isolated, separated and modularized as I would like. As a result I find the amount of fiddling, jiggling and swearing to be altogether too great. When Microsoft Edge finally ships its Chromium based browser in 2020, we can fully embrace modules. That’s when we’ll be able to start treating CSS with the same design and engineering approach that we apply to the other layers of the stack.
Here are those links I promised:
