Наверно, стоило применить известную практику, которую я использовал в других постах о фреймворке "код для привлечения внимания", которую я, как оказалось, ошибочно считал неэффективной. В следующих постах исправлюсь.
Я постарался очень кратко и лаконично объяснить, без излишних разглагольствований, в чем плюсы фреймворка. Дальше посетитель, если пожелает, изучит методы, примеры и прочие материалы (в меню есть ссылки на статьи на хабре) и сделает вывод.
Какие задачи? Это главный вопрос — для чего пригоден, а для чего не пригоден Ваш фреймворк. Ответа процитированное не дает.
Это фреймворк общего назначения для веба. Имеются в виду задачи, которые встречаются при разработке одностраничных веб приложений: работа с DOM элементами и данными. Основная сложность, которая возникает у начинающих программистов — это зависимость одного от другого, другого от третьего и пр.
Меньше ошибок в коде
С опытом разработик начинает писать код без ошибок, а Matreshka.js ускоряет этот процесс за счет того, что связывает одно с другим. Один раз задали правило "первое зависит от второго" и забыли. Это звучит очень абстрактно, посмотрите этот ролик. Он немного устарел (linkProps переименован в calc), но, в целом, отвечает на ваш вопрос.
Эта возможность есть всегда и везде
Скажем, если вы всё переписываете на Реакт, то придется переписать всё, без исключения. Иначе жизнь превращается в боль (по опыту знаю).
Вы уверены, что не выдаете желаемое за действительное?
Это не я сказал. Пользователи фреймворка раз документацию к фреймворку называли "лучшей документацией среди всех фреймворков".
Каждые несколько лет «ломать» можно, иначе накапливается критическая масса недоразумений, которые отталкивают и старых и потенциальных новых пользователей. Это касается любого open source проекта.
И да, пардон за рекламу, именно для заполнения пропасти между говнокодером-jQuery-стом и взрослым разработчиком с современным тулчейном, я работаю над второй версией фреймворка Matreshka.js.
По своему опыту, могу сказать, что те, кто себя иенуют фул-стек разработчиками, не имеют никакого представления о современных практиках разработки фронт-енда. Максимум, что они могут — это поработать со стилями и сделать что-то небольшое с помощью jQuery. В этом нет ничего плохого, просто при найме нужно учитывать эти реалии.
А если какой-то мудак на улице за трубки дёрнет? Сам знаю, что такое трубки в туловище (Бюлау), и ходить рядом с людьми достаточно ссыкотно, скажу я вам.
Пост был бы намного полезнее, если бы не заставлял устанавливать СУБД себе на комп, и результат транзакций (содержимое json файла) можно было бы изучить прямо из статьи.
Взгляните, что генерирует Babel. Если разобрать _asyncToGenerator, там есть неоптимизируемый try..catch. Но это полбеды, посмотрите, во что превращается безобидный код. Попробуйте разобраться, сколько лишнего всего происходит при использовании async/await: конвертация в генератор, вызов вот этой функции (изменение proto налету, ага), вызов вот этой (и всего, что в ней находится). Вы по-прежнему хотите это на сервере? Мы вроде-как наоборот стараемся ускорить приложения на ноде, ну да ладно.
Бабель-фуябель генерирует неоптимизируемый V8 код и это, очевидно, может заметно негативно сказаться на производительности. Пока в движок не будет добавлен синтаксис async/await, во фреймворке нет смысла (не свитая небольших проектов "для души").
Окей, я даже немного растерялся. Webpack, Browserify, Systemjs, Reflow (пусть меня поправят, если я что-то упустил) не требуют никаких "библиотечек для модулей". Только бандл проекта, использующего RequireJS требует библиотеку, имплементирующую AMD, например Almond (это всего 1К оверхеда), и то, даже с этим древним бандлером можно воспользоваться не менее древним AMD Clean. Ваши знания явно немного устарели.
Под конец, в спешке, белиберду написал, сорри. Перефразирую: юзеры так считают, не я.
Наверно, стоило применить известную практику, которую я использовал в других постах о фреймворке "код для привлечения внимания", которую я, как оказалось, ошибочно считал неэффективной. В следующих постах исправлюсь.
Я постарался очень кратко и лаконично объяснить, без излишних разглагольствований, в чем плюсы фреймворка. Дальше посетитель, если пожелает, изучит методы, примеры и прочие материалы (в меню есть ссылки на статьи на хабре) и сделает вывод.
Это фреймворк общего назначения для веба. Имеются в виду задачи, которые встречаются при разработке одностраничных веб приложений: работа с DOM элементами и данными. Основная сложность, которая возникает у начинающих программистов — это зависимость одного от другого, другого от третьего и пр.
С опытом разработик начинает писать код без ошибок, а Matreshka.js ускоряет этот процесс за счет того, что связывает одно с другим. Один раз задали правило "первое зависит от второго" и забыли. Это звучит очень абстрактно, посмотрите этот ролик. Он немного устарел (linkProps переименован в calc), но, в целом, отвечает на ваш вопрос.
Скажем, если вы всё переписываете на Реакт, то придется переписать всё, без исключения. Иначе жизнь превращается в боль (по опыту знаю).
Это не я сказал. Пользователи фреймворка раз документацию к фреймворку называли "лучшей документацией среди всех фреймворков".
В сорсах фреймворка, конечно же, используется import, вместо require.
За две минуты вряд ли что-то можно понять.
И нигде не написано о светдом будущем. Это фреймворк для новичков, не более.
Разве ES 2017 уже приняли?
Пост был бы намного полезнее, если бы не заставлял устанавливать СУБД себе на комп, и результат транзакций (содержимое json файла) можно было бы изучить прямо из статьи.
Т. е. ~50K за полгода (100К в год, ~8К в месяц), всего лишь в два раза больше, чем зарплата программиста в Украине. Не густо.
Взгляните, что генерирует Babel. Если разобрать _asyncToGenerator, там есть неоптимизируемый try..catch. Но это полбеды, посмотрите, во что превращается безобидный код. Попробуйте разобраться, сколько лишнего всего происходит при использовании async/await: конвертация в генератор, вызов вот этой функции (изменение proto налету, ага), вызов вот этой (и всего, что в ней находится). Вы по-прежнему хотите это на сервере? Мы вроде-как наоборот стараемся ускорить приложения на ноде, ну да ладно.
Бабель-фуябель генерирует неоптимизируемый V8 код и это, очевидно, может заметно негативно сказаться на производительности. Пока в движок не будет добавлен синтаксис async/await, во фреймворке нет смысла (не свитая небольших проектов "для души").
Окей, я даже немного растерялся. Webpack, Browserify, Systemjs, Reflow (пусть меня поправят, если я что-то упустил) не требуют никаких "библиотечек для модулей". Только бандл проекта, использующего RequireJS требует библиотеку, имплементирующую AMD, например Almond (это всего 1К оверхеда), и то, даже с этим древним бандлером можно воспользоваться не менее древним AMD Clean. Ваши знания явно немного устарели.
Пост на Хабре предполагает наличие технических подробностей. Эта статья будет отлично смотреться на Мегамозге.