Когда JavaScript-фреймворк не нужен

Наверное стоит понимать, что все эти фреймворки появились не просто так. А потому что в браузере DOM API корявое и убогое. И кривое оно, потому что такова была эволюция браузеров. Да пытаются сейчас исправить, улучшить. Но поломать легче сейчас, чем впилить что-то разумное. На сегодняшний день API очень далеко от совершенства. Поэтому мы видим изобилие фреймворков, как от корпораций, так и собственных.

Каждый из них, позволяет делать разработку легче и быстрее. Если вы попробуете сделать сайт на нативном JS, то рано и поздно, но у вас скопится огромная куча повторяемого кода, и вы изобрете собственный велосипед фреймвор, что бы легче, что бы не повторятся.

Но все эти улучшения не даются просто так. Жервой будут размер бандла, перформанс, пожирание памяти. Все то, что мы имеем сейчас.

Сможем ли мы исправить в ближайшее время ситуацию — думаю нет. Откажемся ли мы от фреймворков — нет конечно, не откажемся. Сделать API лучше, не получится. А кодить в приятных абстракциях и структурах хочется.

Так что же делать? В первую очередь думать головой и применять те инструменты, которые нужны. Искать золотую середину.

Как улучшить ваш API сервис на node.js. Часть 1

Статья и заголовок расходятся в значениях. Из заголовка, я ожидаю прочитать что-то, что поможет мне улучшить мой API сервис (application public interface). Т.е предполагается, что сервис как бы у меня уже есть и пара советов, таких, которые бы помогли бы улучшить стабильность и нагрузку, или дельные советы по REST итд, я бы нашел в статье.

Но увы, статья о банальном «starter kit». И ничего общего с API не имеет.

Рекомендую переименовать статью, типа «NodeJS Starter Kit для новичков». Это бы помогло понять о чем действительно идет речь.

7 рекомендаций по повышению надёжности JavaScript-кода

Одна из причин, почему появились «arrow functions», это потеря контекста. И именно их рекомендуют использовать, как callback функции.

В вашем примере необходимо использовать:

class Person{
  constructor(name){
    this.name = name;
  }
  logName(){
    console.log(this.name);
  }
}

let p = new Person('Ivan');

btn.addEventListener('click', (e) => p.logName()); // нет магии, нет привязки.

Плюс, повышается читабельность кода.

7 рекомендаций по повышению надёжности JavaScript-кода

Одно дело собеседование, где можно блеснуть знаниями, как это работает и что это за такой синтаксический сахар «class» в JS. И совсем другое дело, так делать в реальном проекте.

7 рекомендаций по повышению надёжности JavaScript-кода

Итак по пунктам

1. Фабричные функции.
В чем приимущество перед классами? Не писать new? Как делать extends? Различать по типу? И в чем проблема связываться с классом? В общем, давайте без фанатизма. Против фабричный функций ничего не имею против, но всему свое место. Не надо это лепить куда попало.

2. Прототип.
Ну ребят, ES6 не вчера же появился, и даже не позавчера. А вы продолжаете это лепить. Откройте для себя уже «class» в конце концов. Даже если вас заботит поддержка старых браузеров, то и TS и Babel давно уже могут собрать ваш код в ES5.

PS Да, классы не отменяют того, что вы должны понимать как работают прототипы под капотом и как работает наследование в JS.

7. Откройте для себя схемы и валидацию данных. Это избавит вас от ручной манипуляции. Посмотрите, к примеру, подход MongooseJS. Как там объявляются и валидируются данные.

Совет для новичков. Не стоит эти советы принимать к работе. Ознакомится — да, но не более.

5 рекомендаций по написанию качественных стрелочных функций

Небольшие ремарки по коду.

— Зачем объявлять проперти объекта как строка? Это не JSON файл. Убираем строку и получаем

array.map(number => ({ number: number }))

— Используем возможности ES6 и переписываем строку выше

array.map(number => ({ number }))

— На дворе уже 2020 год можно и не использовать цепочки вызовов в промисах.

myButton.addEventListener('click', async () => {
  let response;

  try {
    response = await fetch('/items.json');
  } catch (err) {
    // do something to check err
    console.log('error ->', err);
    throw err;
  }

  response = await response.json();

  console.log(response.name);
});

