4 ms·

> I think there's a conflict of interest when a guy whose job is to adopt these frameworks says they're good, don't you think? Not at all. The reason I accepte

by ng12 10y ago

> I think there's a conflict of interest when a guy whose job is to adopt these frameworks says they're good, don't you think? Not at all. The reason I accepted that gig was because the team previously had a complex SPA written with what the above poster would consider simple tools -- and they were extremely unhappy with it. It took too long to add features, to modify things, to grok the control flow, to hunt down bugs. And that's not to say the app was poor quality: for the tools used everything was fairly idiomatic and organized. They hired me because they thought things could be better, and I thought they could too. > As a developer, less code WITHOUT knowing what's going on underneath is the worst feeling ever. Do you write all your code in assembly? The whole reason we use tools is because we don't want to think about what's going on underneath. React/Redux are simple by design and both incredibly easy to reason about. Webpack is a little more complicated by nature (most build tools are) but even then the core API is very simple -- just define a chain of compilation tools to process files of a given type. > in adopting one new edge tool every month I'm not sure where you get this impression from. The last major change to my standard stack was Flux -> Redux, and that was almost a year ago (and a relatively simple migration). Apparently you enjoy being crumdugeonly, but please have some faith that some of the web development community know what they're doing and care very deeply about the same things you do -- namely, crafting maintainable software. > I need to build a quick prototype I just use plain old html/css/jquery Sure! Pick the right tools for the job. Those are the right tools for a demo, the wrong tools for a long-lived SPA which needs to be maintained/extended by a team of engineers.

Falkon1313 10y ago
It's actually a lot easier to maintain and extend something over a long lifespan if it doesn't have tons of dependencies from many different sources evolving in different directions at different velocities. In a long-lived application, early team members will need to learn the new tech and later team members will need training in the old ways to work on your now-archaic tech stack (that you couldn't upgrade because of version incompatibilities). They'll also need custom-built dev systems that come with the project (because some of the tools are no longer available in those versions or at all). You won't be able to use new tools without first backporting them. You may have to deal with potential security issues in code that is no longer supported even though you don't even need that code, because it's there in the dependencies. In fact, in some cases the use of lots of dependencies might actually be better for quick prototyping (because they let you do so much with so little development) that you don't have to maintain and extend than for long-term projects. It's a tradeoff. Either way has benefits and drawbacks.

by ng12 10y ago

Falkon1313 10y ago

It's actually a lot easier to maintain and extend something over a long lifespan if it doesn't have tons of dependencies from many different sources evolving in different directions at different velocities. In a long-lived application, early team members will need to learn the new tech and later team members will need training in the old ways to work on your now-archaic tech stack (that you couldn't upgrade because of version incompatibilities). They'll also need custom-built dev systems that come with the project (because some of the tools are no longer available in those versions or at all). You won't be able to use new tools without first backporting them. You may have to deal with potential security issues in code that is no longer supported even though you don't even need that code, because it's there in the dependencies. In fact, in some cases the use of lots of dependencies might actually be better for quick prototyping (because they let you do so much with so little development) that you don't have to maintain and extend than for long-term projects. It's a tradeoff. Either way has benefits and drawbacks.