您需要 登录 才可以下载或查看，没有帐号？立即注册
The developers were overworked and the site had never gotten enough budget to give it the rebuild it needed. Granted, they couldhave stuck with the original framework included but the problem was that as each of the frameworks faded and gave way to the next one, the ecosystem and community around them online dried up and shriveled.
There’s a happy ending to this story. Eventually, jQuery was used and all the other frameworks were removed (talk about a big performance win!). jQuery never suffered from the same fate as the other frameworks the team had tried to use—its ecosystem only continued to grow and flourish as time went on.
That isn’t entirely fair though, is it? There’s a reason people build these tools. Tools exist because somewhere someone thought one would be helpful in some way. So they created it and they shared it. And frankly, that’s pretty darn awesome.
To be clear, I don’t think that was the point of the article. The thing is, it’s not the ecosystem that’s the problem. It’s great that we have a plethora of options available to us. It beats the alternative. No, the problem is the way we’ve chased after each new tool that comes along and even more concerning to me, the way we teach.
Our industry loves tools, and not without reason. Tools help us to be more productive. They can help to automate low-hanging fruit that is critical to the success of a project. They can help to obfuscate tricky browser compatibility issues. The can free us up to focus on the bigger, more interesting challenges presented. Tools are generally a “Good Thing”.
Unfortunately our love of tools has lead to an unhealthy mentality where we constantly feel the need to seek out the next great tool to be released.
Build scripts are a fun example. Gruntcame out and was really instrumental in getting the front-end community as a whole to give more serious consideration to having a formal build process. Just as people started to adopt it more frequently, the early adopters were already starting to promote Gulpas a superior option. As some developers tried to make the shift, still others jumped on Broccoli. For many, it seemed that just as they started to understand how to use what hadbeen the new best option, an even newer best option would become available.
Mostly, I think the evolution is healthy. We should be iterating and improving on what we know. And each build tool does things a little differently and different people will find one or the other fits their workflow a bit better. The problem is if we blindly race after the next great thing without stopping to consider the underlying problem that actually needs solving.
Just as each additional tool adds complexity to our development environment, each additional tool we mention when teaching someone about how to build for the web introduces complexity to the learning environment. That, I think, was the point of the post going around. Not that the ecosystem is flawed, not that the diversity of options is a bad thing, but that when someone wants to find an answer to a problem, the response they get frequently starts with “use this tool, then set this up”.
It’s ok—good even—to teach new tools that may be helpful. But when we do so, we need to be careful to present why these tools may be helpful as well as when they may not be. We need to be careful to separate the underlying issue from the tool itself, so that the two do not become conflated. Let people learn what’s going on under the hood first. Then they can make a determination themselves as to the necessity of the tool.
Those tools are useful in the right context, but you need to be able to understand what that context is. Whenever you come across an issue that needs solving, think about what the underyling problem actually is. Only once you’ve identified that should you consider whether you might want to use a tool to help you address the problem, and which tool that might be.
For the tool itself, there’s a few things you might want to consider. Here’s what I tend to look at:
There may be more questions you want to ask (how active the community is, the number of contributors, etc), but I find this is a really good start to help me begin to think critically about whether or not it is worthwhile to introduce another tool into my current environment.
- Who benefits from the use of this tool and how?Someone has to benefit, or else this tool doesn’t really need to be here, does it? If you can’t articulate who is benefitting and how they’re benefitting, then it’s probably not a tool that needs to be used on this particular project.
- Who suffers and how?There is always a trade-off. Always. Someone is paying for the use of this tool in some way. You could be adding complexity to the development environment or, in the worst case scenario, it could be your users who are paying the price. You need to know the cost so that you can compare it to the benefits and see if its worthwhile.
- How does it fail?I’m stealing this from the fine folks at Clearleft, but I love the way this frames the discussion. What happens when something goes wrong? Like it or not, the web is a hostile environment. At some point, for someone, something will break.
Very often, the answer is no. Which means that when you’re chatting with some developer friends and they’re talking about using this brand new framework inside of a new code editor released last week, you may have to politely nod your head and admit you haven’t really dug into either yet. That’s nothing to be ashamed of. There is power in boring technology. Boring is good.
Have you ever watched someone who has been using Vim for years work in it? It’s amazing! Some joke that the reason they’re still in there is because they haven’t learned how to quit yet, but I think they’re onto something. While some of us jump from tool to new tool year after year, they continue to master this “boring” tool that just works—getting more and more efficient as time goes on.
We are lucky working on the web. Not only cananyone contribute something they think is helpful, but many do. We benefit constantly from the work and knowledge that others share. While that’s something to be encouraged, that doesn’t mean we need to constantly be playing keep-up. Addy’s advice on this is absolutely spot-on:
…get the basics right. Slowly become familiar with tools that add value and then use what helps you get and stay effective.
Start with the core and layer with care. A rock-solid approach for building for the web, as well as for learning.
下一篇：New AppCode 2016.2.3 EAP，集成开发环境