理想的HTML5 Web应用程序是否有任何限制


11

让我们假设以下两个假设是正确的。

  • 您的整个用户群到处都有宽带访问
  • 有一个假想的浏览器X,它始终实现HTML5和WHATWG组的整个规范草案,所有用户都使用浏览器X。

我们需要商业公共桌面应用程序用于商业公共HTML5 Web应用程序的固有限制是什么?

我对无插件Web应用程序的局限性感兴趣,这些应用程序既不依赖Flash / Java / SilverLight / etc桥提供额外功能,也不依赖浏览器插件提供额外功能。

不适用的可能限制:

  • 数据库?我们有WebSQL和indexedDB。
  • 文件IO?我们有HTML5 File API,它可以读写。
  • 速度?在最近的JavaScript引擎竞赛中,浏览器不再缓慢。本机C ++仅比chrome的V8引擎快3倍。
  • 开发工具?网络已经成熟,并且有大量可用的工具可供选择。
  • 封闭源?是的,所有代码都是开源的。这是一把双刃剑,对于使用封闭源代码或开放源代码有很多意见。我个人认为开放源代码的优点胜于缺点。
  • JavaScript / HTML5?诸如“我个人认为HTML5和EcmaScript是可怕的开发平台”之类的争论不计在内。

已知限制:

  • 实时/安全(最高机密)关键代码不属于网络,也不属于网络。它需要使用低级,高度可控的语言(例如C或C ++)编写。
  • 任何需要与计算机上连接的外部第三方硬件交互的工具,都很难与Web应用程序通信。

还有一整套不属于网络的程序。操作系统,驱动程序,服务器软件,低级API。我知道这一点,但是我没有将它们归类为“商业公共”应用程序,这些是可以预先安装在计算机上的软件类型。

顺便说一句,我知道这两个假设非常不现实,但我们可能会在5/10/20/30年内实现它们。我对应用程序的类型以及使它们与网络完全不兼容的应用程序功能感兴趣。

动机:

要点:

考虑到桌面应用程序是有效解决方案的一系列问题。

  • 为什么Web应用程序不是有效的解决方案?
  • 如何确定我是否可以使用Web应用程序作为解决方案。

我试图通过断言它们不存在来消除Web应用程序的主要困难(互联网连接和浏览器支持)。

此外,HTML5脱机应用程序和Modernizr有望解决这两个问题。

Web应用程序开发还有哪些其他困难?


2
主要局限性:对于足够多的人想要使用的Web应用程序来说,这是一个好主意,并与至少会带来回报成本的业务模型相关。其余的仅次于。
SF。

“内在的限制是什么?” “固有限制”是什么意思?这些话是什么意思?您想要什么信息?你有什么问题?问题是什么?
S.Lott

@SF删除单词“ web”。您需要一个问题和一个解决方案。如果该解决方案是一个应用程序,则需要解决该问题,拥有一个用户群并拥有一个可以运行的业务模型。我只是比较将桌面应用程序作为解决方案的问题集,并质疑为什么Web应用程序无法正常工作。
雷诺斯

@ S.Lott您的正确,这个问题太含糊,我希望我已经弄清楚了实际的问题是什么。
雷诺斯

什么?“我们需要商业公共桌面应用程序用于商业公共Web应用程序的固有限制是什么?” 这是否表示“由于网络无法使用,我们何时需要桌面?” 如果是这样,所有的这些都是重复:programmers.stackexchange.com/search?q=desktop+web
美国洛特

Answers:


11

从我头顶上...

  • 访问通过文件以外的其他方式导出其I / O的专有硬件。是科学设备,工业机械或普通CD刻录机以及带有倾斜支撑的数字化仪平板电脑。
  • 仅HTTP和一小部分其他协议。您无法根据需要创建套接字,从而传输所需的任何二进制数据。这极大地限制了与其他系统和服务的连接。
  • 没有理智的开发人员会使用Javascript创建图形密集型游戏。宽带无法与通常需要的DVD / HDD吞吐量相提并论。在Canvas中对3D的支持远远不如游戏引擎。无法支撑操纵杆,同时按下多个键,开放的特性使作弊变得容易。但是首先,性能下降是不可接受的。
  • 沉重的沙箱。您不会得到与OS深度集成的内容。屏幕截图,防病毒,虚拟驱动器,后台任务以及系统任务,管理任务等。
  • 不能成为关键任务。大多数公司都不喜欢始终依靠宽带来运行其基本软件。

1
2. WebSockets公开一个TCP套接字。您无法在浏览器中访问UDP,但是TCP提供了更多选择。
雷诺斯2011年

2
3. WebGL正在取得一些有趣的进展。OpenCL支持最近已经开始。当然,它仍然比桌面游戏开发落后5年,但它开始成为可能。
雷诺斯2011年

