increase the overall size of your code base and push processing to the client-side, causing performance issues for users with a slower network connection or lower powered device
create a reliance on third-party code that your developers do not have control over, requiring you to make major changes to your service in order to stay up to date with changes in the framework
make it difficult to find people with the skills required to maintain the code, if the framework’s loses popularity over time
If you use a JavaScript framework you should:
be able to justify with evidence, how using JavaScript would benefit users
be aware of any negative impacts and be able to mitigate them
consider whether the benefits of using it outweigh the potential problems
only use the framework for parts of the user interface that cannot be built using HTML and CSS alone
design each part of the user interface as a separate component
Having separate components means that if the JavaScript fails to load, it will only be that single component that fails. The rest of the page will load as normal.
Each of these cycles has been larger and lasted longer than the last, and I want to be clear: each cycle has produced genuinely useful technology. It’s just that each follows the progress of a sigmoid curve that everyone mistakes for an exponential one.
There is an initial burst of rapid improvement, followed by gradual improvement, followed by a plateau. Initial promises imply or even state outright “if we pour more {compute, RAM, training data, money} into this, we’ll get improvements forever!” The reality is always that these strategies inevitably have a limit, usually one that does not take too long to find.
