Как говорится смешивать, но не взбалтывать.
Из своего опыта знаю, что лучше наоборот писать компоненты или какие-то не большие библиотеки на VanilaJS. А для фреймворков писать уже адапторы, если это необходимо.
Хотя ваша мысль мне то де нравится, но как и с любыми решениями такого рода, наверняка есть свои подводные камни.
Возможно мысль и благая, но лично меня смущает возможный просмотр листингов хотя бы среднего компонента в таком стиле. Какой-нибудь формочки, например.
Во-первых, на мне кажется, что увеличивается возможность допустить ошибку
Во-вторых, да же на среднем мониторе будет сложно это просматривать. Возможно кровотечение из глаз и поломку мозга
Я бы для демонстрации модуля сделал бы не большое приложение и выложил бы его исходники. И написал бы об этом пост. Где, как раз, рассказал и показал как оно работает и какие плюсы.
Мне кажется у всех могло бы возникнуть меньше вопросов или более конкретизированные.
Плюс многие из нас код читают лучше чем статьи :)
А я всегда думал, что сначала надо обкатать модуль на нескольких проектах, сложнее TODO List. Стабилизировать и только потом идти в сообщество в поиске фидбека и контрибьютеров.
При работе с готовыми gui компонентами. Например material ui, есть проблема, была раньше, чексум из-за вендорных префиксов. На сервере их не было, на клиенте были, в связи с этим суммы не сходились.
arusakov, Я понимаю что с места этот барьер будет тяжело взять. Я к этому не призываю. И сам недавно столкнулся с похожей проблемой.
Но на мой взгляд это не повод опускать руки. Скорость с которой браузеры вводят поддержку новых фич, не говоря уже о ES2015, заставит разработчиков, подобного рода инструментов, подтянуть свои продукты под современные реалии. Иначе придет кто-то новый, более адаптированный.
Например у Uglifyjs есть экспериментальная ветка harmony, как раз нацеленная на поддержку ES6.
В данный момент, я решил пробовать разработку без babel на небольших внутренних проектах. Где можно принебречь некоторыми вещами, например Uglifyjs.
Async/Await в javascript. Взгляд со стороны
Все развивается ;)
React, Web Components, Angular и jQuery — друзья навеки. Универсальные JavaScript-компоненты
Из своего опыта знаю, что лучше наоборот писать компоненты или какие-то не большие библиотеки на VanilaJS. А для фреймворков писать уже адапторы, если это необходимо.
Хотя ваша мысль мне то де нравится, но как и с любыми решениями такого рода, наверняка есть свои подводные камни.
ReactJS: отказ от JSX с сохранением удобства
Касательно BEMJSON, возможно, когда-то смотрел, но лично дело не имел.
ReactJS: отказ от JSX с сохранением удобства
Во-первых, на мне кажется, что увеличивается возможность допустить ошибку
Во-вторых, да же на среднем мониторе будет сложно это просматривать. Возможно кровотечение из глаз и поломку мозга
Redux Action Creators. Без констант и головной боли
Мне кажется у всех могло бы возникнуть меньше вопросов или более конкретизированные.
Плюс многие из нас код читают лучше чем статьи :)
Redux Action Creators. Без констант и головной боли
Для чего вообще нужна изоморфность?
Async/Await в javascript. Взгляд со стороны
Async/Await в javascript. Взгляд со стороны
Async/Await в javascript. Взгляд со стороны
Но на мой взгляд это не повод опускать руки. Скорость с которой браузеры вводят поддержку новых фич, не говоря уже о ES2015, заставит разработчиков, подобного рода инструментов, подтянуть свои продукты под современные реалии. Иначе придет кто-то новый, более адаптированный.
Например у Uglifyjs есть экспериментальная ветка harmony, как раз нацеленная на поддержку ES6.
В данный момент, я решил пробовать разработку без babel на небольших внутренних проектах. Где можно принебречь некоторыми вещами, например Uglifyjs.
Async/Await в javascript. Взгляд со стороны
Async/Await в javascript. Взгляд со стороны