Плюсы веб-языка по сравнению с традиционными языками программирования

Все современные пользователи персональных компьютеров знают, что работая во всемирной сети интернета, любую из его страниц (при желании, конечно), можно сохранить на своём ПК в виде файлов с расширением .HTM или .MHT, что стало неотделимой частью нашей повседневной работы. Но не все знают или хотя бы, задумывались о том, что .HTM-файлы – это программы, которые каждый раз создаются и записываются компьютером (по запросу пользователя) на специальном языке программирования – HTML. При этом, каждый раз, или в сети Интернета, или на ПК пользователя, при открытии файлов страниц интернета с расширением .HTM или .MHT, программа-браузер выполняет роль компилятора:
Она запускает программу, записанную на HTML-языке из открытого файла и выполняет её. Аналогично тому, как ещё, в старом добром DOSe, программа Quick Basic, при открытии файлов исходников программ с расширением .BAS (если она, запускалась соответствующей командой из приглашения командного процессора COMMAND.COM) сразу запускала их, выполняя все заданные в них, пользователем функции, так и любой браузер, является компилятором выполняющим программы записанные HTML-языке. Именно поэтому, в наше время HTML-язык, стал таким же популярным языком программирования, каким в своё время был «легендарный» BASIC.
Надо сказать, что в настоящие время не только, исходники новейших программных разработок, но также и новые версии, старых «добрых» программ написанных в своё время на BASIC, Pascal, C, C++, Ella, PROLOG и других популярных языках программирования, стало очень выгодно создавать на HTML–языке. Это всё потому, что HTML–язык, имеет массу плюсов и новых возможностей по сравнению с традиционными языками программирования.
Вот, некоторые из них:
Если программист пишет свою программу на HTML–языке (в программе, обычного текстового редактора), то необходимость в её отладке – минимальная. Когда, он (программист – автор программы) открывает, эту свою программу написанную на HTML– языке с помощи браузера интернета, то браузер (в данном случае, играя роль компилятора) выполняя программу из данного файла с расширением .HTM выполняет в нём, только те строки, которые программистом были написаны правильно, т.е. без синтактических ошибок. А те строки в данном файле с расширением .HTM, в которых браузер обнаруживает синтактические ошибки, он просто игнорирует и не выполняет.
Таким образом, при написании программы на HTML–языке, необходимость исправлять в исходном тексте программы, все синтактические ошибки (как это в привычных, языках программирования) полностью отпадает.
О том выполняет ли данная программа возложенные на неё функции или не выполняет, можно судить по результатам того, как она выполняется на компьютере. Если же при написании программы на HTML–языке, программист допустил синтактические или какие либо, другие ошибки (из за которых, она не работает так, как ему хочется), то ему надо только, с помощи обычного текстового редактора
открыть её файл с расширением .HTM и в нём найти и исправить, эти ошибки.
В HTML–языке, также расширена и возможность интегрированного программирования по сравнению с такими системами программирования, как C++, C# и Turbo Pascal. Так, в нём с помощи специальных Операторов можно, либо давать ссылки на открытие файлов скриптовых языков (Visual Basic, Java, Pyton и др.), либо включать исходник текста на этих скриптовых языках в тело самого файла HTML–языке. При этом, в файле исходника программы HTML–языке, может находится одновременно, и по несколько вложений исходного текста на этих скриптовых языках.
Стоит заметить, что скриптовый Visul Basic – это усовремененная обновлённая версия старого доброго языка BASIC, а Java – это усовременненный вариант сложных языков программирования, типа C++ и C#. Поэтому, если программист пишет на HTML–языке, обычную прикладную программку работающую с файлами, графикой или звукозаписью, то это лучше всего, сделать на скриптовом языке Visual Basic, а затем, этот исходник текста на Visual Basic с помощи специальных команд (типа<SCRIPT> и </SCRIPT>)

Миниатюры

 

0

Сообщение от voraa А что, другие еще существуют?

