То есть этот инструмент настолько не пойми как работает, что для отладки кода с его использованием нужны десятки килобайт отладочных сообщений?
То есть, сообщения об использовании deprecated классов/модулей/функций, различные warnings, например — это признаки плохого инструмента? Выбирая из 20Мб отладочных сообщений, и модулей ля упрощения разработки в development, и отсутствие оного, зато не требующим шага при сборке — я выберу первый. Потому что, мне это ничего не стоит. Зато это сэкономит мне время, когда палка выстрелит.
Типы несут полезную нагрузку. Неиспользуемые модули — бесполезную. При этом типы вырезаются при любой сборке, а не требуют для продакшена делать отдельную.
Да. Я понимаю вашу позицию. Типы вырезаются при любой сборке, а вот сделать dead code elimination, или tree shaking — это уже в самописной build системе не получится сделать за пять минут и на коленке. Поэтому это сложно, а значит не нужно. Лучше делать отладку на production с пользовательскими данными, верить в то, что используемый инструмент идеально написан, и отладочная информация для слабаков, а настройка сборки — не нужна, потому что наш инструмент ее не умеет и вообще время, и вообще сложно.
Речь шла про TSX, он поймает.
Но речь как раз шла не об ошибках типов, на что вы сказали, что только типизируемый язык такие ошибки словит (хотя при чем тут типы). JSX тоже их поймает. Кажется мы тут упустили нить, но уже не хочу разбираться кто и когда ее упустил.
Чудесный костыль. Чуть более сложные внутренние контролы и это неявное соглашение ломается. Какое он имеет отношение к типизации?
Это не костыль, это всего лишь синтаксис языка. Конечно сломается, но когда оно сломается — тогда и код перепишется. Да и тесты помогут. К типизации это относится ровно так, что TS/Flow не идеальны, и к тому, что краткость синтаксиса, не всегда доступна вместе с типизацией, и нужно выбирать.
Кстати, насчет TS. Как думаете, вот этот код TS поймет как неправильный: function filterArray(a: any[]): number[] { return a.filter(i => typeof i === 'string'); }? Можете в Playground даже попробовать. Надеюсь, банальный filter вы костылями не назовете?
Речь идет о формировании лога событий, предшествующих ошибке
Представьте себе, лучше большое количество бесполезных логов, среди которых есть действия, которые могли привести к ошибке. Такие логи — дополнительный ключ к пониманию, почему произошла ошибка и где ее искать.
Вы зашли на продакшен, видите багу. Что к ней привело — не понятно. Ваши действия?
Так это вам непонятно, что к ней привело. Я то как раз использую "ненужные модули" и "логи про то, как пользователь поскроллил", и могу довольно быстро локализовать ошибку. У меня на руках есть исключение, привязанное к source maps (если это было исключение), у меня есть примерный сценарий поведения пользователя (потому что пользователь никогда вам не скажет, что он сделал, что привело к ошибке), и у меня есть локальная система, где я могу попытаться воспроизвести ошибку, и задействовать бесполезные модули, которые нужно вырезать на этапе сборки. Так что, первым моим действием, будет анализ данных, а не гадание на production, как воспроизвести, и почему так получилось.
А что вы ожидали увидеть? Что вы вкладываете в понятие микромодульности, помимо отсутствия монолитного ядра?
Я ожидал увидеть нечто из ряда вон. Я ожидал, какой-то магической "микро"-модульности. А на деле, простой компонентный подход, разделение на модули (откуда тут взялось микро — не понимаю, отсылка к модным ныне микросервисам?), который у многих уже давно.
Реакт заменяется модулем $mol_viewer.
Я имел ввиду не в рамках $mol, а как инструмент для решения класса задач.
Что вы хотите там кастомизировать?
Например, я хочу кастомизировать используемые PostCSS плагины (а кто-то использует вообще Less/Sass/Stylus — и это их право). И знаете. Не просто кастомизировать. У меня в рамках приложения, может быть допустим, несколько разных типов страниц — основные разделы для пользователя, пара SPA, админка, и пара лендингов. И для каждого я хочу свой набор PostCSS плагинов, потому что у них могут быть разные требования, или нужны по разному настроенные плагины. Или, я хочу импортировать CSS в JS, например. Я хочу, чтобы моя сборка считала зависимостью не только JS/CSS файлы, но и статику, которые те используют. И желательно, это дело тоже как-то оптимизировать. Я хочу прокидывать флаги NODE_ENV, например, но мы это проходили, да. Я хочу контроллировать, как будут собираться бандлы и иметь возможность оптимизировать стратегию их сборки и компоновки под нужды приложения. Я хочу, чтобы сборщик умел кешировать и умел в инкрементальную сборку в development, чтобы было быстро, и может быть умел hot reload. Хотел бы иметь сервер, который бы отдавал ассеты в development режиме, без нужды сбрасывать их каждый раз на диск, а отдавать прямо из памяти. Чтобы было быстро.
Там вполне явные зависимости. Когда вы пишете $mol_defer в бандл включается модуль $mol_defer. Куда уж явнее? То, что вы имеете ввиду — не явные зависимости, а зависимости вынесенные в начало файла. Объявления переменных вы тоже в начало файла выносите?
Ну это так себе — как явные зависимости. Если допустим, я напишу $mol_defer, но такой модуль не будет существовать — ваша сборка скажет мне об этом? А если, не будет существовать не JS файл, а какая-то другая зависимость — я об этом узнаю? Dependency Injection — механизм не явных зависимостей конечно. Но у него есть свои benefits, о которых много копий сломано, и рассказывать то, что можно прочитать в десятке мест — я не хочу. Кстати, этот же механизм есть и у Ember. И он тоже отчасти на соглашениях построен.
Потому же почему и тут карму сливают — я не Дэн Абрамов, $mol — не React, а работаю я не в Google.
Ну может карму сливают не потому, что вы не Абрамов (и он не всегда в FB работал), а потому что, вы можете быть не правы? Или ваше мнение не совпадает с большинством? Роману Дворнову, вот ничего не мешает рассказывать про basis.js, при этом не имея огромной аудитории как у React.
Да банальная отладочная информация. Например, отладочные сообщения, ворнинги. Которые имеют смысл мне локально, но не имеют смысла в продакшене для пользователя. Мы же с этого начинали. Или опять таки propTypes, или те же типы (они бесполезны в рантайме в случае JS, увы). Мы кажется с этого начали — зачем пихать отладочную информацию, чтобы потом удалять её сборкой, разве нет?
В таком случае разглагольствования про выявление ошибок на этапе сборки — ни о чём.
Какая-то странная ультимативность. Type checker выявит ошибки типов (большинство, не все — он в рантайме не защитит от кривых входных данных — ошибка отловится, но уже где-то глубже, а не на точке входа). Но типы не поймают ошибку, если в es6x будет неправильный шаблон, и сборка не поймает. Так что разглагольствовать есть о чем. Кроме того, есть trade off между TS/Flow, и выразительностью, например https://twitter.com/dan_abramov/status/808020948750397441
Он передаёт на сервер слепок памяти? Или как обычно — лишь создаёт видимость в духе "ну браузер такой-то, ось такая-то"?
Вы отлаживаете клиентский JS по слепку памяти? =) Нет, конечно, речь идет не о банальном environment'е, что трекеры умели в бородатые годы. Речь идет о формировании лога событий, предшествующих ошибке https://trackjs.com/assets/images/tour/telemetry-full.png Я могу ошибаться (давно не пользовался), но кажется в sentry подобная штука называется Breadcrumbs.
Лучше искать там, где воспроизводится. Вы соскочили с темы "как понять причину ошибки" на тему "как воспроизвести неуловимую ошибку".
Правильно. Если она воспроизводится локально — то лучше её там и искать. Трогать продакшн конечно же нужно, но если можно этого избежать — почему не воспользоваться этим? =)
Микромодульностью.
Честно, пробежался по репозиторию, и магической микромодульности не увидел. Просто свой набор утилит + компоненты, только самописные и интегрированные между друг другом, а не с npm. Крутое решение для класса задач, но я не вижу как им заменить React, и кастомизируемую сборку. И да, я люблю конечно, convention over configuration, но так же я люблю явные зависимости. Если бы, у вас был dependency injection, аля Angular — это было бы интереснее, но у вас просто парсинг своих соглашений в поисках зависимостей, вместо import/export из es6. Ну как бы, это не микромодульность, ну или не чем-то выделяющаяся, извините.
Что касается $mol вообще. В Питере целых два сообщества проводят митапы по фронтенд разработке. Почему бы вам не рассказать о нем на митапе? Не все пишут на React, в общем-то. Вполне вероятно вы найдете идею/критику/пользователей на них, рассказав о своем инструменте.
Рассказываю. Это очень удобно, когда отладочная информация лежит в отдельном файле.
Круто, расскажите как отладочную информацию положить в отдельный файл в случае обсуждаемых выше задач? Кроме source maps.
propType — это рантайм эмуляция статической типизации. Что мешает использовать полноценную статическую типизацию в виде TSX, которую не нужно "вырезать"?
А я не отметал возможность использования TSX, только вот, TypeScript не всем нужен и не всем нравится. Так то и FlowType есть. Но как и в случае с TS — не все используют.
Есть много разных минификаторов. Сейчас они используются скорее по инерции, так как на фоне gzip практически ничего не дают.
Ну не знаю. У меня почему-то, даже zopfli дает ощутимо разные результаты после и без минификации. Вы делаете слишком обобщенный вывод.
А это вы откуда взяли? У меня сорсмапы кладутся в отдельный файл. А вы вкомпиливаете их прямо в код? Зачем?
А с чего вы взяли, что я имею ввиду только вариант использования source maps внутри скомпилированного файла, а не как отдельного? =) Возможно, я зацепил информацию из треда ниже или выше, не напрямую к вам относящуюся.
Хорошо там у вас наверно в идеальном мире? :-)
Идеальный мир — делаем мы сами. TrackJS умеет в телеметрию, например. Так что, он не такой идеальный, а скорее реальный. Вы же используете, например, console.log. Ну так же вместо него можно сообщения отправлять в трекер. Лучше, чем искать ошибку на продакшене, не так ли? =)
Правильная архитектура позволяет экономить гораздо больше.
И как это связано с размером результирующего бандла приложения? Ну можно и System.import вспомнить, и асинхронную догрузку кусков приложения. И многих подходов. $mol тут чем особо выделяется? Тем что минималистичен?
Кстати, еще пока вспомнил, и касательно конкретно React. В dev и production режиме, JSX транспайлится по разному. createElement против непосредственно JS объектов. Первый дает больше возможностей для отладки, второй — быстрее работает.
Что касается разбора шаблонов непосредственно на клиенте — мы хотим дать лучший UX. Если мы можем отказаться от дополнительных шагов, и быстрее показать страницу пользователю — почему это не делать? Зачем дополнительный шаг? Есть ведь мобильные, есть простые пользователи с не совсем производительными устройствами.
На секундочку, Angular 2, компилирует шаблоны в императивный JS-код непосредственно.
Или вот https://svelte.technology/ от Рича Харриса (автора Rollup). Фреймворк компилирует компоненты в непосредственно императивный код.
Технологии двигаются в сторону оптимизации, тут же предлагается компилировать шаблоны на клиенте (даже во времена классических строковых шаблонизаторов, хорошей практикой была прекомпиляция шаблонов Jade/Pug/etc в функции).
Я уже не говорю о том, что современные редакторы умеют в подсветку JSX синтаксиса, и его легче читать, чем HTML шаблон в строке со вставками.
Еще один момент — компиляция JSX шаблона быстрее покажет ошибку в шаблоне (просто банально не сможет распарсить структуру), нежели мы получим ошибку в runtime при попытке отрендерить страницу. В конце концов, редакторы, вполне себе уже поддерживают JSX и укажут на несоответствие синтаксиса. Это конечно, по большому счету лирика, но тем не менее.
Аргумент в принципе логичен с первого взгляда, но упускает множество моментов.
Во-певрых, отдельно придумывать архитектуру внутри библиотеки, так, чтобы подключать туда расширения только для отладки — это не всегда лучшее или удачное решение. Или лучше сказать — это не всегда наилучший и единственный путь. В конце концов, вы же не рассказываете условным C++-разработчикам, что сборка бинарных файлов с отладочной информацией — это плохо, и поэтому C++ — это странный инструмент, правильно?
Во-вторых, тот же React в development режиме вырезает не только отладочную информацию, но и например, вырезает проверку propTypes. А еще при сборке, их можно вообще вырезать из кода тем же плагином.
В-третьих, вы упускаете момент, что например, есть, например, минификатор babili, который построен поверх babel. Babel и подобные инструменты — это не только полифилл для новых версий языка.
В-четвертых, ECMAScript в отличии от ранних версий, сейчас активно развивается, и говорить о том, что сейчас все фичи будут во всех мажорных браузерах, и нам не нужен будет transpiler — преждевременно. Transpiler используется для проверки и реализации новых возможностей языка (в том числе, посмотрите на процесс TC-39). Во-вторых, новые возможности можно использовать уже с Stage 3 (когда допускаются только критические исправления). Но есть еще Stage 4. И это только до момента внедрения в браузеры (этот процесс тоже не равномерен по времени). То есть, transpiller позволяет подготовить ваш код к будущему переходу на нативную поддержку в движках языка до того момента, как эта поддержка настанет.
В-пятых, отсылка на отказ от source map также преждевременна. Вы можете отказаться от babel, но вы же минифицируете код? Значит, уже нужны source map.
В-шестых, отладка в production… Ну как бы это сказать. Этот этап должен предварять этап сбора отладочных сведений путем таких инструментов как Sentry, TrackJS, Honeybadger, и других. И потом уже можете воспроизводить неисправность локально, зная условия, которые приводят к ошибке. В 99.99% случаев, проблема будет не в сборке.
Transpiler'ы — это данность, поэтому и отказ от JSX, только потому что он требует transpiler'а, который скоро будет не нужен — это слабый, на самом деле, аргумент.
Я уже не говорю о том, что, экономить килобайты важно до сих пор. По очень многим причинам. Странно это вообще объяснять фронтенд-разработчику, не находите?
Это точно Atom. Характерная иконка корня проекта, характерная подсветка дерева файлов, характерная оранжевая иконка незакомиченных изменений внизу справа.
У Саблайма статус бар на все окно, а Atom сайдбар на всю высоту, и под ним нет статус бара. Тема стандартная темная.
Люди мучаются не потому что, Angular или React плох, а потому что не умеют выбирать инструменты для задачи и ведутся на маркетинг и хайп. Для своих задач и Angular, и React отлично подходят. Но когда вы молоток начинаете использовать, чтобы закручивать гайки, а не гвозди забивать — то тут конечно мучения начинаются.
Так вы продайте вашим разрабам chruby, или на худой конец rbenv. RVM конечно монстр, и устарел — но многие до сих пор по банальной инерции им пользуются.
Проблема сильно глубже. У Dart/AtScript/TypeScript строгая статическая типизация. Статическая типизация накладывает ограничения на скорость разработки, а также на качество проектируемой архитектуры. Учитывая средний уровень подготовки типичного JS программиста — такой программист с задачей тупо не справится.
А вышеуказанные языки разрабатываются как правило под влиянием ребят, знакомых с Java/C++/C#, и разработка на этих языках для них не является проблемой.
Идеальным решением было бы сделать строгую динамическую типизацию (как в Ruby или Python). Но вот загвоздка. Без вмешательства в интерпретатор, такую типизацию сделать крайне сложно, и реализация ее на уровне компиляции будет более затратной в плане производительности, чем даже типизация в рантайме у того же AtScript. AtScript может позволить себе вставить условие проверки соответствия переменной конкретному типу в конкретном месте кода. В случае же с динамической типизацией, информацию о типе придется таскать с собой, и проверять соответствия типов при каждой маломальской операции. Это будет занимать наверное 60-80% времени исполнения кода.
Так что, увы — слабая типизация — это бремя языка, которое он будет нести наверное вечно, если все же разработчики интерпретаторов не озаботятся этим вопросом, и не найдут пути плавного перехода на эту схему.
Добавлю свои пять копеек:
1) использование шрифтов для иконок чревато проблемами, но это не критично в некоторых случаях. Но я бы предпочел таки SVG, чем именно шрифт;
2) я удивлен, почему на каждом углу говорят про Avocode, который еле вышел, как я уже несколько месяцев благополучно пользуюсь убийцей PS непосредственно от Adobe — projectparfait.adobe.com. Project Parfait бесплатный, если все подумали, что сейчас придется еще что-то платить.
Телефоны Sony, которые выпускались до Z1 Compact, включая и старшего брата Z1, оснащены не IPS, а TFT матрицей. Z1 Compact, если я не ошибаюсь, первый их телефон, который поставляется именно с IPS матрицей, которая обладает лучшими характеристиками как по цветопередаче, так и по углам обзора.
Я не могу понять, чем ваше решение + Mutation Observer кардинально отличается от React?
Какая разница, что вы вызовете в методе render вашей Backbone.View. Вызовете вы рендер своего Backbone.Component или вызовете renderComponent React'а — суть никак не поменяется. В обоих случаях получаются черные ящики, которые внутри себя несут логику + верстку, и могут генерировать какие-то события во вне, чтобы например Backbone View могла на них реагировать, не вникая во внутреннюю реализацию.
Если в какой-то вьюхе вам не нужен шаблон — не используйте ни шаблон, ни React компонент. Если вам не нужна манипуляция с DOM — не используйте ее. Ваша библиотека отличается от React только названием и тем, что практически ничего не умеет, ну и легче по весу за счет этого, ОК.
React это:
— библиотека, а не фреймворк;
— это V в MVC, поэтому с Backbone и используют.
И главное, что собственная идеология React заключается в том, чтобы не мешаться внутри приложения, а помогать его строить. Именно поэтому, это библиотека с совершенно четкой и единственной целью. И используется она для создания как раз веб-компонентов, подобно Google Polymer. Ну и по сути это тоже самое, о чем написано в посте.
Скажите, а в чем проблема была с тем, чтобы просто прикрутить React.js в качестве библиотеки для таких компонентов? Она то лучше ваших велосипедов, и десятка других, которые есть на рынке. Ну и кроме того, это только библиотека компонентов, и не заставляет отказываться от бекбона, или того, что вы используете.
А что мешает разбивать приложение на модули (даже если они не связаны), загружать клиенту один раз большим (или несколькими поменьше — там в зависимости от) файлом, и кешировать это у него же (я имею ввиду инструменты подобные assets pipeline из Rails)? Тем более, так будет даже быстрее, чем за каждым мелким файлом обращаться к серверу, тратить время на коннект, ждать загрузки, и только потом получать полезный профит от непосредственно кода?
Есть еще какие-то причины такой вот ленивой загрузки?
Меня всегда волновал вопрос, зачем люди используют ленивую загрузку по сети. Ну, вот например, многие обосновывали мне использование require.js или AMD.js — мол модули, мы без них жить не можем, а тут они есть и это круто. Ок.
Здесь я вижу пример, когда даже CommonJS не поддерживается, усложняется код, делается более шатким. И меня очень волнует вопрос, зачем это надо, и чем это хуже, нежели соединить все файлы в один (или несколько больших), минифицировать их, и со спокойной душой отдавать это клиенту один раз, и не париться насчет кеширования, задержек в интерфейсе из-за лишних загрузок, и так далее.
В каких особенных ситуациях нужны вот такие костыли (вероятно они есть, но лично я их никогда не встречал, ну разве что чистейший SPA, и то это довольно редко обоснованный случай)?
То есть, сообщения об использовании deprecated классов/модулей/функций, различные warnings, например — это признаки плохого инструмента? Выбирая из 20Мб отладочных сообщений, и модулей ля упрощения разработки в development, и отсутствие оного, зато не требующим шага при сборке — я выберу первый. Потому что, мне это ничего не стоит. Зато это сэкономит мне время, когда палка выстрелит.
Да. Я понимаю вашу позицию. Типы вырезаются при любой сборке, а вот сделать dead code elimination, или tree shaking — это уже в самописной build системе не получится сделать за пять минут и на коленке. Поэтому это сложно, а значит не нужно. Лучше делать отладку на production с пользовательскими данными, верить в то, что используемый инструмент идеально написан, и отладочная информация для слабаков, а настройка сборки — не нужна, потому что наш инструмент ее не умеет и вообще время, и вообще сложно.
Но речь как раз шла не об ошибках типов, на что вы сказали, что только типизируемый язык такие ошибки словит (хотя при чем тут типы). JSX тоже их поймает. Кажется мы тут упустили нить, но уже не хочу разбираться кто и когда ее упустил.
Это не костыль, это всего лишь синтаксис языка. Конечно сломается, но когда оно сломается — тогда и код перепишется. Да и тесты помогут. К типизации это относится ровно так, что TS/Flow не идеальны, и к тому, что краткость синтаксиса, не всегда доступна вместе с типизацией, и нужно выбирать.
Кстати, насчет TS. Как думаете, вот этот код TS поймет как неправильный:
function filterArray(a: any[]): number[] { return a.filter(i => typeof i === 'string'); }? Можете в Playground даже попробовать. Надеюсь, банальныйfilterвы костылями не назовете?Представьте себе, лучше большое количество бесполезных логов, среди которых есть действия, которые могли привести к ошибке. Такие логи — дополнительный ключ к пониманию, почему произошла ошибка и где ее искать.
Так это вам непонятно, что к ней привело. Я то как раз использую "ненужные модули" и "логи про то, как пользователь поскроллил", и могу довольно быстро локализовать ошибку. У меня на руках есть исключение, привязанное к source maps (если это было исключение), у меня есть примерный сценарий поведения пользователя (потому что пользователь никогда вам не скажет, что он сделал, что привело к ошибке), и у меня есть локальная система, где я могу попытаться воспроизвести ошибку, и задействовать бесполезные модули, которые нужно вырезать на этапе сборки. Так что, первым моим действием, будет анализ данных, а не гадание на production, как воспроизвести, и почему так получилось.
Я ожидал увидеть нечто из ряда вон. Я ожидал, какой-то магической "микро"-модульности. А на деле, простой компонентный подход, разделение на модули (откуда тут взялось микро — не понимаю, отсылка к модным ныне микросервисам?), который у многих уже давно.
Я имел ввиду не в рамках $mol, а как инструмент для решения класса задач.
Например, я хочу кастомизировать используемые PostCSS плагины (а кто-то использует вообще Less/Sass/Stylus — и это их право). И знаете. Не просто кастомизировать. У меня в рамках приложения, может быть допустим, несколько разных типов страниц — основные разделы для пользователя, пара SPA, админка, и пара лендингов. И для каждого я хочу свой набор PostCSS плагинов, потому что у них могут быть разные требования, или нужны по разному настроенные плагины. Или, я хочу импортировать CSS в JS, например. Я хочу, чтобы моя сборка считала зависимостью не только JS/CSS файлы, но и статику, которые те используют. И желательно, это дело тоже как-то оптимизировать. Я хочу прокидывать флаги NODE_ENV, например, но мы это проходили, да. Я хочу контроллировать, как будут собираться бандлы и иметь возможность оптимизировать стратегию их сборки и компоновки под нужды приложения. Я хочу, чтобы сборщик умел кешировать и умел в инкрементальную сборку в development, чтобы было быстро, и может быть умел hot reload. Хотел бы иметь сервер, который бы отдавал ассеты в development режиме, без нужды сбрасывать их каждый раз на диск, а отдавать прямо из памяти. Чтобы было быстро.
Ну это так себе — как явные зависимости. Если допустим, я напишу $mol_defer, но такой модуль не будет существовать — ваша сборка скажет мне об этом? А если, не будет существовать не JS файл, а какая-то другая зависимость — я об этом узнаю? Dependency Injection — механизм не явных зависимостей конечно. Но у него есть свои benefits, о которых много копий сломано, и рассказывать то, что можно прочитать в десятке мест — я не хочу. Кстати, этот же механизм есть и у Ember. И он тоже отчасти на соглашениях построен.
Ну может карму сливают не потому, что вы не Абрамов (и он не всегда в FB работал), а потому что, вы можете быть не правы? Или ваше мнение не совпадает с большинством? Роману Дворнову, вот ничего не мешает рассказывать про basis.js, при этом не имея огромной аудитории как у React.
Да банальная отладочная информация. Например, отладочные сообщения, ворнинги. Которые имеют смысл мне локально, но не имеют смысла в продакшене для пользователя. Мы же с этого начинали. Или опять таки propTypes, или те же типы (они бесполезны в рантайме в случае JS, увы). Мы кажется с этого начали — зачем пихать отладочную информацию, чтобы потом удалять её сборкой, разве нет?
Какая-то странная ультимативность. Type checker выявит ошибки типов (большинство, не все — он в рантайме не защитит от кривых входных данных — ошибка отловится, но уже где-то глубже, а не на точке входа). Но типы не поймают ошибку, если в es6x будет неправильный шаблон, и сборка не поймает. Так что разглагольствовать есть о чем. Кроме того, есть trade off между TS/Flow, и выразительностью, например https://twitter.com/dan_abramov/status/808020948750397441
Вы отлаживаете клиентский JS по слепку памяти? =) Нет, конечно, речь идет не о банальном environment'е, что трекеры умели в бородатые годы. Речь идет о формировании лога событий, предшествующих ошибке https://trackjs.com/assets/images/tour/telemetry-full.png Я могу ошибаться (давно не пользовался), но кажется в sentry подобная штука называется Breadcrumbs.
Правильно. Если она воспроизводится локально — то лучше её там и искать. Трогать продакшн конечно же нужно, но если можно этого избежать — почему не воспользоваться этим? =)
Честно, пробежался по репозиторию, и магической микромодульности не увидел. Просто свой набор утилит + компоненты, только самописные и интегрированные между друг другом, а не с npm. Крутое решение для класса задач, но я не вижу как им заменить React, и кастомизируемую сборку. И да, я люблю конечно, convention over configuration, но так же я люблю явные зависимости. Если бы, у вас был dependency injection, аля Angular — это было бы интереснее, но у вас просто парсинг своих соглашений в поисках зависимостей, вместо import/export из es6. Ну как бы, это не микромодульность, ну или не чем-то выделяющаяся, извините.
Что касается $mol вообще. В Питере целых два сообщества проводят митапы по фронтенд разработке. Почему бы вам не рассказать о нем на митапе? Не все пишут на React, в общем-то. Вполне вероятно вы найдете идею/критику/пользователей на них, рассказав о своем инструменте.
Круто, расскажите как отладочную информацию положить в отдельный файл в случае обсуждаемых выше задач? Кроме source maps.
А я не отметал возможность использования TSX, только вот, TypeScript не всем нужен и не всем нравится. Так то и FlowType есть. Но как и в случае с TS — не все используют.
Ну не знаю. У меня почему-то, даже zopfli дает ощутимо разные результаты после и без минификации. Вы делаете слишком обобщенный вывод.
А с чего вы взяли, что я имею ввиду только вариант использования source maps внутри скомпилированного файла, а не как отдельного? =) Возможно, я зацепил информацию из треда ниже или выше, не напрямую к вам относящуюся.
Идеальный мир — делаем мы сами. TrackJS умеет в телеметрию, например. Так что, он не такой идеальный, а скорее реальный. Вы же используете, например, console.log. Ну так же вместо него можно сообщения отправлять в трекер. Лучше, чем искать ошибку на продакшене, не так ли? =)
И как это связано с размером результирующего бандла приложения? Ну можно и System.import вспомнить, и асинхронную догрузку кусков приложения. И многих подходов. $mol тут чем особо выделяется? Тем что минималистичен?
Кстати, еще пока вспомнил, и касательно конкретно React. В dev и production режиме, JSX транспайлится по разному. createElement против непосредственно JS объектов. Первый дает больше возможностей для отладки, второй — быстрее работает.
Что касается разбора шаблонов непосредственно на клиенте — мы хотим дать лучший UX. Если мы можем отказаться от дополнительных шагов, и быстрее показать страницу пользователю — почему это не делать? Зачем дополнительный шаг? Есть ведь мобильные, есть простые пользователи с не совсем производительными устройствами.
На секундочку, Angular 2, компилирует шаблоны в императивный JS-код непосредственно.
Или вот https://svelte.technology/ от Рича Харриса (автора Rollup). Фреймворк компилирует компоненты в непосредственно императивный код.
Технологии двигаются в сторону оптимизации, тут же предлагается компилировать шаблоны на клиенте (даже во времена классических строковых шаблонизаторов, хорошей практикой была прекомпиляция шаблонов Jade/Pug/etc в функции).
Я уже не говорю о том, что современные редакторы умеют в подсветку JSX синтаксиса, и его легче читать, чем HTML шаблон в строке со вставками.
Еще один момент — компиляция JSX шаблона быстрее покажет ошибку в шаблоне (просто банально не сможет распарсить структуру), нежели мы получим ошибку в runtime при попытке отрендерить страницу. В конце концов, редакторы, вполне себе уже поддерживают JSX и укажут на несоответствие синтаксиса. Это конечно, по большому счету лирика, но тем не менее.
Аргумент в принципе логичен с первого взгляда, но упускает множество моментов.
Во-певрых, отдельно придумывать архитектуру внутри библиотеки, так, чтобы подключать туда расширения только для отладки — это не всегда лучшее или удачное решение. Или лучше сказать — это не всегда наилучший и единственный путь. В конце концов, вы же не рассказываете условным C++-разработчикам, что сборка бинарных файлов с отладочной информацией — это плохо, и поэтому C++ — это странный инструмент, правильно?
Во-вторых, тот же React в development режиме вырезает не только отладочную информацию, но и например, вырезает проверку propTypes. А еще при сборке, их можно вообще вырезать из кода тем же плагином.
В-третьих, вы упускаете момент, что например, есть, например, минификатор babili, который построен поверх babel. Babel и подобные инструменты — это не только полифилл для новых версий языка.
В-четвертых, ECMAScript в отличии от ранних версий, сейчас активно развивается, и говорить о том, что сейчас все фичи будут во всех мажорных браузерах, и нам не нужен будет transpiler — преждевременно. Transpiler используется для проверки и реализации новых возможностей языка (в том числе, посмотрите на процесс TC-39). Во-вторых, новые возможности можно использовать уже с Stage 3 (когда допускаются только критические исправления). Но есть еще Stage 4. И это только до момента внедрения в браузеры (этот процесс тоже не равномерен по времени). То есть, transpiller позволяет подготовить ваш код к будущему переходу на нативную поддержку в движках языка до того момента, как эта поддержка настанет.
В-пятых, отсылка на отказ от source map также преждевременна. Вы можете отказаться от babel, но вы же минифицируете код? Значит, уже нужны source map.
В-шестых, отладка в production… Ну как бы это сказать. Этот этап должен предварять этап сбора отладочных сведений путем таких инструментов как Sentry, TrackJS, Honeybadger, и других. И потом уже можете воспроизводить неисправность локально, зная условия, которые приводят к ошибке. В 99.99% случаев, проблема будет не в сборке.
Transpiler'ы — это данность, поэтому и отказ от JSX, только потому что он требует transpiler'а, который скоро будет не нужен — это слабый, на самом деле, аргумент.
Я уже не говорю о том, что, экономить килобайты важно до сих пор. По очень многим причинам. Странно это вообще объяснять фронтенд-разработчику, не находите?
У Саблайма статус бар на все окно, а Atom сайдбар на всю высоту, и под ним нет статус бара. Тема стандартная темная.
А вышеуказанные языки разрабатываются как правило под влиянием ребят, знакомых с Java/C++/C#, и разработка на этих языках для них не является проблемой.
Идеальным решением было бы сделать строгую динамическую типизацию (как в Ruby или Python). Но вот загвоздка. Без вмешательства в интерпретатор, такую типизацию сделать крайне сложно, и реализация ее на уровне компиляции будет более затратной в плане производительности, чем даже типизация в рантайме у того же AtScript. AtScript может позволить себе вставить условие проверки соответствия переменной конкретному типу в конкретном месте кода. В случае же с динамической типизацией, информацию о типе придется таскать с собой, и проверять соответствия типов при каждой маломальской операции. Это будет занимать наверное 60-80% времени исполнения кода.
Так что, увы — слабая типизация — это бремя языка, которое он будет нести наверное вечно, если все же разработчики интерпретаторов не озаботятся этим вопросом, и не найдут пути плавного перехода на эту схему.
1) использование шрифтов для иконок чревато проблемами, но это не критично в некоторых случаях. Но я бы предпочел таки SVG, чем именно шрифт;
2) я удивлен, почему на каждом углу говорят про Avocode, который еле вышел, как я уже несколько месяцев благополучно пользуюсь убийцей PS непосредственно от Adobe — projectparfait.adobe.com. Project Parfait бесплатный, если все подумали, что сейчас придется еще что-то платить.
Когда покупал еще свой Z1, и уже появлялись новости о Z1 Compact, говорилось, что в новой модели наконец заменят тип дисплея.
Какая разница, что вы вызовете в методе render вашей Backbone.View. Вызовете вы рендер своего Backbone.Component или вызовете renderComponent React'а — суть никак не поменяется. В обоих случаях получаются черные ящики, которые внутри себя несут логику + верстку, и могут генерировать какие-то события во вне, чтобы например Backbone View могла на них реагировать, не вникая во внутреннюю реализацию.
Если в какой-то вьюхе вам не нужен шаблон — не используйте ни шаблон, ни React компонент. Если вам не нужна манипуляция с DOM — не используйте ее. Ваша библиотека отличается от React только названием и тем, что практически ничего не умеет, ну и легче по весу за счет этого, ОК.
React это:
— библиотека, а не фреймворк;
— это V в MVC, поэтому с Backbone и используют.
И главное, что собственная идеология React заключается в том, чтобы не мешаться внутри приложения, а помогать его строить. Именно поэтому, это библиотека с совершенно четкой и единственной целью. И используется она для создания как раз веб-компонентов, подобно Google Polymer. Ну и по сути это тоже самое, о чем написано в посте.
Есть еще какие-то причины такой вот ленивой загрузки?
Здесь я вижу пример, когда даже CommonJS не поддерживается, усложняется код, делается более шатким. И меня очень волнует вопрос, зачем это надо, и чем это хуже, нежели соединить все файлы в один (или несколько больших), минифицировать их, и со спокойной душой отдавать это клиенту один раз, и не париться насчет кеширования, задержек в интерфейсе из-за лишних загрузок, и так далее.
В каких особенных ситуациях нужны вот такие костыли (вероятно они есть, но лично я их никогда не встречал, ну разве что чистейший SPA, и то это довольно редко обоснованный случай)?