Pull to refresh
-12
0
Send message
Вот, если честно, никогда не обращал внимания на эти вещи. И ни разу не пользовался ссылкой «skip to content», считая ее чем-то ненужным. А вот заголовок h1 (или какой-нибудь другой) непосредственно перед основным содержимым — это то, что я безо всякого сомнения ожидаю на каждой адекватной веб-странице.
На этой он, кстати, тоже есть. Так что фронтендерам хабра большой плюс! В отличие, например, от их коллег из яндекс почты, которые в принципе считают, что заголовки — это зло.
И еще хотелось бы, чтобы выходило больше статей о доступности мобильных приложений. Т.к. в вебе мало приходится наблюдать совсем плохо доступных сайтов, а на мобилках — сплошь и рядом, в т.ч. от крупных компаний.
Без двигателей на ядерном топливе, имхо, все это будет космически дорого и крайне небезопасно. А без превращения в рутину полетов земля — луна, земля — (луна) — марс ни о каком освоении не может идти и речи. Слишком много их нужно осуществить.
2. Возможно, с этим и боролись. Т.к. здесь у пакета появляется дополнительная зависимость в виде EventInterface. А для большей переносимости лучше, чтобы аспекты реализации не хранились в интерфейсе.
Во всяком случае их мысль я понимаю именно так.
А чего ему не хватает до «полноценности»? Общение с БД, файловой системой и отправка http запросов? Как бы это, в принципе, могло выглядеть, не нарушая принцип единственной ответственности?
Принцип единственной ответственности (The Single Responsibility Principle)
Каждый класс выполняет лишь одну задачу.


Т.е. должна быть сущность, хранящее состояние и сервис, который ею манипулирует.
ООП о данных инкапсулированных с поведением


Антисолид. Данные от логики управления ими лучше отделять.
Ну, golang, вроде как, на уровне бета-версии сейчас wasm поддерживает. Только ко 2 версии релизную обещают. Да и SPA при условии накладных расходов общения wasm с DOM смысла на нем нет делать.

Скорость старта — тоже важная характеристика. Байт код все-таки, наверное, быстрее парсится да и пространства под оптимизации поболе имеет.
Все равно не вижу ограничений.

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

Хотя я конечно больше говорил про SPA и какой-нибудь golang или ts в качестве языка разработки. И они, кстати, под формулировку «compilation
of high-level languages like...» тоже подходят, так что идеологии wasm, имхо, нисколько не противоречат.
WebAssembly это не швейцарский нож.


А тут я как-то не нашел слов, что wasm не предназначен для решения каких-то задач. Ну, и если wasm не подходит/предназначен для употребления в качестве универсального швейцарского ножа, то что тогда предназначено? JS что ли? :) Какие у него в принципе могут быть преимущества перед wasm, кроме проработанного окружения, конечно же.
На мой взгляд, кроме принципиальной возможности использовать на проде, важно какое количество проблем он готов решить. Т.е., если он по своей идеологии и уровню развития окружения будет подходить лишь для 0,25 процентов проектов, то говорить о том, что эта технология действительно взлетела и хоть сколько-то реализовала свой потенциал, не приходится.

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

Поэтому и интересно, является ли wasm частью чьих-нибудь «будней веб-разработчика». Потому что, на мой субъективный взгляд, в широкой практике его не видно вообще.
запуск WebAssembly за пределами веба


А что, в пределах веба он уже играет какую-то ощутимую роль? А то я за последнее время лишь парочку статей на хабре по практическому применению WebAssembly видел. И все они в духе «Да, технология перспективная. И у нас действительно что-то получилось. Но у нее еще есть ряд немаловажных ограничений.»
Так что складывается впечатление, что все об этом уже долго говорят и единодушно признают, что за этим будущее, а оно все никак не наступает, и когда наступит — непонятно.
Ну, «реактами» в итоге стали очень немногие, по пальцам одной руки пересчитать можно. А сколько умерло по дороге… Так что теория вероятности, наверное, все же не на вашей стороне. :)
А по багам по доступности какие-то действия будут? А то с моего репорта уже 2 месяца прошло, а там, по-моему, даже ответа нет. Или надо как-то иначе оформлять?
Югославия, Ирак, Афганистан, Сирия… Но это все ничего.
Кстати, Прибалтика-то тут причем? В свое время отпустили, как миленьких. Сейчас в ЕС и НАТО входит.
Отличная новость! Ждем интересных и животрепещущих расшифровок на хабре! :)

Лично меня очень интересует асинхронное программирование на PHP, т.к., по-моему, это наиболее узкое его место в сравнении с другими популярными бэкенд платформами.
От solid при таком подходе придется отказаться в первую очередь. А вообще, представляю эти «божественные объекты», хранящие в себе логику обработки запросов, обращения к бд и вывода. Вот уж гибкая, читаемая и прозрачная структура получится. :)
Имхо, логика все-таки должна быть разделена по слоям, и даже компонентный подход этому не противоречит. А MVC в свое время как раз и возник, как способ разгрести ту кашу, в которую очень быстро превращается реализация предлагаемого вами паттерна.
Впрочем, всему свое время и место, наверное.
они разбились о сложность
реального мира, и более неактуальны.


Как по мне, очень спорное и слишком категоричное утверждение. Может поясните?

В конце концов, MVC — это всего навсего способ организации обработки http запроса, и он нисколько не противоречит DDD. А, наоборот, чаще всего с ним сочетается.

Если MVC — это неправильная архитектура организации приложения, то как тогда в go надо? Чем он так принципиально отличается от всего остального back-end мира?
Ну, и учите, что вас смущает? Программирование, само по себе — классная штука! Куча всего интересного и каждый день что-то новое и т.д. Тут же статья про матерого разработчика, который, по сути, знает и умеет уже все, что ему нужно в повседневной работе, и весь процесс для него сводится к жонглированию н-ным количеством заранее известных паттернов. Да, такая проблема, безусловно, в какой-то момент возникает, как и десятки каких-то других, но решений у них слишком много, чтобы пренебрегать еще большим количеством плюсов и значительными возможностями.
В конце концов одной из наиболее интересных возможностей в программировании является то, что вы сами можете формировать свое рабочее окружение. Хотите — сидите в офисе с 9 до 6, хотите — работайте из дома, хотите — идите на фриланс, хотите — ищите себя в open source, работайте с заказчиками по всему миру, в любом стеке, в любой стране, в любой предметной области, в больших компаниях, стартапах, собственных проектах, за столом, в кафе, да хоть под кроватью, но везде за хорошие деньги. Т.к. спрос на хороших разработчиков всегда сильно превышает предложение. Так что найти для себя комфортные условия, или создать их, вряд ли можно где-нибудь проще, чем в ИТ.

Information

Rating
Does not participate
Registered
Activity