Поэтому не стоит делать из языка элитарное сообщество, ограниченное трехметровым порогом входа. Не забывайте, что есть ряд людей, которые не пишут фуллтайм на JS, но им приходится с ним работать.
IDE многое пропускают и они могут быть разные. В моей команде, например, используется минимум 3 различных IDE/текстовых редакторов и нам приходится использовать инструменты jshint + jscs + editorconfig + csscomb, чтобы уровнять редакторы.
У многих IDE, конечно, есть интеграция с jshint, но он отловит только часть проблем, да и ничего не мешает забыть/не заметить/проигнорировать замечание IDE.
Я предпочитаю максимально минимизировать потенциальную проблему всеми возможными средствами. С текущим workflow это прекрасно получается. За последний год я не видел ни одного комента вида «а ты тут пробел забыл».
Зато избавляют от кучи треш-коментов вида «а ты тут пробел забыл» и позволяет полностью сосредоточиться на чтении и понимании кода и внесении значимых корректировок. Функциональные особенности это уже не Code-Style, IMO ;)
Кстати, с одной стороны песочница это крутая штука, но она может превратиться в большой слой бюрократии если постоянно все везде ограничивать. Те когда нужно получать какие-то новые данные приложения приходится добавить этот модуль в песочницу, а потом вызвать его в Модуле. Похоже на антипаттерн Павлик Морозов.
В свою очередь интерфейс CommonJS модулей так же является своеобразной песочницей и эта песочница положительно сказывается на качестве продукта и не вставляет палок в колеса.
Веб Компоненты могут убрать эту фрагментированность: все компоненты будут совместимы друг с другом, потому что это будет просто HTML.
Я согласен, что они будут работать. Однако вы не будете использовать компоненты написанные на «чужом языке» и сделанные «чужим инструментом» потому как эти компоненты могут тянуть какие-то тяжелые зависимости (платформу), вы не будете понимать как они устроены и напишете свой. Да они будут скомпилированы в CSS, HTML и JS но сорцы их будут на Stylus, Jade и например TypеScript с примесью React.
Сегодня WebComponents это buzzword как раньше был HTML5. Это прекрасная идея кастомного HTML элемента (которая существовала с эпохи Web 2.0) и несколько API, которые делают жизнь чуть-чуть проще. Я думаю, что для вас не секрет, что каждый первый web-UI-движок так или иначе позволяет создавать такой элемент, что BEM Tools, что React, что jQueryUI. Совсем другое дело это какой интерфейс будет на выходе и на сколько сложно в него вникнуть.
Не думаю, что тут стоит употреблять «закостылять». Сегодня эти «костыли» помогают создавать приложения под все платформы, позволяют писать компоненты, которые можно реиспользовать в рамках ваших договоренностей. Просто нужно их понять как и любой другой API в том числе Web Components.
Я считаю, что утверждение «стандарт построения кастомного HTML элемента спасет мир» — это миф. Опять будет тасяча галерей, просто написанных на WebComponents API. И, я уверен, что вы напишете свою потому как чужие галереи несут такой невероятные оверхэд по количеству поддерживаемых фичей из-за того, что их создатель не понимает KISS.
«Прописал импорт компоненты с CDN и вуаля» — так не будет. Мы и через 10 лет будем пытаться сокращать количество запросов. Как обычно скачаем все компоненты и будем использовать инструменты для сборки этих компонент.
Shadow DOM и Scoped CSS поможет избежать конфликтов «Встраиваемым приложениям» (Disqus например). В прочем, мы можем и так можем свести количество конфликтов к 0, используя кастомные теги (как делают API Яндекс Карт) и методологию BEM.
W3C молодцы, что выделили эту часть HTML5 в отдельное понятие Web Components. По крайней мере теперь разработчики будут копаться в этом слове (Components) и начнут осознавать, что жирные библиотеки вроде jQuery нужно заменять маленькими компонентами(модулями), которые будут использоваться на 100%.
Начните пользоваться Компонентами (без Web-) и начните забывать слово Библиотека, например, попробуйте выкинуть jQuery и заменить его на что-то более изящное.
на сервере MVC может быть только если у нас пользовательский интерфейс полностью реализован на сервере, т.е. нет браузерного кода, интерфейс генерируется на сервере, а браузер просто показывает его.
V будет, но мнимая. Должен же кто-то словари и массивы отрисовать в JSON ;)
Есть еще одна библиотека — debug (npm debug). Ее очень удобно использовать как в процессе написания библиотек, так и для логирования. Она не имеет привычных уровней логирования, вместо этого вводятся id типа логов, кооторые можно гибко включать, используя wildcard.
var debug = require('debug')('worker');
setInterval(function(){
debug('doing some work');
}, 1000);
Это так называемое 2.5D С одного кадра такое автоматически сделать сложно. Софт по кадру не сможет построить правильную глубину. Руками это делается не так долго.
!!x— читается как магия;Boolean(x)— все понятно ;)У многих IDE, конечно, есть интеграция с jshint, но он отловит только часть проблем, да и ничего не мешает забыть/не заметить/проигнорировать замечание IDE.
Я предпочитаю максимально минимизировать потенциальную проблему всеми возможными средствами. С текущим workflow это прекрасно получается. За последний год я не видел ни одного комента вида «а ты тут пробел забыл».
В свою очередь интерфейс CommonJS модулей так же является своеобразной песочницей и эта песочница положительно сказывается на качестве продукта и не вставляет палок в колеса.
Не думаю, что тут стоит употреблять «закостылять». Сегодня эти «костыли» помогают создавать приложения под все платформы, позволяют писать компоненты, которые можно реиспользовать в рамках ваших договоренностей. Просто нужно их понять как и любой другой API в том числе Web Components.
Я считаю, что утверждение «стандарт построения кастомного HTML элемента спасет мир» — это миф. Опять будет тасяча галерей, просто написанных на WebComponents API. И, я уверен, что вы напишете свою потому как чужие галереи несут такой невероятные оверхэд по количеству поддерживаемых фичей из-за того, что их создатель не понимает KISS.
«Прописал импорт компоненты с CDN и вуаля» — так не будет. Мы и через 10 лет будем пытаться сокращать количество запросов. Как обычно скачаем все компоненты и будем использовать инструменты для сборки этих компонент.
Shadow DOM и Scoped CSS поможет избежать конфликтов «Встраиваемым приложениям» (Disqus например). В прочем, мы можем и так можем свести количество конфликтов к 0, используя кастомные теги (как делают API Яндекс Карт) и методологию BEM.
W3C молодцы, что выделили эту часть HTML5 в отдельное понятие Web Components. По крайней мере теперь разработчики будут копаться в этом слове (Components) и начнут осознавать, что жирные библиотеки вроде jQuery нужно заменять маленькими компонентами(модулями), которые будут использоваться на 100%.
Начните пользоваться Компонентами (без Web-) и начните забывать слово Библиотека, например, попробуйте выкинуть jQuery и заменить его на что-то более изящное.
Рекомендую ;)