Angular вроде не плохой инструмент и TypeScript я считаю большим прорывом, но все же vue.js выглядит для новичка интереснее.
Подскажите все же что на ваш взгляд будет более востребованным в ближайшее время?
В фронтенде каждый год хайп меняется на противоположный, так что будущее планировать нереально. Живите сегодняшним днем.
Есть только [хрень.js] между прошлым и будущим...
за софтиной которая будет конвертить дизайн в код, а все феды пойдут работать в макдональдс
Ты че не спишь? Еще даже 7 утра нет. ))
Я все не перестроюсь на такое воемя, хотя это самое продуктивное время дня.
Сколько лет и сколько подделок было уже сделано и так и не сделано... Так что на данный момент это только пустые мысли в слух
Макдональдс можно автоматизировать уже сейчас, но он нужен как хороший мотиватор для персонала компаний.
Автор, спасибо за тему. Почитать комментарии — то что надо было сидя в аэропорту.
пока вы спорите некоторые галеры даже проплачивают изучение ангулара
www.dev-pro.net/...heteam-angular-education
Я планирую новый веб-проект, но не хочу использовать javascript. Подскажите, какой из этих языков лучше выбрать чтоб транслировать его в javascript?
C++
Только писать свой..
TypeScript — он прекрасен как C#.
CoffeeScript — гораздо приятней чистого JS’a
будущее за EcmaScript / WebAssembly
а завтра angular6/fiber
Кто даст гарантию что ангулар6 не будет отличаться от ангулар4 также, как ангулар1.5 от ангулар2?
а кто даст гарантию, что тебя завтра не собьет машина на улице?
Машина меня еще не сбивала, а вот ангулар уже переписывали с нуля.
Я вчив першу і другу версію. Час витратив не дарма, бо у вакансіях, де потрібен котрийсь із фронтенд фреймворків, найчастіше запитують саме за Angular, причому з великим відривом від найближчого конкурента — React’а.
Самое печальное, что это статья 2016 года и большинство вещей, там описанных, уже превратились в унылое легаси
С мегатоннами ещё более унылого кода на этом самом легаси. Конечно же в стадии полной готовности (и не дышать!)
Нужно смотреть действительно по вакансиям, что хотят больше. Большинство больших проектов написаны на том, что уже хардкорщики считают диким легаси. Так что здесь, либо быстро найти работу, либо считаться модным фронтендером — одно другое как правило исключает.
Как минимум стоит ознакомиться что из себя представляют React, Angular 2, Ember, Vue. Углубиться, если нашли интересную вакансию и проект и очень хотите таким заниматься.
Вопрос TypeScript vs ES6 vs Dart vs Flow лежит в другой плоскости. Здесь всё зависит от фундаментальных основ и скила использовать возможности любой из надстроек. TypeScript доказал свою состоятельность, но с таким же успехом можно создать проекты ентерпрайз уровня и на стандартном ES6.
Надо срочно запилить фреймворк Holywar.js — он будет совмещать в себе синтаксический сахар всех языков, со всеми граблями недокументированными фичами. Обязательная поддержка всех новых особенностей браузеров (в том числе найт-версий). С переопределением работы в каждой новой версии, включая замену сигнатур методов (с выпиливанием «устаревших»).
Обязательно дописать в лицензию пунктик, который при достижении коммерческого успеха отдаёт всё компании Майкрософт и обязуется брать ренту с пользователей и предоставить чёрный вход АНБ для просмотра всех данных. Также обязуется находить не менее 20 (двадцати) террористов в год, и мешок нарушителей авторских прав. Авторские права должны создаваться автоматически в пользу MS.
Обычно все обсырание js’а, сводится к каким то чисто сферическим в вакууме неявным приведениям типов, которые в реальной практике вообще никогда не встретишь. Так и не понял чем плох js . Тем что не похож на джаву или c#?
Без типизации нет контроля. Без контроля — нет мало-мальски крупных проектов. А есть лишь сборники наколенных поделок соло-кодерков, с кучей багов.
Контроля над чем? И что мешает на js проверить тип параметра? И что это за контроль такой, если:
Notice that although there were errors, the greeter.js file is still created. You can use TypeScript even if there are errors in your code. But in this case, TypeScript is warning that your code will likely not run as expected.
Это фактически jshint/jslint/eslint
И что мешает на js проверить тип параметра?
Если проверять — программа будет состоять из одних лишь проверок. И в чём тогда смысл нетипизированности языка, как фичи (а не бага)?
Смысл нетипизированности в том, что не нужно доказывать компилятору что у нас за тип пришел. И проверять нужно не везде, а где вот прям не всё равно что придет.
Ой, блин, половина дотнетного кода до введения оператора ’?.’ состояла из бесконечных ифов с проверками на null во избежание великого и ужасного NullReferenceException, и ничего, никто за это шарп не хейтит.
говнячить можно на любоя языке, если у человека иф решение всех проблем, то он их везде наставит
Прикольно, но «И чё?». Кстати NaN вообще ни с чем не сравним, о чем я только что прочел в MDN, которые никто не читает (я в том числе), потому что и так же всё понятно.
en.wikipedia.org/wiki/NaN
такое поведение определяет сама концепция.
хоть в С, хоть в JS
Так и я о том же! Мильйон объяснений почему через жопу хорошо, вместо того чтобы сделать иначе. Надо ещё ивентов пафосных провести, ваще гут будет.
const JSgovno = null == null
Хотелось бы увидеть реальный кейс где тебе будет необходимо сравнивать два null’a . А то как я и писал выше, какой-то высосанный из пальца довод.
if(document.getElementById("devkiVOzereKupails")!==null){
school.go(false);
}
И зачем тут сравнивать null’ы ?
Так null сравнивается нормально, это Алексей гонит
Я так и написал. Что null сравнивается, NaN не сравнивается (но присваивается), и всё это «нормально» просто потому что так его череж зопу написали — и теперь вариантов нет!
Ещё более «нормально» что нет
И конечно же феерическое поведение setInterval, которое если превышает неочевидный порог — тупо выполняется МОМЕНТАЛЬНО вместо выброса исключений.
Про нумерацию числа в дате с 1, а месяца с 0 только ленивый не писал.
Я не говорю что это нельзя выучить. Лишь о том, что если человеку надо плясать с бубном — язык говно. С бубном должен плясать код!
Я так и написал. Что null сравнивается, NaN не сравнивается (но присваивается), и всё это «нормально» просто потому что так его череж зопу написали — и теперь вариантов нет!
Да, но если сравнивать с null ещё может понадобиться, то сравнивать с NaN — ну очень редко, и для этого собственно есть isNaN
Ещё более «нормально» что нет64-битных целых. Действительно, а зачем нам, когда можно втихаря закастить в double и просрать значение.
Ну, с математикой у js не сложилось. Но есть варианты:
1. Не делать вычислений на js
2. Использовать mathjs.org, «Supports numbers, big numbers, complex numbers, fractions, units, strings, arrays, and matrices»
И конечно же феерическое поведение setInterval, которое если превышает неочевидный порог — тупо выполняется МОМЕНТАЛЬНО вместо выброса исключений.
Не сталкивался, есть ссылки на подробное описание?
Про нумерацию числа в дате с 1, а месяца с 0 только ленивый не писал.
Есть такое. Но опять-таки momentjs.com решает проблемы с парсингом/форматированием дат
Лишь о том, что если человеку надо плясать с бубном — язык говно.
А есть языки, которые не говно? Плясать всегда придется, иначе профессии программиста бы не было в нынешнем виде.
Читаю из темы в тему это нытье про сравнивание разных типов в джс и складывается ощущение, что люди застряли где-то в начале нулевых. Оттуда же и повальные рекомендации учить jQuery.
Сравнивать с NaN? Вот тебе isNaN функция. Сравнивать что угодно с чем угодно? Вот тебе Object.is, не обляпайся.
Джс предоставляет тебе целых 2 варианта интервалов: через setInterval с фиксированным промежутком, независящим от время выполнения колбека, и через рекурсивный setTimeout, который будет срабатывать только после выполнения колбека. Что нужно, то и используй.
Люди из 2003 видимо не в курсе про Intl и продолжают ныть про формматирование дат.
Я не говорю, что нет решений. На JavaScript можно реализовать что угодно. Через жопу конечно, но работать будет. И конечно же все виды костыльных велосипедов применяются на продакшене, с разной степенью успешности и стабильности по времени.
Просто ставлю перед фактом, что JavaScript не торт. И поскольку у Хрома есть явное лидерство рынка, то первое же внедрение в браузере своего языка для приложений — с покером и танцовщицами, произведёт фурор на рынке, и заставит толпы понторезов перейти на этот новейший писк моды.
С другой стороны, у JS из коробки есть и функциональное программирование, и прототипирование, и никаких заморочек с мнимой безпоасностью доступа. Да и с зонами видимости давно порешали.
Что даст нормальный язык:
1) Нэймспэйс. Да, такая вот глупость. Скрипты пишутся разными производителями, зачастую на продакшене навешано с десяток разных плагинов. И когда два идиота начинают писать myvar = «блаблабла», получается куча гемороя на саппорт всем непричастным.
2) Нормальная типизация. Всё равно ж она ЕСТЬ, так какого же хера она недоступна программисту?
3) Нормальные массивы. Обычные йобаные массивы!
4) Нормальный доступ к полям, без костылей в виде hasOwnProperty.
5) Нормальная типизация и утиная типизация. Не надо всё мешать в одну кучу! В абсолютном большинстве случаев типизация задаётся логикой алгоритма, и должна светить свои ошибки уже на этапе компиляции.
6) Скомпилированный скрипт. Да, чтобы без мутагенности в процессе, чтобы движок мог нормально брать его в код и не дрочить каждый раз туеву хучу таблиц. Особо полезно для приложений к браузеру.
100500) Нужен ОБЫЧНЫЙ опыт ОБЫЧНЫХ приложений. Не мелких скриптов, а полноценных аппликух. С полным управлением жизненным циклом на основе цикла обработки событий. В том числе, для виджетов, которые чётко выделяются в своё приложение, и могут быть оптимизированы для максимальной производительности. Почему грёбаный флеш так работает, а встроенный язык не может? Не хочет. Не заставили.
Хром может и лидер рынка, но далеко не единственный браузер на рынке. Сейчас джс начали довольно хорошо развивать, но появилась такая же проблема как и в начале нулевых — разные браузеры поддерживают и имплементят разные фичи с разным синтаксисом. Производители браузеров даже стандартизированный джс осилить не могут, а тут Гугл придумает какой-то язык, который будет поддерживаться только в хроме? Окай, пусть этот язык будет супер крутым и толпы бородатых хипстеров с подворотами побегут на нем писать. Но что это даст конечному пользователю, для которого все эти сайты и пишутся? Ничего не даст, ибо что в начале нулевых на чистом HTML и jQuery, что сейчас с ангуларом/реактом и тысячей дополнительных библиотек, модулей и инструментов, сайты выглядят и работают одинаково. Об этом нужно думать, а не о выдумывании все новых языков и фреймворков.
Всегда есть категория людей, готовых оправдать «авторитетное мнение», и объяснить остальным идиотам почему как есть — абсолютно так и должно быть.
Самые страшные люди. Честно. Именно такие готовы служить любой власти, в том числе позволяя шизофренику стать главой фашистского государства (посмотрите на северо-восток). Ведь один человек такое не построит. И сотня не построит. Нужна армия людей-приспособленцев, которым обязательно нужно «правильное» мнение, за которое не накажут, а скорее похвалят. И разумеется, всегда готовых учить других как надо, а также возглавить любой бардак.
В случае с JS — будет как будет. Поживём увидим. Пока имеем факты, что львиная доля сайтов с логикой — бажные и глючные.
Про людей и северного соседа абсолютно согласен. Выучат какую-нибудь джаву или шарп, а потом лезут всюду со своим «авторитетным мнением» в другие страны языки насаждая русский джава мир и убеждая всех, что везде должно быть так же как и у них. А если напрямую не получается, то начинают создавать всякие ДНР тайпскрипты.
Но что это даст конечному пользователю, для которого все эти сайты и пишутся?
Пара вкладок браузера перестанут занимать пару гиг памяти к примеру?
Это в какой вселенной такое? Проверил пару десятков посещаемых мною сайтов — в среднем 100кб памяти на вкладку. Итого 1 гиг на 10 вкладов при том, что планки оперативки сейчас стоят копейки и у многих стоит 16/32 Гб. Проблема высосана из пальца.
в настоящей вселенной, у меня открыто 2 вкладки с джирой, вкладка со слаком и эта страница, фф занимает 560мб
Итого 4 вкладки по +/- 100 Мб и сам фф еще 100Мб. Как я выше и написал. Но где тут «пара вкладок браузера занимает пару гиг памяти»?
у тебя кб написано, и я специално перезапустил браузер чтобы свеженькое увидеть, до этого были теже вкладки и еще одна, а занимало 1.5гб
ну в среднем наверное да
я специално перезапустил браузер
Это уже не верно, если для комфортной работы нужно перегружать браузер постоянно.
много сайтов просто течет по памяти, действительно вшивая вкладка может через время разжиреть до 1гб. Но все таки это не проблема js. Чего стоит только вкладка gmail, жрет и никак не нажрется. А так средняя вкладка 60-100мб.
До сих пор не могу понять как я мог заходить в интернет с компа с 16МБ оперативной памяти.
Скорость интернета с того времени немного выросла :)
Количество контента на странице не выросло, но кол-во памяти для отображения одной страницы выросло раз в 100 минимум.
Это не проблема джса или какой-то другой технологии. В первую очередь это проблема нашей цивилизации, которая пошла по пути потребления. Всем плевать на ресурсы, главное понты и свистоперделки. Технологии всего лишь подстраиваются под эти потребности.
Сайт на чистом HTML без джса и SPA со всеми трендовыми фичами могут иметь абсолютно одинаковый контент, только люди будут пользоваться именно SPA. И всем плевать что оно жрет в 100 раз больше памяти.
только люди будут пользоваться именно SPA
Покажите мне людей, которые будут пользоваться SPA, когда есть нормальный HTML вариант
Также покажите мне один не тормозящий SPA вебсайт
Добавь сюда, покажи хоть один мало-мальски известный spa вебсайт с норм. посещаемостью.
privat24?
Особенно нравится, когда после какой-то операции с картой, остаток на этой карте в разных частях интерфейса разный. А вообще приватовское spa так и просится, чтобы его переписали по нормальному — глюкавое безбожно.
Т.е. СПА тормозят, ими не пользуются обычные люди, они дороже в разработке. Зачем же тогда сейчас каждый первый заказчик требует делать СПА и почему на фронтенде главными фаворитами являются реакт и ангулар, в основном применяющиеся для создания этих самых СПА?
Я б показав...
Куча видеорекламы и прочих говно картинок с говно ссылками тоже по просьбам трудящихся добавляют наверное. Что характерно, реклама погружается первая, а контент в последнюю очередь.
А какой еще есть способ монетизации? Либо реклама, либо платный контент. Только вот платить за контент почему-то никто не хочет. Всем все нужно на халяву.
При том, что рекламу можно заблочить..
Если честно, я готов платить за некоторый сервис вменяемые деньги, но с этим тоже беда.
Как то слишком назойливо
Звідкіля в вас такі цифри про 100 разів більше пам’яті?
с 16МБ оперативной памяти.
ага, дешевое железо сделало свое дело, львиная доля ресурсов уходит на UI свистелки и плату за высокоуровневое программирование для удовлетворения потребностей капитализма в быстроте и дешевизне создания ПО.
P.S моя стартонуть с 128мб, а теперь и своих 16гб не чувствовать...
Проверил пару десятков посещаемых мною сайтов — в среднем 100кб памяти на вкладку. Итого 1 гиг на 10 вкладов при том, что планки оперативки сейчас стоят копейки и у многих стоит 16/32 Гб.
Может таки 100мб? Что полный здец.
Итого 1 гиг на 10 вкладов
А теперь поработайте час в асане, запустите фильм на второй монитор, проверьте почту и т.д. А потом посмотрите снова.
при том, что планки оперативки сейчас стоят копейки и у многих стоит 16/32 Гб.
А на ноутах и нефиг открывать сайты. И вообще — целевая аудитория сайта, компы с 16+гиг памяти, я правильно ваш посыл понял?
На мобильных устройствах это очень даже заметно
Нафіг нафіг з JS робити AS! Наїлися вдосталь. JS — проста скриптова мова! Не треба з неї робити конкурента C++, Java, etc. Навчіться краще не переносити знання з інших мов в JS, а використовувати позитивні сторони JS. Ваші вимоги до типізації не більше ніж ваші власні обмеження як програміста.
Так а я про що писав? Для простих скриптів на 3 строчки — JS цяця. Для серйозних бізнес-проектів — кака.
Коли вже скажуть досить дороблянням паперового кораблика до титаніка? Коли вже знайдуть таку багу, що знищить весь JS врешето.
Для серйозних бізнес-проектів теж цяця. Бо аналоги на інших мовах для UI не просто жахливі, а супержахливі. Якщо перестати використовувати архітектуру «JS first», то взагалі все стає шоколадним. Розмір проекту перестає грати роль.
Не треба з неї робити конкурента C++, Java, etc.
На C++ и Java пишутся серьёзные крупные проекты. На JS мелкие наколенные «поделки одного кодерка» с кучей багов.
Какая уж тут конкуренция? :)
Так я теж не розумію, навіщо з павіана робити мегагриб?
1) зачем? есть модули, или то что функционально на них похоже, тут все устраивает, разве что кроме загрузчика/транспорта. В глобал никто не лезет уже давно.
2) Нафик не нужна. Хотя введение альтернативных эм... типизированных типов, в целях производительности и редких финтов ушами не помешала, но без breaking changes... как отдельный api. Движок то конечно сам выбирает подходящий тип для числа в js на момент оптимизации функции, но ведь можно ему помочь. Да и иногда не хватает настоящего u64 или упираешься в u32 в битовых операциях. Так что не мешало им расширить math.
3) Они и так нормальные, а нормальные нормальные массивы в виде отдельного типизированного api есть и это правильно, осталось аналогичное api для чисел реализовать.
4) И так весьма четенько вышло. С какого боку hasOwnProperty костыль?
5) Никто ничего не должен, тогда это будет очередная джава, а какое место она в вебе занимает нынче? Баланс в js самый оптимальный для этого дела. Ошибки с типами все ровно отловятся на этапе прогонки тестов, если уж так беспокоит, то самому проверять и бросать исключение.
Вот возможность юзать api модулей, написанных на более низкоуровневых языках в песочнице браузера, конечно, было бы интересно...
Там можно подставить контекст «Java» и качество мысли не изменится. Кто сказал что java это правильно? Джависты?
Можно и так:
Всегда есть категория людей, готовых насаждать «авторитетное мнение», и объяснить остальным идиотам почему как есть — неправильно и не должно быть.
Самые страшные люди. Честно...
Пока имеем факты, что львиная доля сайтов с логикой — бажные и глючные.
Так может все таки они глючные потому, что львиная доля хотят быстренько, дешево и на «аггулярчиках»? И это тоже нормально для определенных проектов, но при чем тут JS? Лояльность JS к говнокоду не означает, что говнокод под js априори должен летать. 90% разрабов в веб вообще не заморачиваються над вопросом производительности, никто не задротит над оптимизацией кода, максимум это когда сайт в сыром виде пол минуты грузится, тогда о ней вспоминают. Не все готовы платить за оптимизацию и вычищенный код, не всем это нужно, если ты не Amazon, а дело то это тонкое, не быстрое и еще и одними джунами с вчерашних курсов, где надрессировали ng-repeat тут не отделаешься.
Кто сказал что java это правильно?
Не я. Здесь много за что нужно дать по рукам. И хотя львиная доля уже исправлена, но туеву хучу задач даже не брались доделать.
К примеру, GUI на Java — идея хорошая, но для круглых коней в вакууме. Довести до нормального человеческого стиля — а зачем. Я уже молчу, что Java должна уметь имплементиться в операционки бесшовно, а не «поднимите левую ногу одновременно взбалтывая яйца».
А уж сколько лэгаси-кода, который как оказалось весьма сложно перенести на новую платформу.
Ну и ключевой гвоздь: отсутствие нормального всего, приходится знать туеву хучу фреймворков, которые через ноздри оперируют то, что надо было делать «из коробки».
Очередной неосилятор?
let completelyTrue = Object.is(NaN, NaN);
На Java я бы держал в руках ошибку ещё на этапе компиляции. Банальное несоответствие типа.
Ну давай, напиши фронт часть веб приложения на Java, только без транспайлинга в JS
Webassembly?
если остались браузеры, которые поддерживают Java-апплеты, то напишет)
let almostTrue = NaN == NaN;
так все знают с незапамятных времен, что NaN единственное значение не равно самому себе в js
let realTrue = NaN !== NaN;
ммм это же прекрасно :)
И каждый новый обучающийся просто есть обязан минимум раз об этом услышать, и минимум раз нарваться самостоятельно. В продакшене, разумеется!
И так с каждым сделанным чережжопу «все знают» в любом языке. Однако JS — безусловный лидер по забивке дерьма в ядро языка. Даже PHP решились выкорчевать гвозди из задниц, но не JS...
Даже PHP решились выкорчевать гвозди из задниц, но не JS
Есть «небольшая» разница между этими языками. PHP — серверный. Арендовал VPS за 5-10$ в месяц, поставил там php7 и пилишь свой пет-прожект мечты под последней версией и на хорошем фреймворке. А JS — клиентский, клиент не один и каждый реализует отдельно. Можно написать спецификацию идеального js, но вот щелкнуть пальцами и переключить сайт на него — нельзя никак. Потому что кто-то пользуется Firefox, кто-то Vivaldi, а кто-то вообще убогим IE11.
Яндекс и Амиго браузеры -наше все!
В смысле, Хромиум и Хромиум? Нну да.
Вот так-то вернее. Потребность ЕСТЬ, просто порог перехода малость повыше. Через него зассали прыгнуть в
Но поддержать абсолютно иной язык, с отказом от JS, в пользу более быстрой и безопасной работы — это самое оно! То есть чтобы был иной движок, не совместимый с ЖабаСкриптом, и применение обеих было теориетически возможно, но нежелательно (тормоза), что вызвало бы сокращение рынка самого JS, оставив за ним всё более мелкие и мелкие задачи.
а миллиарды строк легаси- кто будет переписывать?
А зачем? Просто перестать развивать движок и пусть себе пашет. Изретка секьюрити апдейты накатывать, вот и весь сказ.
Неочевидная истина: JS транслируется в объекты настоящего движка, где уже и типизация, и указатели, и многопоточность и все другие плюшки.
Так поддерживать одновременно 2 движка- это головная боль, для производителей браузеров. Хотя....Было бы проще- просто JS тоже транслировать в этот новый движок, аля вебассембли, который еще пока не придумали толком)
Да по сути это уже делается, я имею в виду трансляцию. Правда движков несколько. И это реально крутой конфликт, который требует волевых решений в отношении священной говядины.
Современный капиталистический мир- так устроен ,что тут вряд ли возможна полная монополия. На бэкенде сотни языков и десятки движков. А на фронте — все транслируется через прослойку JS?
Мое имхо -так не будет продолжаться вечно. Это просто неудобно и самое главное — не конкурентно)
Просто перестать развивать движок
Хм... это какая то форма деструктивного мышления :) Благо у нас есть тут люди, что могут пролить на это свет :)
убогим IE11.
та уже с IE9 жить стало уже не так страшно) Хотя и сейчас, говорят, находятся уникумы, что требуют поддержку с
Не поверите, но даже 6го.
Заявляй. Всё равно проверить не смогут :)
Хотя вот реальный прецедент: на мну наехали что проект не пашет в Сафари, от слова «совсем». По факту оказалось проверяли на Сафари под Винду, которое не разрабатывается уж вторую пятилетку.
Результат — слово «let» для него оказалось в диковинку. Вот такие яблочьки.
слово «let» для него оказалось в диковинку.
Ну та как бы еще рано отрубать альтернативную ES5 версию скриптов, это не такое извращение как связь со старыми ослами.
Да, с 9й версии стало полегче. Но c css-преобразованиями до сих пор всё так себе, и с анимацией тоже. Даже в Edge нет счастья.
И каждый новый обучающийся просто есть обязан минимум раз об этом услышать, и минимум раз нарваться самостоятельно. В продакшене, разумеется!
Если человек знает про NaN, но не знает про isNaN — он плохо учился. А недоучка на любом языке наговнокодит. Кроме того, если где-то в веб-приложении есть «NaN» или «isNaN» — скорей всего оно используется неправильно (для проверки типа аргумента, например). Повод для рефакторинга, если поиск вернул не ноль результатов.
И каждый новый обучающийся просто есть обязан минимум раз об этом услышать
Ну вообще то да, какие там «ангуляры» если азов языка не знает? Что сложного включить какую то Игру Престолов и почитать выжимку на learn.javascript.ru? Все уже готово, сиди вот читай, эра недоступности инфы, убогости и тьмы эпических багов в войне браузеров прошла, весь инет забит кодами сиди учись, нет же нужно по ныть что то не так и это не так. Да сейчас это лафа по сравнению.
и минимум раз нарваться самостоятельно. В продакшене, разумеется!
вообще то нормальный путь разраба в обучении лежит через кодинг своих проектов/велосипедов, а не пошел послушать курсы, а уже через пару месяцев пускают в проект.
Однако JS — безусловный лидер по забивке дерьма в ядро языка
как раз одна из причин чего мне он нравится- кратность api ядра, а не как в пыхе 100500 функций и по десятку функциональных алиасов для каждой.
Даже PHP решились выкорчевать гвозди из задниц, но не JS...
И превратить кучу легаси библиотек в пшик? Можно только добавить что то, менять ничего нельзя. Единственный там частичный отход от этого правила — strict mode
И что мешает на js проверить тип параметра?
Заважає незручність.
Наприклад, уявімо що вам треба передати в якості параметра у певну функцію усього три варіанти значень: ’mysql’ | ’mssql’ | ’postgresql’. Якщо ви зробите помилку і передасте у функцію, наприклад, ’mysqi’, цю помилку ви зможете виявити лише на етапі запуску коду. Причому не відомо чи ви взагалі задієте у своїх тестах цей код, і чи напишете для нього відповідну перевірку. Використовуючи чистий JS, ви не зможете сказати своїй IDE, що можна передавати не просто рядкове значення...
TypeScript виявляє такі помилки прямо під час їх написання:
let dbType: 'mysql' | 'mssql' | 'postgresql'; dbType = 'mysqi'; // Error: [ts] Type '"mysqi"' is not assignable to type '"mysql" | "mssql" | "postgresql"'.
Наприклад, уявімо що вам треба передати в якості параметра у певну функцію усього три варіанти значень
То ви щось робите не так. Ви собі вішаєте гірю на ногу, потім намагаєтеся з нею бігати.
Запитання, яка різниця для коду функції, які саме параметри туди передаються? Відповідь — ніяких. Так, функція деякі розуміє, деякі — ні, але не розуміння певних параметрів != помилка. Це нормальний стан системи! Все одне пече в дупі мати контроль над тим, чи параметри співпадають з очікуваними? Так зробіть їх методами об’єкту та звертайтеся до них dbConnect[dbType]. Після того, як я вибив зі своєї макітри дурну думку все контролювати, я нарешті почав писати код, який стійкий до змін та не містить критичних помилок.
Очевидно, що ви не програмували на жодній із мов, що пропонує статичну типізацію.
Artyom Krivokrisenko
Олексій Пєніє
anonymous
Jim Moriarty
NewOne NewOne
Alex
Сергій Вдоварейзе
IRD
Александр Шевченко
Dron БПЛА
Andrew Bykovets
Andrey Balokha
Artyom Krivokrisenko
Volodymyr Yatsevsky
Igor Filippov
Artem Perchyk
Євген Козлов
Igor Filippov
Dmitriy Mozgovoy
Alex Koshterek
Sergey Sheshenya
Так зробіть їх методами об’єкту та звертайтеся до них dbConnect[dbType]
Так можна зробити, коли у вас вже є об’єкт dbConnect, а що ви будете робити, коли у вас є лише його клас DbConnect і вам треба передавати в аргументі одну з назв його методів? Така необхідність може бути, наприклад, при написанні роутів на бекенді.
Тобто коли ви робите мапінг між URL і методом певного контролера, об’єкта даного контролера ще не створено, є лише його клас, а вам треба безпомилково написати назву його метода. Що ви будете робити? Йти у контролер й копіпастити назву його методів? — Добре, але якщо ця назва зміниться, ваша IDE підкаже вам, що рядкове значення тепер невалідне?
А завдяки TypeScript, ви можете це пояснити своїй IDE:
class MyClass
{
one(){};
two(){};
}
function genericForClass
<T extends Function, K extends keyof T['prototype']>
(classHandler: T, method: K)
{
}
genericForClass(MyClass, 'one') // OK
genericForClass(MyClass, 'fake') // Error
Можете поекспериментувати у TypeScript Playground. Не важливо у що транспілюється код, важливіше — що вам підказує редактор ще на етапі написання коду у лівому вікні.
Очевидно, що ви не програмували на жодній із мов, що пропонує статичну типізацію.
false. Але дійсно це було дуже давно.
Так можна зробити, коли у вас вже є об’єкт dbConnect, а що ви будете робити, коли у вас є лише його клас DbConnect і вам треба передавати в аргументі одну з назв його методів? Така необхідність може бути, наприклад, при написанні роутів на бекенді.
Я не бачу жодних проблем із даним прикладом. API цього класу мусить бути фіксованим на використання та динамічним під час ініціалізації. Ви надто довго жили в світі статичної типізації, ваш мозок вміє приймати тепер тільки ті рішення, до яких ви звикли. Якщо б я вам розповів про подійно-структурне програмування, ви б взагалі сказали, що це повне лайно та так працювати не можна.
подійно-структурне програмування
Шо? Програмування на Node.js до таких відноситься? Якщо — так, то я досить добре почуваю себе у такому програмуванні. Ось зробив навіть форк відомого Node.js-фреймворка переписавши його на TypeScript-версію.
Програмування на Node.js буде відноситися, якщо написати фреймворк, який би реалізовував це. Це підхід, на тому ж рівні як event-driven, oop, reactive programming, frp etc.
K extends keyof T['prototype'] — лучшую иллюстрацию для фразы «натягивать сову на глобус» нужно еще поискать... :)
По-вашому це — занадто складна конструкція? Ви раніше мали справу з генеріками?
Простая как грабли, но выглядит презабавно. Типа берешь яп с прототипным наследованием, прикладываешь титанические усилия чтобы имитировать оргaзм «настоящее оопэ с блэкджеком, классами-почти-как-у -взрослых и дженериками», а по факту из каждого угла все равно торчат уши прототипов...
ви не зможете сказати своїй IDE
IDE по инлайновой документации и так все разрулит
цю помилку ви зможете виявити лише на етапі запуску коду
и? Код всегда верится на CI сервисе и ошибки вылетят не отходя от кассы, это функционально тоже самое, что и созерцание ошибки от статического анализатора, только наверняка, так что реального профита от тупоскрипта очень мало.
IDE по инлайновой документации и так все разрулит
Дмитрий, IDE може розуміти документацію по аргументах, якщо мова програмування це дозволяє зробити. Наявного у JavaScript типу даних string буде явно не достатньо для означеної задачі. Уважніше читайте і уявляйте, задача ж елементарна...
Дякую за антирекламу хейтерів TypeScript, думаю ваших однодумців буде не багато. Народ, не будьте такими як Дмитрий =).
PHPstorm понимает jsdoc. Даже pojo можно описывать. Я когда-то пробовал, но описывать просто возможные структуры не оч нравится. Проблема вознивает только в одном случае — когда используешь фреймворк, из-за различной магии.
PHPstorm понимает jsdoc
Якщо говорити за наведений вище мій приклад, PHPstorm детектить помилку, коли передаєш ліві значення? Чи він просто показує введений текст у підказці?
В наведених прикладах jsdoc я не побачив як можна означити параметри якимись іншими типами даних, окрім цих типів.
Эта IDE многое умеет.
Вот я опечатку в коде сделал например c2n.me/3NQS2A5
Да, подсказка не очень c2n.me/3NQSksO
Но автокомплит предлагает правильные значения c2n.me/3NQSp1r
И если ввести неправильное — подчеркивает как ошибку c2n.me/3NQStYE
В верхнем правом углу всегда есть индикатор, показывающий есть ли ошибки. В данном случае он показывает что ошибок нет, но есть опечатки (в словаре нет ’mssql’, но можно добавить и больше это опечаткой не будет) c2n.me/3NQSFe6
Правда бывает что ошибок уже нет, но индикатор закешировался. Наоборот ещё не замечал, если ошибки есть — они показываются. По ошибкам в файле можно путешествовать с помощью F2. Обычно, если время не прижимает, я прохожусь по всем ошибкам в файле и исправляю/игнорирую (бывает из-за магии фреймворка IDE видит ошибку в импорте например).
Методы классов и переменные тоже видны в автокомплите. Но могут быть не видны, если для создания объекта используется какая-нибудь магия (IDE не может проследить какие-то связи) c2n.me/3NQT9EW c2n.me/3NQTdDg
Попытка прямого доступа к приватному мемберу тоже подсвечивается и при наведении показывает ошибку c2n.me/3NQThrU
А вот здесь IDE ошибки не видит (а она есть) c2n.me/3NQTooH
Ещё анализирует код и знает тип, хотя в jsdoc я не писал что connectedAt типа Date c2n.me/3NQTuRo
Гист для контекста: gist.github.com/...2854cbe64269657c4d933f163 (вообще я это не запускал, но работать должно если прогнать через babel, просто мне лениво — я его никогда не настраивал руками)
IDE не может проследить какие-то связи
Коротше зрозуміло, я так і думав. З TypeScript ваша IDE стане помітно «розумнішою» (при умові, що ви не будете позначати усі типи як any, звичайно ж).
1. Тогда мне придется скорей всего и фреймворк сменить. Если у PHPStrom возникают какие-то трудности с автокомплитом — они возникают из-за того что IDE недостаточно поддерживает Ember. Точнее не IDE, а соответствующий плагин. Менять нравящийся мне фреймворк из-за того что где-то не сработал автокомплит — это немножко слишком. Тем более, я не на себя работаю и если предложу переписать всё на ангулар — мне просто на дверь укажут )
2. Проверка типов на этапе написания кода — это такая мелочь. Что существенно и сложно — это написать фронт, адекватно реагирующий на некорректный ответ от бекенда с кодом 200.
мне просто на дверь укажут
Одні двері закриються, але 40 відкриються (приблизне співвідношення вакансій, навіть якщо брати Angular 2+).
Проверка типов на этапе написания кода — это такая мелочь.
Ооо! Поки не спробуєте написати щось на TypeScript хоча б на одному проекті, ви не знатимете із чим порівняти теперішній рівень сервісу вашої IDE.
Что существенно и сложно — это написать фронт, адекватно реагирующий на некорректный ответ от бекенда с кодом 200
От бачите, а в Angular v4.3.0+ якраз вийшов новий HttpClient з прекрасною можливістю тестування й перехвату запиту/відповіді. React з Ember і поруч не валялись...
От бачите, а в Angular v4.3.0+ якраз вийшов новий HttpClient з прекрасною можливістю тестування й перехвату запиту/відповіді.
Для тестов и эмуляции бэкенда есть ember-cli-mirage. Качество эмуляции зависит лишь от потребностей и имеющегося времени. Можно хоть логику бэкенда имплементировать.
Чем это поможет при неправильном ответе от бэка реального? Там всё что угодно происходит. Сегодня у объекта есть какое-то свойство, а завтра его нет. Баг там или отрефакторили, или так и задумывалось, но фронтендера не предупредили. Проверять всю структуру ответа после каждого запроса — так там не todo application, приходят объектики с парой десятков свойств, парочка из которых тоже сложные объектики.
вийшов новий HttpClient з прекрасною можливістю тестування й перехвату запиту/відповіді. React з Ember і поруч не валялись...
А то... до ангуляров вообще жизни не было, мрак и пустота царили во вселенной, никто ничего не тестил и уж точно не было нигде такой новомодной фичи как перехват запросов/ http тестирование))
Autocomplete Development — вельми популярна забаванка в 1C програмістів :D
Наявного у JavaScript типу даних string буде явно не достатньо для означеної задачі. Уважніше читайте і уявляйте, задача ж елементарна...
Ок. Вызов принят. В каком месте будет «не достаточно»?
Konstantin Strukov
/**
* @param kind {('mysql'|'mssql'|'postgresql')} Type of the db
*/
function Foo(kind){}
Дякую за антирекламу хейтерів TypeScript, думаю ваших однодумців буде не багато.
Всегда пожалуйста. Дмитрий не баба-модница, ему плевать на тренд (если за это не добавят $$$), ему нужны факты, аргументация и выраженный профит от технологии, который явно перекрывает привносимый ею вред.
@param kind {(’mysql’|’mssql’|’postgresql’)} Type of the db
Перевірив у VS Code — при наведенні на параметр видається начебто підказка, але ніякої помилки не детектиться, коли передаєш ліве значення. У NetBeans навіть і підказки не видає, не кажучи про помилку.
Щоправда, може для цього треба якось їх по особливому готувати. Але це більше схоже на хак, що може й працює в якомусь Webstorm, але очевидно що не усі IDE це розуміють.
Але це більше схоже на хак
Т.е тайпскипт это не хак? Чем проще- тем лучше. jsdoc/jshint при поддержке плагинами со стороны IDE уже решает 95% кейсов.
що може й працює в якомусь Webstorm
Да, в «якомусь» Webstorm это работает, и параметры предлагает и Warning постит, а вот в блокноте нет...
А можно ссылку на серьезный проект где фронт не на JS написан?
И вообще не в бразузере, а честной апликухой.
Маячня. Все залежить від архітектури. Якщо в компанії «рахітектура», то дійсно проблеми будуть.
чем плох js
Да хотя бы тем, что никогда не рождался как язык программирования. Это макро-язык манипуляции готовыми объектами. Максимум чтобы написать onclick.
Для полновесных приложений в рамках «тонкого клиента» (жрущего по 12Gb памяти не прищуриваясь) нужен полноценный язык. С лисичкой и осликами кучей, стэком, управлением многопоточностью и очисткой мусора. С таймерами и диспетчеризацией. Со стандартизированным хранением данных на клиенте, и своевременным апдейтом самих барузеров на девайсах.
И наконец ампутировать его ахиллесову пяту по самые йайца: БЕЗОПАСНОСТЬ. Чтобы было чёткое распределение, какие данные безопасны, какие нет, как их хранить, и под какие данные нужны строго определённые компоненты. Возможно, поставляемые самим браузером.
Сделать наконец WebPush работающим не через жопу, в смысле без необходимости довешивать сторонние компоненты, мало того что собирающие данные, так ещё и имеющие право чудить на сайтах.
Дальше больше — сторонние библиотеки. Их используют не только лишь все. На уровне «я в неё верю, потому что круто называется, много обещает». Параметры безопасности для сторонних скриптов — ИХ ТУПО НЕТ.
JS плох уж тем, что геморой. Прогрессирующий с каждым годом. Без обратной совместимости.
Дальше больше — сторонние библиотеки. Их используют не только лишь все.
Окей, что предлагаешь для быстрой разработки? Писать всё с нуля не вариант, засовывать все возможные хотелки всех девов и заказчиков в ядро тоже.
для быстрой разработки?
Специальную теорию относительности никто не отменял.
Согласен, но! Это ж придется перепедалить полностью браузер! А там немного отдельный мир, конкуренция браузеров и прочая лабуда, а еще браузер это такая программа котора рендерит странички с тексто, картинками и минающими кнопками, это девелоперы смотрят на него как на среду для исполнения приложения, а еще браузер стал не просто такой средой но и спосбом доставки этого приложения! Так что прикол в том, что не только js юзается не для того чего предназначен но и сам барузер тоже!
Ну раз точно знаешь, как лучше, можешь и заняться.
Если в наличии говно, это ещё не повод становиться кондитером. Тем более что за столько лет написано кучу прекрасных фантиков для сей конфетки. О чём собственно и топик.
Колега, поки не спробуєш писати на TypeScript в хорошій IDE, наприклад у VS Code, доти не зрозумієш на скільки це мега-круто. Сам був таким же теоретиком «нафіг ті типи, якщо можна обійтись без них».
Грубо кажучи, 95% вигоди від статичної типізації відчувається завдяки підказкам IDE. При конвертуванні TypeScript в JavaScript код, транспілятор теж може надати корисну інфу, але від того лише 5% користі...
исходя из того, что мир скоро захватит Go, нада юзать github.com/gopherjs/gopherjs :-))
Только это будет параллельный мир.
Поддерживаю насчет clojurescript’а) кстати предполагаю, что его вполне можно использовать вне зависимости от того, пишешь ли ты бэкенд на кложуре или нет.
Ну и по-моему обычно делают так, если бэкенд на функциональном языке (clojure, elixir, scala, ocaml, haskell, etc.), то и фронтэнд на функциональщине (ClojureScript, Elm, PureScript, Backlescript, и т.п), а если бэкенд на каком-нить ООП-языке, то выбирают что-то типа тайпскрипта (особенно, если C#) или коффескрипта (в случае с рельсами, например). Ну типа по принципу подобное к подобному).
А если бекенд на ПХП или питоне?
ну про питон — на днях попадалась статейка про связку Django + Elm (где именно видел — не помню :( ), хотя с питоном вроде в основном сам джаваскрипт юзают. За пхп как-то не особо слежу счас, но вроде нигде не видел, чтобы с пхп использовали какой-то компилятор_в_джаваскрипт...
Лесом не лесом. Но пхп в вебе пока лидирует, с учетом легаси, да и на серьезных новых проектах- пхписты- фронтенд редко пишут, особенно, если на всяких джавоподобных симфони, там работы хватает без фронта.
а ангуляр язык? Мы говорили же о транслируемых в джс языках, вроде бы?)
Вы используете одновременно термины «будущее» и «в ближайшее время», они противоречат друг другу. Так чтобы прям вот в ближайшее время — то это angular, react и vue. Первые два точно ещё не сдохнут несколько лет, т.к. много проектов на них замутили. Особенно на первом. Ну а с перспективой на будущее — нужно мониторить плотнее чем что-либо. Тема раскрыта: habrahabr.ru/post/277323
И это правильный ответ. Время — лучшее доказательство. Много знаете фреймворков, которые после 11 лет эксплуатации работают в каждой свистелке?
Учить обязательно. Даже если на нём не писать [верим, верим], то понимать код на StackOverflow надо. А он на jQuery чуть менее чем полностью.
ответ на сабж не сделает твой говнокод чище и понятнее
1) белый человек прежде чем поднимать срач на форуме (а тема подобрана очень тонко) мог бы уделить по пару часов времени на каждый фреймворчик и посмотреть хотя бы туториал чтобы иметь базовое представление о чем спрашивать
2) формулировать вопрос надо исходя из своих целей и ожиданий — если есть понимание что осилишь новый фреймворк за месяц и цель +Х денег к зп — то мониторишь вакансии — и да на ангуляре 1/2/4 в украине их пока что ±= количеству вакансий на реакте и вью и джкЬЮри вместе взятых
3) а так за топик + - надеюсь тема на 1К комментариев — а то скучно на доу в последнее время
Не смотрел на другие логотипы, но мне понравился логотип vue, вот и стал его учить
posovetuite esche krasivyh logotipov. jelatel’no na c++
плюс и TLD моднявый — angular.io, в отличае от .org
.org Карл!
Разбираюсь в международной политике и ценах на нефть. Логотип красивый. Поехали!
Почитайте тут habrahabr.ru/post/337578 Как раз сегодня вышла. Кратко: гугл — как всегда
там по перековбашування стилів зрозуміло і проблем з цим, але можна це виключати, на рахунок всього решти, реактивних форм, рхджс і решти не згодний, вони не такі як в першому ангуларі, вони по архітектурі я б сказав крутіші, не всім дано зрозуміти, хоча якщо щось складне, то час може потопити фреймворк, якщо його ніхто не буде використовувати
Я дочитав до того місця, де чувак говорить, що він параметри в хедері хотів передавати, а вони не передались.
fj
minodvesP Vasya
Iliya Isd
Yarik Shlyakhov
Valentyn Yakovliev
Vlad Stelmahovsky
Dmytro Shchurov
Андрій Сягровський
let params = new HttpParams();
params.set('param', param);
params.set('anotherParam', anotherParam);
...
this.http.get('test', {params: params});
І це говорить програміст, хто пише на TypeScript, і хто може навести мишку на той params.set() щоб побачити підказку:
(method) HttpParams.set(param: string, value: string): HttpParams
Construct a new body with a new value for the given parameter name.
Причому це він може зробити не заходячи на сторінку документації. Цей же хейтер говорить, що:
Только открыв сам класс в TypeScript можно найти комментарийThis class is immuatable — all mutation operations return a new instance.
Хто йому доктор?
Это самый наркоманский API который я видел в своей жизни.
Справа у тому, що HttpParams — це звичайнісінький Set. Він повинен поводитися передбачувано. Те, що ангулярівці витягнули назовні якусь їм одним відому внутрішню реалізацію, з-за якої HttpParams виглядає як Immutable, це не дає мільярдній компанії плюсів.
Я теж з ним промучався 4 роки, але зараз счастливий з «іншим виробником» )
HttpParams — це звичайнісінький Set
Де ви тут побачили „звичайнісінький” Set? У Map є теж метод set(), але і він має іншу сигнатуру.
Стосовно immutable, ось є пояснення в офіційній документації:
This is for a reason: because the app may retry requests, the interceptor chain may process an individual request multiple times. If requests were mutable, a retried request would be different than the original request. Immutability ensures the interceptors see the same request for each try.
LOL interceptor на то він і є, шоби щось змінювати. Якщо ж гуглу потрібно відслідковувати оригінал, кажу, то є їх внутрішня проблема. Мені ангуляр не цікавий від слова «взагалі». Гугл лабс ще нічого цікавого не подарував світові. Все зачиняється, що вони робили.
Потому что апп может делать ретраи — сделали наркоманский API. Ничего ведь не мешало внутри копировать данные в immutable структуру. Более того, что там имутабельность помешает, http-заголовки уже уйдут на сервер к тому времени как кто-то захочет делать retry.
TypeScript я считаю большим прорывом
Это прорыв в зад, извините. Или куда-нибудь в сторону в лучшем случае. Но не вперед. Его придумали для тех кто не осилил JS, но почему-то упорно хочет писать фронт. Не надо так.
пачиму так катигоричен?
Ничего не имею против тайпскрипта как такового — дисциплинирует и сдерживает команду разработчиков одного проекта в плане хотелок писать код кто как привык)) Однако лично моё мнение, что это совсем не повод судорожно переписывать вэб-приложение, которое писалось несколько лет на чистом и понятном... Приведу реальный пример из моего опыта. Работал я в команде обычных javascript-синьёров, и мы в течении нескольких лет не испытывали совершенно никакого нетипизированного дискомфорта, применяя чистый и понятный javascript. Если данные в метод передаются непредсказуемых типов, то первые же пару строчек это дело преобразовывали в необходимый для дальнейшей работы вид («тип»)... это же естественно, очевидно и не понятно только наверное... а дальше о тех, кому это непонятно)) Так вот, решил один из «ридисек» соседней команды сишарповцев, что приелся ему этот C# и срочно нужно расширять свой кругозор (...приелся ему, блин... ему 20, а мне 40, но не в этом суть). А что тут такого: синтаксис сишный, легкотня, и к тому же если я спец в C#, то какой-то не то джава недо-скрипт обуздаю как два пальца... Неделю он въезжал, а потом оказалось, что «да как так вообще можно писать код, что совершенно непонятно каких типов данные и по каким интерфейсам куда передаются...» Его поддержал ещё один «да да, мы ещё в Яндексе на тайпскрипте код писали... а ещё у нас был такой супер BEM для css»... и тут понеслась)) Короче, тимлид с ПМ-ом прониклись серъёзнейшими проблемами в нашем коде и приняли решение всё всё переписать на TypeScript (ну а весь scss конечно же на новомодный яндексовский, сука, BEM)... Месяца через три сишарповец свалил обратно в «своё стойло» (ну а чё, теперь и с фронтэндом всё также предельно понятно и скучно, да ещё и переписывать всё нада — нафик), а мы так и продолжили переписывать «каждый дэв хотябы один файл в день» на понятный (для непонятно кого) TypeScript с непонятного типа джаваскрипта. Теперь конечно, всё стало нааамного понятнее и удобнее: на каждый прежний метод с параметрами разных типов — разные методы, для описания типов переменных — разные интерфейсы, а чтобы куча строк текста не бросалась в глаза — всё дробим в разные файлики. В итоге весь проект почти ничем не отличается от проекта на си-шарпе)) Про BEM вообще ничего писать не буду... Что получается? Лично моё мнение — каждый язык нужно учить! А не судить о нём со своей колокольни. И учить не надстройки (typescript, coffescript) и улучшалки (фреймворки и библиотеки), а язык (который чистый и понятный)! ...ну и не брать в команду идиотов! Помните: каждая улучшалка и надстройка была написала на чистом и понятном, и даже компилируется в итоге в него (если кто не знал), и все они писались под конкретные задачи тех кто это писал
что это совсем не повод судорожно переписывать вэб-приложение, которое писалось несколько лет на чистом и понятном
личные хотелки любого размаха в принципе не должны приводить к переписыванию.
хоть с ангуляра на реакт, хоть с JS на TS. тут я согласен.
только разве это касается
Его придумали для тех кто не осилил JS, но почему-то упорно хочет писать фронт.
?
ну а весь scss конечно же на новомодный яндексовский, сука, BEM
вы так говорите, как будто это взаимоисключающие вещи.
PS я понимаю вашу боль, но не понимаю, к чему вы ведёте в контексте ветки «TS бесполезная приблуда или право имеет».
TS — штука хорошая для команды, когда проект пишется с нуля. Один раз приняли общие конвенции и дальше все их придерживаются. Но мне это не доставляет совершенно никакого удовольствия (хотя отвращения вроде тоже не наблюдается) — проекты компилятся намного дольше, буков кода намного больше, файлов намного больше, проблемы в дэбаггере с маппингом после компиляции и т.п. Лично для меня это бесполезная надстройка, которая не ускоряет разработку, а просто дисциплинирует команду и позволяет не осилившим JS си-шарповцам внести смуту в наши ряды.
а каждый прежний метод с параметрами разных типов — разные методы, для описания типов переменных — разные интерфейсы, а чтобы куча строк текста не бросалась в глаза — всё дробим в разные файлики.
Как будто это что-то плохое.
Читаемость и чистота кода ведь лучше стала?)
А что тут собственно хорошего то? Что можно написать тремя строчками в одном метода нужно писать разными методами и часто в разных файлами — это улучшение читаемости? О какой чистоте кода речь? На тайпскрипте невозможно говнокодить? Чего только стоит каша из описания абстрактных типов... А вот если рассуждать с точки зрения базовых знаний строго типизированных языков — да, конечно же, такой код им читать намного понятнее. Я не пойму, прошла мода учить нативный javascript? Ах да, в тренде щас фреймворки)) Так скоро может появиться поколение, которое способно «программировать» лишь на языках этих фреймворков... ведь под капот всё равно никто не заглядывает
Так скоро может появиться поколение, которое способно «программировать» лишь на языках этих фреймворков
На SO как зайдешь — так кажется уже. Например если нужно использовать в ember какой-нибудь jquery-плагин, они берут первый попавшийся на гитхабе ember-компонент без нормальных доков, потом он у них не работает и они идут на SO спрашивать а пачиму. При том что обернуть сторонний плагин в ember-компонент — это от 15 минут до получаса времени, в зависимости от количества возможных параметров и сценариев использования. Это базовые знания, описанные в официальном гайде, я не знаю как это можно не уметь. О том чтобы посмотреть сорцы готового тоже речь не идет, проще задать вопрос и ждать пока кто-то ответит.
Кто все эти люди, кто отвечает на SO?)
Я иногда отвечаю, когда хочется. Но только на то что кажется интересным и знаю как ответить. Некоторые прямо заседают там и отвечают на всё подряд.
И на SO не заходил когда гуглил? :)
К тому, что почти всегда ответ находится на SO, который ранее кто-то задал.
Логическая цепочка — если бы вопрос не задали на SO, вы бы не нашли ответ на некоторые вопросы, и задали бы сами, наверное.
А значит вы просто немного отстаете от других, которые раньше вас столкнулись с проблемой, потому и можете всегда нагуглить.
Просто бывает что гуглишь, а кто-то твой вопрос уже задавал на SO )
На чистом js тоже можно все пораскидать по файлам и собрать какой-нибудь утилитой в один. Проблема в этом вот:
а каждый прежний метод с параметрами разных типов — разные методы
Например у меня есть функция, преобразующая ошибку с бекенда в строку (чтобы показать пользователю сообщение об ошибке). На входе может быть как объект типа Error, XHR, так и просто хеш — зависит от того как получены данные, от характера ошибки. Но на выходе будет всегда строка. И это отлично работает. В случае со строгой типизацией мне нужно будет написать для каждого типа параметра свой метод. Ради чего? Чтобы было понятно другим — есть комментарии/документация
На входе может быть как объект типа Error, XHR, так и просто хеш — зависит от того как получены данные, от характера ошибки. Но на выходе будет всегда строка. И это отлично работает.
Так в такому випадку проблема на бекенді, якщо він замість нормальної відповіді у визначеному форматі може всяку х..ю повертати. Треба бити бекендщика по пальцях: це майже як послати з бекенду на фрондент при помилці увесь стектрейс — тобі треба, ти й розгрібай.
як послати з бекенду на фрондент при помилці увесь стектрейс
А что, так делать нельзя?
Ну як «нельзя» — можна. :) Але я вважаю, що не бажано.
По-перше, це свого роду security issue — ти вивалюєш на фронтенд інформацію про кишки бекенду.
По-друге, свідчить що ти не надто напрягаєшся, пишучи код в exception handler на бекенді.
По-третє, це неповага до фронтенд-девелопера — замість віддати йому інформацію в чітко визначеному форматі, ти вивалюєш йому стек помилки, щоб він його розпарсив на фронтенді.
Там все не так однозначно. Это всё в ember, и ember data возвращает Error. Но ED не очень гибкая библиотека (только простой CRUD и сложно кастомизировать URL’ы под бекенд) и часто приходится делать запросы средствами $.ajax, который возвращает кажется XHR. А сторонний загрузчик файлов возвращает ещё третью дичь.
parseError = (error: string | Xhr | Error | whatever) => {
if (error instanceof string) {
/*компайлер дальше воспринимает error как string/* stringAnswer
} else if (error instanceof Xhr) {
/*после этого error — xhr*/ xhrAnswer;
} else if ..
Или даже так
type yesNo = ’yes’ | ’no’;
error: yesNo | string.
Почитайте о type guard.
ТС это очень хорошо продуманный язык для выполнения тех же самых задач, с которыми работал JS. Там сознательно используется сигнатурная типизация.
Вы, милейший, чушь пишете. TS это действительно лучшая штука для исправления косяков JS за все годы его существования. А Ваш комментарий сродни «С++ для тех кто не осилил ассемблер».
JS создан для работы с пользователем. А пользовательский ввод нетипизирован. Точнее — пользователь в 90% случаев вводит строку. Программисту для работы с фронтендом нужны мозги чтобы эту строку распарсить, валидировать и сообщить пользователю если что-то не так. И для этого удобнее язык, который не ограничивает разработчика типами. То есть JavaScript.
Это чушь. Современный backend — это сотни и тысячи классов, это сложная логика, писать которую на нетипизированном языке — это мучение. Ну не на голом же месте появились попытки типизации JS (TS, Closure Compiler, etc, etc) — а решают вполне конкретную проблему. А пользовательский ввод он нетипизирован когда пользователь в терминале печатает, но эти времена прошли еще в прошлом веке.
А при чем здесь вообще бек? Хоть на жаве его пишите. TS для фронта используется, не слышал чтобы его в node.js пихали (хотя там это могло бы быть ещё оправдано)
Фронтенд конечно же. Описался, mia culpa. Хотя и на ноде тайпскрипт все прогрессивное человечество гоняет в хвост и гриву.
TS для фронта используется, не слышал чтобы его в node.js пихали (хотя там это могло бы быть ещё оправдано)
Хоча ще на стадії альфа-версії, тим не менше працює справно github.com/restify-ts/core
А пользовательский ввод он нетипизирован когда пользователь в терминале печатает
Ну да, конечно. И когда пользователя попросишь ввести в поле ввода цену, он точно её введет и введёт с нужным разделителем.
Я вот хоть убейте не вижу как и почему задача валидации строки введённой пользователем делает типизацию бессмысленной. Она как-то особенно сложно делается на языке со строгой типизацией?
Ну и по факту, это таки тип string, то что вводит юзер.
Даа, а потом чтобы над введенным числом произвести какие-то действия, нужно доказать языку со строгой типизацией, что это таки число. Чем бы дитя не тешилось.
Там все это делается элементарно, и валидация на бэкэнде всегда легче чем на фронте пишется, видать ты такие языки не видел.
Ну я не хотел сказать что надо только на бэкэнде, я к тому что типизация не есть проблемой этой самой валидации, а скорее наоборот.
Откуда вообще эта дихотомия «либо мы проверяем разработчика либо пользовательский ввод»?
Вообще не понимаю. В языке со строгой типизацией нет функций вида Int parseString(String) ? О чем вообще разговор?
И по всему коду такие конструкции, да. А, ещё это дело обязательно в try catch обернуть, а то даже не скомпилируется.
Да Вы верно шутите. Для Вас статическая типизация == Java 1.0 без всяких фреймвоков и даже возможности написать собственную функцию для парсинга?
А бывает иначе? А зачем?
Конечно же бывает иначе. Те же регэкспы (не к ночи будь помянуты) работают во всех статических типизированных языках. А вопроса «зачем» я не понимаю.
User-Defined Type Guards вам в поміч. Спрощує пояснення для TypeScript, що змінна має саме певний тип.
А мозги программиста — это субстанция сильно ограниченная, и тратить её на то чтобы помнить где в динамическом языке какие пропертЯ — непозволительное расточительство.
JS разработчики делятся на 2 типа, а именно на тех кто уже осознал необходимость типизации и тех кому нет ещё
Возраст тут ни при чем. Нужно всего лишь попробовать поразрабатывать проект где есть хотя бы под сотню разных классов и требования периодически меняются. Когда к твоим услугам рефакторинги в IDE, быстрая навигация по коду и ошибки времени компиляции — то ценить это начинаешь ОЧЕНЬ быстро.
И то как студия в пару кликов заливает твой код с докером в облаком и там его деплоит и мне не надо ипаться неделю с этими скриптами работает из коробки.
проект где есть хотя бы под сотню разных классов
На фронте? Хороший проектик
Тобто по-вашому — це багато? Ну SPA-сайти мають саме під сотню класів. Причому SPA-сайти дозволяють в кінцевому підсумку скоротити кількість коду, якщо брати суму бекенд+фронтенд.
Это вы контроллеры, компоненты и так далее классами считаете, да?
Если вы пишете сам фреймворк, то это конечно считается. Иначе стоит вести разговор только о том, что пишет пользователь фреймворка. Это называют бизнес-логикой обычно. И на фронте это означает манипуляцию DOM и валидацию форм. Где там необходимость в классическом ООП пока что никто объяснить не смог.
Это называют бизнес-логикой обычно. И на фронте это означает манипуляцию DOM и валидацию форм. Где там необходимость в классическом ООП пока что никто объяснить не смог.
Сучасна бізнес-логіка на фроненді часто досить складна. ООП дозволяє програмісту ізолювати релевантну функціональність в окремих класах, дозволяє користуватись перевагами Dependency Injection архітектури, з кращою можливістю тестування...
Сучасна бізнес-логіка на фроненді часто досить складна.
Какая логика? Получить данные, отобразить, отправить запрос на изменение? Это требует классического ООП с наследованием и фабрикой абстрактных фабрик?
Ну для описаної функціональності, взагалі HTML підійде. Але ж одного HTML, як відомо, на багато не вистачить.
P.S. успадкування — це лише одна із можливостей в ООП. Накриклад в Angular, незрівнянно частіше користуються композицією.
Сучасна бізнес-логіка на фроненді часто досить складна.
Тому реалізовувати її за допомогою OOP — стріляти собі в ногу із базуки. Бізнес-логіка — це граф, де зазвичай в одній точці існує більше одного входу та одного виходу.
JS создан для работы с пользователем.
Нет, уважаемый, изначально он был создан для придания разметке динамичности (всякие мигающие банеры, анимации и т.д.)
JS уже давно не такой, каким его задумывал создатель. Раньше все данные обрабатывались на бекенде, в том числе и валидация. Сейчас же бекенд зачастую сводиться к restful APIs, а вся магия происходит на клиенте. Потому и возникла необходимость строгой типизации.
Сейчас же бекенд зачастую сводиться к restful APIs, а вся магия происходит на клиенте
Бизнес-логика на клиенте — это security issue, если только вы не делаете социалку для котиков. Какая ещё магия требует типизации, классов, наследования — не могу себе представить.
А зачем это все и правда, нафигачил все в одном фалике с одним классом и ок, а ооп дураки придумали ))))
Да зачем класс, обернул весь код в самовызывающуюся функцию и концы в воду))
А если честно, я не думал, что еще есть люди, которым нужно доказывать целесообразность использования ООП подхода в JS
Зачем вагина, если обернул в презерватив — и через универсальный интерфейс!
Класическое ооп там не очень приживается, ибо протоипы, которые даже фанаты js не всегда хавают что оно и как его готовить, итого там куча каши, но они ее выдают за фичу, говоря что проще работать с коневешенами, типа мы с пацанами решили что лошадью будет заяц. )))
Оно никому не нужно на фронте, классическое ооп. Кроме тех кто пришел с жавы/плюсов и клал изучать жс.
Ну да, не нужно. То-то МС вкладывается в TS а Гугл — в Closure Compiler. Дураки, не осилили JS.
И? У богатых свои причуды. MS вообще вон в silverlight вкладывались. И где сейчас silverlight? Даже flash живее.
Да потому и вкладываются что у JS есть проблемы, и пытаются их решить (не всегда получается, но на то есть обьективные причины). А не потому что «не осилили JS». Уж поверьте — что в MS что в Гугле в джаваскрипт умеют ну очень неплохо.
Ну это уже на уровне религии, не буду спорить.
Я думал ты скажешь: «где сейчас эти богатые ?»
«Так делает <big corp name>, а они умные» — вообще так себе аргумент
Хм. Ну вот я человек не считающий себя самым умным — потому если умный человек что-то делает — стараюсь понять зачем. Ну то такое, мое личное мнение.
Ошибка в том, что вы ум по капитализации и раскрученности компании меряете. А они набирают на работу вполне обычных программистов. Может они и стараются взять лучших из лучших, вероятно даже берут, но это всё равно люди со своими причудами.
Нет. Я меряю по качеству кода. Я видел много проектов сделанных гуглом — и везде они были сильно выше среднего по качеству. Ну и да, я знаю пару человек которые там работают — весьма толковые люди. Более того — я сам к ним ездил на собеседование — и могу сказать что собеседование было ОЧЕНЬ серьезным.
Я видел много проектов сделанных гуглом — и везде они были сильно выше среднего по качеству
В то же время YT API v3 — дичайшее недоделанное говно, например. В котором сначала много месяцев висит баг что апи не отдает историю просмотров (а понравившиеся видео например отдает), а потом гугл заявляет что это так задумано потому что данные пользовательские (что странно, так как понравившиеся видео дают информацию более ценную, чем просто просмотренные).
Гуглокартами тоже пользоваться удобно до тех пор, пока ты просто пользователь. Сточки зрения разработки намного удобнее mapbox. Хотя и для пользователя сервис карт, который приблизительно показывает где находится дом, которого у него в базе нет — так себе.
На документацию к своим продуктам для разработчиков гугл вообще болт кладет обычно.
С моей точки зрения у гугла бывают хорошие сервисы только для пользователей, когда весь UI делает гугл. Для программистов сервисы у них так себе, и непонятно почему сделанный ними язык будет лучше сделанных ними API.
Смешались в кучу кони, люди... Погугли про gulp и разбивай по файликам на здоровье. И классов можешь сколько хочешь использовать. А вот наследование нафиг не нужно на фронте. Кого от чего ты собираешься наследовать?
Наследование и статическая типизация — вещи ортогональные. Одно совершенно не подразумевает другого.
нафигачил все в одном фалике с одним классом и ок, а ооп дураки придумали
Что вижу на то и отвечаю. Количество файлов тоже ничего не подразумевает, собственно.
Кстати, поинтересуйтесь КТО придумал TS. Это седой дядька с воооттакенной длинны пипякой. Он компиляторы писал еще тогда когда я писать прописи учился. И умеет он это очень здорово, такой красивой концепции натягивания совы на глобус (я имею в виду систему типов TS для JS) я даже близко нигде не видел.
Вообще-то это система сигнатур типов. Кто понял — с ТС дружит.
Script# умер и TypeScript умрет.
В мире вообще ничего нет вечного — все когда-то умрет.
Вы разобрались в прототипах. Поздравляю. Я вот ассемблер Z80 знал. Тоже крутая штука!
В прототипах? Нет, не разобрался. Ну как, я в общем понимаю с чем едят прототипное наследование, да только оно нужно раз в году, если не реже. Нечего на фронте наследовать особо. Классы фреймворка наследуются вызовом специального метода extend, а не чистыми прототипами. А больше нечего наследовать.
Кстати, реальные темы в js — замыкания и асинхронный код. Используются каждый день, а понимаются новичками тяжело. Прототипное наследование же просто непривычно, но оно и не нужно каждый день.
Для Вас это должно быть сигналом: «каждый день». Это 100% повод решить так, чтобы никто в этом больше не путался. ТС не столько про типы (потому что Foo & Bar и language: {code: string} сплошь и рядом. На типы особо никто не обращает внимание. any спасает даже в самом тяжелом случае), сколько избавление от _каждодневных_ проблем. Это неразумно: придавать ценность чему-то, что другой язык не считает за проблему.
А вот как раз понимание прототипирования и внутренностей Object, как ни странно, с ТС востребовано, если есть желание упростить код с помощью декораторов (например, избавившись от глупостей вроде const Foo = ’Foo’).
Его придумали для тех кто не осилил JS, но почему-то упорно хочет писать фронт.
Я так и знал, что языки из этого github.com/...guages-that-compile-to-js списочка написаны для тех, кто ниасилил джаваскрипт. :-))
По камментам вывод: нужно написать по проектику небольшом на Angular 4+, Vue и React. Это будет кул. А дальше уже что понравится или что придется :)
Angular 2 так то самый простой в освоении
Проще Реакта без Redux/Router/... обвязок?
(Сарказма нет, мне интересно, поскольку я не знаю Ангуляр 2, но базовый Реакт нахожу очень простым, особенно в сравнении с первым Ангуляром)
Базовый, конечно легче. Но ведь на базовом никто не пишет. Тянут 100500 модулей, потом неделю настраивают, а потом уже и писать начинают
За неделю вложится даже пионер в реакте (но не в UI JS).
Базовый реакт это как лунапарк без покера и прекрасных дам — представляет исключительно академический интерес :)
нужно написать по проектику небольшом на Angular 4+, Vue и React
GitHub? Не! Только с нуля!
Есть только [хрень.js] между прошлым и будущим...
вы серьезно думаете что вы выучите правильную библиотеку и ваше будущее будет обеспечено?
это тоже самое.
Нет смысла что то учить или не учить наперед. Никто не знает что будет завтра никто не знает какой будет проект.
Нужно учить пррамирование как таковое и уметь самостоятельно разбиратся в технологиях. Заказчие не ьбудет ждать полка вы обсудите вопрос на DOU/
Проблема с заказчиками/работодателями — часто ищут с опытом конкретного фреймворка. Некоторые вообще ищут прям со знанием вплоть предметной области проекта. Так что какую-то аббревиатуру знать полезно.
Нужно учить пррамирование как таковое и уметь самостоятельно разбиратся в технологиях.
HR: На чем вы пишите?
Я: Ну, я учил программирование как таковое, и умею самостоятельно разбираться в технологиях.
HR: На чем вы пишите?
Я: Ну, я учил программирование как таковое, и умею самостоятельно разбираться в технологиях.
HR: Следующий!!!
А на собеседованиях от Амазонов и Фейсбуков мозг морочят именнно алгоритмами и программированием как таковым, и им посрать на твои знания фреймворков типа .NET или Java. Разве не так? Все воют про задачки на логику и структуры данных и алгоритмы от Майкрософт, Амазон, Фейсбук, HP, и др. американских компаний. Как-то не часто можно услышать что кого-то JS или C# вопросм завалили на интервью. Значит это считается более важным там. А в СНГ базирующихся компаниях вакансии слошь и рядом хотят и фронт-энд и бэк-энд и еще вагон ималенькую тележку и все попару лет работы. Самое при этом смешное, что неважно какой у тебя опыт и насколько долго ты в программировании, нет Ангуляра — все, резюме в мусорку. Если человек не хочет фронт-эндом заниматься то на работу он может не попасть вообще. И требование всего знать по немногу поражадет говно-прудукты, говно-код, сорванные сроки, сплошные овертаймы и тонны неподдерживаемого кала, велосипедо-костыли и прочие жуткие болячки быдлокодерства.
Василий, иди как ты в Гугл , вместе с фейсбуком и амазоном :)
Сам в тоже место и ступай! Вот тебе вопросы с первого попавшегося интервью в Гугл с гласдора, а также всем поклонникам специалистов „которые пишут на чем-то” но не уверенны в том, что могут что-то написать вменяемое:
www.glassdoor.com/...rview-Questions-E9079.htm
I applied through an employee referral. The process took 4 weeks. I interviewed at Google (Mountain View, CA) in April 2014.
Interview
Direct onsite because I interviewed in the past and did well that time. From the time I sent my resume to interview day: 2 weeks. From interview day to offer over the phone: 2 weeks.
The syllabus for the interviews is very clear and simple:
1) Dynamic Programming
2) Super recursion (permutation, combination,...2^n, m^n, n!...etc. type of program. (NP hard, NP programs)
3) Probability related programs
4) Graphs: BFS/DFS are usually enough
5) All basic data structures from Arrays/Lists to circular queues, BSTs, Hash tables, B-Trees, and Red-Black trees, and all basic algorithms like sorting, binary search, median,...
6) Problem solving ability at a level similar to TopCoder Division 1, 250 points. If you can consistently solve these, then you are almost sure to get in with
7) Review all old interview questions in Glassdoor to get a feel. If you can solve 95% of them at home (including coding them up quickly and testing them out in a debugger + editor setup), you are in good shape.
8) Practice coding—write often and write a lot. If you can think of a solution, you should be able to code it easily...without much thought.
9) Very good to have for design interview: distributed systems knowledge and practical experience.
10) Good understanding of basic discrete math, computer architecture, basic math.
11) Coursera courses and assignments give a lot of what you need to know.
12) Note that all the above except the first 2 are useful in „real life” programming too!
Interview 1:
Graph related question and super recursion
Interview 2:
Design discussion involving a distributed system with writes/reads going on at different sites in parallel.
Interview 3:
Array and Tree related questions
Interview 4:
Designing a simple class to do something. Not hard, but not easy either. You need to know basic data structures very well to consider different designs and trade-offs.
Interview 5:
Dynamic programming,
Computer architecture and low level perf. enhancement question which requires knowledge of Trees, binary search, etc.
At the end, I wasn’t tired and rather enjoyed the discussions. I think the key was long term preparation and time spent doing topcoder for several years (on and off as I enjoy solving the problems).
Conclusion: „It’s not the best who win the race; it’s the best prepared who win it.”
Show Less
Negotiation
You can and should negotiate politely. You are in a stronger position if you have another offer, but even otherwise, you should ask for more of every type of payment!
Спасибо , я там бывал и на интервью в том числе, поэтому гласдор не особо интересен
Да мне как-то все равно где ты бывал. А если и бывал, то не понятно к чему в**бон был. Это была наверное демонстрация твоего искрометного юмора.
ну все перечисленные, таки не JEE стэки, так что за пару недель можно раскурить все три, и затем юзать тот или иной (по необходимости прокачивая скиллы под какой-то конкретный, показавшийся вам наиболее юзабельным и востребованным за это время)
а по трендам как-то так но популярность реакта — скорее «дурная» так как все на западе именно с него и начинают (чем и объясняется большее кол-во сёрчей,- т.е. это нубосёрчи так сказать)
Кстати да. Но там будущее за three.js :)
Оно еще живое? )) лет 5 назад юзал, как всегда — ебала с поддрежкой браузеров, ща хз.
Да вроде живое. Но это не точно. :)
будущее за D3
За ХЗ. Чуть ли к каждому спецу есть требование понимать ХЗ. И львиная доля всего, что сейчас работает — работает ХЗ как, ХЗ почему, и за счёт удачной комбинации нескольких ХЗ.
Именно неумение работать на ХЗ отличает наших улылых кодеров от лидеров индийских компаний. А наши бездари не умеют даже прочитать то гениальное ХЗ, которое до них написали лучшие умы компании ASAP, ASAP & VPRODAKSHEN, которое «работает» лишь нуждается в мелком ремонте.
Взяли VueJS в продакшн, пока что вау
По стравнению с продакшеном без VueJS, очевидно же.
Таке може говорити той, хто раніше в продакшені використовували максимум — jQuery =).
В фронтенде каждый год хайп меняется на противоположный, так что будущее планировать нереально. Живите сегодняшним днем.
Aurelia!
Angular 1.x уйдет в прошлое, бо не поддерживается. но будет масса старых проектов, которые тоже надо будет сапортить и добавлять новые фичи.
С Angular 2+ пока еще не понятно.
VueJS тянет на себя одеяло. Развитие стабильное, под новые проекты вполне выбирают.
React — стабильно развивается, вакансий меньше не становится.
Всё, кроме Ангуляра — про джаваскрипт.
И только Ангуляр предлагает писать на Ангуляре.
хейт-спич с аргументами: habrahabr.ru/post/337578 и tuhub.ru/...angular-2-prosto-uzhasen
Резюме: для старты выбери что-нибудь, кроме Ангуляра.
PS или вопрос не о стабильности, а только о «более востребованности»? тогда ангуляр 1.х выбирай. Рано или поздно люди с него уйдут, а проекты никуда не денутся, особенно энтерпрайз.
Angular може не подобатись лише дрищам, які не можуть осилити TypeScript. Реальні пацани з цим справляються на відмінно. Не читайте різних.., треба самому вивчити хоча б хелоу ворлд TypeScript + Angular... тоді й зрозумієте цінність Angular.
???? МОЙ БРАТ УМЕР ОТ ПЕРЕДОЗИРОВКИ ЭТОЙ ДРЯНЬЯ ТЫ ???? ???? ТЫ ?????? ЧТО ANGULAR БЕЗВРЕДЕН ?????!!1
дожили...
Angular или React — остальные имеют меньшую долю на рынке
Angular
первый — это уже тупик
на 2+ проектов еще маловато
второй получил популярность только из-за названия
доволі крути! хоча і потрібно більше знати про те як працює
Антон, пробовали и в работе React Fiber? (Интересует будет ли быстрее работать анимация?)
Стоит ли обратить внимание на Flow, или лучше использовать TypeScript?
Для работы с формами, что посоветуете (redux-form.com/7.0.4 или есть что получше )?
Что посоветуете с готовых UI библиотек для React (например: www.material-ui.com и подобные ей)
Спасибо ))
Zhang Jike
Nikolay Mihalych
Gennady Dogaev
Vladimir Fyodorov
Vitaliy Fedoriv
Vadim Ridosh
Oleg Skalozub
Yurii
Леонид Мартынюк
Леонид Мартынюк
Oleksandr Tkalenko
Дмитро
Oleksandr Vorobyov
Dmytro Hridin
Євген Козлов
Dmitry Panfilov
Podoprigora Alexandr
Найкращі коментарі пропустити