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 saying you're wrong. I'm not e
by cocktailpeanuts 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 saying you're wrong. I'm not even saying what you're doing doesn't matter. In theory it should work as you described. But I'm saying in reality you may be too into what you're doing that you don't realize what others think.
I've had a few people who were in your position in my past job, and they seemed to believe what they are doing is indeed better for the team (and so did the managers, that's why they were working on it in the first place!), but from an actual "user" point of view, they didn't help at all but made me a very dissatisfied developer. The thing is most people don't officially complain about it because they don't want to be seen as a loser who "can't move fast enough".
But here's what REALLY happens while you're thinking everyone's benefitting from your work:
As a developer, less code WITHOUT knowing what's going on underneath is the worst feeling ever. That's one of the biggest criticisms on rails. But that's a different story since rails actually provides huge benefit as a result (and people know that it isn't going anywhere so it's worth learning)
When we come to JS land, there's no clear "10X" benefit to adopting these technologies. Sure there are incremental benefits but they don't justify learning every new packaging tool / framework every couple of months. I shit you not, a lot of companies have gone from grunt to gulp to webpack (and who knows what's next) just because they're the cool new tool that's "better" than the other. Some may say I'm lying just to exaggerate, but I am not. They do this because they want to "attract new developers who are looking to work with latest technology".
But in my opinion that's the stupidest thing a product building company should do. You're better off attracting great developers by building a product that's so compelling that developers want to contribute no matter what the stack is. I'm sure Snapchat had no problem attracting top talent in LA when all they had was a shitty mobile app that they didn't even bother making pretty.
Lastly in most cases, only a few people on the team are responsible for taking on these framework migrations. Which means the rest of the developers just become "users" and are left feeling like some passive idiots who just follow the "early adopters". As a result the developers fall into two categories: 1. People who don't want to feel left out and pretend they like the tool and keep following (and this feeling of "following" feels really shitty if you are not a "follower" kind of person); 2. People who complain how these "upgrades" are totally unnecessary and as a result treated like "old school" by the people of group 1.
Step back and think about how much efficient web development has become for 90% of developers (Not for you, who already are on board and an expert in adopting one new edge tool every month). To be clear, I know how to use all these tools (grunt, gulp, webpack, etc.) but whenever I need to build a quick prototype I just use plain old html/css/jquery. You could say you could use things like Yeoman to set up things quickly, but that's not the point.
- 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 agoIt'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.