Comments 56
Я наверно один такой сумасшедший, но мне совсем непонятно, зачем делать все эти решетки, звездочки и прочий кошмар в коде.
В чем проблема написать интерпретатор, способный нормально работать с такими шаблонами?
<script>
const todos = ['Код должен быть простым!']
let newTodo = 'Новое значение'
const add = () => {
todo.push(newTodo)
}
</script>
<div bind="todos" index="todoKey">
Наш ключик {todoKey}. и здесь его значение {.}.
</div>
<input type="text" value="{newTodo}">
<button onClick="add()">Добавить<button>В данном случае транспайлер должен быть достаточно "умен", чтобы понять, что в bind передается итерируемое значение.
Передачу параметров внутрь можно реализовать через механизм, подобный React props.
Везде есть нормальный двухнаправленный биндинг для обычных компонентов ввода.
Могу привести альтернативный пример подобного подхода
<script>
class Todos extends Component {
// наш траспайлер поймет, что это свойство инициализируется через конструктор
private items: string[];
// как бы мы не использовали наш класс, мы всегда можем его отбразить в строку
toString(): string {
return <ul>
<li bind="this.items">{.}</li>
</ul>
}
}
<script>
<Todos items="['']" />А теперь просто покажу такую идею
<ul>
<li bind="['a', 'b', 'c']">{.}</li>
</ul>Вместо bind можно использовать что-то другое, например делать так
<script>
const items = ['a', 'b', 'c']
</script>
<ul>
<input {items} value={.} />
</ul>С таким подходом можно писать простые приложения с точки зрения его интерпретации человеком. А машине все равно, что ей скормят, главное, чтобы она могла это быстро и без ошибок выполнить.
Я наверно один такой сумасшедший, но мне совсем непонятно, зачем делать все эти решетки, звездочки и прочий кошмар в коде.
Может быть потому что не всем нравятся управляющие конструкции в тегах? Этим страдают Vue и Angular и это является главным минусом их шаблонизаторов.
Мне кажется — это дело вкуса и привычек. Мне лично структуры в Svelte симпатизируют больше — легче писать и сильно легче читать и воспринимать. Особенно если структуры в несколько этапов или имеют вложенность.
Если подумать, написать для Svelte препроцессор, который развернет теги со структурными атрибутами в HTMLx, совсем не сложно. Но пока, видимо, без надобности.
typescript-френдли
Боюсь нормально интергрируется с TS лишь один шаблонизатор — JSX. И то с ограничениями. Всё остальное нормально с тайпскриптом не интегрируется, пока MS не добавит в него хотя бы поддержку трансформаций до тайпчекинга.
Что, и подсказки в именах компонент и их свойств в строковых литералах работают?
Вы, фактически, тут просите TS поработать на разбор HTML. TS не умеет разбирать HTML.
TS умеет в плагины, только сейчас они отрабатывают после тайпчека. Если бы их можно было применять к AST до тайпчека, то можно было бы расширять тайпскрипт любым синтаксисом.
- Умеет в TSX файлах.
- Никто не предлагает вкорячивать парсеры других языков в TS компилятор. Нужна возможность подключения своих плагинов, чтобы поддержать свой кастомный DSL.
Смотрел сам примерно 8 месяцев назад, выводы точно такие же: стильно, модно, молодёжно, но в продакшн — извините.
NYT, GoDaddy, Яндекс.Деньги и Mail.Ru почему-то решили что норм. ;-) Но это ваше право конечно.
NYT, GoDaddy, Яндекс.Деньги и Mail.Ru почему-то решили что норм. ;-)
Argumentum ad verecundiam. Придумайте что-нибудь поинтереснее. Пока что вы слишком похожи на Wrike, которые со своим «нам не хочется признаваться, что dart был выбран по большей части от безысходности на тот момент, а поэтому будем топить за то, что это аж сам Хухл изобрел!».
Вы, в целом тоже не блещите своей аргументацией ни в предыдущем комментарии, ни в других комментариях к другим статьям. Так что извините.
Вы, в целом тоже не блещите своей аргументацией ни в предыдущем комментарии, ни в других комментариях к другим статьям.
Я и не собирался блистать, всего лишь назвал критичные на мой взгляд недостатки. На что вы рассчитываете, когда на «нет TS и поддержки IDE» вы в ответ пишете «зато этим всякие условно-важные конторы пользуются»?
От того, что сабж где-то среди всего Mail.Ru применили — появилась поддержка TS, или что?
И эти люди будут мне за аргументацию чего-то объяснять, ага.
И опять же, причем тут TS если статья находится в хабе по JS и имеет тег JS. Можно с таким же успехом прийти и про CoffeScript затирать. Любите TS любите дальше, никто вас ни к чему не призывает, но не обязательно пытаться его присунуть везде где он не нужен.
была недостаточная, чтобы оценить какая поддержка TS или IDE имеется на данный момент
Так и какая?
И опять же, причем тут TS
При том, что лично я отношу отсутствие поддержки TS к существенным недостаткам. При чём тут хабы и теги?
Так и какая?
Нормальная поддержка IDE. TS поддерживается в скриптах, в шаблонах нет, но можно и минимизировать выражения в шаблонах и не использовать автоматические биндинги.
При том, что лично я отношу отсутствие поддержки TS к существенным недостаткам. При чём тут хабы и теги?
Потому что это 2 разных языка. Это как сейчас набегут адепты Elm в статью по React и начнут ныть, что React не поддерживает Elm.
Нормальная поддержка IDE.
Я вижу WIP Language Server с открытыми issues в духе «TS не поддерживается» и «Language server молча падает». На моем языке это называется «поддержка IDE начинает появляться».
TS поддерживается в скриптах, в шаблонах нет, но можно и минимизировать выражения в шаблонах и не использовать автоматические биндинги.
Вот это говорит мне о том, что таки «TS не поддерживается». То, что можно проявить некоторую ловкость рук, и намазать TS отдельным слоем сборки над всей конструкцией — это нельзя назвать поддержкой.
Потому что это 2 разных языка.
И?
На всякий случай, если вы с первого раза не прочитали: «назвал критичные на мой взгляд недостатки». По каким причинам лично вы считаете это не важным или недостаточно важным — мне совершенно неинтересно.
Я вижу WIP Language Server с открытыми issues в духе «TS не поддерживается» и «Language server молча падает». На моем языке это называется «поддержка IDE начинает появляться».
А причем тут TS? Я про поддержку синтаксиса Svelte. На TS всем плевать.
Вот это говорит мне о том, что таки «TS не поддерживается». То, что можно проявить некоторую ловкость рук, и намазать TS отдельным слоем сборки над всей конструкцией — это нельзя назвать поддержкой.
Это ишак про поддержку из коробки, которая нафиг не нужна. Для таких вещей придуманы препроцессоры. Собственно TS это и есть препроцессинг для JS, поэтому не вижу тут ничего из разряда «ловкость рук». Точно также нужно поставить препроцессоры для PostCSS или SCSS если они необходимы. Так как 100% разработчиков Svelte не нужен TS, значит его не должно быть в Svelte по-умолчанию.
На всякий случай, если вы с первого раза не прочитали: «назвал критичные на мой взгляд недостатки». По каким причинам лично вы считаете это не важным или недостаточно важным — мне совершенно неинтересно.
Кроме фейспалма, у меня ничего для вас нет в этом вопросе.
Для таких вещей придуманы препроцессоры.
Конечно. Транспилятор TS таковым и является, вам не надо писать собственный.
Собственно TS это и есть препроцессинг для JS
Даже странно, что вы так быстро это для себя открыли.
поэтому не вижу тут ничего из разряда «ловкость рук»
«Ловкость рук» — это вот это вот:
TS поддерживается в скриптах, в шаблонах нет, но можно и минимизировать выражения в шаблонах и не использовать автоматические биндинги.
В переводе с русского на русский это и означает «да, вы можете пользоваться TS, но требуется проявить некоторую ловкость рук». Когда не будет никакого «но» — это и будет означать поддержку TS.
Конечно. Транспилятор TS таковым и является, вам не надо писать собственный.
А мне и не надо. Надо писать препроцессор для компонентов Svelte (точнее он уже написан), потому что они не просто JS, а SFC.
Даже странно, что вы так быстро это для себя открыли.
Если вы согласны с тем, что TS это препроцессинг, тогда в чем проблема его использоваться как препроцессор? Зачем его по-умолчанию включать туда, где он не нужен всем, а только вам например?
В переводе с русского на русский это и означает «да, вы можете пользоваться TS, но требуется проявить некоторую ловкость рук». Когда не будет никакого «но» — это и будет означать поддержку TS.
Это означает только то, что TS штука ограниченная в возможностях. Это TS не поддерживает использование кастомных шаблонизаторов. Как только TS начнет поддерживать HTMLx, никаких проблем с ним в шаблонах не будет.
Опять же, для фанатов и сейчас не так много преград, вы лишь бездумно скачете по верхам.
Если вы согласны с тем, что TS это препроцессинг, тогда в чем проблема его использоваться как препроцессор?
Всё в том же:
TS поддерживается в скриптах, в шаблонах нет, но можно и минимизировать выражения в шаблонах и не использовать автоматические биндинги.
Зачем его по-умолчанию включать туда, где он не нужен всем, а только вам например?
А я вам где-то это предлагал? Или вы сами выдумали и сами же обиделись?
Это означает только то, что TS штука ограниченная в возможностях.
Это означает то, что ограниченная в возможностях штука по имени TS мне нужна для достижения других важных вещей (статической типизации), и серьезных конкурентов у неё нет. В то время как Svelte — это очень здоровская концепция, но ничего функционально уникального в ней нет: сочетание одного из нескольких десятков компонентных фреймворков с одним из дюжин инструментов для управления стейтом даст в итоге всё то же самое. Чуть менее изящно и с чуть большим количеством кода в рантайме, но нисколько не менее функционально (а то и более).
Поэтому в выборе «или-или» проиграет отнюдь не TS.
Опять же, для фанатов и сейчас не так много преград, вы лишь бездумно скачете по верхам.
Для фанатов никогда нет преград. Это JS, где всегда можно примерно всё, хоть Ангуляр вместе с реактом и Vue на одной странице. Вопрос не в «можно-нельзя», а в «а так уж ли это надо?».
Всё в том же:
И? Обычная цена типизации. Все надо описывать явно и не использовать «магию». Собственно Svelte и не заставляет использовать магию. Не нужна типизация пишем так:
$store = 'value';
А если нужна, тогда так:
store.set('value');
Не вижу в этом ничего страшного.
А я вам где-то это предлагал? Или вы сами выдумали и сами же обиделись?
Похоже что да, потому что когда я написал вам, что поддержка TS имеется с помощью препроцессора вы мне ответили:
намазать TS отдельным слоем сборки над всей конструкцией — это нельзя назвать поддержкой.
То есть вам не понравилось, что TS поддерживается лишь опционально и лишь с помощью дополнительных «плагинов». Теперь вы утверждаете, что ничего такого не говорили.
Поэтому в выборе «или-или» проиграет отнюдь не TS.
Могу лишь повторить еще раз, поддержка TS есть, но она опциональная. И по всей видимости, если ее так и не включили по-умолчанию, те кому она нужна в меньшинстве.
Вопрос не в «можно-нельзя», а в «а так уж ли это надо?».
Вот и я о том. А так ли нужен Typescript? Судя по всему нет, потому что я не видел ни одного факта доказывающего, что именно TS сделал приложение лучше/надежнее/поддерживаемее, но зато читал и слышал много историй о том, что это бесполезная штука, с недоказанной пользой, влияющая на скорость разработки.
Вот и возникает вопрос, с чего так много шума вокруг него? И почему все должны срочно его поддерживать и волноваться по этому поводу?
<input on:input={(e) => onChange(e, ‘a’)} /> — Svelte
<input input=«onChange($event, 'a')»> — Vue
Возможно.
Просто поясню, что в Svelte в атрибутах внутри {} всегда используется javascript выражение, по аналогии с правой частью стрелочной функции. Поэтому, и в шаблонах Svelte можно написать такую же короткую запись как и в Vue(даже еще короче):
<input on:input={onChange(‘a’)} />Просто надо понимать, что обработчиком события станет не сама функция с переданным ей параметром, а то, что она вернёт.
Поэтому, можно в компоненте объявить функцию для обработчика таким образом:
const onChange = (param)=>(e)=>console.log(e,param);
// или специально для нелюбителей скобок:
const onChange = param => e => console.log(e,param);
Интересно, но явных преимуществ лично я пока не вижу. Ну или если точнее, то что-то сделано лучше чем в Angular, что-то [как минимум пока] хуже. Аналогично с React/Vue.
Но я не вижу ничего что было бы лучше чем во всех уже имеющихся альтернативах.
И в такой ситуации лично я не буду выбирать для рабочих решений "молодой" и необкатанный фреймворк без большого коммьюнити и всех вытекающих из этого последствий.
Главная особенность, отличающая Svelte от мейнстрима — он компилируется, а не тащит рантайм с собой. В статье про это ни слова, по-скольку у нее цель помочь ангулярщикам "въехать" в Svelte. А особенности уже не раз обсуждались в других статьях, в том числе и на Хабре.
Вот об этом тогда пожалуйста поподробнее. Что значит "компилируется" и в чём отличие от того же Angular, который вроде бы тоже компилирует Typescript в Javascript?
И что имеется ввиду под "рантайм" и что конкретно Svelte меньше тащит по сравнению с Angular.
П.С. Я взял Angular для примера потому что в статье скорее сравнивают с ним, но если не сложно то было бы интересно прочитать и какие в этом плане есть отличия/преимущества по сравнению с React/Vue.
П.П.С. Если это слишком обширная тема для комментариев, то с удовольствием подожду отдельную статью или хотя бы ссылочку:)
habr.com/ru/post/446026
Можно почитать вводную статью по Svelte3 — https://habr.com/ru/post/449450/
Комментарии, как всегда, сильно интереснее самой статьи =)
В общем почитал в обед поподробнее и наверное всё-таки останусь при своём мнении.
Особых плюсов я пока не вижу. То есть в теории может быть, но конкретно в наших проектах пожалуй нет.
А вот отсутствие typescript, относительно маленькое коммьюнити и слабая поддержка IDE это одгозначно большие минусы.
Гляну на это дело ещё раз годика через два-три:)
Главная особенность, отличающая Svelte от мейнстрима — он компилируется, а не тащит рантайм с собой.
Это сложно записать в неоспоримое «лучше», ибо дебаг тут же машет ручкой из-за угла: если пишется одно, а выполняется уже другое, то для полноценного дебага нужен сопоставлятор выполняемого кода и исходников. А его нет.
Это «интересно», но не обязательно «лучше».
Source maps же для этого и придуманы?
* Отключаем сурсмапы — получаем дебаг по тому коду, который генерирует компилятор(который к слову весьма очевидный).
* Ошибки, специфичные для Svelte отлавливает сам компилятор.
Мне кажется, тут можно провести полную аналогию с цепочкой `Typescript -> Javascript -> браузер`
В большом проекте, а не ToDoMVC, процент рантайма в общем объеме кода будет снижаться, а вот "вес" экосистемы, комьюнити и банально количества разработчиков, доступных для найма тут выйдет на первый план
import {
SvelteComponent,
append,
detach,
element,
init,
insert,
listen,
noop,
safe_not_equal
} from "svelte/internal";
import { createEventDispatcher } from "svelte";Вот это вот тоже "компилируется, а не тащит в рантайм", да?
Конечно же, не без хелперов — атомарные операции над DOM и прочее, например:
// append
export function append(target, node) {
target.appendChild(node);
}Вся эта история с "исчезновением", конечно же, рекламный трюк, всего там насобирается аж 1043 байта загзипованного кода для пустого приложения.
Под отстутсвием рантайма можно понимать всю ту логику, которая происходит при вычислении изменений представления при изменении стейта. Это то всё как раз и происходит во время компиляции, а не во время выполнения.
Быстрое введение в Svelte с точки зрения разработчика на Angular