Как стать автором
Обновить
0
@bjorndread⁠-⁠only

Пользователь

Отправить сообщение
Лично я их не ищу, я только работаю с результатами поиска. И результаты эти удручают даже для Angular и React, не говоря уже о Vue.
Расскажите бизнесу, что вы хотите лишить его единственной возможности мгновенно доставлять клиентам практически любой функционал и контент. Просто потому что вам сложно. Бизнес поржет, уволит вас и наймет того, кому не так сложно.
А теперь попробуйте найти разработчиков в свой проект на React/Angular/Vue.
Мое отношение простое. Разработчиков на и на React то днем с огем не сыщешь, а уж на Vue и подавно.
Они понятны, в них легко разобраться, но выглядят хуже чем например вот так: ...

Этот пример в моем коде выглядел бы вот так:
const ChildClass = this.state.something ? MyChildComponent : MyOtherChildComponent;
return (
  <div>
    <div class="layout-8">
      {children.map(c => <ChildClass {...myChildProps} />)}
    </div>
  </div>
);

Вообще правильное разделение логики представления и бизнес-логики позволяет оставить в render-методах компонентов только базовые if и for, что как раз соответсвует семантике vue-шаблонов, о чем и был мой первоначальный комментарий.

PS: условие if спрятанное где-то в центре блока кода читается просто ужасно.
Не понимаю в чем критическая разница между:
<ul>
  <li v-for="(item, index) in items">
    {{ parentMessage }} - {{ index }} - {{ item.message }}
  </li>
</ul>

и
<ul>
  { items.map( (item, index) => <li>{parentMessage} - {index} - {item.message}</li> ) }
</ul>

Ember.js — пробовал и настоятельно не рекомендую. Можно быстро сделать типовой проект, но развивать и кастомизировать — сущее наказание. Взять к примеру ember-data, модуль htfkbpe.obq абстракцию доступа к данным. С первого взгляда все хорошо — следуем определенным стандартам API на сервере и все данные, даже связанные, у нас легко и просто доступны на клиенте. Но копнуть чуть глубже и оказывается, что даже такая простая вещь как откат изменения связи объекта реализуется костылями или monkey-patching'ом.
Но в чем смысл? Почему не написать просто на JS? Это что сильно труднее?

Более-менее сложные SPA или web-компоненты, написаные просто на JS очень сложно поддерживать и практически невозможно развивать. React, Vue и дргуие инструменты позволяет применяет более-менее декларативный подход при написании front-end, что существенно сокращает затраты на развитие проекта, поддержку, тестирование.
Глупая фраза с указанием неверного авторства — лучший аргумент в любом споре.
Это – одни из самых популярных JavaScript-библиотек в мире. Взгляните на этот список, посмотрите их репозитории на GitHub.

Я бы рекомендовал смотреть на более объективные источники, например реальные опросы большого количества людей
Если в том объеме, что сейчас, то нормальному фрилансеру, это было бы часов так 30 и стоимость максимум в $1000

Чтобы найти нормального фрилансера нужно попытки 3, а если не повезет, то и больше.
У нас у соседа по дверью нагадили. Мы, разработчики браузера Vivaldi, ни у кого под дверью не гадим. Качайте браузер Vivaldi.
То есть REST с авторизацией на основе скажем http-сookies это сразу сервис?
Да, но и для Cordova это тоже верно.
splash-screen показывается системой во время загрузки и инициализации приложения, поэтому привычных компонент еще нет
React Native позволяет создавать проекты которые обладают несколькими важными качествами. Во-первых на выходе получаются приложения которые выглядит и работают как нативные. Почему нативные приложения лучше объяснять думаю не стоит. При этом основную логику отображения и бизнес-логику дублировать не приходится как в схеме с независимой кодовой базой для каждой платформы. Критичные же для производительности или с точки зрения платформы вещи, как-то сложные вычисления, получения GPS-координат устройства или отображение splash screen'а, придется реализовать нативно для каждой платформы.

В вашем случае действительно не было никаких предпосылок использовать React Native. Писали вы только для Android, а большая часть функционала приложения состояла из сложных вычислений.
Автор не обижайтесь, но получилось примерно следующая ситуация.

Так ли хорошо микроскоп?

Микроскоп довольно новая технология, которая с первого взгляда кажется серебряной пулей для многих начинающих забивателей гвоздей. И так по порядку, я — закручивальщик шурупов широкого профиля, опыта забивания гвоздей до этого не было. Опробовать микроскоп я решил для забивания гвоздя сотки в березу растущую у нас во дворе. Береза красивая, высокая и зеленая. На этом вступительная часть закончена, перейдем собственно к забиванию.

Подготовка у забиванию гвоздей микроскопом почти такая же как и при закручивании шурупов шуруповертом. Главное правильно покрутить управляющие элементы, крутятся они примерно так же, так что больших проблем нет, хотя есть нюансы. Логика забивания гвоздя заключалась в одном простом действии — нанесении одного сильного удара по гвоздю микроскопом. Пару раз я промахнулся и по гвоздю не попал, пару раз попал, но гвоздь погнулся, в итоге взял камень лежащий рядом и загнал гвоздь в дерево по самую шляпку.

По моему мнению, микроскоп не годится в текущем его состоянии для забивания гвоздей. Основные факторы — плохо лежит в руке и недостаточно тяжелый. По итогу если вам нужно закрутить шуруп используйте шуруповерт, если хотите срубить дерево то тут подойдет топор. С топором дерево удалось повалить за 30 минут.
Недовольных try/catch и switch/case блоками в подавляющем большинстве случаев можно заткнуть простой цитатой Кнута:
«We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%»
Происходит катастрофический недостаток кадров, вызванный взрывным ростом индустрии.
Если все-равно нужно подставлять свойство type=«application/pdf», почему просто не подставить class=«link_pdf» и не выдумывать всяких трюков с CSS-селекторами?

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность