Есть ли у Classic ASP / JScript недостатки в производительности, масштабируемости или надежности?

Question

Написание классического ASP-кода на JScript имеет много общего: более гуманный синтаксис, разумная объектная система, знакомство программиста и общее отсутствие раздражающих факторов.Вы даже можете смешать унаследованный VBScript и новый код JScript в своих существующих приложениях Classic ASP, если вы помните о нескольких причудах.

Я думал, что должна быть какая-то причина, по которой он не используетсяБольше.Это просто импульс и отсутствие документации?Или есть ли веские причины с точки зрения производительности, масштабируемости или надежности придерживаться VBScript?

Примечание: меня интересует только сравнение VBScript и JScript.Я знаю, что Classic ASP вообще куча, но у меня здесь нет выбора.

Answer 1

Я голосую за JScript. Несколько лет назад я провел некоторые исследования и не обнаружил реального влияния на производительность при использовании того или другого. Это правда, что многие примеры и документация (все они будут старыми) будут использовать VBScript, но их легко перевести, если вы немного знакомы с JScript.

JScript - это разновидность Microsoft ECMAScript или «JavaScript».

• JavaScript работает на Windows, Linux и Mac (а также на iPhone, Android, Windows Phone и даже .NET и Java через проекты компиляторов / интерпретаторов). VBScript работает только в Windows, и даже тогда у меня есть только два основных интерпретатора, о которых я знаю: Classic ASP и Windows Scripting Host, и оба устарели.
• JavaScript - открытый стандарт, VBScript - проприетарный язык (http://en.wikipedia.org/wiki/ECMAScript)
• JavaScript включен по умолчанию в каждой операционной системе Windows после '95
• Microsoft, Google, Mozilla и многие другие активно разрабатывают способы ускорения работы JavaScript в других средах, таких как браузер. Нет такой разработки для VBScript, который в значительной степени тупик.
• JavaScript - это объектный / прототипный язык, который поддерживает ООП (включая наследование, полиморфизм и инкапсуляцию через замыкания). Попробуйте сделать все это в VBScript.

http://javascript.crockford.com/prototypal.html

http://ejohn.org/blog/simple-javascript-inheritance/

http://w3mentor.com/learn/javascript-examples/object-oriented-javascript/example-of-encapsulation-using-javascript/

• И VBScript, и JScript могут использовать встроенные инструменты для анализа XML, но JScript выигрывает с JSON
• JScript в WSH может делать все, что VBScript может делать с одним или двумя очень редкими исключениями. В этих случаях RARE вы можете вызывать VBScript с помощью механизма сценариев ActiveXObject.
• JScript имеет гораздо лучший / современный метод try {} catch {}, который принят даже в VB.NET, тогда как VBScript имеет только ON ERROR

VBScript может иметь преимущество над JScript с некоторыми API или интерфейсами, но это легко исправить. То же самое делает jQuery для ужасного DOM API в браузере, JScript на стороне сервера может сделать, потому что он чертовски гибок.

Не должно быть проблем с поддержкой JScript на стороне сервера (в отличие от VBScript), потому что любому порядочному веб-программисту нужно знать JavaScript, который Microsoft приняла (см. Windows 8, см. VS2010, включая jQuery в шаблонах и т. Д.). и многое другое).

Я думаю, что это больше связано с аудиторией и невежеством. Microsoft любит обслуживать своих разработчиков VB. Я был разработчиком VB до того, как мои глаза открылись для C # и JavaScript.

Пожалуйста! Используйте JScript. Продвигать JScript. Давайте двигаться вперед и оставим VBScript в пыли.

Answer 2

Позвольте мне отметить это в верхней части ответа. Используйте VBScript на стороне сервера. По двум ключевым причинам.

1. 99,99% всех примеров / примеров / обсуждений о кодировании ASP представлены в VBScript.
2. VBScript предназначен для работы с интерфейсами OLE Automation.

Нет реальной проблемы масштабирования или производительности при использовании стороны JScript-сервера.

Надежность требует дальнейшей квалификации. Движок JScript так же надежен, как и движок VBScript. Однако от надежности зависит многое от разработчика.

Хорошо разбираясь как в VBScript, так и в JScript, я подумал, что предоставлю JScript на сервер назад (поскольку из этих двух Javascript - мой предпочтительный язык). Я обнаружил, что легко запутался в коде, который должен был работать на стороне сервера. и код для запуска на стороне клиента, все выглядит одинаково. Следовательно, наличие серверного кода в совершенно ином синтаксисе, чем у клиента, нельзя недооценивать.

Настоящая причина, по которой следует избегать JScript, заключается в том, что VBScript предназначен для работы с объектами автоматизации COM / OLE, тогда как автоматизация COM / OLE должна была быть «подкована» в JScript. Я постоянно находил код, который пытался добавить свойство к объекту, которое на самом деле ActiveXObject не могло бы принять создание атрибутов. Также достаточно лаконичный код, если VBScript (да, я знаю, вы не ожидали, что я это скажу) станет более громоздким, поскольку JScript не понимает концепции свойства по умолчанию, как VBScript.

Обычно серверный код подразумевает работу с ADODB, и я обнаружил, что в JScript это выглядит немного неприятно. VBScript является гораздо более естественным партнером для ADODB, чем JScript.

Вам также необходимо учитывать разработчика / подрядчика сопровождения ASP, который придет за вами. Работа в ASP в современном мире достаточно плохая, но вы не оказываете никакой пользы работе с ASP нестандартным способом. Через 5 лет все еще будут работать старшие разработчики, которые будут зарабатывать хорошие деньги, настраивая очень старый, но работающий ASP-код, но они будут ожидать, что он был написан на VBScript, иначе они просто уйдут.

Answer 3

Не многие люди используют jScript для классического ASP, большинство предпочитает VBScript.Хотя я не знаю о каких-либо различиях в производительности, обычно будет проще найти примеры кода, людей, которые «сделали это», и других форм поддержки, использующих VBScript.