代码之家 › 专栏 › 技术社区 › Francis Shanahan

是否应该避免编写Javascript而支持GWT/WebSharper或其他抽象?

websharper gwt javascript

11

Francis Shanahan · 技术社区 · 15 年前

我很好奇对“编译成javascript的东西”有什么看法,比如GWT、Script和WebSharper等等。这些似乎是相当利基的组件,旨在让人们不用编写javascript就可以编写javascript。

就我个人而言,我很乐意编写javascript(使用JQuery/Prototype/ExtJS或其他类似的库),并将GWT之类的东西视为不必要的抽象,最终可能会限制开发人员需要完成的工作,或者提供一个非常冗长的解决方案。在某些情况下,您仍然会编写javascript,例如JSNI。

更糟糕的是,如果你不知道在幕后发生了什么,你就会冒着意外后果的风险。例如,您如何知道GWT正在正确地创建闭包和管理名称空间?

我很想听听别人的意见。这就是网络编程的发展方向吗?

5 回复 | 直到 15 年前

1

8

Anurag 15 年前

尽管我个人并不喜欢一种风格胜过另一种风格,但我不认为Javascript的抽象是这些框架带来的唯一好处。当然,在抽象整个语言的过程中,会有一些以前可能的事情变得不可能,反之亦然。使用GWT这样的框架而不是编写香草JavaScript的决定取决于许多因素。

$("p") == $("p") 回去吧 false

与上述问题有关的另一个方面是信任。我们不断地在低层抽象的基础上构建高层抽象,并依赖于这样一个事实,即低层的东西应该按预期工作。最后一次你是如何编译到C++或java程序的二进制中,以确保它正确工作?我们不相信,因为我们信任编译器。

此外,当使用这样一个框架时,例如使用JSNI回归JavaScript并不丢脸。这一切都是为了用手头的工具以最好的方式解决问题。JavaScript、Java、C#或Ruby等都不是什么神圣的东西。它们都是解决问题的工具,虽然它可能会成为你的障碍,但它可能是一个真正的节省时间的工具,而且对其他人有利。

至于我认为web编程将走向何方,我认为有许多有趣的趋势,或者更确切地说,我希望这些趋势会成功,比如服务器端的JavaScript。它为我解决了非常实际的问题,至少我们可以在web应用程序中轻松避免代码重复。相同的验证、逻辑等可以在客户端和服务器端共享。它还允许编写简单的(反)序列化机制,以便RPC或RMI通信变得非常容易。我的意思是,如果能写:

account.debit(200);

在客户端,而不是:

$.ajax({
    url: "/account",
    data: { amount: 200 },
    success: function(data) {
        ..
    }
    error: function() {
        ..
    }
});

最后,我们在构建web应用程序的框架和解决方案方面拥有如此多的多样性是很好的,因为下一代解决方案可以从每个解决方案的失败中吸取教训,并专注于它们的成功,以构建更好、更快和更棒的工具。

2

20

t0yv0 15 年前

应该避免使用JavaScript而支持X吗?尽一切办法!

为了我, ,与C在世界其他地区的作用相同。它是便携式的,广泛使用,它将保持。但我不想写JavaScript,就像我不想写汇编一样。我不想使用JavaScript作为语言的原因包括:

工具(代码编辑器、调试器、探查器)相当糟糕,其中大部分原因是(1)和(2):JavaScript不适合静态分析。
没有或非常有限的标准库。
有许多粗糙的边缘和使用变异的偏见。JavaScript是一种设计糟糕的语言,即使在非类型化的家族中也是如此(我更喜欢Scheme)。

我们正试图在WebSharper中解决所有这些问题。例如,visualstudio中的WebSharper具有代码完成功能,即使它公开了第三方JavaScript api,比如extjs。但我们是否已经成功或将要失败并不是关键。关键是,解决这些问题是可能的,而且我希望是非常可取的。

更糟糕的是,如果你不知道意外后果的风险。例如。你怎么知道GWT正在创造正确地?

这仅仅是关于以正确的方式编写编译器。例如,WebSharper以1-1的方式将F#lambda映射到JavaScript lambda(事实上,它从未引入lambda)。我也许会接受你的论点,如果你提到,比如说,韦伯尚不够成熟和测试,因此你是犹豫是否相信它。但是GWT已经存在了一段时间,应该会产生正确的代码。

归根结底,强类型语言要比非类型语言好得多——如果需要的话,您可以轻松地用它们编写非类型代码,但是您可以选择使用类型检查器,即程序员的拼写检查器。你为什么不呢?拒绝这样做在我看来有点鲁迪。

3

5

Ian Ringrose 14 年前

如果你不熟悉Javascript,你就不能理解web上大多数使用DOM/ExtJs的例子,所以你必须学习Javascript(出于某种原因,所有的F#程序员必须至少能够阅读C#或VB.NET,否则他们无法访问有关.NET framework的大部分信息)
在任何一个网络项目上,你都需要一些对DOM和CSS了如指掌的网络专家;这样的人愿意使用F而不是Javascript吗?
被绑定到编译器的提供者,他们将在5年左右的时间;我希望完全开放源码或由微软支持的工具。

在服务器/客户端之间共享代码
F#程序员的平均质量要比jscript程序员好得多。

4

2

eSniff 15 年前

我的观点是,每个框架都有其优缺点,项目团队应该在包含一个框架之前评估它们的用例。对我来说,任何框架都只是用来解决问题的工具,你应该为这项工作挑选最好的框架。

我自己更喜欢使用纯JavaScript解决方案,但是我可以想到一些GWT会有所帮助的情况。

5

1

Sasha Chedygov 15 年前

我知道这是一个过于简单的问题,因为像GWT这样的框架提供了很多其他的东西,但我是这样看待它的:如果你喜欢JavaScript,就写JavaScript;如果你不喜欢,就用GWT或者卡布奇诺什么的。

人们使用像GWT这样的框架的原因不一定是他们给出的抽象——你可以使用像ExtJS这样的JavaScript框架——而是他们允许你用JavaScript以外的东西编写web应用程序。如果我是一个想要编写web应用程序的Java程序员,我会使用GWT,因为我不必学习新的语言。