All streams
Search
Write a publication
Pull to refresh
11
Каспер Грин @KasperGreenread⁠-⁠only

Front-end developer, UI/UX, ReactJS

Send message

Понятно. prerender.io по прежнему в фаворитах. Он готовит страницу как браузер и может передавать её nginx прокси например для кеширования.


Это избавляет от жонглирования датастором и решает проблемы индексации. Google кстати в нём не нуждается и сам исполняет JS о чём prerender.io знает и ему лишний трафик не отдаёт.


Иначе двойной трафик получается. Вёрстку загрузи с датастором, потом бандл загрузи, датастор снова загрузи. И всё это время вместо favicon — кругляш загрузки.


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

[irony]
                    Если речь о зерне — оно
                    А если о напитке — он
[/irony]

Метод hydrate учитывает, что данные для рендера могут подгружаться асинхронно? С этим будет из коробки работать Redux?

Теперь во всём. Похоже я живу в мире иллюзий, но и в этом я не уверен. Как собственно и в том, что vintage не потомок Сима.

Ок. Если данные обновляются полностью, то ReactJS перерендерит всё, от App и ниже в своём виртуальном DOM, а результат вставит на место #ROOT_APP сделав всего одно обращение к реальному DOM. Разве не так?

Да, но если вас этих участков DOM изменилась тыща, то потребуется тыща обращений к DOM, а это — медленно.
React в этом случае всю тыщу изменений произведёт в виртуальном DOM, а в реальный сделает одну единственную вставку, что быстрее, т.к. в настоящий DOM будет всего одно обращение.

У меня 8 стадия похоже. Спасибо за статью. Пожалуй для меня уже поздно что-то менять :)


Раньше крайне подозрительно относился к ноде на бэкенде, а теперь просто подозрительно к этому отношусь. Считаю сабж слишком молодым, чтобы не обрастал детскими инъекция и и другими граблями, но потенциал есть.


Про многопоточность кстати всё не так плохо. Плохо конечно, но уже и прямой доступ к памяти есть, и кривоватая, но многопоточность на видяхах.


Уверен, что если нужна числодробилка с миллионом операций в секунду лучше использовать хорошие низкоуровневые языки, а всякий скрипт подойдёт для быстрого написания тормозного прототипа, который можно переписать на труёвый язык. Ты же уже полюбил переписывать код по несколько раз, %Юзернейм%?


Дорогой автор, мне нравится твой стиль изложения пиши ещё на тему веб-программистов в принципе. Мне кажется вебдевелоперы отдельная каста и часть советов для них не совсем подходят. Но это может быть я глупенький и не понимаю простых вещей в силу своего программисткого несовершеннолетия. Авось после 18 лет придёт озарение в мою голову, а пока учу JavaScript и совсем php забросил.

class ololo { 
  constructor() { this.hello = 'Привет';}
}
class hohoho extends ololo {
  toString() { return this.hello; }
}
let bathert = `${new hohoho}`;
console.log(bathert);

JS может всё, или Ruby может так?


class ruby {
 constructor() {this = 'Строка'}
}

JS второй пример не может

Вот все про это говорят, а кто нибудь может привести пример?

Лично сталкивался только с примером для SVG, но сферически могу предположить:


  • Балансировку нагрузки между клиентом и сервером;
  • Преобразования форматирования для вывода на сайте или отправки электронных писем с сервера;
  • Генерацию\верификацию открытых\закрытых ключей;
  • Можно рендерить страницы на сервере и отправлять в IPFS;
  • Писать проверки данных на клиенте и использовать тот же код на сервере, чтобы не дать клиенту на эти проверки повлиять, но не плодить запросы к серверу;
  • Давать клиентам возможность на себе выполнять абстрактные операции, а по подписке принимать их на сервер;
  • Comming soon…
Backend — разве это событийно-ориентированное программирование? Как по мне, бэкенд можно спокойно разложить в последовательный (синхронный) порядок выполнения.

И в результате получить 42


По мне так вызов метода API это уже событие. Да, что там вызов метода. Запуск программы это тоже событие! А передача ей входных данных, ещё какое событие! Наступление определённого времени? Достижение конца файла? Подключение с определённого IP? Без тех или иных событий смысл в программировании сомнителен.


