• В честь 8 марта дарим бесплатные переводные татуировки для девушек-айтишниц
    +1
    Чтобы быть военнообязанным, в РФ не обязательно нужно служить.
  • Рейтинг языков программирования 2021: доля Python падает, а TypeScript обошел С++, в лидерах JavaScript, Java, C#
    0
    В Firefox, к примеру.
  • Как создавался отечественный браузер с боковыми вкладками на HTML5
    0
    Вкладок очень много и в классическом варианте они нечитаемы

    Когда в FF вкладки перестают влезать, панель вкладок начинает прокручиваться. А минимальный размер конфигурируется стандартными средствами.
  • Что не так с WebAssembly?
    +1
    Почему его должно быть больше? Это же обертки над API и всякие бутстраперы WASM-модулей, а логика делается на чем-то WASM-совместимом.
    К примеру, у Yew (web_sys) бутстрапер в ~16Кб неминифицированного кода, благодаря чему хэлловорд в сборе выходит меньше размером, чем голый реакт.
  • Как меня чуть не уволили за выбор React для корпоративного приложения
    +1
    на поставленные вопросы вы так и не ответили.

    На все поставленные вами вопросы вроде бы ответил прямо или косвенно. Давайте еще раз:

    Сколько итераций потратите на реализацию этой дизайнерской задумки?

    Тут вы число ждали? Вслепую оценивать объем работ как-то странно.

    Что делать с остальными 40%?

    Искать более подходящий компонент или форкать имеющийся.

    можно построить архитектуру так, чтобы:

    Предлагаемый подход с патчингом удовлетворяет лишь крайнему пункту.
  • Как меня чуть не уволили за выбор React для корпоративного приложения
    +1
    вам надо в конкретном приложении сделать, чтобы иконки фалов увеличивались при наведении на имя файла. А компонент этот поддерживаете вообще не вы.

    Предлагается изменить внутреннее поведение компонента. Если так, то логичнее было бы его в самом деле форкнуть и наделить необходимым функционалом, а не патчить результат извне. Не факт, что будет дороже, но 100% — надежнее.

    Форкать, вставлять костыли и поддерживать их при каждом обновлении?

    Внедряясь во внутреннюю структуру разметки и стилей так же никто не сможет гарантировать, что при следующем обновлении все не поломается.
  • Как меня чуть не уволили за выбор React для корпоративного приложения
    0
    В разных контекстах необходимо менять разные особенности визуализации компонента.

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

    А просовывание классов ломает саму идею компонентного подхода — оборачивающий код жестко завязывается на низкоуровневую специфику отображения своего дочернего компонента.

    За примерами можете посмотреть любой более-менее матёрый компонент.

    Матерые компоненты (DevExtreme, к примеру) имеют богатые настройки отображения через параметризацию, хотя и поддерживают передачу css-классов в некоторых местах.
  • Как меня чуть не уволили за выбор React для корпоративного приложения
    0
    необходимость ручного прокидывания: классов для стилизации

    Но зачем? Стилизация компонентов — ответственность самих компонентов, а возможная вариативность — это часть явного интерфейса компонента, которой в пропсах самое место. Да и то, не факт, что там нужны именно CSS-классы, а не флаги или другие высокоуровневые параметры.
  • Что не так с WebAssembly?
    +1
    Контринтуитивные правила приведения типов, баги, которые они вызывают и противостоящий им код (который параноидально явно приводит типы).
  • Что не так с WebAssembly?
    +2
    Сейчас есть гора костылей, любовно наслаиваемых десятками лет, от которых все с радостью бы избавились, если бы не обратная совместимость.
  • Что не так с WebAssembly?
    +1
    При обращении по невалидной ссылке уже сейчас JS умеет падать с TypeError, почему вдруг ошибка типа в выражении должна устраивать глобальную катастрофу с белым экраном?
    А так — да, это позволило бы повысить качество.
  • Что не так с WebAssembly?
    0
    Это никак не отменяет необходимость валидации данных между сервером и клиентом.

    Это был лишь один пример. Контракты могут быть разломаны локально, проявляться в более хитрых случаях и все так же далеко уплывать, пользуясь «преимуществом» слабой типизации.

    Всякие сложные штуки вроде google docs в расчет не берём, это совсем другая лига

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

    речь про всякие «Access violation reading location», которые переодически возникают.

    Если считать это обращением к невалидному/нулевому указателю, то в подобном случае и выполнение JS-скрипта так же отпадает.
  • Что не так с WebAssembly?
    +1
    речь про UI, какая там бизнес логика?

    У нас тут за окошком 2к21 с SPA и прочими serverless во фронтенде.

    Там же и видно как это реализуется на практике – приложение закрывается целиком, предлагая отправить сообщение об ошибке.

    Вот бы все браузеры падали с сообщением об ошибке, когда пользователь ошибся в домене)
  • Что не так с WebAssembly?
    +3
    Преимущество в том, что система работает непредсказуемо?)

    пользователь увидит NaN

    Благо, если NaN только в интерфейсе отобразится, а не пойдет дальше под капотом ломать инварианты и шатать бизнес-логику, суля занимательными часами/днями отладки в поисках причины сломанных данных в системе.

    А в случае сильной типизации случится рантайм ошибка и сломается вообще всё.

    Скорее отлавливаемое исключение (или аналогичная технология обработки ошибок), позволяющее корректно себя обработать или хотя бы показать милое сообщение об ошибке и отправить лог разработчику. Если восстановление работы возможно (и имеет смысл) или затронута лишь незначительная часть приложения/сайта, никто не мешает продолжить работу. Вместо NaN можно написать что-то более осмысленное, например.
  • Что не так с WebAssembly?
    +1

    Только шарпы ведь специально в wasm не компилят, а затаскивают реализацию виртуальной машины, которая исполняет обычный байткод дотнета. Из ощутимых проблем — это увеличивает размер бандла, хотя код рантайма отлично кэшируется.

  • Что не так с WebAssembly?
    0
    JS все еще передается и компилируется из высокоуровневой текстовой формы. WASM компактнее и сразу готов к исполнению.

    С поправкой на то, что WASM должен быть готов к исполнению JS (встроена стандартная библиотека, GC и т.п.).
  • Что не так с WebAssembly?
    +3
    В веб-фреймворках под WASM обычно реализованы обертки с интеропом под капотом, чтобы у пользователя не было нужды вылезать из привычной технологии. А тот же Razor для C# вовсе заточен на создание интерфейсов.
  • Что не так с WebAssembly?
    +2
    есть фреймворки типа реакта или вью, удобный процесс отладки, декларативно-реактивный подход

    Blazor и Yew эксплуатируют React-подобный подход с XML-подобным синтаксисом и реактивностью. Первый из коробки отлаживается прямо в девтулзах хрома.

    тайпскрипт, который устранил единственный js-ный недостаток — отсутствие типизации.

    В рантайме типов нет, а слабость типизации все так же присутствует.
  • Фронтендеры — герои. Yehuda Katz объясняет почему
    0
    В чем проблема сделать новое браузерное API, если обратная совместимость нас не тянет? Это как раз тот случай, когда можно и нужно. Легаси продолжит использовать интероп, ибо и сам JS сразу никуда не планирует исчезать из браузеров.
  • JS и его запретные тайны
    0
    Всегда запускается параллельно интерпретация и компиляция

    И интерпретация, и компиляция требуют парсинга JS-сорцов.

    И JS, если не использовать некоторые редкие особенности

    for-in, например, достаточно редок? Ведь любое метапрограммирование плохо оптимизируется.
  • JS и его запретные тайны
    0
    На холодную — чуть чаще, чем всегда.
    Да и динамическая природа JS не то, чтобы располагает к оптимизациям (не просто так идея куцего ASM.js появилась в свое время).
  • Таблицы и CSS-свойство float в современной веб-разработке
    +9
    TL;DR: <table> и float можно использовать в тех целях, для которых они изначально и задумывались.

    Гениальная идея для статьи!
  • JS и его запретные тайны
    0
    При прочих равных откомпилировать низкоуровневый байткод будет быстрее, чем сорцы скриптового языка.
  • # Стоит ли связываться с C#
    +1
    что мешает написать сигнатуру навроде

    Передача структуры в метод по значению (копирование).

    И плевать, что мог быть структурой — мы всё равно сделаем сигнатуру, которая всегда будет требовать боксинга.

    Все стандартные коллекции (включая массивы) .NET — референсные типы. Кейс с коллекциями-значениями имеет право на существование, но преувеличивать их значение в типичных сценариях использования C#, имхо, не стоит.
  • # Стоит ли связываться с C#
    +3
    О каком стирании типов речь? Сам интерфейс LINQ статически типизирован, а .NET поддерживает дженерики в рантайме (в отличие от JVM, где параметры-типы затираются).
  • # Стоит ли связываться с C#
    0
    Не перестали) Это рассуждения уровня: «C# можно писать в VS Code, там классный IntelliSense». В студии таки начали появляться реафакторинги, но до R# она до сих пор не дотягивает.
  • # Стоит ли связываться с C#
    0
    О, благая весть, спасибо.
  • # Стоит ли связываться с C#
    0
    В VS испокон веков прикручивали R#, который в райдере, по сути, идет «из коробки». Единственное ограничение, с которым я сталкивался на практике — нет поддержки шаблонов T4, которые любят в легаси проектах.
    Про саму IDEA судить особо не могу, но она славится своими рефакторингами, которых у Rider тоже есть богато.
  • # Стоит ли связываться с C#
    +3
    Как минимум наличием нормальной IDE под Linux.

    Внезапно
  • Статистика зарплат Java-разработчиков: максимальные ожидания от зарплат в Москве, а джунам платят меньше всего в Самаре
    +1
    Сами проросли бы в обнимку с доступным дешевым интернетом. Неужели на огромный Новосиб не найдется десятка аутсорсинговых контор, радушных к способным к работе новичкам?
  • Введение в React, которого нам не хватало
    +2
    Ответ на это есть в документации. TL;DR.: реакт не знает, как правильно сравнивать объекты списка, чтобы отличить вставку/удаление/замену отдельных элементов от полной замены списка, чтобы понять: весь список перерисовывать или часть? Если часть, то какую? А так — ответственность за корректное хэширование элементов остается программисту, обо всем остальном заботится реакт.
  • Горячая четвёрка умирающих языков программирования
    +4
    На платформе .NET используется VB.NET. В нем отличий от VB гораздо больше, чем между VB и VBA.
  • Выбираем лучший бэкенд-фреймворк 2021 года
    0
    просто интерфейс портит

    Интерфейс портят ошибки в программе, а не инструмент, который их находит) Грамотную обработку ошибок с наличием исключений построить не сложно.

    и лезешь пытаешься воспроизвести проблему.

    И ведь сразу ясно, куда нужно лезть. Со слабой, да еще и динамической типизацией ошибка может дрейфовать в далекие дали и порождать спец.эффекты, вроде результата деления строк на цифры. Отладка будет печальна.
  • Выбираем лучший бэкенд-фреймворк 2021 года
    0
    там где PHP просто проигнорирует какой нибудь отсутствующий параметр, ASP ругнется и покажет ошибку.

    Просто прекрасно) Если эта ошибка приводит, скажем, к порче данных, то поиск причины рискует быть очень увлекательным.
  • Scala мертва?
    +4
    Здесь это подразумевается под TypeScript.
  • Выбираем лучший бэкенд-фреймворк 2021 года
    0
    Действительно плохо знаю. Но здесь речь идет о C#, которому, якобы, совсем не помогает строгая статическая типизация.
  • Выбираем лучший бэкенд-фреймворк 2021 года
    0
    Статически компилируемым же. В рантайме работает старый добрый JS.
  • Выбираем лучший бэкенд-фреймворк 2021 года
    +4
    это не мешало постоянно ловить баги в рантайме.

    Эксепшны)
    Чтобы ловить исключения уровня: «Ой, у объекта нет такого свойства!» в рантайме — нужно сильно постараться.
  • Выбираем лучший бэкенд-фреймворк 2021 года
    +2
    Какие-то выстраданные преимущества у Django. После каждого хочется спросить: это точно особенности, которыми он выгодно отличается от двух остальных?
  • JavaScript, Python или Go: что лучше всего подойдёт для бэкенд-разработки в 2021 году?
    0
    Появление гиктаймс — это попытка реанимации уже к тому моменту издохшего хабра. Такой себе референс к «изначальности».