На чем лучше писать и отлаживать Java script?
10249
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
ну а если хочется самому таким стать - то на специализированных форумах думаю квалифицированнее будет информация.Сейчас читают
Перерегистрация авто
87782
21
Куда идти учиться после школы? Оставаться в 9 или идти до 11?
271594
227
БАРАХОЛКА- 2 Правила в первом посте
398128
341
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-платформы, существенно допиленный интелом лично. Есть мнение, что в такой парадигме правильнее всего вместо эмулятора пользовать виртуалку с андроидом.
Впрочем, андроид-планшет - штука не дорогая, вполне можно взять опять же вместо мучений и потерь времени на эмуляторе.
ТОП 5
1
2
3
4