GWT与ScriptSharp优点和缺点 [英] GWT vs. ScriptSharp Pros and Cons

查看:99
本文介绍了GWT与ScriptSharp优点和缺点的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们已经确定,要维持大量JavaScript,我们需要编写全面的单页JavaScript应用程序,这对我们来说太困难了。依靠编程公约仍然让我们想要......特别是在重构领域。对于刚接触这些项目的开发人员来说,他们发现改变任何东西非常困难,因为他们不相信他们知道还有哪些人真正依赖于组件(易于处理找到所有参考文献...,并强烈地编码访问级别键入语言)。

我们一直在玩GWT,但我们的开发人员之一想要使用Script#。我们已经是一家基于微软的商店,并且使用C#完成我们所有的服务器端工作。

我不认为java会成为GWT的显示屏,因为它与C#非常相似。

我最初关注Script#主要围绕支持和文档。



一方面我们有谷歌,另一方面......一些老兄。
Script#也是封闭源代码......所以如果开发人员停止使用它,我们是S.O.L.吗?
我也觉得GWT有更多的文档和社区支持。



无论如何,你有没有使用过?思考?优点/缺点?



(关键是关头:问题不在于是否使用编译器......问题在于哪个编译器)



类似但不同的问题:

ScriptSharp可以带给我的工具包吗?

我应该使用ScriptSharp

解决方案

<我已经使用GWT好几年了。我从来没有听说过Script#,所以我只会告诉你为什么你应该坚持使用Google解决方案。


  1. 主动开发。谷歌有一个付费团队的工程师,既积极修复缺陷,又致力于新功能。我正在和其他一些开发者讨论如何为GWT实现一项新功能。


  2. 大型机构。谷歌已经投资这个项目并用它来实施大规模的解决方案。换句话说,他们正在吃自己的狗粮。他们有既得利益,不让它停滞不前或过时。

  3. 社区。有很多人在加入插件/第三方/ etc等库和API上工作,与香草发行版一起使用。这些人也在测试,归档和修复缺陷。
  4. 兼容性。 GWT可以使用浏览器可以执行的任何操作。还有针对jQuery和其他主要JavaScript库的插件,这些插件让您在使用JavaScript时更容易管理项目的复杂性。

  5. 打开。您自己触及了这一点。

注意我没有涉及到语言选择的问题。我认为这与你所描述的水平无关。请记住,第一次遇到Script#的限制或障碍时,由于您和我描述的内容,您将很快陷入停顿。



当然, ,我建议GWT只是因为记录。


We have determined it's too difficult for us to maintain the bulk of javascript we need to write full-scale "single page" javascript "applications". Relying on programming conventions still has left us wanting... especially in the area of refactoring. For developers new to these projects, they find it very difficult to change anything because they have no faith they know who else is truly relying on the component (things easy to do with "find all references..." and code access levels in strongly typed languages).

We've been playing with GWT, but one of our developers wants to use Script#. We are already a Microsoft-based shop, and do all of our server-side work in C#.

I don't consider java to be a show-stopper for GWT, as it's extremely similar to C#.

My initial concerns with Script# primarily revolve around support and documentation.

On one hand we have Google, on the other... "Some Dude". Script# is also closed-source... so if the developer stops working on it, are we S.O.L.? I also feel GWT has more documentation and community support.

Anyways, have you worked with both? Thoughts? Pros/Cons?

(To head this off at the pass: the question is not whether to go with a compiler or not... the question is which compiler)

Similar, but different, questions:

What advantages can ScriptSharp bring to my tool kit?
Should I use ScriptSharp

解决方案

I have been using GWT for several years. I have never heard of Script# so I will just tell you why you should stick with the Google solution.

  1. Active development. Google has a paid team of engineers both actively fixing defects and working on new functionality. I am currently in discussions with some other developers on how to implement a new feature for GWT.

  2. Large institution. Google has invested this project and used it to implement large-scale solutions. They're eating their own dogfood, in other words. They have a vested interest in not letting it stagnate or become obsolete.

  3. Community. There are plenty of people working on add-ins/third-party/etc libraries and APIs to use alongside the vanilla distribution. These same people are also testing, filing, and fixing defects.

  4. Compatibility. GWT can work with anything that the browser can do. There are also plugins for jQuery and other major JavaScript libraries that just make it plain easier to manage the complexity of your project when working with JavaScript.

  5. Open. You touched on this yourself.

Notice how I didn't touch on issues of language choice. I don't think that's really relevant at the level you describe. Remember that the first time you run into a limitation or road block with Script# you'll become quickly stuck due to the things that both you and I described.

Of course, I recommend GWT just because of the track record.

这篇关于GWT与ScriptSharp优点和缺点的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