Или вы под событиями только onClick понимаете?


Вот только речь здесь про то, что говняных табуреток с JS будет больше, чем с каким-нибудь C#.
И это опять такие мое, и думаю не только, мнение.

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

Сомневаюсь, что это негативно повлияет на ценность высококвалифицированных специалистов.

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

Соглашусь JS крутой язык (моё субъективное мнение). Насчёт остального не от меня информация. Можно действительно многое. Но я нынче фронтенд программист, поэтому не искушён в забраузерных возможностях. Но в браузере оно будет работать без установки, на любой платформе где есть браузер. Без компиляции и скачивания инсталяторов. Кроссплатформенность — это круто.


От себя скажу, что написав функциональность на клиенте со сборкой SVG, я конечно не мог принимать результат на бэкенде. Там пришлось написать нечто похожее, принимающее только исходные настройки и повторяющее из них то, что видел в браузере пользователь. Это было проще чем фантазировать как победить XSS. Если бы на бэкенде тоже был на JS, то мне не пришлось бы после каждой правки переписывать и тестировать обе версии.


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


Я могу показаться немного адольфиком, но все же.

Это не круто.


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

Для того кто его сделал быть может он нужен (мало ли шоу какое устраивает), а ты можешь его не замечать и для тебя его не будет.


Но ты предпочитаешь замечать и выбиваешь у шоумена табурет из под ног потому, что табурет не правильный. Надеюсь у шоумена не было петли на шее. Извини, опять филлосовствую.


А тем временем человек сделавший табурет, может (если ты конечно уже не успел его линчевать) в следующий раз учесть ошибки проектирования и сделать табурет который тоже будет говном, но не вонючим. А потом новый, следующий, ещё один, сто пятый и наконец классный.


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


Отрывать им руки за первый блин, по Адольфски.

Даст кучу «разработчиков», которые могут использовать язык как калькулятор и писать Hello World?

Даст кучу «разработчиков» которые сами смогут решать свои задачи и не отвлекать «других разработчиков» по пустякам. Или смогут лучше объяснить, чего они хотят от других разработчиков если сами не справятся.


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


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


Как по мне, то основы лучше осваивать не на js. А низкий порог входа означает низкое качество кода в целом.

Возможно если поставить себе цель стать программистом то есть более подходящие языки.


Но у меня такой цели не было например. А была цель не править шапку сайта с играми в локалке на каждой странице и для решения этой задачи подошёл PHP с его include(), а потом ещё были задачи и он тоже отлично подходил.


Но когда стало нужно держать миллион коннектов, PHP оказался слоном и прога написанная на C++ работала в миллион раз быстрее. Это была чужая прога и в исходниках не сказал бы, что удалось разобраться. Вся остальная часть сайта продолжала работать на PHP/MySQL и с этими задачами язык продолжал прекрасно справляться. Потом для решения задач понадобился JS и сейчас на нём писать классно.


А низкий порог входа означает низкое качество кода в целом.

В целом конечно. Но кто вообще это целое видел и зачем?


Я полагаю среде JS хватает высококлассных программистов которые пишут качественный код и могут на ревью джунов подтянуть.


Но от того, что нубы марают светлое лицо языка кому от этого хуже кроме статистики?


Если есть софт который написан некачественно, и софт которого нет — какой лучше?

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


Если коротко:


Низкий порог входа это здорово. Так больше людей сможет научиться основам программирования. Это сделает мир лучше.

Пожалуйста не кричите на меня. То, что не делается правильно, может делаться левельно (за счёт мастерства и глубокого понимания происходящего)(в основе юмора английское слово Level которое ты и так знаешь %username%). И это здорово — можно не вставлять квадратное в треугольное в угоду правильности и закостеневшим в мозгу паттернам.


Я не пытаюсь сказать, что паттерны это плохо, а лишь намекаю на волновую структуру жизненного цикла [людей и программ]. Сейчас ты упарываешься по паттерну и делаешь всё правильно (хотя и не понимаешь почему именно так правильно). Завтра упираешься в его углы и начинаешь мыслить за пределами его границ и получаешь свободу, в том числе выстрела в ногу. Послезавтра, когда надоест танцевать на граблях, снова примешь чью-то новомодную методу. Далее по синусоиде, но уже с пониманием того почему ты использовал этот паттерн и почему именно таким образом. А дальше ночь, улица, фонарь, аптека…


