By your coworkers point of view, .NET and JAVA are for people who don't know enough assembly.
Frameworks exist for a reason. They allow you go focus on the problem instead of dealing with repetitive code. They allow you to be confident (assuming you use well tested frameworks) that certain pieces of your code are reliable and well tested.
If your coworkers are against frameworks, I would seriously consider moving on.
Since no one has mentioned it - a Javascript framework rapidly becomes one more project dependancy, and in general terms, dependencies are bad as they represent points of failure.
As for this:
Mainly for people that don't know enough JS
Without elaborating, I will say that if one of our team said something like that in my presence, I would try to shrug it off as a joke. If I thought they were being serious, I would probably have to kill them.
And as for this:
Frameworks limit Javascript developers
That could translate to "Frameworks make it marginally harder to write spaghetti code, and that's what I do best"
A few positives for javascript frameworks (like JQuery).
They provide standardization in ui elements.
Reduce time to develop complex interfaces and effects.
Normalize efforts by providing functions that are already cross-browser compatible.
Due to efforts in cross compatibility documentation is more useful in a framework as you can use the framework's api as canon instead of searching for obscure support for various/proprietary javascript functions.
Reduced learning curve for new developers making them productive on your software quicker.
I completely disagree that a framework limits javascript developers. Quite the opposite actually. Most frameworks provide extensive plug-in mechanisms where the framework can be extended using raw javascript utilizing hooks in the framework itself.
I'll use jQuery as an example, but what I'm saying here could apply to most JavaScript frameworks.
Many frameworks (notably jQuery) are far too monolithic and not modular enough.
While depending on well-tested 3rd party software is often more than justified, "frameworks" tend to give you a lot more functionality than you need at the moment.
In many projects, I very much like the convenience that jQuery gives me for selecting sets of elements (using $(".classname"), for example). But, if I'm not using any significant amount of AJAX, I don't need the AJAX utilities provided by jQuery.
Software should do one thing and do it well, and software written in JavaScript is no exception. Most of the frameworks you refer to try to do everything, resulting in unnecessary complexity.
One place this can bite you is when you're considering upgrading to the next version of the framework. That involves crawling through jQuery's changelogs for backwards-incompatible changes and searching your project for areas where that code is used. This can be quite a nightmare, especially if you don't necessarily have a comprehensive list of which jQuery features you use and which ones you don't.
Also, jQuery (and other frameworks) tends to cause developers to start depending on new features of jQuery without even thinking about it, making it harder to determine which features of jQuery your project uses and which it doesn't.
If you use a utility which does one thing, then you know exactly which features of that utility you're using. There's only one. (If you aren't using that utility at all, it's easy to determine. Such a determination would mean you could safely remove it from your project.)
I'm all for using well-tested 3rd party code. But if it tries to do too much, (that is, if it's a framework rather than a utility), you should probably look for an alternative. If it tries to do too much (like jQuery tries to do too much), then it's got some serious, foundational design flaws that will probably come back to bite you.
A lot of web developers default to using JQuery without considering the alternatives
And end up including it on a web page to do a few trivial tasks which could easily be done in pure JavaScript
The result is that users have to wait for the whole library to download and it slows down web browsing
Also:
Some web developers get carried away with the design of web pages, and end up developing unnecessarily complex web pages because of the power of JQuery
Just because JQuery enables you to create scripts with good cross-browser compatibility it doesn't mean that the end result is usable on different devices / interfaces
I'd also argue the cross-browser compatibilty because I've seen instances of webkit not playing well with JQuery
JQuery encourages "fast" scripting - but if you rush it you are likely to have missed something out
Writing in JavaScript from scratch is slower - but I believe that you end up with a more complete solution which more closely matches the users needs
Using JQuery can shift the focus of the web developer to creating web sites which are highly graphical and visually appealing, whereas the focus should be on functionality and usability
JQuery is not a silver bullet for web development
I am biased here because I don't use JQuery, but it is because I haven't found a need for it yet - maybe it's because I focus more on usability and functionality rather than making the user interface look pretty (sorry I know JQuery can do more than that).
There are plenty of good reasons to be suspicious of frameworks in general, balanced of course by lots of reasons why they are worthwhile.
I use jquery now, and frankly within an hour of learning it realised that it fits the job so well that if it didn't exist I'd only end up reimplementing something very similar myself, only it wouldn't be as good or as cross platform.
There isn't much bloat there, it's very small and well designed and does nothing at all that stops you writing any javascript you want for specific cases that don't fit your needs.
反对库的一个论点是浏览器支持大多数库只支持一部分浏览器。 这里是 BBC 推出自己的示例而不是使用 jquery 之类的东西。
An argument against libraries is BROWSER SUPPORT most libraries support only a subset of browsers out there . Here is an example of BBC rolling out their own instead of using something like jquery .
发布评论
评论（9）
反对的论点：
Arguments against:
</sarcasm>
从您同事的角度来看，.NET 和 JAVA 适合那些不太了解汇编的人。
框架的存在是有原因的。 它们使您可以专注于问题而不是处理重复的代码。 它们让您确信（假设您使用经过良好测试的框架）您的某些代码片段是可靠且经过良好测试的。
如果你的同事反对框架，我会认真考虑继续前进。
By your coworkers point of view, .NET and JAVA are for people who don't know enough assembly.
Frameworks exist for a reason. They allow you go focus on the problem instead of dealing with repetitive code. They allow you to be confident (assuming you use well tested frameworks) that certain pieces of your code are reliable and well tested.
If your coworkers are against frameworks, I would seriously consider moving on.
由于没有人提到它 - Javascript 框架很快就成为又一个项目依赖项，一般来说，依赖项很糟糕，因为它们代表了失败点。
至于这个：
足够的 JS
无需详细说明，我会说，如果我们团队中的一个人当着我的面说了类似的话，我会尝试将其视为一个笑话而耸耸肩。 如果我认为他们是认真的，我可能不得不杀了他们。
至于这个：
这可以翻译为“框架
使编写意大利面条式代码变得稍微困难，而这就是我最擅长的”
这些不是争论，而是借口。
Since no one has mentioned it - a Javascript framework rapidly becomes one more project dependancy, and in general terms, dependencies are bad as they represent points of failure.
As for this:
enough JS
Without elaborating, I will say that if one of our team said something like that in my presence, I would try to shrug it off as a joke. If I thought they were being serious, I would probably have to kill them.
And as for this:
developers
That could translate to "Frameworks make it marginally harder to write spaghetti code, and that's what I do best"
Those are not arguments, they are excuses.
JavaScript 框架（如 JQuery）的一些积极因素。
元素。
界面和效果。
已经有的功能
跨浏览器兼容。
兼容性文档比较多
在框架中很有用，因为您可以使用
框架的 api 与 canon 一样
而不是去寻找晦涩难懂的东西
支持各种/专有
JavaScript 函数。
开发人员使他们富有成效
您的软件速度更快。
我完全不同意框架限制 javascript 开发人员的观点。 实际上恰恰相反。 大多数框架提供了广泛的插件机制，可以使用框架本身中的钩子使用原始 JavaScript 来扩展框架。
A few positives for javascript frameworks (like JQuery).
elements.
interfaces and effects.
functions that are already
cross-browser compatible.
compatibility documentation is more
useful in a framework as you can use
the framework's api as canon
instead of searching for obscure
support for various/proprietary
javascript functions.
developers making them productive on
your software quicker.
I completely disagree that a framework limits javascript developers. Quite the opposite actually. Most frameworks provide extensive plug-in mechanisms where the framework can be extended using raw javascript utilizing hooks in the framework itself.
我将使用 jQuery 作为示例，但我在这里所说的内容可以适用于大多数 JavaScript 框架。
许多框架（尤其是 jQuery）过于单一且不够模块化。
虽然依赖经过充分测试的第三方软件通常是合理的，但“框架”往往会为您提供比您目前需要的更多的功能。
在许多项目中，我非常喜欢 jQuery 为我提供的选择元素集的便利（例如，使用 $(".classname")）。 但是，如果我没有使用任何大量的 AJAX，我就不需要 jQuery 提供的 AJAX 实用程序。
软件应该只做一件事并且把它做好，用 JavaScript 编写的软件也不例外。 您提到的大多数框架都试图做一切，导致不必要的复杂性。
当您考虑升级到框架的下一版本时，这可能会困扰您。 这涉及到在 jQuery 的变更日志中爬行以查找向后不兼容的更改，并在项目中搜索使用该代码的区域。 这可能是一场噩梦，特别是如果您不一定有您使用的 jQuery 功能和不使用的 jQuery 功能的完整列表。
此外，jQuery（和其他框架）往往会导致开发人员不假思索地开始依赖 jQuery 的新功能，从而更难确定您的项目使用和不使用 jQuery 的哪些功能。
如果您使用的实用程序只做一件事，那么您就确切地知道您正在使用该实用程序的哪些功能。 只有一个。 （如果您根本不使用该实用程序，则很容易确定。这样的确定意味着您可以安全地将其从项目中删除。）
我完全赞成使用经过良好测试的第三方代码。 但如果它试图做太多事情（也就是说，如果它是一个框架而不是一个实用程序），您可能应该寻找替代方案。 如果它试图做太多事情（就像 jQuery 试图做太多事情一样），那么它就会有一些严重的、基础性的设计缺陷，这些缺陷可能会反过来咬你一口。
I'll use jQuery as an example, but what I'm saying here could apply to most JavaScript frameworks.
Many frameworks (notably jQuery) are far too monolithic and not modular enough.
While depending on well-tested 3rd party software is often more than justified, "frameworks" tend to give you a lot more functionality than you need at the moment.
In many projects, I very much like the convenience that jQuery gives me for selecting sets of elements (using $(".classname"), for example). But, if I'm not using any significant amount of AJAX, I don't need the AJAX utilities provided by jQuery.
Software should do one thing and do it well, and software written in JavaScript is no exception. Most of the frameworks you refer to try to do everything, resulting in unnecessary complexity.
One place this can bite you is when you're considering upgrading to the next version of the framework. That involves crawling through jQuery's changelogs for backwards-incompatible changes and searching your project for areas where that code is used. This can be quite a nightmare, especially if you don't necessarily have a comprehensive list of which jQuery features you use and which ones you don't.
Also, jQuery (and other frameworks) tends to cause developers to start depending on new features of jQuery without even thinking about it, making it harder to determine which features of jQuery your project uses and which it doesn't.
If you use a utility which does one thing, then you know exactly which features of that utility you're using. There's only one. (If you aren't using that utility at all, it's easy to determine. Such a determination would mean you could safely remove it from your project.)
I'm all for using well-tested 3rd party code. But if it tries to do too much, (that is, if it's a framework rather than a utility), you should probably look for an alternative. If it tries to do too much (like jQuery tries to do too much), then it's got some serious, foundational design flaws that will probably come back to bite you.
我很惊讶没有人提到过它：
另外：
我在这里有偏见，因为我不使用 JQuery，但它是因为我还没有找到它的需要 - 也许是因为我更关注可用性和功能，而不是让用户界面看起来漂亮（抱歉，我知道 JQuery 可以做更多的事情）。
I'm surprised no one has already mentioned it:
Also:
I am biased here because I don't use JQuery, but it is because I haven't found a need for it yet - maybe it's because I focus more on usability and functionality rather than making the user interface look pretty (sorry I know JQuery can do more than that).
一般来说，有很多充分的理由对框架表示怀疑，当然也有很多理由说明它们值得。
我现在使用jquery，坦率地说，在学习的一个小时内，它意识到它非常适合这项工作，如果它不存在，我最终只会重新实现一些非常相似的东西，只是它不会那么好或不如跨平台。
那里没有太多的臃肿，它非常小并且设计精良，并且完全不会阻止您为不符合您需求的特定情况编写任何您想要的 JavaScript。
There are plenty of good reasons to be suspicious of frameworks in general, balanced of course by lots of reasons why they are worthwhile.
I use jquery now, and frankly within an hour of learning it realised that it fits the job so well that if it didn't exist I'd only end up reimplementing something very similar myself, only it wouldn't be as good or as cross platform.
There isn't much bloat there, it's very small and well designed and does nothing at all that stops you writing any javascript you want for specific cases that don't fit your needs.
我喜欢pb +的答案
我相信这对他们来说太复杂了，所以他们用这个借口。 FW 允许您构建更复杂的应用程序。
废话
今天额外100k-200k是什么？ 特别是如果您使用 CDN 版本（例如在 google）。 这是假设您在固件中没有使用任何内容。
I liked the answer of pb +
I believe it is too complicated for them, so they use this excuse. FW allows you to build much more complex applications.
bullshit
what is it today extra 100k-200k? especially if you use the CDN versions (at google for instance). And this is assuming you use nothing in the FW.
反对库的一个论点是浏览器支持大多数库只支持一部分浏览器。
这里是 BBC 推出自己的示例而不是使用 jquery 之类的东西。
An argument against libraries is BROWSER SUPPORT most libraries support only a subset of browsers out there .
Here is an example of BBC rolling out their own instead of using something like jquery .