Comments 71
Разве плохо было бы, если б большинство фич C++ 20 работали с более старыми (и все еще широко использующимися) версиями компиляторов...
-Да, никому не упали лишние UB
В формате мема:
Все: Ржут над npm с его node_modules и говорят что python куда лучше для новичков
Python3: Я буду ставить зависимости всех проектов прямо в систему. Ну, если только если ты не обманешь её, сделав одним из нескольких способов венв и не пообещаешь на словах, что не забудешь включать венв когда будешь ставить зависимости. Которые, кстати, будут просто в текстовом файле, а если там нужны системные библиотеки — то пошел ты нафиг, вот что.
А как она изменила это мнение?
И какие аргументы Вы нашли?
Что значит "низкий порог входа"? Создать index.html в 2к21 уже недостаточно, если что :)
Довольно низкий порог входа. Весьма большое, как мне кажется, количество задач покрывается знаниями, которые можно получить за 2-3 месяца с нуля.
Низкий порог входа только для тех, кто копипастит примеры jQuery со Stack Overflow.
Я пару лет активно занимался кастомным фронтедом HTML/CSS/Vanilla JS (никакого jQuery или Бутстрапа). А потом за 2-3 месяца освоил бекенд (настройка сервера и NodeJS). До этого я боялся бекенда. Думал, что им занимаются только хардкорные программисты. Но я очень удивился, когда осознал, что те логические задачи которые мне приходится решать на фронденте на порядок сложнее тех, с которыми я сталкиваюсь на бекенде. Это в разрезе одного среднестатистического сайта на котором я делаю и фронт, и бек.
Тут автор правильно заметил: фронтендер имеет дело с асинхронным кодом и «многослойным» приложением в котором вам параллельно нужно решать разные задачи (дирижировать этим всем). А на бекенде, грубо говоря: точка входа и точка выхода. И вся работа бекендера между этими точками «по прямой». Это я про обработку запроса.
Это моё субъективное впечатление на основе описанного выше опыта.
Статья показалась очень наивной:
- Фронтэндеры подменяются мифическими "опытными фронтэндерами"
- "Сложность" частично подменяется "важностью"
- Много воды типа "сложные проблемы такие сложные", "МНОГО думают над этими проблемами", "ПОСТОЯННО работают над этими проблемами"
Показалось что кучка джунов напостила комменты в твиттер — и вот статья.
Люди:
"С фронтом справится любая обезьяна, там делов-то что джейсон перекладывать и формочки клепать"
Эти же люди:
"Эй, почему у меня сайт тормозит? Почему он грузит мегабайты жс-кода? Почему так медленно? Где доступ с клавиатуры? Почему в сафари всё поехало? Какие дятлы вообще так делают?!"
Редко соглашаюсь с этим автором, но вот тут он прав — Объясните, почему мой рокет-саенс бэкенд билдится пару секунд, а четыре формы на фронте — полгода
А по-поводу отношения как к джунам — не знаю как так получается, но у меня сложилось впечатление, что фронтендеры гораздо чаще изучают и знают именно технологии, а не само программирование. Вы когда-нибудь видели чтобы в мире C# делили людей на EntityFramework-разработчик или Dapper-разработчик? А Senior React Developer — это в порядке вещей.
Яхуда Кац явно работа с проектами вне фронтенда. И большие проекты явно делал.
А на C можно membomb написать, которая вообще не соберется.
strict: true надо включать и типы чаще прописывать, тогда тайпскрипт компилирует довольно быстро. Ну и реакты с англурярами собирать отдельно, чтобы по 10МБ на диск не читать/писать
ну программисты Dart с вами не согласны.
А можно пример?
Когда у тебя тайпчек после простого изменения делается по 2-3 минуты
Это проблема. Но стоит отметить, что эта проблема присутствует, наверное, во всех языках с продвинутой системой типов. И ею она и обусловлена. Т.е. тормозами вы платите за комфорт. Если вас устраивает система типов в C#, то вы можете писать на TS так, чтобы он копилировал быстро.
Настройте babel для транспиляции и линтер для tsc.
А tsc --noEmit используйте периодически для проверки.
Итого, компиляция через бейбл 1,7сек, через tsc 47. Как-то так.)
у меня сложилось впечатление, что фронтендеры гораздо чаще изучают и знают именно технологии, а не само программирование
Это ложное впечатление. Прочитайте мой комментарий выше: habr.com/ru/post/535724/#comment_22530464
Вы когда-нибудь видели чтобы в мире C# делили людей на EntityFramework-разработчик или Dapper-разработчик? А Senior React Developer — это в порядке вещей.
"Senior Oracle Developer", это тоже человек, который просто знает именно технологию, а не само программирование? (вакансия как доказательство существования профессии, а не реклама).
В целом, все описанные Вами проблемы решаются очень просто, у нас проект, которому больше 7 лет, с кучей файлов, ts'ом, scss'ом, vue, и прочая и прочая, собирается за 30 секунд 3-им webpack'ом:) (можно и быстрее, но неактуально, пока что)
У меня есть гипотеза, почему «фронтенд для джунов».
- Никто не хочет тратить время на нагромождение костылей по имени HTML+CSS и часто отдают это джунам.
- Делать типовые формы и таблицы действительно несложно.
Верстка, формы и таблицы это, наверное, 80% всего фронтенда и с этим справляются джуны. То же самое можно сказать и про бек, где 80% это принять запрос, запустить SQL, вернуть результат.
Сложный фронтенд это же модель в памяти, обновляемая и читаемая из разных потоков, без транзакций, в среде, где приложение может быть закрыто или остановлено в любой момент. Это сложно как ни крути.
То же самое можно сказать и про бек, где 80% это принять запрос, запустить SQL, вернуть результат.
Кто то еще этим занимается в 21 веке? Я уже лет 10 ввод/вывод данных не писал, есть куча спецификаций которые это делают автоматом для CRUD.
На одной из работ нужно было делать много разных таблиц.
На первый взгляд действительно просто. Но потом возникают такие вещи как:
- динамические данные
- фельтиперсовые ячейки а-ля прогресс-бары, чарты, красотульки, свистелки и пукалки
- фильтрация, из хэдеров или из-вне.
- пагинация, причем обязательно сподвывертом и красивыми кнопочками
- сортировка, причем когда у вас фельтиперсовые ячейки в виде графиков, прогрессбаров и тд
- изменение данные прямо из таблички
- объединение ячеек и колонок
- drag-and-drop
- i18n
- ....
Вот и прыгаешь по всем этим DataTables, ag-Grids и мериадам реактовых велосипедов. А потом еще и сам свой велосипед начинаешь городить ибо ничего из готового под фантазию твоих продуктов не подходит.
На беке если пропало соединение с базой, то просто вернули ошибку и все. На фронте же нужно переходить в состояние «восстанавливаю соединение», завершать начатые операции каким-то образом, бывает закрывать диалоговые окна, может быть чистить что-то в памяти и так далее. Понятно, что на беке такое тоже может быть, например кеш очистить. Но на беке это бывает нужно, а на фронте такое нужно всегда.
Отличие в том, что в бекенд обычно stateless и подобные приколы решаются рестартом сервиса. Сложные распределенные системы где нужно хранить состояние встречаются нечасто.
А вот требование, чтобы страничка нормально работала когда ноутбук выходит из спящего режима – это норма для даже самого простого онлайн-магазина.
Кстати, о TypeScript. TypeScript — лучшая в своем классе система постепенной типизации для динамического языка.
Не знаю как Вы, но лично я бы предпочел, чтобы TypeScript имел обязательную статическую типизацию. Думаю, если сильно постараться можно даже отказаться от типа
any. Но больше всего в ts мне не нравятся дженерики. Окей, они есть, но почему нужно делать какие-то костыли?Окей, они есть, но почему нужно делать какие-то костыли?
Принимая во внимание, что в TS это просто типы поверх JS, получается, что автор вопроса хочет странного. Он хочет получить тип, который есть только на стадии компиляции, и использовать его в runtime. Для этого надо класс передавать явным образом в виде, скажем, аргумента. Ну или замыкания. Т.е. generic-и в TS тут совсем не причём, т.к. они — просто типы. Они абстрактная нематериальная сущность, к ним нельзя обратиться в runtime, т.к. их просто не существует в runtime. Весь TS это просто абстракция.
TypeScript имел обязательную статическую типизацию. Думаю, если сильно постараться можно даже отказаться от типа any
TS это wrapper над JS, и практически все проблемы TS вытекают именно из этого. Например отсутствие удобных перегрузок, отсутствие доступа к типам в runtime, unsoundness и пр..
Я бы тоже предпочёл, чтобы в browser-ах появился новый язык, с выразительностью и системой типов не ниже TS/Flow, но sound (напр. Scala 3). Это же позволит сделать его весьма быстрым. Однако этого, я полагаю, не случится в ближайшее десятилетие.
И, я надеюсь, с какого-то момента из webassembly будет доступ к DOM без JS interop и мы забудем про JS как про страшный сон.
Доступ в DOM из WASM не поможет. Потому что внезапно выскочат все те же грабли что и в JS
- Массивы, которые совсем не массивы, а NodeList со своим поведением
- document.all который имеет тип undefined, но со значением
Можно, конечно, сказать "а давайте выкинем это легаси и сделаем новый нормальный API", но это совсем другого порядка задача и как заметил faiwer, в ближайшем десятилетии это вряд ли случится
Потому что эффект второй системы никто не отменял. Создание нового "правильного" DOM API будет тем еще долгостроем.
Т.е. generic-и в TS тут совсем не причём, т.к. они — просто типы. Они абстрактная нематериальная сущность, к ним нельзя обратиться в runtime, т.к. их просто не существует в runtime.
Так ведь можно сделать так, чтобы они были доступны: записывать референсы на конструктор в приватных статических полях класса, доставать их оттуда. Проблема только в том, что это не будет работать с выдуманными типами «string», «number». Но даже это можно обойти, если во время транспиляции подставлять соответственно «String» и «Number». Это всё только должен разруливать tsc, а не программист.
В NestJS подобный бойлерплейт заменили аннотациями, менее удобно, но сойдет.
Так ведь можно сделать так, чтобы они были доступны: записывать референсы на конструктор в приватных статических полях класса, доставать их оттуда
Записать в references вы можете только class-ы, т.к. interface-ов и type-ов просто не существует в runtime. Записывать же туда только классы — очень спорное решение.
Но даже это можно обойти, если во время транспиляции подставлять соответственно «String» и «Number»
Очень слабое решение. Это позволит покрыть условно 0.1% возможностей типов в TS. Зачем оно такое нужно на уровне языка? Я уже использовал это решение как раз с NestJS. Ощущение того что это эпичный костыль не покидало и не покидает меня по сей день. Там такое количество "но"…
очень спорное решение
Ну дык из enum'ов сделали же порнографию, что с дженериками такое провернуть не могут?
Ладно, я понял Вашу позицию. Можете привести примеры возможностей типов в TS только? Пока не сообразил, что имеете в виду.
Ладно, я понял Вашу позицию. Можете привести примеры возможностей типов в TS только? Пока не сообразил, что имеете в виду.
Ну например:
- Сигнатуры у методов
- Алгебра типов (особенно
|) - higher order rank polymorphism
- Рекурсивные типы
- Литералы
- Перегрузка
Если честно я вообще не понял, что вы этим хотели сказать. Зачем вы процитировали моё сообщение. И причём тут автор (я не автор). Так же как непонятно причём тут Deno.
дено тут при том что тут люди обсуждают то что тс статический, что мб было бы актуально года так полтора назад
Вы уверены, что вы понимаете, что такое Deno? :) Это просто аналог nodeJS от его же автора. Да в нём используется TS по-умолчанию. Но, come on, runtime там всё тот же V8. Соответственно там нет никаких типов в runtime. Deno никак не меняет сущность TS. Просто транспилятор встроен в сам Deno. Поэтому он мало кому интересен. Кроме "революционной" идеи про url-import-ы он ничем не примечателен.
лол ваще в шоке как это можно не понять
Ну то что у вас трудности с формулировками я вижу :) JS не является моим первым языком. И единственным тоже не является. И нет, я писал на языках со статической системой типов. Я "курил" куда больше, чем ванильный JS. Подозреваю, что в цитате, на которую вы мне ответили, вы непонимаете значения половины пунктов :)
Сигнатуры у методов — ЛЮБОЙ ооп язык
Почему именно ООП? Любой язык со статическими типами вообще. Как без них то? Писалось в контексте того что TS не может предоставить в runtime такие вещи
алгебра типов — тут согласен такого нигде больше нету
С чего это вдруг? Wiki пишет про несколько десятков языков, среди которых Scala и Haskell
higher order rank polymorphism — ну тут вообще цирковое представление
Насколько я могу судить в TS вообще нет Kind-ов. Отсюда и нет их полиморфизма. Issue по твоей ссылке я читал. Их там много. Каждый любитель FP заводит по одной, чтобы завести свои монады ;) На хабре есть даже неплохая статья про то как это можно обойти, если очень надо.
Но я не про -Kinded polymorphism, я про:
type A<T1> = <T2>(t1: T1, t2: T2) => <T3>(t3: T3) => [T1, T2, T3]По сути про polymorphism за счёт generic-ов в рамках higher-order-functions. Но ок, раз ты смог нагуглить про Kind-ы поставим галочку ;)
— литералы — помянем автора
— перегрузка — аналогично
Overloaded Functions. Впрочем уверен что если ты слышал про ООП, то про них ты знаешь.
тут тебе уже бог только поможет
ставлю свечки за упокой в общем
помянем автора
с пониманием я тебе уже ничем не помогу, хоть фактуру разжую
ниче не курил
Хорошо, что к вам "на район" завезли интернет ;) TS всяко лучше, чем 228
Браузер всегда укладывается в 1 Гб RAM.
А вот с тем, что через несколько дней использования hibernate браузер начинает глючить, согласен полностью.
Впрочем, chrome не лучше.
Очень сильно течет от просмотров видео.
Самое время задуматься о том, что у вас с кодеками понаверчено, если у вас от просмотра видео память течет.
Ну а если вы просто оставляете 50 вкладок с открытым HD видео — то и не обижайтесь, что только на буферы несколько гигабайт уйдет.
но раньше на это хватало 2-3 гигабайт памяти, сейчас уходит в 10 раз больше
В целях общего развития (моего), а в каком году было это "раньше"?
Интересно получается. В то время уже были SPA, и Angular и React уже набрали популярность, даже редизайн Хабра уже случился. По идее, с тех пор должно становиться только лучше, потому что весь этот молодой и не окрепший стек вышел на плато продуктивности, без новых JS-фреймворков каждую неделю
Дело в том, что компиляторов нужно не много и требования к качеству высоки
Вебcайтов же напротив нужно очень много и требования к качеству — самые разные, отсюда — множество нубов во фронтенде и еще больше — в простой верстке и создании сайтов «из коробки».
«что, если случайные 5% моих SQL-запросов в Rails фейлятся». Начинающие фронтендеры не думают об этом, но более опытные — точно учитывают такие кейсы.
Постоянно сталкиваюсь с тем, что об этом забывают дизайнеры. Ну никак не могут усвоить и принять для себя классическую асинхронную триаду "waiting/success/failure". На картинках всегда только "success", остальных состояний нет, приходится пинать.
Фронтендеры — герои. Yehuda Katz объясняет почему