Comments 29
Это статья для веб-разработчиков которые не знают git, JS, паттерны проектирования, не умеют отлаживать код и так далее. Но пишут технические статьи и примеряют сеньорские лычки.
Понизились требования к специальности, понизились.
Понизились требования к специальности, понизились.
Да, тоже порадовался, но немножко с другой стороны: на том же хабре уже просто потоки откровенно «мусорных» статей, которые без всяких шуток приносят автору гораздо больше пользы (я написаль!), чем всем читателям вместе взятым (потому что читать это не только бесполезно, но часто и немного вредно). Наверное как раз в том числе и от обилия растунов над собой.
А уж предложение изучить JS и вообще очень умиляет. Кто все эти люди, которые могут всерьез называть себя «веб-разработчиками», и при этом не знать JS?
А уж предложение изучить JS и вообще очень умиляет. Кто все эти люди, которые могут всерьез называть себя «веб-разработчиками», и при этом не знать JS?
Где-то, чисто теоретически, могут существовать люди, которые пишут сайты на PHP/Python/Go/Ruby/Java/С/etc при этом не используют JS даже на фронте. Было бы интересно увидеть их творения, чисто в ознакомительных целях.
Встречал таких. Пишут на PHP вполне обычные сайты, при этом дальше var в JS не продвинулись.
Правда давно это было, тогда многие сайты и правда не уходили дальше выезжающей менюшки или яндекс.карт в контактах.
Правда давно это было, тогда многие сайты и правда не уходили дальше выезжающей менюшки или яндекс.карт в контактах.
Я слышал, что github.com так написан.
Они генерят практически весь html на бакенде.
Там есть небольшое количество javascript, но в почти всё работает без него.
Они генерят практически весь html на бакенде.
Там есть небольшое количество javascript, но в почти всё работает без него.
google: web engine pure C++
UFO just landed and posted this here
Как минимум Dart и Blazor позволяют писать фронтенды без строчки (ручками) на JS. Первое активно используется самим гуглом (Google Ads веб морда как минимум), второе сравнительно недавно вышло в прод и мне неизвестны реальные (прод) проекты, но наверняка они или уже есть или появятся совсем скоро.
По мере раскручивания web assembly появятся и другие варианты (на самом деле уже есть, просто пока ещё не особо раскручены).
JS, несмотря на всю свою мощь и простоту, всё же не самый удобный и иногда не самый приятный язык для разработки, многочисленные «навороты» поверх (типа typescript и прочих транспилеров) ясно на это намекают.
По мере раскручивания web assembly появятся и другие варианты (на самом деле уже есть, просто пока ещё не особо раскручены).
JS, несмотря на всю свою мощь и простоту, всё же не самый удобный и иногда не самый приятный язык для разработки, многочисленные «навороты» поверх (типа typescript и прочих транспилеров) ясно на это намекают.
Как минимум Dart и Blazor позволяют писать фронтенды без строчки (ручками) на JS.
В конечном итоге для браузера это всё превратится в JS. И если вы не понимаете, как и почему оно превращается в то, что превращается, то писать фронтэнды вы будете до первых проблем.
Без JS можно писать статику, во всем другом оно неизбежно будет. Вы конечно можете сказать, что это сродни заявлению «всем программистам на С надо знать машинный код» — но… в общем-то на достаточно серьезном уровне это именно так и работает. Таки надо.
По мере раскручивания web assembly появятся и другие варианты
Не появятся, просто потому, что wasm придуман не для того, чтоб можно было на С клепать сайтики. Это не более, чем побочный эффект, что таки можно — но преимуществ у такого подхода примерно нисколько, ни по производительности, ни по размеру, ни даже по удобству — всё остальное помимо JS вам придётся знать, если вы захотите сайтик через wasm. Wasm никогда не будет чем-то большим, чем высокопроизводительная числодробилка для нужд браузера (сюрприз, именно для этого оно и задумывалось).
В конечном итоге для браузера это всё превратится в JS
Blazor — это вроде как WebAssembly. В JS он не превращается ни на каком этапе, насколько я понимаю.
Blazor — угу. Не взлетит, впрочем, второй абзац в посте выше как раз про это. Опять же, blazor будет обречен на использование 3rd-party JS, потому что иначе решений-то взять неоткуда — будут подключать JS и дёргать его из блазора, куда денутся.
Dart уже скоро тоже в wasm будет напрямую собираться. Так что уже сейчас js для веба знать не обязательно. Дальше будет только больше.
Dart уже скоро тоже в wasm будет напрямую собираться.
Не будет — именно потому, что профита нет. Wasm работающий с DOM и браузерной архитектурой — настолько же медленный, насколько и JS, работающий с этим всем. Плюс, wasm не модулен, плюс, wasm не компактнее (вернее — компактнее только на достаточно больших объемах, исчисляемых многими мегабайтами).
Wasm как инструмент клепания сайтиков сейчас способен решить только одну проблему: «я знаю C#/Dart/чё-то еще, категорически не хочу изучать JS, и не собираюсь писать ничего настолько большого, чтоб намертво влипнуть в проблемы масштабирования». И еще он прекрасно подходит для вендор-лока — собственно это главная причина, почему все эти ваши гуглы-микрософты навострили уши и потирают ручками; профит от потенциального заворачивания существенной части веба на какой-нибудь дотнет или дарт — огромен.
Но тот же гугль бьёт не в wasm, а в native mobile. Wasm — это так, до кучи зацепило.
Ваш код да – сконвертируется в WebAssembly. Но вот для его нормальной работы на странице потребуется еще какое-то количество JS. И когда понадобится оптимизировать производительность, или делать какой-то кастомный компонент – с этим JS придется иметь дело.
И если вы не понимаете, как и почему оно превращается в то, что превращается, то писать фронтэнды вы будете до первых проблем.
Большинство программистов не понимает как их код на C/C++/Java/etc превращается в то что превращается (байт-код или собственно машинный код), и это не мешает им писать годные приложения. Более того, многие из них имеют весьма смутные представления о железе на котором работают их приложения, и оперируют абстракциями — и это тоже не особо мешает, по крайней мере до тех пор пока не нужно что-то жутко оптимизировать или заставить работать на конкретном железе, где нет готовых абстракций.
Важно понимать не как что во что превращается, а то как им правильно пользоваться, и то что Dart/C#/whatever превратится в итоге в JS (если превратится) — не имеет ровно никакого значения, если, разумеется, транспилер или компилятор правильно делают своё дело, а разработчики не пытаются лезть за пределы API.
всё остальное помимо JS вам придётся знать, если вы захотите сайтик через wasm
Это «всё остальное» называется API, и да, его полезно знать, но без знания JS можно обойтись, потому что, в конечном счёте, JS это всего лишь встроенный почти везде способ использования этого API, не более того.
Более того, многие из них имеют весьма смутные представления о железе на котором работают их приложения, и оперируют абстракциями — и это тоже не особо мешает
Сейчас я вспомнил, сколько багов мне в своё время пришлось чинить в одном ява-коде, просто потому, что разработчики имели весьма смутные представления о различиях файловой системы венды (на которой они это писали) и линукса (на котором это всё работало). И взгрустнул.
Но вообще да, вы правы. Большинство программистов пишет код, который потом меньшинство программистов приводит во вменяемое состояние, когда большинство программистов таки допишут его до состояния помойки. Помогает только то, что существенная часть этого кода не особо-то и нужна, а поэтому и спасать её никому не нужно.
Важно понимать не как что во что превращается, а то как им правильно пользоваться
… что в некотором пределе эквивалентно как раз «важно понимать как что во что превращается». Потому что документация всегда будет неполна, и ваши попытки «правильно пользоваться» всегда в какой-то момент станут не такими уж и правильными, если вы будете пытаться, как говорится, hard enough.
потому что, в конечном счёте, JS это всего лишь встроенный почти везде способ использования этого API, не более того
Не стоит уподобляться архитектурным космонавтам, это вас до добра не доведет. Это я про ваше «в конечном счете». В реальном счете JS — это не просто язык, а еще и море опенсорсного и не только кода, написанного для решения самых разных проблем, и местами очень неплохо работающего. Конечно, отдельные упоротые люди будут пытаться всё переписать на дотнет или еще на что; но нормальные люди будут всё так же использовать чужой код на JS еще очень долгое время.
Но на самом деле я вам отвечать начал не сколько ради всего, что написано выше, сколько ради вашего упоминания про «железо». Для C-программистов — это да, именно железо. Для дотнетчиков — это уже железо плюс (одна) OS, что уже добавляет веселья и нестабильности. А вот для сайтописателей «железо» — это на самом деле не железо, а софт. От многих производителей, во многих версиях, и с многими разными интересными специфическими проблемами. Подумайте об этом. И удачи вам это всё смело игнорировать.
В реальном счете JS — это не просто язык, а еще и море опенсорсного и не только кода, написанного для решения самых разных проблем, и местами очень неплохо работающего.
И что из этого следует? Он популярен и под него много чего написано — но это не значит что он лучший и ничего другого существовать не может и не должно. Если бы люди перестали изобретать колесо, то велосипеды и автомобили тоже не были бы изобретены.
Тот же Dart предоставляет доступ ко всему что может JS, в любом современном браузере по крайней мере, а несовременное и глючное всё равно нужно убивать (хотя и для этого есть решения). Или вы можете привести пример что такого может JS но не может Dart, и при этом это «что-то» нужно в существенном количестве фронтендов?
Для C-программистов — это да, именно железо. Для дотнетчиков — это уже железо плюс (одна) OS, что уже добавляет веселья и нестабильности.
Большинству приложений совершенно всё равно на каком железе и какой ОС они крутятся, им нужны только файлы и сетка, фронтендам нужен экран (и абстрактные же ручки, лампочки, клавиатура) — всё. Можно писать приложения независимые от железа и ОС, и если не заморачиваться совместимостью с тем что используется небольшим процентом клиентов — то в дебри низкого уровня нет смысла лезть (поэтому, кстати, и создаются фреймворки).
И кстати, dotnet core, точно также как и Dart, довольно хорошо абстрагируют железо и ОС, и если вычесть баги (которые фиксятся) или очень специфичные вещи то работает одинаково на Linux/MacOS/Windows и на x86/arm архитектурах, позволяя не задумываться о низком уровне в большинстве случаев.
А вот для сайтописателей «железо» — это на самом деле не железо, а софт. От многих производителей, во многих версиях, и с многими разными интересными специфическими проблемами
Если у вас требованияе поддержки IE 6 и всех версий Firefox/Chrome/Safari 10-ти летней давности — ок, это проблема, согласен.
Но я могу себе позволить сказать клиентам «ваш браузер должен быть не старше 2017 года для использования сервиса, и это должен быть Firefox/Chrome/Safari, всё остальное не поддерживаем и не гарантируем», и написать один код для всех браузеров 2017 года используя только общие для них фичи. Как показывает практика, небольшой процент возмущается но в итоге ставят, и ещё никто не ушёл из-за этого, хотя даже если бы ушло 3-5% — мне это выгоднее чем поддерживать зоопарк который работает на браузерах которым уже 5-7 лет.
Просто не нужно поддерживать старые технологии, а также технологии которые не присутствуют у всех игроков рынка — часто их поддержка в итоге съедает всю ту прибыль которуе вы (теоретически) можете получить за счёт клиентов сидящих на них.
Или вы можете привести пример что такого может JS но не может Dart, и при этом это «что-то» нужно в существенном количестве фронтендов?
Плохая постановка вопроса — к чему тут «может»? C и Asm тоже «могут» всё, что могут более узкие DSL, в частности яваскрипт. И как, много спроса на веб, написанный прямо на asm?
Сами принципиальные возможности мало кого интересуют (когда они есть, а в данном случае они есть), значение имеют именно сопутствующие накладные расходы использования этих возможностей.
Большинству приложений совершенно всё равно на каком железе и какой ОС они крутятся, им нужны только файлы и сетка
Я вам даже пример выше приводил, когда конкретное «нам всё равно» и «нам только файлы и сетку» вылилось в последующие многочисленные багфиксы, разборы полётов, и прочие интересные вещи. Как говорится, в теории теория от практики не отличается, а вот на практике теория от практики очень отличается.
фронтендам нужен экран
Нет, не только. Да и экраны тоже очень разные бывают. И если за все эти годы вопрос вёрстки на экраны разных размеров можно часто (но не всегда) решить готовыми средствами, то вот вопросы взаимодействия пользователя с тачскрином против обычной мышки готовыми средствами не решаются, будьте добры описать всю необходимую разницу в логике и верстке самостоятельно. Способы взаимодействия-то разные и пересекаются лишь очень частично.
Но я могу себе позволить сказать клиентам «ваш браузер должен быть не старше 2017 года для использования сервиса, и это должен быть Firefox/Chrome/Safari, всё остальное не поддерживаем и не гарантируем», и написать один код для всех браузеров 2017 года используя только общие для них фичи.
«Общие фичи» могут по-разному работать в разных браузерах; выработка решений, работающих и выглядящих везде одинаково опять же останется на вас. Отсечение старых браузеров тут ничего не меняет — это количественное улучшение, а не качественное. Головной боли у вас будет меньше, а вот принципиальные проблемы всё такие же, и всё так же вам нужно будет представлять себе, откуда они вообще берутся.
C и Asm тоже «могут» всё, что могут более узкие DSL, в частности яваскрипт.
Простите, причём тут asm? Речь шла про Dart, это очень даже не asm, и я утверждаю (отчасти на собственном опыте) что на нём можно сделать всё что можно сделать напрямую в JS, при этом не влезая в JS.
Вы же утверждаете что «без JS не обойтись» и «есть тонкости». Я вот с ними не сталкивался, поэтому и попросил привести пример.
на практике теория от практики очень отличается
Это зависит от практики и теории. Нам удаётся минимизировать эти отличия, часто достаточно хорошо чтобы не заморачиваться деталями.
«Общие фичи» могут по-разному работать в разных браузерах
Речь шла о фичах которые работают одинаково, любые другие (кроме мелких типа смещения или цвета одного пикселя) просто исключаются из использования (как правило, без них вполне можно обойтись).
Простите, причём тут asm?
При том, что «на asm тоже можно сделать всё, что можно сделать на JS». Вот без шуток. Вопрос только в цене.
У дарта своя цена деланья на нём — тоже имеется.
Вы же утверждаете что «без JS не обойтись»
Я утверждаю, что пока Dart компилируется в JS и вы на нем что-то достаточно сложное пишите — лучше б вам разбираться и в JS, а иначе оно может выйти вам боком.
любые другие (кроме мелких типа смещения или цвета одного пикселя)
«Мелочь» типа неправильного смещения может вам убить всю верстку, если что. Другие «мелочи» типа дефолтных размеров svg (это, если чо, та самая разница между актуальнейшим файрфоксом и актуальнейшим же хромом, которая уже несколько лет никуда не девается) могут убить все ваши иконки.
А так-то мелочи конечно.
UFO just landed and posted this here
Вместо VS code предпочитаю продукции jetbrains, в частностм webstorm)
А что не 132 совета? Ведь всего 32 совета — это ни о чём.
Можно добавить (или отдельно взять) 33 совет: "Идите!" (почти что из одесского анекдота). И да у меня пока сайт на чистом html + css, а второй вообще на ssg lektor сделан. Думаю, что добавить лучше js или flask|django + mysql|postgresql + elasticsearch. Хотелось бы возможности работы с текстом на сайте как в Adobe Page Maker 6.5, но или мозгов не хватает, как это сделать просто или это невозможно. Интересует произвольные drag & drop операции с буквами, словами, картинками в быстро-удобном редакторе.
Sign up to leave a comment.
32 совета веб-разработчику, который хочет вырасти над собой в 2020 году