хз,
брузер шоп память не грузил на старых ноутах, будет криво выводить современный веб.
таких полно в инете.

я хз, из старья оно или обновляется...

0

Сообщение от XLAT интерпретатора

из описания современного движка JS V8

Компиляция исходного кода JavaScript непосредственно в собственный машинный код, минуя стадию промежуточного байт-кода.

0

Сообщение от voraa По мне называть текст, написанный на HTML программой - не совсем верно.

ок,
html, как расширение файла, то раз туда можно всунуть js и css,
то тогда почему не обозвать такой файл программой, ну с натяжкой?
))

хотя, разумеется, это скрипт.

Сообщение от testuser2 из описания современного движка JS V8

это опционально или уже обязательно?

0

Сообщение от XLAT это опционально или уже обязательно?

Я не знаю, забиваю в поисковик "современный движок js Chrome" и в первой строке Яндекса страница Вики на это

Добавлено через 11 минут
Вообще чуть раньше я услыша про V8 на Ютуб-стриме некого Мурыча (как я понимаю не последнего человека в теме JS). Я в JS ноль, и думал просто бегло глянуть видео для интереса, но, надо сказать, мне понравилось, то что он говорит, именно те аспекты и критерии, вообще подход и я досмотрел видео (час с лишним) от начала и до конца. Если опираться на его повествование, он раскрывает какой весь и себя JS и какие там проблеммы. Для себя я сделал вывод, что одна из основных проблемм - отсутствие статической типизации (как опции) в JS (о чем он мельком упоминает тоже), откуда проистекает сложность с точным контролем расхода памяти..

2

Сообщение от testuser2 отсутствие статической типизации

дык, если её туда добавить, то получится TypeScript

0

Сообщение от XLAT TypeScript

Слышал типа, это нечто работающее поверх JS, лень проверять.

Сообщение от testuser2 Для себя я сделал вывод

Точнее сказать, я так считаю, но у меня не было четкого представления и опоры, на какие-нибудь авторитеты. И вот наконец я услыша от этого Мурыча фразу, о том, что одно из того что он хотел бы увидеть в будуще в JS это статическая типизация - и меня это очень порадовало. Думаю, человека, занимающегося с давних лет реверс-инжинирингом (по его заверениям) можно в какой-то мере считать авторитетом и серьезным голосом. Мне не нравится идея ли концепция онли динамической типизации в языке тем более таком распространенном и широко-профильном как JS, это какая-то фикция, ошибка хрень. По моему хоть как ты проектируй ЯП, лучше сделать типы и все, опционально, но это будет лучше. Но с др. стороны кто я такой и что я знаю.., а вто когда я слышу подобные заявления т.ск. авторитетных людей это меня безусловно радует

0

Веб моей мечты - это латехоподобный язык разметки (т.е. полный по Тьюрингу язык программирования в качестве разметочного) вместо ублюдочной комбинации html+css, и эдакий аналог webassembly без необходимости приплетать всякий бред вроде жабоскрипта в качестве "загрузчика". Вот тогда заживем! Сел, написал на С бэкенд, на том же С написал код фронтенда, а разметка позволила бы одновременно получить и веб-морду, и standalone.
Сейчас нечто подобное пытаются сделать - тот же emscripten. Но оно еще очень и очень сырое. А т.к. я категорически не собираюсь лезть в GUI, покуда не будет вменяемых библиотек разработки (кстати, есть nuklear - потыкал палочкой, мне понравилось, но таки нет нужды, т.к. мне CLI за глаза хватает), плохо в курсе насчет современных тенденций этого.

Ну и да: все взаимодействие моих приложений - через SHM, UNIX-сокеты и INET-сокеты. Вот так бы и в веб-мордах… И не нужно было бы изобретать всякие невменяемые алгоритмы аутентификации, внедряя TLS: просто подключил libopenssh, и готово!

0