[По докам] Flutter. Часть 4. Для веб-разработчиков

Думаю, что Flutter вам стоит рассматривать как браузер. Только вместо браузера у вас Flutter приложение. И вместо веб странички вы делаете приложение на Dart/Flutter. А вот остальные коммуникации — теже самые подходы. Регистрация, авторизация (JWT), проверка входящих данных, права доступа, формирование ответа итд итд итд — все это будет тоже самое, что и для веба, ну конечно в рамках вашего приложения.

Мне конечно сложно оценить ваше приложение и его возможности. Поэтому я написал выше изходя из своего опыта.

[По докам] Flutter. Часть 4. Для веб-разработчиков

Вам скорее всего надо для себя понять, что для вас база данных. Если вам достаточно хранить конфигурацию приложения и токены, то подойдет LocalStorage. Это обычное key:value хранилище.

Если что-то поболее, к примеру какие нибудь записки, чек листы итд, что не подразумевает больших данных и они служат только для пользователя и не для шаринга другим пользователям. Смотрим на SQLite, SQLCipher. Я больше чем на 100% что для таких вещей SQLite просто за глаза.

Ну и если подразумевается работа с данными у пользователя, не только в приложении, а и, к примеру, из веб странички. Или же это лента новостей или общий чат для пользователей или общие данные для покупателя/продавца. Здесь вам уже понадобится отдельный сервер, логика приложения и база или может быть базы данных. Но это уже другая история, как делать серверные приложения. И тут информации для нескольких книг наберется, а не для коммента здесь.

Удачи!

Новый год, новый браузер: Microsoft Edge вышел из стадии предварительной оценки и теперь доступен для загрузки

Никогда не был фанатом майкрософта. Но то что они сделали, у меня лично вызывает респект. Я очень надеюсь на вклад в Chromium сообщество от майкрософта. А еще больше рад, что IE таки умрет и больше не надо будет думать, о поддержке старых версий.

Ну и классная фишка — интерграция со своими продуктами.

Действительно ли нам нужен TypeScript в 2020?

У них в описании указано, что можно указать, что использовать. По умолчанию ExpressJS, но так же можно указать Fastify.

Under the hood, Nest makes use of robust HTTP Server frameworks like Express (the default) and optionally can be configured to use Fastify as well!

Хороший подход :)

Действительно ли нам нужен TypeScript в 2020?

Посмотрел NestJS по приведенному линку. Они используют такой же подход для написанию контроллеров, который я сделал у себя. Правда у меня это только обертка над ExpressJS. Но приятно, когда взгляды у людей совпадают :)

Действительно ли нам нужен TypeScript в 2020?

Да, они самые :)

Действительно ли нам нужен TypeScript в 2020?

Не соглашусь с автором. Да, признаюсь я был таким же как автор, и с такими же взглядами. Когда появился TS я был против. Ну зачем, зачем еще какие-то надстройки? Если вы хороший разработчик, вам TS не нужен. Я действительно так думал и говорил.

Но пару лет назад я начал писать на TS, понемногу. Где-то с ошибками, где-то тупо в лоб с any. И сейчас, спустя два года, я полностью перешел на TS. На вопрос — почему, почему я кардинально изменил свои взгляды и мировозрение? Ответ прост — это просто удобно и приносит свои плоды. И сейчас я все свои проекты перевожу с JS на TS.

Самое большое удобство — это читаемость кода. Да, когда ты работаешь в команде из 10 человек. То понять код товарища — ой как сложно. И TS помогает понять и проанализировать что к чему. Следующее удобство — IDE. Приятно иметь быструю навигацию по проекту с подсказками и проверками. Поверте, для больших проектов это неоценимо.

Так же добавлю, что TS это не новый язык, это все тот же JS просто добавлено немного контроля. И это помогает держать в голове логику, а не вспоминать где какие аргументы принимает функция.

По поводу читабельности кода. Приведу контроллер со своего TS проекта. Так как, то что привел автор — фигня какая-то.

@Injectable
@Controller()
class Word extends AppController {

