Не все деньгами меряется — качество еды (колбаса из мяса, сыр из молока, который к тому же дешевле* чем в россии), безопасность, окружающая среда, бесплатная* медицина, экология, бесплатные* и качественные садики/школы/универы (а то ходят слухи детей в школах москвы трявят), гораздо ближе и дешевле путешествовать по европе (сходу нашел перелет Швеция-Испания за 26 евро), пенсии, и пр. социалки…
Больше услуг, развлечений
Ну это спорно, имхо, гораздо больше людей едут в Европу за услугами/развлечениями чем в Россию из Европы.
в этом языке на самом деле не существуют указатели
x указывает на новый PyObject.
Если сравнивать со статический типизированными языками, где разделяется на передачу по ссылке и передачу по значению, в питоне всегда* передается «по ссылке» (указатель на объект).
Не nginx, а njs, не уязвимость, а просто баг (уже пофикшен в последней версии) — компания Nginx отписалась, что этот баг не может быть использован как уязвимость.
Вообщем шум не очем.
2) Никак не генерит. Компилятор Svelte вообще генерирует ES6 код. Далее, если вам нужен даунгрейд до каких-то таргетов, вы можете использовать Babel как обычно и подключаете полифилы, типа corejs.
Мне казалось я в доке видел ключик для компиляции в es5
Статья устарела (даже на момент написания оригинала), в монге уже давно есть транзакции и альтернатива «join», что многое меняет если для вас транзакции — ключевой фактор. Поэтому раздел «В чем отличие SQL от NoSQL?» можно спускать в шредер.
У вас есть obj, в нем есть baz, который прокидывается внутрь вложенного компонента, и в нем есть baz2, который используется в биндинге. Мы изменяем baz2 из внешнег окомпонента, как свелте об этом узнает?
Вот так, только что проверил, это ключевой кусок из скомпилленого приложения:
var component_changes = {};
if (changed.obj) component_changes.data = ctx.obj.baz;
component.$set(component_changes);
Ну то есть мы бегаем по всем биндингам в текущем поддереве и проверяем не изменилось ли чего в каждом, так?
Так.
Не позволяет, это невозможно. На этапе компиляции такой информации просто не существует. Зачем вы пишите вещи, которые заведомо ложны? Не понятно.
Похоже вы спортие про разные вещи, приведите пример того «что невозможно», или можете просто посмотреть во что компилируется код (его там совсем не много), тогда все вопросы отпадут.
В моем случае наоборот произошла экономия ЧЧ, я им дал одну команду «make start» и проект запускается (и не факт что они знают что оно на докере), вручную запускать и связывать эту кучу сервисов — они бы потратили не один день.
В angular помнится был digest cycle и наблюдатели для переменных (всякие там $watch)
Просто другая резализация того же опроса биндингов, а $watch — это фича, в Svelte тоже не плохо бы её заиметь, т.к. computed $: вызывается даже если нет изменений, хотя это легко допилить кому надо.
Тут всего этого нет — просто проверки конкретных условий
В ангуляре эти проверки происходят в цикле, а не линейно развернуто (т.к. добавляются динамический). Да в свелте оно получается легковестней, но разницы вы не заметите т.к. 99%* (большую часть) времени уходит на отрисовку DOM и пр.
p/s То что фукнция будет деграться можно считать pull-реактивностью)))
Хорошо что теперь вы позитивно на это смотрите, а то 2 года назад когда мы спорили про Ractive/angular вы были против подобного ;-)
что Svelte не сможет определить что на изменение пользователем селекта, нужно менять только две ноды в DOM (select и последний span без глубокого сравнения state либо результатов render
В кратце работает так: 1. вы меняете например «obj.user.name», svelte инвалилирует «obj» (корневой объект) 2. на следующем тике проверяются все биндинги которые начинаются с «obj» (т.е. входят в состав этого объекта). т.е. если есть 2 биндинга {obj.user.name} и {obj.user.getAge()}, они оба будут вызваны (высчитаны) и сверятся с предыдущим значением (не все данные в obj, а только все биндинги в obj) 3. если значение изменлось оно сравнивается с тем что лежит в DOM и если оно отличается — то оно обновляется.
Итого: DOM обновляется точечно, весь стейт не проверяется, а проверяются все биндинги у которых инвалидировался корневой объект.
нужно менять только две ноды в DOM (select и последний span без глубокого сравнения state
Для этого примера если данные так и хранить объектом, будет произведено 4 проверки биндингов (или 2 если переменные лежат вне объекта), и изменен только {state[state.whichName]}, а селект не будет изменен т.к. уже имеет актуальное значение.
При это не важно если в стейте ещё 100500 других полей.
Ну это спорно, имхо, гораздо больше людей едут в Европу за услугами/развлечениями чем в Россию из Европы.
">>> y = x"
Вообщем шум не очем.
PS: В питоне нормально решаются циклические зависимости, проблемы не в питоне, а «в руках».
Тестировалось на python 3.7, оригинал.
:=
(3.8+)строгаястатическая типизацияПохоже вы спортие про разные вещи, приведите пример того «что невозможно», или можете просто посмотреть во что компилируется код (его там совсем не много), тогда все вопросы отпадут.
Типа того: Observable (frp), DirtyChecking, VDOM, [Property, Zone.js, Proxy] (какие ещё?), и вот уникальная новинка! от Svelte 3 — «статическая» инвалидация (или как назвать?).
Knockout.js: Observable
Vue.js 1: Property + Observable
Recat.js: VDOM ( + всякий flow)
Angular 1: DirtyChecking
Angular 2+: Zone.js + DirtyChecking
Svelte 3: Статическая инвалидация + DirtyChecking ( + фильтрация по корневому объекту, чтобы не все проверять).
Я приписываю DirtyChecking потому что идет не точечный отлов, а проверка списка биндингов (вычисление выражений и вызов ф-ий если они там есть).
Но кроме системы отслеживания у фреймворков ещё разные фичи, так что есть что посравнивать.
В ангуляре эти проверки происходят в цикле, а не линейно развернуто (т.к. добавляются динамический). Да в свелте оно получается легковестней, но разницы вы не заметите т.к. 99%* (большую часть) времени уходит на отрисовку DOM и пр.
Хорошо что теперь вы позитивно на это смотрите, а то 2 года назад когда мы спорили про Ractive/angular вы были против подобного ;-)
1. вы меняете например «obj.user.name», svelte инвалилирует «obj» (корневой объект)
2. на следующем тике проверяются все биндинги которые начинаются с «obj» (т.е. входят в состав этого объекта). т.е. если есть 2 биндинга {obj.user.name} и {obj.user.getAge()}, они оба будут вызваны (высчитаны) и сверятся с предыдущим значением (не все данные в obj, а только все биндинги в obj)
3. если значение изменлось оно сравнивается с тем что лежит в DOM и если оно отличается — то оно обновляется.
Итого: DOM обновляется точечно, весь стейт не проверяется, а проверяются все биндинги у которых инвалидировался корневой объект.
Для этого примера если данные так и хранить объектом, будет произведено 4 проверки биндингов (или 2 если переменные лежат вне объекта), и изменен только {state[state.whichName]}, а селект не будет изменен т.к. уже имеет актуальное значение.
При это не важно если в стейте ещё 100500 других полей.