Svelte не пишется на Svelte. Так как Svelte это компилятор то для тестов нужны образцы языка для компиляции и сличение с ожидаемым результатом. Сам компилятор написан на TS.
Интерфейс Slack может просто летать но у разработчиков просто руки не от туда ростут… увы толковых frontend девелоперов очень мало. Ну и оишибится с выбором технологии легко, а потом уже размер не будет давать вам все переписать.
Я не фанат C# но писал для него под маком в Visual Studio Code и тулзами от net core очень уверено и удобно. Т.е. к тулзам и окружению не было никаких претензий.
Я вот только не пойму, почему на более чистом и простом (в смысле синтаксиса) Python эта бизнес логика будет хуже? Или ее будет сложнее написать? При том что в Python async/await отлично работают.
Например, по ссылке ниже, можно заметить, что Go идёт только за PHP.
Тут надо понимать что какой ценой был получен этот результат. И если говорить про БД то с PHP приходится использовать сторонние пулеры для Postgres.
Плюсы статической типизации переоценены. В последнее время я вижу на хабре прям крестовый поход против динамической типизации причем даже в очень хамских статьях.
Видимо буду писать статью-ответ которая могла бы защитить динамическую типизацию.
Но сразу оговорюсь — я не говорю что одно лучше другого, просто у них своих плюсы и минусы которые раскрываются в разных контекстах и у разных людей.
Во многом я соглашусь с автором статьи — сторонние либы и плохо настроенный бандлер это главные причины убивания плюшек Svelte. Отчасти по этому Rollup бывает предпочтительнее из-за того что он лучше делает tree shake но конечно главное тут что вам совершенно не нужен axios для этого виджета. Я понимаю что скорее всего вы копипастили код из других своих проектов на React но все же для целей экономии тут можно было бы немного доработать.
В любом случае я рад что вы воспользовались Svelte и у вас получился хороший и работающий виджет.
На уровне концепции — костылей для решения проблемы медленного DOM.
Лучше жевать чем говорить… вы бы хотя бы изучили тему. ShadowDOM вообще не про скорость хотя в некоторых случаях может быть и такой эффект.
Если говорить о скорости то в Svelte механизм эффективнее чем VirtualDOM.
это все байндинги внутри в любом случае будет Си. Я бы тогда Python бы взял но иногда это плохо. Так что даже новые приложения для Gnome и GTK пишут на чистом Си.
Было бы классно если вы написали. Мы перед выбором Svelte пробовали Инферно и прекат но в итоге остановились на Svelte. Но это не те изыскание по которым можно было бы статью написать.
Svelte вышел в 2016 году. Vue вышел в 2014. Разница в 2 года. Т.е. Svelte мог учесть все ошибки Vue и стать лучшим, отвоевать аудиторию и рынок. Но он до сих пор является полнейшей маргинальщиной известной в основном по своим хвалебным статьям.
Это совершенно не соответствует действительности. Первые две версии Svelte были прототипами где набивались шишки нового подхода и считать надо с появления третей версии. Синтаксис у всех трех разный и не совместим. А за один год Svelte3 достиг очень крутых результатов. Ну и трудно назвать маргинальщиной проект который используют крупные компании (NY, Mail.RU). Что бы вы там не думали но Svelte3 входит в четверку, а вот сможет ли он устоять это вопрос уже к сообществу.
Альтернативные легкие фреймворки типа Flask, хотя и позволяют быть свободнее Django в экосистеме и конфигурации, могут потребовать лишнего времени на поиск/создание дополнительных библиотек и функциональных возможностей в долгосрочной перспективе.
В корне с этим не согласен. Вначале может быть готовые батарейки и спасают но потом все все равно приходится переписывать и делать кастомные варианты и именно тут гибкость легких подходов дают свою пользу.
Ну и честно говоря для большинства кейсов в python есть готовые "плагины" которые можно хоть с Tornado хоть с Sanic использовать без особых трудов.
Svelte не пишется на Svelte. Так как Svelte это компилятор то для тестов нужны образцы языка для компиляции и сличение с ожидаемым результатом. Сам компилятор написан на TS.
Интерфейс Slack может просто летать но у разработчиков просто руки не от туда ростут… увы толковых frontend девелоперов очень мало. Ну и оишибится с выбором технологии легко, а потом уже размер не будет давать вам все переписать.
Так веб морду вам в любом случае на JS надо будет писать т.к. прямого доступа к DOM у WASM нет.
Для Mali же сейчас активно OpenSource драйвера пишут.
Я не фанат C# но писал для него под маком в Visual Studio Code и тулзами от net core очень уверено и удобно. Т.е. к тулзам и окружению не было никаких претензий.
Я вот только не пойму, почему на более чистом и простом (в смысле синтаксиса) Python эта бизнес логика будет хуже? Или ее будет сложнее написать? При том что в Python async/await отлично работают.
Тут надо понимать что какой ценой был получен этот результат. И если говорить про БД то с PHP приходится использовать сторонние пулеры для Postgres.
Плюсы статической типизации переоценены. В последнее время я вижу на хабре прям крестовый поход против динамической типизации причем даже в очень хамских статьях.
Видимо буду писать статью-ответ которая могла бы защитить динамическую типизацию.
Но сразу оговорюсь — я не говорю что одно лучше другого, просто у них своих плюсы и минусы которые раскрываются в разных контекстах и у разных людей.
Во многом я соглашусь с автором статьи — сторонние либы и плохо настроенный бандлер это главные причины убивания плюшек Svelte. Отчасти по этому Rollup бывает предпочтительнее из-за того что он лучше делает tree shake но конечно главное тут что вам совершенно не нужен axios для этого виджета. Я понимаю что скорее всего вы копипастили код из других своих проектов на React но все же для целей экономии тут можно было бы немного доработать.
В любом случае я рад что вы воспользовались Svelte и у вас получился хороший и работающий виджет.
Мдя, у нас в Японии все работает немного иначе...
В Японии ) Welcome
Svelte и предлагает. Если конкретно для вас этих плюшек не хватает то вас никто не тащит.
Лучше жевать чем говорить… вы бы хотя бы изучили тему. ShadowDOM вообще не про скорость хотя в некоторых случаях может быть и такой эффект.
Если говорить о скорости то в Svelte механизм эффективнее чем VirtualDOM.
А почему не готова для продакшена? Мы уже давно используем. (на самом деле мы даже начали с версии 1 играться)
это все байндинги внутри в любом случае будет Си. Я бы тогда Python бы взял но иногда это плохо. Так что даже новые приложения для Gnome и GTK пишут на чистом Си.
Ну если вы пишите под линукс то будете использовать GTK который на Си. (или Qt на C++ но это зависит от многих критериев)
Было бы классно если вы написали. Мы перед выбором Svelte пробовали Инферно и прекат но в итоге остановились на Svelte. Но это не те изыскание по которым можно было бы статью написать.
Самое интересное что по хорошему Svelte только год, до этого были по сути другие проекты с этим именем.
Это совершенно не соответствует действительности. Первые две версии Svelte были прототипами где набивались шишки нового подхода и считать надо с появления третей версии. Синтаксис у всех трех разный и не совместим. А за один год Svelte3 достиг очень крутых результатов. Ну и трудно назвать маргинальщиной проект который используют крупные компании (NY, Mail.RU). Что бы вы там не думали но Svelte3 входит в четверку, а вот сможет ли он устоять это вопрос уже к сообществу.
В корне с этим не согласен. Вначале может быть готовые батарейки и спасают но потом все все равно приходится переписывать и делать кастомные варианты и именно тут гибкость легких подходов дают свою пользу.
Ну и честно говоря для большинства кейсов в python есть готовые "плагины" которые можно хоть с Tornado хоть с Sanic использовать без особых трудов.
За меня это сделал бутстрап зачем мне что то реализовывать заново? Я обычно пишу более высокоуровневые компоненты.