Сообщение от testuser2 из описания современного движка JS V8 Компиляция исходного кода JavaScript непосредственно в собственный машинный код, минуя стадию промежуточного байт-кода.

Пруф дайте.
Нет такого.
В браузере компиляции в машинный код (ассемблер) трудно дождаться.
Задача браузера показывать html страницу. И делать это максимально быстро. Если он все библиотеки, которые подключают к странице (а сейчас это может быть сотни килобайт js) будет компилить в машинный код, то мы долго будем ждать появления страницы.
В реальности сначала делается быстрый синтаксический анализ (строится AST). А компиляция любой функции в байт-код происходит только в момент ее вызова. Зачем компилить библиотеку из 100 функций, если в реальности вызовутся 10-20? (Про Файрфокс некоторое время назад читал, что даже при первом вызове он не компилирует, а интерпретирует по AST - простая одноразовая интерпретация по AST в среднем быстрее, чем компиляция в байт-код и интерпретация байт-кода, если функцию вызовут второй раз, то есть предположение, что эту функцию будут вызывать часто. Тогда имеет смысл компилировать байт-код)
Генерация ассемблерного кода производится только для часто вызываемых функций. И то не для всех. Если функция вызывается много раз (порядка сотни), то браузер начинает следить за ней. Если ее постоянно вызывают с параметрами одного типа, и глобальные переменные, которые она использует тоже не меняют свой тип, то через некоторое количество вызовов (это уже порядка 3000 - 5000) он принимает решение откомпилить ее в машинный код.

Сообщение от testuser2 я услыша от этого Мурыча фразу, о том, что одно из того что он хотел бы увидеть в будуще в JS это статическая типизация - и меня это очень порадовало.

А объективно, зачем в интерпретируемом языке нужна строгая типизация? Часто ли на языках, где она есть, программисты делают ошибки именно в типах. Скажем вместо строки передают число? Или вместо объекта (структуры) строку?
Или другие ошибки, не связанные с типизацией случаются чаще?

Сообщение от testuser2 Думаю, человека, занимающегося с давних лет реверс-инжинирингом (по его заверениям)

Думаю, если бы он занимался именно создание сайтов и приложений, писал бы реально используемый код, это было бы более авторитетно.

0

Сообщение от voraa В браузере компиляции в машинный код (ассемблер) трудно дождаться. Задача браузера показывать html страницу. И делать это максимально быстро. Если он все библиотеки, которые подключают к странице (а сейчас это может быть сотни килобайт js) будет компилить в машинный код, то мы долго будем ждать появления страницы. В реальности сначала делается быстрый синтаксический анализ (строится AST). А компиляция любой функции в байт-код происходит только в момент ее вызова. Зачем компилить библиотеку из 100 функций, если в реальности вызовутся 10-20? (Про Файрфокс некоторое время назад читал, что даже при первом вызове он не компилирует, а интерпретирует по AST - простая одноразовая интерпретация по AST в среднем быстрее, чем компиляция в байт-код и интерпретация байт-кода, если функцию вызовут второй раз, то есть предположение, что эту функцию будут вызывать часто. Тогда имеет смысл компилировать байт-код) Генерация ассемблерного кода производится только для часто вызываемых функций. И то не для всех. Если функция вызывается много раз (порядка сотни), то браузер начинает следить за ней. Если ее постоянно вызывают с параметрами одного типа, и глобальные переменные, которые она использует тоже не меняют свой тип, то через некоторое количество вызовов (это уже порядка 3000 - 5000) он принимает решение откомпилить ее в машинный код.