Автор соседнего поста ругает ES8 за низкий порог входа, но ПМЛМ это зря. Язык разрабатываемый десятком светил до которых не достать, может быть сколь угодно крутым, но что толку если программирует на нём всего сотня-другая людей?


PHP в своё время взлетел и стал очень популярен из-за своей доступности. Достаточно было скачать бинарники, написать в командной строке php file.php в котором написано <?=6*7?> и получить ответ 42. Ну или можно поставить себе локальный денвер и байбай консоль, теперь можно результаты вписывать в разметку\оформление. Красиво. А до него был Perl.


Сейчас вообще ничего скачивать не нужно и файлов создавать тоже. Жмёшь заветные ctrl + shift + i, пишешь 2**10 и получаешь 1024 в ответ! Даже знать о том, что пишешь на JSES не нужно. А стоит узнать о том, как пользоваться переменными и всё — ты программист. И тут я понимаю всё негодование тех кто отучился не один год, чтобы написать свой первый хеловорд. Такая щемящая несправедливость просто, обязана не давать им покоя.


Интерпретируемые языки имеют отличную от компилируемых парадигму разработки. Если для компилятора ты готовишь свою программу, пишешь, потом ещё пишешь, потом исправляешь и только потом компилируешь и наслаждаешься результатом. То в интерпретируемых скриптах мелкоитеративный цикл разработки, в котором ты смотришь на результат во время программирования (привет LiveReload), сверяя его с тем чего ожидаешь.


Сделав изменение в одну букву, можешь сразу посмотреть результат и убедиться, что всё идёт так как задумано. В таких условиях недостатки отсутствия строгой типизации вываливаются сразу, а не накапливаются и выдаются в качестве непредсказуемых результатов после компиляции. Если складываешь цифру со строкой, то заметишь, что в результате у тебя не цифра. И это здорово. Пишешь интуитивно и лаконично. Сразу получаешь результат.


А если с типом накосячил в компилируемом языке, притом в не очевидном месте, то можно провести не один час в поисках ошибки которую допустил час назад и строгая типизация тут и вправду помочь может. Но что, тебе поможет если ты перепутал две очень похожие функции, тем более если они отличаются в названии всего одним символом‽ Статическая типизация, компиляция, строгие правила — не панацея. Если ты достаточно везуч и любознателен, ты найдёшь способ выстрелить себе в ногу, даже если разработчики языка всеми силами стараются этому помешать.


Но если ты хочешь программировать здесь и сейчас то, JS твой почти безальтернативный выбор. И помни, что наговнокодить можно на любом языке и только годы практики и танцев на граблях отделяют тебя от чистого кода (совершенного кода кстати не бывает, это вектор, а не точка). И на чём бы ты ни писал, год за годом ты будешь смотреть на свой код, написанный год назад и мысль — «Что за говнокод?», тебя не покинет.


ЗЫ всё это моё личное мнение, я не учился в институте и руководствуюсь только своим опытом разработки на PHP/JS. Ну а то, что я так и не написал своё первое приложение на C++ это потому, что [irony]С++ плохой и сразу не работает[/irony]

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


Это всё кстати ПМЛМ. Не нравится подача информации, в глаза бросается реклама. А я хотел про UX почитать.


Это мой такой ЮзерскийЭкспиренс если хотите. Статья — неудобная

Вместо почты для домена, по адресу pdd.yandex.ru в chrome мерцает главная страница яндекса уже второй день. В edge просто перенаправляет на главную страницу.


У всех так? Молча закрыли сервис или я что-то пропустил?

Information

Rating
Does not participate
Location
Таиланд
Date of birth
Registered
Activity

Specialization

Frontend Developer, Software Architect
Senior
From 4,200 $
TypeScript
Node.js
React
NextJS
Adaptive layout
Agile
Automation of processes
Git
Progressive Web Apps
Server-side rendering