На информационном ресурсе применяются cookie-файлы. Оставаясь на сайте, вы подтверждаете свое согласие на их использование.
На чем лучше писать и отлаживать Java script?
11009
20
Посоветуйте, пожалуйста. Я в этом полный пень, Java script вообще пишу впервые, но при этом спец в C#/C++. Поэтому вопросы как делать и что делать почти не возникают. Скрипта написать надо много, при этом HTML практически не нужен. Возникает вопрос - чем делать. Пока отлаживаю отладчиком Сафари, а пишу в JetBrains WebStorm. Вроде все хорошо, но WebStorm через месяц захочет 50 баксов, пока триал период еще не кончился. Платить или чего другое попробовать?
раз все равно не знаете javascript, я бы предложил GWT (пишешь на Java компиляемой в кроссбраузерный javascript), Java слабо отличается от C# (в той части, что нужно чтобы написать на GWT UI), C# и GWT достаточно просто стыкуются, разберетесь.
Спасибо большое, изучаю. Ну, да. На удивление, JS вообще почти не отличается от C#, может я чего не знаю пока... Дело в том, что UI практически не нужен. Я нарисовал сервис на C# и ныне модных WebSocket-ах, а теперь вот делаю клиента на JS, которого надо прикрутить к уже существующему UI и поправить существующие скрипты. То есть, дело делается далеко не с нуля. Все это худо-бедно уже дышит, вопрос только в средствах разработки...
tutanxamon
member
[почти офф] а случаем для шарпа нет готового решения, которое даёт всю инфраструктуру на клиентской (JS) стороне и на серверной (C#) стороне для обмена по WebSocket (типа фреймворка обмена сообщениями) ? ну типа и там и там чтоб просто взять канал с предопределенным именем и обмениваться там сообщениями-объектами. тогда бы для клиентской части достаточно было 10 строк написать в Notepad.
а то, что WebSocket отключен в браузерах по умолчание - это не проблем? или разработка академическая?
а по теме - отлаживаю JS в Firebug. но предпочитаю его вовсе не писать ))
а то, что WebSocket отключен в браузерах по умолчание - это не проблем? или разработка академическая?
а по теме - отлаживаю JS в Firebug. но предпочитаю его вовсе не писать ))
R00
experienced
Есть такой. Даже дофига их. Вот , например. Но мне-то надо прикладной протокол реализовать поверх него, а это за меня никто делать не будет... Ога, я почти что в Notepad и начинал это дело, только сейчас кода уже много стало, захотелось чего-то повеселее.
Да-да, кроме Хрома и Сафари нормально пока нигде не работает. Но, будто бы все дружно собираются реализовать. К тому же имеются писатели примочек к прочим браузерам. Вообще-то клиентская часть пишется для всяких Айпадов, в основном. Не для десктопов.
Да-да, кроме Хрома и Сафари нормально пока нигде не работает. Но, будто бы все дружно собираются реализовать. К тому же имеются писатели примочек к прочим браузерам. Вообще-то клиентская часть пишется для всяких Айпадов, в основном. Не для десктопов.
Разработка корпоративная. Браузер у юзверей будет такой, какой скажут.
tutanxamon
member
>Но мне-то надо прикладной протокол реализовать поверх него
я может сильно заблуждаюсь насчёт сложности прикладного протокола, но по-моему клиентский (js) код должен быть весьма простым (отладить в Firebug такое не должно быть проблемой):
1. определить канал обмена сообщениями используя сервис фреймворка для WS (1-3 строк)
2. для каждого типа запросов на сервер - создать value-object для отдачи на сервер, заполнить его свойства и засунуть в канал.
3. для каждого типа запросов с сервера определить слушателя-обработчика сообщения.
4. В каждом обработчике забрать value-object с сервера и по значениям его свойств чего-то сделать.
Если прикладная обработка value-объектов действительно сложная (пп. 2,4) - то видимо кроме хороших средств разработки js не помешало бы найти и хорошего специалиста в js
ну а если хочется самому таким стать - то на специализированных форумах думаю квалифицированнее будет информация.
я может сильно заблуждаюсь насчёт сложности прикладного протокола, но по-моему клиентский (js) код должен быть весьма простым (отладить в Firebug такое не должно быть проблемой):
1. определить канал обмена сообщениями используя сервис фреймворка для WS (1-3 строк)
2. для каждого типа запросов на сервер - создать value-object для отдачи на сервер, заполнить его свойства и засунуть в канал.
3. для каждого типа запросов с сервера определить слушателя-обработчика сообщения.
4. В каждом обработчике забрать value-object с сервера и по значениям его свойств чего-то сделать.
Если прикладная обработка value-объектов действительно сложная (пп. 2,4) - то видимо кроме хороших средств разработки js не помешало бы найти и хорошего специалиста в js
ну а если хочется самому таким стать - то на специализированных форумах думаю квалифицированнее будет информация.Сейчас читают
ВВП ПРЕЗИДЕНТ?
218180
992
УАЗ Патриот (Стоит брать)? (часть 5)
240903
1000
Последняя прочитанная книга (часть 3)
518669
1000
R00
experienced
Спасибо, примерно так и есть. Сам-то канал, действительно - пара экранчиков кода. И это отлажено уже. Данные гоняются прямо в JSON. Но клиентская часть должна и в оффлайне тоже работать. Это, по существу, просто программа на JS. Оно, конечно, лучше бы спеца на JS найти, может, так и сделаем. У нас раньше на JS писал сайтостроитель и это считалось сравнительно легкой работой, сайт-то нехитрый. А то, что я пишу, это не сайт, это реализация кусочка имеющейся корпоративной системы для планшетов и телефонов. В итоге мне проще выучить JS, чем сайтостроителю структуру БД и бизнес-логику. Там еще и ГИС вдобавок. Идея в том, что C# программеры напишут серверную часть и прототипчик клиента, только сразу правильно. А потом можно будет и JS-профи привлечь на допиливание UI и функционала.
Если у вас есть любимый форум, где обитают JS программисты, буду очень признателен за адресочек. Я же и этого, блин, тоже не знаю. Форумов-то много.
Если у вас есть любимый форум, где обитают JS программисты, буду очень признателен за адресочек. Я же и этого, блин, тоже не знаю. Форумов-то много.
решение GWT + java (не javascript), если покопаетесь в нем дАльше и дОльше поймете насколько просто на нем разрабатывать именно приложения исполняющиеся в браузере. Насколько легко все интегрируется с сервером. Поскольку клиент и сервер пишется на жабе, то у вас будут одни и теже объекты/классы, что на сервере, что на клиенте. Клиент GWT-ой компилится в кроссбраузерный javascript исполняемый браузером. Ессно со всеми ништяками языка вроде compile time checks, скоростью разработки, сложностью бизнес моделей и т.п.. JS программист будет не нужен.
Да, возможно, дурака мы сваляли по причине отсутствия среди нас серьезных спецов по Java. Вопрос о том, на чем писать серверную часть, вообще не ставился, ибо было совершенно ясно, как это сделать на C# по-быстрому.
Надо было думать до того, а еще лучше ВМЕСТО того...
Надо было думать до того, а еще лучше ВМЕСТО того...
tutanxamon
member
>Если у вас есть любимый форум,
увы, у меня нет любимого форума про не-любимый javascript
но я бы поддержал предыдущего оратора в плане того, чтобы НЕ реализовывать прикладную логику на javascript. вы огребёте с этим проблем при развитии проекта, особенно, не имея выделенного спеца js. а если будете такого иметь, то будете от него зависеть и опять огребёте.
по-моему и полезнее и приятнее освоить в вашем случае GWT, можете заодно глянуть на фреймворк cometd (WS как транспорт), там для GWT как раз есть наработки, но возможно это будет не совместимо с вашими уже сделанными серверными частями (там возможно другой messaging протокол, но в GWT вставить js не проблема).
увы, у меня нет любимого форума про не-любимый javascript
но я бы поддержал предыдущего оратора в плане того, чтобы НЕ реализовывать прикладную логику на javascript. вы огребёте с этим проблем при развитии проекта, особенно, не имея выделенного спеца js. а если будете такого иметь, то будете от него зависеть и опять огребёте.
по-моему и полезнее и приятнее освоить в вашем случае GWT, можете заодно глянуть на фреймворк cometd (WS как транспорт), там для GWT как раз есть наработки, но возможно это будет не совместимо с вашими уже сделанными серверными частями (там возможно другой messaging протокол, но в GWT вставить js не проблема).
tutanxamon
member
>Вопрос о том, на чем писать серверную часть, вообще не ставился
это не проблема. на чём серверная часть - по барабану. в GWT у вас уйдет бизнес-логика, выполняемая на клиенте. и даже клиентскую транспортную прослойку можно оставить на javascript (если она уже реализована). а там глядишь, и responsive интерфейс быстренько на gwt наваяете, даже не связываясь html.
это не проблема. на чём серверная часть - по барабану. в GWT у вас уйдет бизнес-логика, выполняемая на клиенте. и даже клиентскую транспортную прослойку можно оставить на javascript (если она уже реализована). а там глядишь, и responsive интерфейс быстренько на gwt наваяете, даже не связываясь html.
R00
experienced
После того, что мы огребли от предыдущего поколения Delphi-нов, нас жабоскриптом не напугаешь. Кстати, поэтому и отдали прототип клиента расово верным С++ девелоперам, чтобы избежать совсем уже фундаментальных косяков. Но че-то поздновато я спросил на чем клиента писать... Эхх...
За подсказку пр GWT - спасибо. Будем пробовать его.
За подсказку пр GWT - спасибо. Будем пробовать его.
tutanxamon
member
> нас жабоскриптом не напугаешь
а жаль, я как раз хотел напугать. потому что однажды имел "счастье" поддерживать код, доставшийся от предыдущего javascript-ина. а сейчас вижу проект, где в команде единственный js-разработчик, а вся команда даже боится туда нос сувать, при этом баги и доработки там регулярные.
а жаль, я как раз хотел напугать. потому что однажды имел "счастье" поддерживать код, доставшийся от предыдущего javascript-ина. а сейчас вижу проект, где в команде единственный js-разработчик, а вся команда даже боится туда нос сувать, при этом баги и доработки там регулярные.
перейти с С# на жабу не сложно, по моему опыту переквалификации, разница в основном только в знании фреймворков, для сервера, для доступа к базе рекомендую jpa
R00
experienced
Ужас поддержки древних и крупных проектов на Delphi в том, что там глючный компилятор в дополнение ко всем остальным прелестям. И все время угнетает мысль, почему Борланд не удосужился нанять пару студентов с мехмата НГУ, которые честно сдали теорию трансляции? Чтобы они сделали компилятор безглючный. И как для такого примитивного языка, который специально заточен под удобство трансляции, можно вообще написать глючный транслятор, если кругом море безглючного и бесплатного открытого кода трансляторов с куда более сложных языков... А если в проекте еще использована куча бесплатных компонентов, написанных кем попало... А если еще Дельфины до того ничего не знали, кроме Паскаля и принялись строгать классы... Неужели-ж JS еще страшнее этого? Во избежание холиваров сразу скажу, что качественный код можно написать на любом языке, включая Дельфи. Вопрос затрат.
а жаль, я как раз хотел напугать. потому что однажды имел "счастье" поддерживать код, доставшийся от предыдущего javascript-ина. а сейчас вижу проект, где в команде единственный js-разработчик, а вся команда даже боится туда нос сувать, при этом баги и доработки там регулярные.ничего страшного в жабоскрипте нет, много чего не нем написал. Правда смотря как писать, ну и нуно проверять во всех броузерах.
Ужас поддержки древних и крупных проектов на Delphi в том, что там глючный компилятор в дополнение ко всем остальным прелестям.то же самое моно сказать и о жабрскрипте, кроме отсутствия кроссброузерности (каждый броузер в чем-то да разнится + пожелание скорейшего сдохнуть опере) моно добавить всякие глюки от кривизны кода броузера, до попыток разрабов броузера обойти кривизну рук жабоскрипт писателей. В первый раз видел чтобы по логике абсолютно не работающая конструкция все таки правильно работала. На всякий случай все равно переписал.
Хотя см. выше, жабоскрипт ну язык и язык, програамить моно.Ужас поддержки древних и крупных проектов на Delphi в том, что там глючный компилятор в дополнение ко всем остальным прелестям.
А мужики-то не знают...А если в проекте еще использована куча бесплатных компонентов, написанных кем попало...Это, понятно, тоже проблема Дельфи, ага?
ХочуСпросить
ЗооПрограммист
Тихо, тихо! Не спугни!!! 
R00
experienced
Доложусь, чем сердце успокоилось: phonegap-ом, внезапно превратившемся в процессе в cordova. Строго говоря, в итоге получилось не совсем web-приложение. Но это всех устроило. Жабоскрипт пишется на все том же Jetbrains Webstorm. Ничо умнее не нашли. Скрипт оказался не так уж и страшен. ПО предназначено для работы с базой данных и, вобщем-то, весь функционал типовой, новые фичи добавляются по образу и подобию имющихся.
Из прочих впечатлений - эмулятор андроида - тормоз! ТОРМОЗ!!!, блин, как задолбал! И к тому же глючит. Добрым словом вспоминается, как ни странно, майкрософт. У них эмулятор Win CE еще в 2000 г. еще на пентиуме-3 вполне бодро работал. Как они умудрились слить рынок, ума не приложу. И слава богу, что софт на жабоскрипте, хоть и крив скрипт и кос, зато отлаживать можно без эмулятора вапще.
Еще раз всем спасибо.
Из прочих впечатлений - эмулятор андроида - тормоз! ТОРМОЗ!!!, блин, как задолбал! И к тому же глючит. Добрым словом вспоминается, как ни странно, майкрософт. У них эмулятор Win CE еще в 2000 г. еще на пентиуме-3 вполне бодро работал. Как они умудрились слить рынок, ума не приложу. И слава богу, что софт на жабоскрипте, хоть и крив скрипт и кос, зато отлаживать можно без эмулятора вапще.
Еще раз всем спасибо.
Из прочих впечатлений - эмулятор андроида - тормоз! ТОРМОЗ!!!, блин, как задолбал! И к тому же глючит.Да.
Но уже есть андроид для x86-платформы, существенно допиленный интелом лично. Есть мнение, что в такой парадигме правильнее всего вместо эмулятора пользовать виртуалку с андроидом.
Впрочем, андроид-планшет - штука не дорогая, вполне можно взять опять же вместо мучений и потерь времени на эмуляторе.