Комментарии 11
У меня всё-таки получилось в три раза больше javascript'а. Если не считать папку lib с «моим фреймворком», получается тот же порядок (разницы 20 строк).
recompose-github-ui$ cloc public src
8 text files.
8 unique files.
0 files ignored.
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
CSS 2 21 0 123
JavaScript 5 12 0 120
HTML 1 6 20 17
-------------------------------------------------------------------------------
SUM: 8 39 20 260
-------------------------------------------------------------------------------
vanilla-github-habr$ cloc .
14 text files.
14 unique files.
1 file ignored.
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
JavaScript 12 115 9 358
CSS 1 25 0 67
HTML 1 10 0 53
-------------------------------------------------------------------------------
SUM: 14 150 9 478
-------------------------------------------------------------------------------
Btw, со Svelte вы также не используете никаких зависимостей, кроме браузера)))) В том то и фишка, никакого специфического рантайма, только ещё и код за вас компилятор пишет)))
Так что поддерживаю ваше стремление использовать ванилу, однако позволю себе процитировать Рича Харриса, автора Svelte:
“You can't write serious applications in vanilla JavaScript without hitting a complexity wall. But a compiler can do it for you.”
Пожалуй я с ним согласен в этом.
Спасибо за отзыв.
Мне нравится концепция исчезающих фреймворков, возможно, через какое-то время изучу один из них, возможно, Svelte.
Мне не нравится, что фронтенд-фреймворки это какой-то сплошной хайп, за которым сложно уследить (хотя сейчас устаканилось довольно с реактом/vue/angular). А в итоге мы имеем легаси-проекты на первых ангулярах, потому что раньше это было круто.
Полифилл, да. Для IE11, к сожалению, тоже нужен полифилл, он в конструктор массив не принимает, можно забыть.
Версии фиксируются, а документацию/примеры по старым версиям потом сложно искать.
Я больше боюсь за то, что сборщик может вдруг перестать быть просто сборщиком и начнёт очень сильно влиять на сам код. Вроде влиять на import'ы.
Если мы начинаем писать код, который не может самостоятельно работать в браузере — это уже не javascript, а какой-то собственный язык. Чем мне заниматься не хотелось бы по религиозным причинам. Хотя тут на вкус и цвет.
Спасибо за статью. Замечательный цикл получается :)
Тоже раньше делал небольшую страничку для подтягивания данных о пользователях GitHub с помощью VanillaJS/SCSS. Правда, там много циклов, поэтому работает медленно.
Если кому интересно, пример здесь.
Вы просто для всех репозиториев отдельно запрашиваете topics и только после этого их показываете. Можно было бы сразу показать репозитории и затем уже им добрасывать теги, выглядело бы быстро.
innerHTML += за гранью добра и зла. Вообще, лучше никогда не генерировать HTML руками, ибо можно легко что-нибудь непроэкранировать.
Вот тут, например:
'<p class="repository__description">' + repository.description + '</p>'В description можно положить <script>, например.
topics!Насчёт
innerHTML: я правильно понимаю, что вместо `${something}` корректнее было бы с помощью repositoryElement.appendChild добавлять все элементы, предварительно проверяя каждый из них (например, тот же repository.description)? Если так, как могла бы выполняться проверка/экранирование таких данных?
Как сделать поиск пользователей по Github используя VanillaJS