Тут главное еще понять что считать компиляцией. Вот допустим существуте понятие компиляции в пи-код (p-code). В vba, допустим компилится в такой код, в меню Debug есть пункт Compile VBA Project. Получается довольно быстрый код в отдельных случаях можно обрабатывать милионы данных за минуты. Присутствует ли в JS подобный вид компиляции я не знаю, но JS предоставляется как аналог VBA во многих софтовых решениях. Суть то в принципе похожая - скриптовый язык на базе приложения.. Хотелось бы видеть от JS тех же возможностей что и у VBA. VBA это очень не безопасный язык, там возможен вызов WinApi функций, что является его благословение и проклятием. JS это априори безопасный язык, + современный, многопоточный и т.д., + из недавних новостей, мы узнаем что там есть даже компиляция в натив (при определенных условиях и определенной погоде). Но есть одно НО.. В vba я могу создать массив типа double или long и точно знать что этот массив занимает непрерывный блок памяти определенного известного размера и обработка этого массива будет в 5-10 раз быстрее, если бы это это был массив типа variant. Может быть сравнение с JS будет не очен корректным, ведь там наверное хитро-выстеганые супербыстрые алгоритмы для того чтобы быстро вычислить и что куда расположить и как преобразовать в памяти, но строгие типы все равно будут быстрей.

Сообщение от voraa А объективно, зачем в интерпретируемом языке нужна строгая типизация?

Когда есть строгие типы компилятору (интерпретатору если хотите) уже не надо думать и вычислять что и как преобразовать и как расположить, ему уже сказали. Это должно работать быстрей + более точный и прозрачный контроль использования памяти. Что мне еще не нравится в ЯП-ах с дин. типизацией - это концепция - передачи данных по ссылке. Это конечно классная концепция, но почему бы программисту не дать выбор самому решать как передать данное конкретное значение, чтобы компил-интерпретатор об этом не думал.

Добавлено через 44 минуты

Сообщение от voraa Думаю, если бы он занимался именно создание сайтов и приложений, писал бы реально используемый код, это было бы более авторитетно.

Я не знаю, кто этот человек, но он говорит, допустим, что большинство js-программистов, не знают как правильно программировать и что даже в таких штуках как React творится полный бардак.. ) Кстати вот

Сообщение от voraa Если он все библиотеки, которые подключают к странице (а сейчас это может быть сотни килобайт js) будет компилить в машинный код, то мы долго будем ждать появления страницы.

все эти Реакты и пр. они тоже динамически подгружаются и компилируются каждый раз из нового сайта и заранее не предустановлены и не предкомпилированы в браузере?

0

Сообщение от testuser2 там возможен вызов WinApi функций

упоминание этой фикни в 21 веке,
когда речь идёт о веб-программировании(и тем более о веб),
просто не прилично.

только этим VBA себя полностью дискредитировал.

ибо:

Сообщение от XLAT Плюсы веб-языка по сравнению с традиционными языками программирования Раскрываю: 1. Кроссплатформенность: один и тот же HTML-5 код будет одинаково работать на любом железе с любой ОС где есть стандартный браузер. 2. Безопасность: гавно-хакеры могу писать любой HTML-5 код и можно не боятся его запускать у ся в песочнице, которая брузер.

если убиваются эти два пункта,
то мы сразу возвращаем веб-программирование в "дос-стоические" времена...

нужно уже перестать копаться в олдгуане,
рискуя на вечно там остаться,
лайф то короток.

0

Сообщение от testuser2 Вот допустим существуте понятие компиляции в пи-код (p-code).

В js компилится в байт-код, который потом интерпретируется. Для горячих функций производится перекомпиляция в ассемблерный машинный код, который исполняется непосредственно.

Сообщение от testuser2 JS это априори безопасный язык, + современный, многопоточный и т.д.,

В самом языке никак не определено, какие операции может или не может исполнять программа на js. В спецификации зафиксирован только стандартный набор функций для работы с массивами, объектами, строками, датами и т.п. Но js исполняется в какой то среде (браузер или node.js или еще что то) и эта среда предоставляет набор операций (API), которые там можно выполнять. В браузере есть только операция чтения из файла, и то не их любого, а только того, который явно укажет пользователь выбором в диалоговом окне. Есть API для работы с элементами HTML, Есть API для сетевых запросов, много других, типа геолокации. Многие операции требуют особого разрешения, и браузер перед выполнением операции спрашивает пользователя можно ли выполнять такие операции.
В node.js есть и API для работы с файловой системой.

