The exhausting trend of taking simple standardized HTML markup, CSS styling, and JavaScript then further convolute this by introducing complexity and unmaintainable code.
There have been browser conflicts and push towards standardization on how client side code is processed by web browsers. Now after having standards and coming to agreements more complexity has been introduced by using libraries requiring compiling of client side CSS and JavaScript. Using additional command line tools to pre-process code before having the code served by a web server. With Web Assembly, analogous to a bull dozer turning all client side into bite size code to allow grown kids to render 3D games in 2D space web browsers.
You might ask. What productivity is gained by using command line tools to compile client side code written in more buzz word friendly grammar syntax? At some point in the future the original code packager configurations may require being tracked down. Maybe the latest version of code packager dependencies will no longer exist. Will the same packager allow all the programming syntax grammar originally used or you will be left with fixing outdated undocumented syntax?
Here is an example (https://youtu.be/8vnkM8JgjpU) of making minor changes and using a popular packager named Webpack to process client side code. Presenter in this video demonstrates use of variable declaration in .scss files, a feature of SASS and some JavaScript syntax that requires to be processed by Webpack before publishing. While watching this video (https://youtu.be/8vnkM8JgjpU), think about how you would maintain this code in the next two or three years.
With webpack you are maintaining the following overall items:
- Webpack.config.js file used by npm webpack command line script for outputing processed code
- package.json file referencing all the dependencies of WebPack
- Various .scss files
- Source input code along with distribution code processed by WebPack
- Fix errors due to configuration changes caught by command line tool
Aside from Webpack there is also WebAssembly. (https://youtu.be/L5wxqcPD9mI) Here is an example of possible modern usages of Web Assembly. While watching this (https://youtu.be/L5wxqcPD9mI), think of yourself required to make a few minor changes to a customer facing web view. To make those minor changes you open your IDE to have the IDE auto generate some files based on a WebAssembly template for the given server side language. Will all the dependencies be available in the future when additional modifications are required?
Considering the issues of productivity and maintainability of code is the study of technical debt. Technical debt varies for each type of programming work, organization, and individual.
For further understanding watch this lecture from a Goto conference(https://youtu.be/SdUewLCHWvU) about technical debt. Yes, the petri dish like circle graphs in this video represent file directories, lines of code, functions and on some slides groups of people.
Overcoming technical debt requires writing software with ability to withstand future changes, pressures of adding new features and new circumstances.