Pull to refresh

Comments 12

А можно мне вот наоборот?

Чтобы просто нажал кнопочку, а там средствами npm и может быть небольшого скриптика мне генерится обыкновенный html фаил со статически залинкованым js.

И можно, даже, чтобы без babel? Я готов использовать subset ECMA Script 6. Его уже неплохо поддерживают все браузеры, благо выпущен он был в 2015. И мне глубоко пофиг, что мы пытаемся поддержать какой-то там мобильный браузер для Nokia 3310. Мне не нужны мегабайты транспайленого скрипта, в котором ошибки ищуются через определённые места.

И чтобы просто JSX преобразовывался во всё тот же, понятный и не перегруженый, но уже поддерживаемый ECMA 6.

Нет, честное слово, я понимаю, что Perl был неимоверно сложным языком. Но зачем-же тогда надо с таким упорством переделывать все остальные языки в Perl?

// Это вам пример ES15
const calculatedValue = -10
  |> (n => Math.max(0, n)) // Replacing Math.max
  |> (n => Math.pow(n, 1/3)) // Replacing Math.pow
  |> Math.ceil; // Using Math.ceil

Оно мне надо?

Если мне так лень писать, то за меня допишет GPT этот код. В 2024 году рассказы про Boilerplate выглядят смехотворными.

Нафига мне для моего клиентского приложения иметь набор инструментов, которые будут запускать это приложение, учитывая, что оно написано на языке, который должен запускаться практически на любом браузере?

PS. Я сейчас пишу на Vue. Два проекта. Один на Vue2 другой на Vue3. Смысл перехода не понятен от слова совсем. Да, я понимаю, вся эта маркетинговая фигня, но по факту мы просто сами создаём себе проблемы, а потом радостно удивляемся "как же сложно!"

Я не заставляю никого переходить, а лишь говорю о том, как это можно сделать.

Смысл перехода в том, что скорость разработки с Vite гораздо быстрее, чем при использовании Webpack. Приведу ниже таблицу.

Vite в сравнении с Vue-CLI + Webpack
Vite в сравнении с Vue-CLI + Webpack

А я говорю о том, что обыкновенный HTML без транспайлинга - моментален. Мы очень сильно заморачиваемся тем, что нам нужны фреймворки для того, что уже отлично работает годами.

Обычный HTML без транспиляции может быть моментальным, но это не означает, что использование фреймворков не имеет преимуществ.

Фреймворки предоставляют готовые решения для различных задач и позволяют быстрее и эффективнее создавать веб-приложения. Так и плюс ко всему, фреймворки обеспечивают более структурированный и поддерживаемый код, а также повышают безопасность приложения. 

Я вот тут себе захотел развернуть на vps вебморду для chatgpt, поискал на гитхабе, нашел готовое решение на js... 1.5гб зависимостей + еще firebase на столько же. Я не против vue и фреймворков как таковых, но такие размеры это уже перебор, js в целом в них погряз. По скрину - 840кб, что бы сделать ничего. То есть ты нечего ничего не написал, а оно уже весит больше, чем все картинки со среднестатистической странички

Подвязывайте с жпт

Зачем пользоваться если не надо? Выбор это всегда хорошо.

Отличная статья!

Не пробовали использовать esbuild? Возможно он будет быстрее Vite

Спасибо большое! С Esbuild не работал, но наслышан о нем, нужно будет как-нибудь его попробовать

Vite под капотом использует Esbuild для дев сервера и rollup для продакшена. Именно по причине использования Esbuild он быстрее. Обратная сторона медали - потенциальная возможность багов в продакшене, т.к. отладка и сборка разными утилитами.

Ммм, как прекрасны миры, где и проект небольшой и одно приложение, а не виджеты вставляемые шаблонизатором рельс/ларки и js`ом и человеко-часы бесконечные

Сегодня пол дня искал альтернативу конструкции require("...") для приложений Vie на Vite. Так и не нашёл. Какие-то странные вещи, громоздкие и неудобные конструкции с import и new URL().

В старых приложениях во многих местах шаблонов используются динамические пути для вставки иконок и т.д. изображений через require() внутри циклов.

Пример:

<img :src="`@/images/icons/${iconType}.png`"

>

Sign up to leave a comment.

Articles