Сообщение от testuser2 многопоточный и т.д., +

Вообще то js однопоточный, но с возиожностью асинхронности. Хотя организовать дополнительные потоки есть, но там многие возможности ограничены.

Сообщение от testuser2 Но есть одно НО.. В vba я могу создать массив типа double или long и точно знать что этот массив занимает непрерывный блок памяти определенного известного размера и обработка этого массива будет в 5-10 раз быстрее,

И как в таком случае сделать динамический массив? Добавлять новые элементы по мере необходимости, если заранее не известно, сколько их будет?
В js есть только один тип - number. Хранится как 64 разрядное число с плавающей запятой (double). Для разных внутренних операци он автоматически преобразуется как надо. Например, если число используется как индекс массива, оно будет преобразовано в 32 разрядное беззнаковое целое.

Сообщение от testuser2 Может быть сравнение с JS будет не очен корректным, ведь там наверное хитро-выстеганые супербыстрые алгоритмы для того чтобы быстро вычислить и что куда расположить и как преобразовать в памяти

Так и есть. Движок все сильно оптимизирует.

Сообщение от testuser2 но он говорит, допустим, что большинство js-программистов, не знают как правильно программировать

Не думаю, что он один знает. Он теоретик. А на практике работают сотни миллионов сайтов, и миллионы серверов. И без его подсказок. Копеечной экономией в пару машинных команд никто не занимается.

Сообщение от testuser2 все эти Реакты и пр. они тоже динамически подгружаются и компилируются каждый раз из нового сайта и заранее не предустановлены и не предкомпилированы в браузере?

Конечно их нет в браузере. Существуют десятки современных фрейворков, тысячи разных библиотек. Не будешь же все пихать в браузер. Многие фрейворки и библиотеки устаревают, придумываются новые. Но старые сайты используют старые. Они же должны работать. Призагрузке страницы весь код заново каждый раз загружается по сети. Конечно есть кеш браузера, но он ограниченный. Если загрузилась одна страница с библиотекой, потом пользователь перешел на другую страницу с такой де библиотекой, то сам файл библиотеки окажется в кеше и браузер его возьмет от туда. Но если открыть эту же страницу на следующий день, то этой библиотеки в кеше уже может не быть. Кеш не бесконечен. И ее заново придется скачивать.

Сообщение от testuser2 Что мне еще не нравится в ЯП-ах с дин. типизацией - это концепция - передачи данных по ссылке. Это конечно классная концепция, но почему бы программисту не дать выбор самому решать как передать данное конкретное значение, чтобы компил-интерпретатор об этом не думал.

А он и не думает. примитивные типы передаются по значению, объекты по ссылке.

1

Сообщение от XLAT упоминание этой фикни в 21 веке, когда речь идёт о веб-программировании(и тем более о веб), просто не прилично.

Неприлично выхватывать фразы из контекста.

Сообщение от XLAT олько этим VBA себя полностью дискредитировал.

Ни фига не дискридитировал, майкры все-то не могут от него отказаться, и по сей день нет лучшего решения среди аналогов оффисного софта. Всё хуже - среда разработки хуже, скорость хуже и т.д. VBA это все-таки язык 21 века, расцвет его использовани именно в 21 веке, хотя база у него 98 год, в последних версиях добавили поддержку x64, и юникод в диалгах и формах, но в сути это все тот же VB6.

Сообщение от XLAT нужно уже перестать копаться в олдгуане, рискуя на вечно там остаться,

Предлагаю наоброт мысленно вернуться в то время и представить, как бы развивался web, если бы в js добавили типы еще тогда, быть может "Одноклассники" были чуть быстрее... Вдруг там в тех далеких, было какое-то говно в концепциях и в головах, которое по прежнему не исправили.
Слышал, вот, в Ruby вроде хотят типы внедрять..

0

