简体   繁体   中英

Javascript: At what point (if ever) should we use libraries?

Similar questions have been asked on SO, but I couldn't find this one. If I'm wrong, I'm sure the SO vigilantes will correct me ;)

My question is (deceptively) simple: At what point, if ever, should we use Javascript libraries?

Many developers advocate only using pure Javascript. Any yet it seems most developers do use some libraries. I'm not (necessarily) asking about specific libraries, but at what point do you decide to use a library or even a framework?

For example:

If I want to display a countdown timer, it would certainly be wasteful to include libraries for a timer and for DOM manipulation, since Javascript is perfectly capable of simply handling these operations.

BUT

If I am building a large-scale social media platform (think Facebook), surely it would be wise to at least include JQuery for cross-browser UI consistency, DOM manipulation, maybe Ajax, etc...

THEN

maybe we can look at some others -- an MVC framework, a templating library, etc...

I know many people also recommend only pulling the parts that you actually use out of a library.

SO

Any general recommendations for when (or how) to include libraries?

恕我直言,当您花费更多的时间来实现移动部件而不是应用程序本身时,就该开始使用库了

In general, you should use a library when you are comfortable with it. If you use jQuery or Mootools, and include them from for example Google Hosted Libraries ( https://developers.google.com/speed/libraries/ ) or another CDN, the file itself will nearly always be cached, or served once from a highspeed CDN with 30+ day expiration. While it is certainly possible to implement simple problems without using any libraries, the point of the library is to make your life as a developer easy. If your life becomes easier by using a library which does not make your site slower, or puts strain on your server, make it easier by all means.

As a recommendation, I'd reverse the question: always use a library, unless you can just as simply and quickly implement the full required solution without it.

I don't think there's a clear answer on this, and wouldn't be surprised if the question is closed because of it. I'll offer up my views in any case.

Your example of a counter vs. a social media platform is much too contrived to be in any way realistic. But even if it was a reasonable example, I'd say application size or complexity (perceived or otherwise) has very little to do with your decision. In fact, I think you're creating a problem you very likely don't have yet.

Instead of thinking of the tools needed to implement your application, think about what it is that you're trying to achieve with it. Some call this business logic, call it whatever you will, but if you're spending time thinking about tools rather then how to get to market, it's very likely you're focusing on the wrong things. Tools, and when to use them, should never be your primary concern.

Here's what I think you should do. Jot down two lines about why your application makes sense and why it's existence is justified – don't mention any tools! Bake them in to a fortune cookie and open it a few days later. If you read it and it still makes sense, then figure out what the minimum feature set is – don't mention any tools! Look at it again a couple of days later, does it still make sense? Excellent! Now build a prototype – don't care about what tools to use, just use whatever works to prove your idea. Show it to someone else, is it a useful demo? Yes? Superb, you've got a project!

Nowhere in this does it matter whether it was your own pure javascript, polluted by libraries or whether it was a completely different environment. The tools are not important. What's important is what you're trying to achieve and how to get it out there. The tools are peripheral, secondary. They are whatever you need to use to get where you're going. If that means using libraries that provide the moving parts to get your app rolling – fine! If it means using coffeescript over javascript – fine! In the end, what really matters is what you're trying to achieve, the tools you use to get there can't ever be the primary concern.

Figure it out as you go along. You'll probably get it wrong a bunch of times before you get it right, that's just the way the cookie crumbles.


You may also find this video useful. It's a talk about clean architectures, although it's mostly a recount of how not focusing on tools helped build a better product, and is likely what you want to do.

https://vimeo.com/43612849

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM