Comments 22
Как то скептически отношусь ко всяким «компилируемым в JS» языкам. Мало того, что повышает порог вхождения, так ещё и приносит новые проблемы, в данном случае «биндинги не для новичков», зачем? Если есть immutable.js, где нет таких проблем
Библиотека React основана на принципах функционального программирования, так как React-приложения представляют собой композиции функций. Хотя в JavaScript имеются некоторые возможности функционального программирования, такие, как функции первого класса, функциональным языком программирования он не является
И далее вывод из этого и других посылов:
Как видите, JavaScript не совместим с базовыми принципами React.
Как бы не вижу. То, что JavaScript не является полностью функциональным языком программирования, не говорит о том, что он не совместим с базовыми принципами React.
В JavaScript нет стандартных механизмов для обеспечения иммутабельности
Тоже не соответствует действительности, по крайней мере, частично. В JavaScript «из коробки» иммутабельны строки. Для объектов есть Object.freeze() и Object.defineProperty() с тонкой настройкой каждого свойства на чтение/запись/модификацию.
В статье также не упомянуты принципы React, которые очень хорошо сочетаются с Javascript. Например, в своей простейшей форме компонент Реакта – это Javascript-функция. JSX синтаксис неплохо вписывается в Javascript-инфраструктуру, потому что JavaScript-выражения можно использовать в любом месте JSX. Принцип событий и их обработки — это вообще одна из основных причин, для чего Javascript создавался как язык программирования в вебе и основа изменения компонентов в React.
Зело страшный физбаз приведен для сравнения с несравненным RE (чем бы оно ни было).
Вот такой еще есть:
Вот такой еще есть:
const f = 'Fizz', b = 'Buzz', fb = f+b;
const pattern = [,,f,,b,f,,,f,b,,f,,,fb];
for(let num = 1; num <= 100; )
for(let i = 0; i < 15 && num <= 100; i++, num++)
console.log( pattern[i] ? pattern[i] : num );
В JavaScript нет стандартных механизмов для обеспечения иммутабельности
Спред-оператор, slice, map/filter/reduce, Object.assign вполне себе обеспечивают иммутабельность
Это значит что они запрещают менять объект? Или надо программисту памятку повесить, что пользоваться можно толкьо этими ф-циями?
Это значит, что с их помощью можно спокойно работать с объектами, не изменяя первоначальные.
И как мне кажется, программист в состоянии запомнить, что нужно сделать для достижение той или иной цели. Вы же не пишете памятки о том, что для объявления константы нужно использовать ключевое слово const. Или пишете?
И как мне кажется, программист в состоянии запомнить, что нужно сделать для достижение той или иной цели. Вы же не пишете памятки о том, что для объявления константы нужно использовать ключевое слово const. Или пишете?
Вы не поверите, но можно "спокойно" (а зачем нервничать) работать с объектами, не изменяя их, даже без перечисленных вами функций и spread-operator-а. Причём, я полагаю, в любом языке программирования. Речь всё же о другом ;)
Вы же не пишете памятки о том, что для объявления константы нужно использовать ключевое слово const. Или пишете?\
const не нужна. (С)
В результате, из-за того, что использование const может привести к путанице, и из-за того, что при наличии ключевого слова let наличие const выглядит избыточным, я решил всегда использовать let.
const не нужна вообще! (С)
Переходите на php, там не нужны ни var, ни const, ни let ;)
там не нужны ни var, ни const, ни let ;)
Дело не в количестве, дело в том, что const в Javascript имеет тот же самый смысл что final в Java.
Но final в Java программисты так редко практически вообще используют (хотя могут писать final хоть в каждой строчке почти), что было бы странно чтобы программисты Javascript вдруг, с какого-то бодуна, стали массово и всюду использовать const.
Практика показала, что в реальном программировании (без «финишной лакировки» кода) использование и final и const не имеет никакого смысла.
const практически не нужен никому вообще! (С)
P.S. О лени — Мне один из разработчиков на JavaScript сообщил, что вначале они повелись и писали const («метим всё const, а затем уже у тех переменным, значение которых меняем при разработке(написании кода), метим let.») — «полируя код». Но со временем перестали, так как при рефакторинге им приходилось возвращаться назад по коду и заменять const на let, и они стали использовать только и только let.
Да-да-да, я читал всё, что вы там писали. И я в корне не согласен почти со всем. Но не вижу смысла спорить об этом. Ничего нового я вам не открою, в том топике были даны все ответы.
P.S. И да, ваша практика в корне противоречит моей. Думаю на этом можно вопрос закрыть :) Пусть это будет делом вкуса.
ваша практика в корне противоречит моей.А причина?
Java-программисты только под дулом пистолета будут писать final String myDarling =…
JavaScript-программисты напишут let myDarling =…
Почему?
JavaScript-программистам надо что-то писать при объявлении переменной. Выбор есть — var, let, const или ничего.
Но ничего писать нельзя! Ибо глобальная видимость.
Остаётся выбор из var, let, const.
У Java-программисты есть выбор писать:
final String myDarling =…
или
String myDarling =…
Конечно они выбирают писать без final
Другое дело, если бы да кабы в JavaScript было:
var — это как и сейчас var
const — это как и сейчас const
global — это как сейчас ничего
ничего — это как и сейчас let
В этом случае JavaScript-программисты на практике почти никогда бы вообще не указывали этот модификатор видимости переменной при её объявлении. Но… поезд ушёл.
Я там выше про PHP не спроста упомянул. Убрав keyword для декларации переменной вы получаете хаос и жуткие лямбды с use($var1, $var2).
Убрав keyword для декларации переменной вы получаете хаос и жуткие лямбды с use($var1, $var2).Вы не поняли. Убирать уже… поздно.
JavaScript был разработан не для программистов, а для обычных юзеров, коим удобнее было (то есть они часто это использовали) никак не декларировать переменную.
Но, JavaScript стал использоваться программистами, которым удобно сейчас (то есть они наиболее часто это используют) декларировать переменную имеенно как let.
P.S.
Языки редко используют те, для кого они предназначались:
С — для разработчиков операционной системы, что и сейчас есть.
С++ — как универсальный язык, но который занял нишу у разработчиков игрушек и видео-звуко-фото-редакторов.
Паскаль — для обучения программированию.
Фортран для физиков.
PL/1 — универсальный язык для всех — канул в лету.
Cobol — язык для экономистов — написано много было, всё переводят на Java его.
Java — язык для динамических картинок в броузере — но залез аж на сервер и там глубоко обосновался.
SQL — язык был сознательно выбран и разработан для бухгалтеров, кладовщиков, экономистов и библиотекарей — но его выхватили себе программисты баз данных и не выпускают из рук, лет 15 назад не пустив в него ООП.
Неисповедимы пути языков. (С)
Технически, для обеспечения иммутабельности, можно использовать Object#freeze. Хотя конечно это все равно не будет работать с вложенными объктами по-человечески.
Я конечно понимаю, что компиляторы, парсеры отлично пишутся на функциональных языках, работа с математикой удобна, ну и подобные вещи.
И какой процент этого требуется в Web-приложениях?
Нет, спасибо, не надо тут чистую функциональщину.
И какой процент этого требуется в Web-приложениях?
Нет, спасибо, не надо тут чистую функциональщину.
UFO just landed and posted this here
Вот почему мне всё больше нравиться Vue.js. React разработчики всё сильнее и сильнее усложняют себе код и его читабельность, увеличивают его обьёмы используя десятки подходов и библиотек мотивируя себя тем, что в итоге вся эта тяжелая конструкция облегчит им жизнь в большом проекте. В итоге либо проект так и не доживает до больших масштабов, либо работает исправно, но время на его написание/поддержание увеличивается в разы и когда разработчик через пару-тройку месяцев заходит править свой же код и редеплоить — у него течёт слеза… Я не говорю что Vue + тесты решают все проблемы, но что ускоряют разработку, уменьшают код и сохраняют нервы — проверено.
Sign up to leave a comment.
Разработка React-приложений с использованием ReasonReact