На любом языке можно написать бекенд почти любой сложности. Все зависит от итоговых трудозатрат на это.
Писать лучше на том, что лучше знаешь и понимаешь. Наличие готовые решений для конкретных задач тоже помогает.
NodeJS хорош прежде всего тем, что имеет наиболее очевидные преимущества перед другими серверными языками в контексте веба. Если раньше языком веба был HTML и поэтому очевидные преимущества имел PHP (встраиваемость в html из коробки) и поэтому так много сайтов на нем. Языком для современных веб-приложений является прежде всего Javascript.
Из всего вышесказанного, несмотря на то, что по-сути на NodeJS можно написать что угодно, наиболее очевидные применения находятся в сфере frontend-серверов (BFF), прежде всего потому что его преимущества перед другими серверными языками неоспоримы в этой части (изоморфность).
Леонид, MyComponent.svelte это уже совершенно обычный Svelte компонент. answer передан ему как пропс. Соответственно просто читайте доку по Svelte, можно на русском: https://ru.svelte.dev/
Кратко (MyComponent.svelte):
<h1>{answer}</h1>
<script>
export let answer = '';
</script>
p/s так как пример упрощенный, нужно еще не забыть, что все data-аттрибуты - это исключительно строки, поэтому в mount хорошо бы еще предусмотреть какое-то приведение типов.
> Можете сделать свою версию immutable.js на прототипах, если будете вкладываться в разработку и пиар, то возможно через пару лет вашу реализацию будут везде юзать вместе текущей immutable.js
Откровенно говоря, на это нет времени и желанию особого тоже нет. Вопрос родился из текущей необходимости.
В проекте, нужно в нескольких местах получить некий вид иммутабельности, а точнее быть уверенным, что не произойдет случайного изменения изначальных значений и вся история изменений сохраниться. Все советуют immutable.js, но мне он показался излишним и я решил посмотреть в сторону прототипов. Тем более что мне и не нужно столько строгая иммутабельность, за которую так борется Назар. )))
> Короче, много слов, а понимания мало. Идите читать фундаментальную мат. часть)
Вы такой пафосный, однако)) Не смотря на то, что специалистом в иммутабельности очевидно не являетесь, судя по вашим ответам. Я задал вопрос не потому что не понимаю то, о чем вы говорите. Но вот вы не понимаете о чем говорю я.
> Во что обернуть?
Назар, я найду во что обернуть, так что вы вообще не поймете, что работаете с прототипами и не будете иметь доступ к самим объектам. Только через интерфейс который я вам дам. В этом смысле, и без всяких прокси и геттеров/сеттеров, можно сделать инкапсуляцию не хуже, а может даже лучше чем сделано в immutable.js. Будут у вас также методы set(), get(), никаких map1.b = 50; вы сделать не сможете. Вас это беспокоит? Меня нет, потому что это просто и к сути вопроса вообще отношения не имеет. Вы вообще можете понять, что проблемы доступа к самим объектам вообще не является сутью вопроса?
> Я вам уже доказал что оно не неизменяемое.
Вы постоянно говорите о том, что родительский объект может менять себя и своих потомков. (Что в целом даже круто на некотором ряде задач.) А я вам говорю о том, что потомки не могут менять родительский объект. Все остальное решается путем обертки в собственный апи. И к вопросу опять же отношения не имеет.
> Это не ограничение, а фундаментальное отличие изменяемых (mutable) от неизменяемых (immutable) объектов. В этом вся суть!
Еще раз - в вашем контексте, в JS иммутабельности не может быть вообще. Она лишь эмулируется. Такую же эмуляцию можно сделать и на прототипах. Вопрос почему этого не делают? Я ведь не считаю себя самым умным и должны быть какие-то причины.
lega: Как вариант. Считай классический JS способ создание private свойств. Интересно, почему immutable.js не замкнули объекты, а вытащили из в "приватные" свойства? Может дорого? Сборщик же плоховато с замыканиями работает.
Назар Мокринский: > Вы лезете во внутренности (_root), я же оперирую публичным интерфейсом, как и вы выше.
Так как в JS по сути нет модификаторов доступа, свойство _root ничем не отличается от метода set(), с точки зрения языка. Это не более чем соглашение. А, как вы написали, вы очень даже хотите изменить "неизменяемый" объект, то вы всегда найдете путь как это сделать в JS. Поэтому эта ваша часть доводов по сути своей не серьезна.
> Если я могу поменять объект 1 и при этом измениться объект 2 - то какие они неизменные?
Опять же, я могу цепочку прототипов обернуть и выдать вам публичный интерфейс, через который мы не сможете ничего менять. Это что-то меняет в самой идее?
Даже в таком виде, это можно назвать "ситуативной иммутабельностью", когда вы не можете изменить изначальный объект, через новый объект случайно, только если захотите это сделать специально. Но откровенно говоря, я не понимаю, зачем программисту надо делать объект иммутабельным, а потом пытаться его изменить.
> Я всё к тому, что прототипное наследование это наследование.
Наследование то оно, конечно, наследование. Да только иммутабельное. Вы же пишете на PHP? Тогда должны знать, что там отнаследовавшись от класса, вы можете менять его доступные свойства (propected) в дочернем классе, перезаписывая свойства самого родителя. В JS вы этого делать не можете по умолчанию. Я лишь хотел узнать, почему это замечательное свойство не используют при создании иммутабельных структур, пусть даже через обертки и все такое ( вам же менять _свойства религия не позволит :-) ), но все же.
lega: Логика в ваших словах есть и она пересевается с моей. Собственно, поэтому меня и удивляет, что данные возможности языка практически не используются в наше время, а скоро похоже все вообще переключатся на классическое ООП с классами.
Назар Мокринский: > А если не смогу - поздравляю, вы изобрели immutable.js:)
Нет, потому что immutable.js не использует прототипирование под капотом. Собственно вопрос почему? На первый взгляд не имеет смысла копировать все свойства объекта, если изменилось одно. Собственно прототипирование изначально эту цель и преследует. Отличие от того что вы говорите - наложение дополнительных ограничений, которое можно реализовать путем инкапсуляции объектов внутрь какой-то обертки.
Однако, если вы реально хотите поменять "неизменный" объект, то никакой immutable.js вам не помешает это сделать. Тут вопрос же не в том, что это нельзя сделать в принципе, в js можно все, а в том, что если программист решил сделать какой-то объект неизменным, он вроде как не должен искать способы его поменять. Кейс лишь в том, что он может это сделать случайно и в этом смысле прототипирование не даст ему изменить свойства изначального объекта, через новый объект.
Назар Мокринский: а зачем вы меняете свойство объекта, который менять не хотите? Если я все это оберну в интерфейс на подобии Immutable.js и у вас не будет прямого доступа к объектам, идея станет понятнее для вас?
На базовом уровне иммутабельность цепочки прототипов все же есть. Конечно, в JS нет чистой иммутабельности, также как нет чистого ФП или любой другой парадигмы, которую он так или иначе реализует. Посмотрите пожалуйста update к моему вопросу, может станет понятнее, что я имею ввиду.
Алексей Уколов: А что там больно прикручивать то? Базовая иммутабельность цепочки прототипов работает из коробки, без каких либо наворотов вообще. Разве что апи не такой красивый)) В целом согласен, что вопрос требует уточнений, которые я дописал в блоках UPDATE.
lega: Да, похоже вы правильно поняли идею. Спасибо. Уточнил в описании вопроса. Мысли по поводу перформанса тоже не оставляют. В целом прототипы считаются довольно медленной штукой, может поэтому и не используют. Но как вы правильно заметили, можно время от времени их flat'ить, как бы делая re-base.
Надеюсь мой ответ будет полезен.