| This type of arguments come up often here on HN, and I would guess many developers including myself will agree that things are bloated and bloated is not good. But the solution to this problem has to be in small actionable steps, not built on assuming (or shaming) everyone to put nice principles above the everyday toil of software development. And it's a darn messy problem to try and solve even in small actionable steps, because I think most of the choices that lead to bloat are choices that make sense at that point in time. E.g. "use a dependency instead of code it myself", "use AI instead of thinking through every angle", "write 2 unit tests instead of the 20 that would give full coverage", "don't write extra tools to measure the speed of everything, it seems fast enough". Taking the route that minimizes bloat can be very time-consuming and demanding on the individual average developer. And any solution we come up with will not give us security guarantees - but any solution that moves the average one point in the right direction is still a good thing! I sometimes find these type of question fall into old tropes like "it's Javascript's fault, better go back to C". But I think that is a fallacy. Javascript in a browser can easily run millions of ops a second. The big time offenders come from elsewhere, most likely network operations and the way they are used. Some things that I think would help (and yes, some of them exist, but not as mainstream tools for the common tech stacks) Tools that analyze and handle dependency trees better. We need better insights than just "it's enormous and always change". A tool that could tell me things like:
- "adding this package will add X kb of code"
- "the package you are adding has often had vulnerabilities"
- "the package you are adding changes very often"
- "this package and pinned version is trusted by many and will not likely need to change"
- "here are your dependencies ranked by how much you use them and how much bloat they contribute with"
- "your limited usage of this package shows that you would be better off writing the code yourself" Tools that help us understand performance better. Performance monitoring in production is a complicated task in itself (even with stuff like Sentry) and still is poor at producing actionable insights. I would want tools that tell me things like:
- This function you are writing is likely to be slow (due to exponential complexity, due to sequential slow/network operations, etc)
- This function has this time distribution in prodution, as reported from your performance monitoring system
- There are faster versions of this code (e.g. reference jsperf)
- This library / package / language feature has this performance characteristic
- Here are outliers in the flamegraph generated by this function or line
- This code is X% slower than similar solutions
- Making developers load their apps at the average speed users access them (e.g. throttling)
- Bots that can produce PRs to open source projects to find common low hanging fruits in reducing complexity or increasing performance Tools to evaluate complexity and tech debt over time:
- Can a tool tell us what the lifetime cost of a solution is? How can a development organization make tradeoffs between what's fast to get out the door vs what it takes to maintain over time? |