Сообщение от testuser2 если бы в js добавили типы еще тогда, быть может "Одноклассники" были чуть быстрее...

Почти ничего не зависит от скорости работы js. (Ну кроме случаев, если решается система сотен дифференциальных уравнений). Скорость работы сайта больше зависит от объема передаваемой информации, организации html и css (ведь помимо выполнения js кода браузер еще и занимается расчетом положений элементов html, применением к ним правил CSS и проч.). Ну и от скорости ответа сервера. Если на сервере сотни тысяч запросов в секунду, то конечно время ответа будет больше.

Добавлено через 2 минуты

Сообщение от testuser2 майкры все-то не могут от него отказаться, и по сей день нет лучшего решения среди аналогов оффисного софта.

Не могут отказаться и не откажутся, потому, что все старое должно работать.
Но javascript в офисе есть.
https://learn.microsoft.com/ru... for-office

0

Сообщение от voraa Но javascript в офисе есть.

как отедльная надстройка.

Добавлено через 3 минуты

Сообщение от voraa Почти ничего не зависит от скорости работы js.

И это тоже

Сообщение от voraa Если не учитывать время, в которое отсылает статья, то возможностей много.

Вы ранее упоминали про какие-то возможности..

Добавлено через 3 минуты

Сообщение от voraa (а сейчас это может быть сотни килобайт js)

сотни килобайт загружаются но "почти ни чего не зависит"

0

Сообщение от testuser2 Вы ранее упоминали про какие-то возможности..

Что именно вас интересует?
Для работы с графикой есть куча возможностей. В зависимости от потребностей. От создания простых графиков и рисунков, до довольно сложных графических объектов. Конечно это не изначально заложено в js. Используются API предоставляемое браузером.
Примеры
https://threejs.org/examples/#... _keyframes
https://threejs.org/examples/#... g_blending
https://threejs.org/examples/#webgl_decals

Разумеется есть и API для работы со звуком, микрофоном, камерой...

2

Сообщение от testuser2 из контекста.

вы умничка, что нашли это слово.

вот эта страница у меня одинаково крутится и на дескотопе и на дешёвом андроиде:
https://www.shadertoy.com/view/4t3SzN

и это значит, что всё хорошо.

а вба с винапи у меня будут также одинаково крутиться на всех девайсах, которые у меня есть?

или это риторический вопрос?

0

Сообщение от testuser2 сотни килобайт загружаются но "почти ни чего не зависит"

Это разные вещи.
Js событийный язык. Произошло какое то событие, на которое установлен обработчик (нажатие на кнопку, перемещение курсора, получение данных по сетевому запросу), срабатывает функция обработки этого события. Сами функции работают быстро. Но их много. Их все надо загрузить при открытии страницы.

0

по поводу компиляции в веб-программировании,

моё имхо, без всякого гугла:

вот и вся тема компиляции в веб на стороне клиента.

0

Сообщение от XLAT вот и вся тема компиляции в веб на стороне клиента.

В браузере (да и в библиотеках всех языков программирования) есть стандартные, скомпилированные в нативный код, функции sin и cos.

Но когда я пишу (на js)
С этим выражением браузер должен что то делать.
Компилить в нативный код? Компилить в байт-код? Просто проинтерпретировать?

0

Сообщение от voraa С этим выражением браузер должен что то делать.

есть такой игровой двиг Urho3D

там я заюзал AngelScript.
всю демку написал на нем.

плеер(или спецбраузер) весом в 20 мег,
не похоже что внутри у него компилятор))

и там было много кода, типа:

Сообщение от voraa let a = Math.sin(x) + 2 * Math.cos(x);

но она(демка) летала на старом ноуте с фпс >130

Сообщение от voraa С этим выражением браузер должен что то делать.

вопрос не в том, что он должен делать, а в том, что он РЕАЛЬНО уже делает.

если в стандарте заложен режим компиляции, то почему бы и не прокомпилировать,
я не буду против.

0