2
@Raynos:WebSockets将提供类似套接字的功能,但是需要特定的握手,您不能轻松地使其适应现有系统,需要服务器端修改。意味着没有通用的SSH客户端Web应用程序。WebGL可能解决了一些gfx问题,仍然无法解决大量数据需求(千兆字节的纹理和网格),控制器I / O,而且音频支持目前也很差。
SF。

1
4. W3C设备API(我不知道)实际上已经在解决沙盒问题上扎实了。
雷诺斯

1
自您首次编写此答案以来,许多事情已经改变。浏览器本身已成为合法的软件平台;您在答案中描述的大部分内容现已成为可能。是的,只要付出足够的努力,我几乎可以想象浏览器中运行的任何游戏或应用程序。
罗伯特·哈维

3

本质上,任何适合服务器/客户端模型的东西都可以构成一个良好的Web应用程序,事实相反,也可以说是相反的。迁移到网络的趋势之所以如此迅速,是因为看到如何将大多数程序建模为“模型/控制器/视图”,程序可以从视图中拆分模型和控制器。

当然,出于效率方面的考虑,一些控制器也放置在客户端,以避免服务器因错误的请求和数据而过载。

尽管我的观点是:哪些程序不适合模型/控制器/视图软件体系结构,因为它们很可能是从未被转换为Web应用程序的相同程序。想到的好例子是操作系统,任务计划程序,命令提示符,病毒防护,间谍软件防护。由于其中的每一种都不适合该模型,因此可能无法在网站上实现。而且,这些程序中的每个程序都严重依赖于您的系统并非偶然。大多数服务器需要直接访问硬件,而其他一些仅需要更高的安全性才能运行,并且不能被Internet网站信任。

当然,Google会在其新操作系统中完全重新适应此概念。据推测,与Windows不同,它不仅仅是一个逐渐使用Internet的系统,而是一个严重依赖于Internet的系统。很快,您可能会看到所有这些程序都可以在线访问,并可以通过严格的证书认证来访问您的硬件和软件,以防止只是任何站点都可以这样做,而是阻止受信任的站点。我很想知道他们的想法,因为我考虑20年后,将不再使用可安装的软件来制造计算机。而是所有服务都将在线提供。


0

•任何需要与计算机上连接的外部第三方硬件交互的工具,都很难与Web应用程序通信。

我正在使用的软件现在具有桌面方面和基于Web方面,正是因为它需要从第三方外围设备收集数据。开发需要驱动程序和客户端桌面程序来弥合Device和Web之间的鸿沟。

但是,这并不排除Web应用程序,因为这些类型的桌面应用程序可能很薄,而逻辑大多位于服务器上。

另一方面,可以从云计算和大规模虚拟化方面说,没有应用程序必然受到网络技术的局限性和安全漏洞的限制。在虚拟终端(类似于Citrix)上从虚拟化环境运行桌面应用程序变得更容易实现,并且可能成为下一个发展的“时尚”。

最重要的是,现在有更多的选择比以往任何时候都多,并且有更多的议论者将明天的技术称为“最佳”方法。


1
有趣的是,您可以在Web浏览器上的虚拟环境中运行桌面应用程序。大多数VNC服务器的古老功能是VNC查看器Java小程序,默认情况下可在http:// [远程计算机]:5800 /上获得。
SF。

0

让我们假设以下两个假设是正确的。

  • 您的整个用户群到处都有宽带访问
  • 有一个假想的浏览器X,它始终实现HTML5和WHATWG组的整个规范草案,所有用户都使用浏览器X。

我们需要商业公共桌面应用程序用于商业公共HTML5 Web应用程序的固有限制是什么?

我对无插件Web应用程序的局限性感兴趣,这些应用程序既不依赖Flash / Java / SilverLight / etc桥提供额外功能,也不依赖浏览器插件提供额外功能。

好的,这就是麻烦所在:该浏览器本质上将是不安全的。因此,您要我们在两者之间进行权衡。但是,超越这一点,并假设我们确实有javascript(您在帖子中提到过),那么答案就是没有仅使用HTML5 / Javascript不能编写的应用程序。但是,我们确实假定浏览器不会妨碍您。

它有一个本地数据库存储,可以使用HTTP请求(RESTafarian会告诉您)来调用任何其他平台,并且可以(通过Canvas)绘制任何您想要的东西。已经有使用开放标准(OpenGL ish)编写的3D游戏,并且有API可以完成您想要的任何事情。

唯一真正的缺点是速度。使那些HTTP API调用其他系统(数据库)需要花费时间。处理FILE(COM1 :)请求(例如,通过Windows上的串行设备读取)将花费一些时间,因此这是我所期望的问题区域。当然,我还假定将驱动程序编写为像文件一样被访问,我敢肯定,现在不再如此。但是他们可以揭露这种机制;)

对于用户而言,根本没有什么不同。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.