3 ms·

Yeah, I'm becoming increasingly frustrated by the flood of "anti-hype-driven-development" blog posts being praised. The entire article could be summed up with:

Yeah, I'm becoming increasingly frustrated by the flood of "anti-hype-driven-development" blog posts being praised. The entire article could be summed up with: > Is it solving your problem, and what is the cost? And it cuts both ways. Change for the sake of change is bad. But so is stagnation for the sake of stagnation. Picking the best tool for the job and continuous improvement are the closest thing to universal advise in front-end land. The "everything new is bad" rhetoric is getting exhausting.

hn_check 6y ago
In the JavaScript/web framework space, it is absolutely remarkable how much running to stand still occurs. How people making absolutely trivial apps have megabytes of frameworks, having injected many magnitudes extra complexity, for illusions. It's bizarre. It's like web developers have some major inferiority complex so there's this desperate need to make responding to a button and changing an input into some monstrosity of hilarious over-engineering, the result being some colossal piece of shit. There have been incredible advances in software engineering in general, but the web space is really a counter-example -- I really don't feel there has been beneficial movement in a decade or more. Which is why frameworks and approaches are all so temporal -- the lack of legitimacy makes it so easy to unseat for the next silver bullet for hilariously simple apps.
brailsafe 6y ago
I think the idea is to disassociate newness from improvement and only associate it with improvement when it's actually improvement. It's not wise to pick a different tool for every job, nor is it wise to only stick to one tool all the time. The fatigue imo comes from producing approximately the same output in ever more complex but not necessarily more interesting or better ways. If it does arguably provide a marked improvement, then definitely experiment and see how it might help

hn_check 6y ago

In the JavaScript/web framework space, it is absolutely remarkable how much running to stand still occurs. How people making absolutely trivial apps have megabytes of frameworks, having injected many magnitudes extra complexity, for illusions. It's bizarre. It's like web developers have some major inferiority complex so there's this desperate need to make responding to a button and changing an input into some monstrosity of hilarious over-engineering, the result being some colossal piece of shit. There have been incredible advances in software engineering in general, but the web space is really a counter-example -- I really don't feel there has been beneficial movement in a decade or more. Which is why frameworks and approaches are all so temporal -- the lack of legitimacy makes it so easy to unseat for the next silver bullet for hilariously simple apps.

brailsafe 6y ago

I think the idea is to disassociate newness from improvement and only associate it with improvement when it's actually improvement. It's not wise to pick a different tool for every job, nor is it wise to only stick to one tool all the time. The fatigue imo comes from producing approximately the same output in ever more complex but not necessarily more interesting or better ways. If it does arguably provide a marked improvement, then definitely experiment and see how it might help