4 ms·
> in order to build anything of any remote sophistication, you need a framework Sure. But does the project/requirement described in the original article sound
by bigiain 6y ago
> in order to build anything of any remote sophistication, you need a framework
Sure. But does the project/requirement described in the original article sound particularly sophisticated?
I note that HN loads less that 150 lines of js and no framework. While there's an argument to be made that this place's frontend code is "not remotely sophisticated", it without doubt provides a huge amount of value anyway.
While I agree with everybody here about the requirements for good frameworks (and good development practices) for complex or sophisticated web applications, to me at least it's abundantly clear the author of the article made the correct choice for her problem domain.
Some things should resist every effort to make them more complex or more sophisticated than they need to be. Most things probably.
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery
I strongly believe that, while he did not know it at the time, he was totally talking there about lines of code.
Bill Atkinson clearly took that philosophy to heart:
"He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000."
from: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
- spion 6y agoThe issue is that on regular projects/products, you are trying to hone on perfection by adding and removing a bunch of things and trying different stuff. This repeats for a longer period of time, say 6 months to a year. The codebase has got to be able to survive that churn in a sensible way, and certain tools like (ES6) modules, types and declarative UI descriptions that automatically update to reflect the changes really help with this process. Why does this declarative approach help? Because the more features you add, the more places can generate events that cause updates to the same DOM, and the number of possible transitions between those DOM states grows a lot larger. If the number of possible states that the DOM can end up in is N, the number of possible transitions is N^2. To a first approximation, declarative frameworks scale linearly with the number of interacting features, while imperative (the vanilla DOM API) scale quadratically.