  @Auth('user')
  @Get('/get/:id')
  async get(@Req() req: Request, @Param('id') id: string): Promise<IWord> {
    return await WordModel.getByUser(req.user, id);
  }

  @Auth('user')
  @Delete('/remove/:id')
  async remove(@Req() req: Request, @Param('id') id: string): Promise<IWord> {
    const word: IWord = await WordModel.getByUser(req.user, id);

    await word.remove();

    return word;
  }

}

export {
  Word
};

Axios или Fetch: чем пользоваться в 2019 году?

Много лет использовал axios как основную библиотеку для запросов из браузера. Но в последнем проекте решил, что тянуть огромную либу в проект только для запросов не разумно.

В итоге написал обертку class API над fetch. Все красиво завернул в async/await, плюс обработка ответа и перехват ошибок. В итоге вышло чуть более 100 строк кода на TS. Что совсем ничего, по сравнении в кодом axios.

Так что думаю, имеет смысл переходить на нативный функционал. Да, пришлось немного допилить, что бы вот совсем хорошо было. Но доработка минимальна.

PS Что касается загрузки файлов и показа прогресса. В данном кейсе пришлось написать обортку над XMLHttpRequest. Увы…

Использование полифиллов при написании кросс-браузерных приложений

Однажды я работал в одной биллинговой конторе. Не суть имя конторы. Так вот. Софт у них был написан еще в начале 2000-х. Причем фронт был заточен только под IE. Причем, под IE 6-7 версии. На 8-ке уже глючило. Софт не маленький и за эти годы было написанно тонные кода.

Когда я пришел туда, и копнул код. Я был в ужасе. Конечно я пришел с предложением переписать код, как многие до меня. Так как оддерживать сие — боль. Да и о новых фишках можно было и не думать.

И ответ топ менеджмента — Дима, у нас нет бюджета и времени на переписание фронта. Мы не можем выделить команду на полтора два года, для этого. Да и в чем смысл для нас? Клиенты покупают, мы продаем — все овольны. Какой профит принесет переписанный фронт допустим на Реакт?

И если подумать — а профита особо и нет для клиента. Увы.

Так что не все зависит от программистов. У него свои рамки и приходится выкручиваться и саппортить ненависный IE.

Использование полифиллов при написании кросс-браузерных приложений

Что касается полифилов. То лучше использовать webpack, который будет компилировать ваш ESNext to ES5. А уже скомпилированный бандл подключать в приложение.

По крайней мере проблему flat и Promise вы бы точно решили.

Элегантные паттерны в современном JavaScript (сборная статья по циклу от Bill Sourour)

Спасибо, забрал себе в копилку выброс исключения для аргумента функции. Интересное решение, не знал о нем. Обычно в самом коде проверял.

Делаем интерфейс более отзывчивым благодаря отложенному Promise

Что касается ошибки промиса, то его всегда можно поймать в «catch» и уже обработать. Показать сообщение об ошибке/сделать редирект/итд.

Что касаемо отмены промиса. То здесь работа не для промиса, а для самого реквеста. XMLHttpRequest/fetch позволяют вызвать cancel запроса. Промис, он служит для ожидания выполнения.

Как Яндекс научил меня собеседовать программистов

Я где-то выше написал, что непонимаю промисов и как они работают? Или я не знаю, что asyn/await это всего лишь сахар?

Еще раз повторю — код на промисах и код на async/await — это два разных вида написания кода. И второй вид, более простой и читабельный. Если человек написал выполнение кода с async/await, с моей точки зрения это только плюс.

Как Яндекс научил меня собеседовать программистов

Скажите, а почему на беке именно важны промисы. Вот прям так, что бы на них писать код.

Я к тому, что NodeJS давно поддерживает async/await. А для более старых версий, код всегда можно прогнать через babel и получить поддержку. А если у вас typescript, так в конфиге указали, какая поддержка ES вам нужна, и радуетесь.

Соглашусь, понимание должно быть. Но вот что бы промисы были в приоритете — для меня звучит странно.

PS Я знаю как работают промисы, даже когда-то делал полифил для IE, что бы получить поддержку в ослике. Но когда появился async/await это же как глоток свежего воздуха.